--- /dev/null
+From wse@tuxedocomputers.com Thu Oct 27 12:25:48 2022
+From: Werner Sembach <wse@tuxedocomputers.com>
+Date: Wed, 26 Oct 2022 17:22:46 +0200
+Subject: [PATCH v3] ACPI: video: Force backlight native for more TongFang devices
+To: stable@vger.kernel.org
+Cc: hdegoede@redhat.com, daniel@ffwll.ch, airlied@redhat.com, lenb@kernel.org, rafael.j.wysocki@intel.com
+Message-ID: <20221026152246.24990-1-wse@tuxedocomputers.com>
+
+From: Werner Sembach <wse@tuxedocomputers.com>
+
+commit 3dbc80a3e4c55c4a5b89ef207bed7b7de36157b4 upstream.
+
+This commit is very different from the upstream commit! It fixes the same
+issue by adding more quirks, rather then the general fix from the 6.1
+kernel, because the general fix from the 6.1 kernel is part of a larger
+refactoring of the backlight code which is not suitable for the stable
+series.
+
+As described in "ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U??
+acpi_backlight=native quirks" (10212754a0d2) the upstream commit "ACPI:
+video: Make backlight class device registration a separate step (v2)"
+(3dbc80a3e4c5) makes these quirks unnecessary. However as mentioned in this
+bugtracker ticket https://bugzilla.kernel.org/show_bug.cgi?id=215683#c17
+the upstream fix is part of a larger patchset that is overall too complex
+for stable.
+
+The TongFang GKxNRxx, GMxNGxx, GMxZGxx, and GMxRGxx / TUXEDO
+Stellaris/Polaris Gen 1-4, have the same problem as the Clevo NL5xRU and
+NL5xNU / TUXEDO Aura 15 Gen1 and Gen2:
+They have a working native and video interface for screen backlight.
+However the default detection mechanism first registers the video interface
+before unregistering it again and switching to the native interface during
+boot. This results in a dangling SBIOS request for backlight change for
+some reason, causing the backlight to switch to ~2% once per boot on the
+first power cord connect or disconnect event. Setting the native interface
+explicitly circumvents this buggy behaviour by avoiding the unregistering
+process.
+
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/video_detect.c | 64 ++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 64 insertions(+)
+
+--- a/drivers/acpi/video_detect.c
++++ b/drivers/acpi/video_detect.c
+@@ -501,6 +501,70 @@ static const struct dmi_system_id video_
+ },
+ },
+ /*
++ * More Tongfang devices with the same issue as the Clevo NL5xRU and
++ * NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description above.
++ */
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GKxNRxx",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GKxNRxx"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GKxNRxx",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
++ DMI_MATCH(DMI_BOARD_NAME, "POLARIS1501A1650TI"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GKxNRxx",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
++ DMI_MATCH(DMI_BOARD_NAME, "POLARIS1501A2060"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GKxNRxx",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
++ DMI_MATCH(DMI_BOARD_NAME, "POLARIS1701A1650TI"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GKxNRxx",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
++ DMI_MATCH(DMI_BOARD_NAME, "POLARIS1701A2060"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GMxNGxx",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GMxNGxx"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GMxZGxx",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GMxZGxx"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang GMxRGxx",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GMxRGxx"),
++ },
++ },
++ /*
+ * Desktops which falsely report a backlight and which our heuristics
+ * for this do not catch.
+ */
--- /dev/null
+From 365e1ececb2905f94cc10a5817c5b644a32a3ae2 Mon Sep 17 00:00:00 2001
+From: Gaurav Kohli <gauravkohli@linux.microsoft.com>
+Date: Wed, 5 Oct 2022 22:52:59 -0700
+Subject: hv_netvsc: Fix race between VF offering and VF association message from host
+
+From: Gaurav Kohli <gauravkohli@linux.microsoft.com>
+
+commit 365e1ececb2905f94cc10a5817c5b644a32a3ae2 upstream.
+
+During vm boot, there might be possibility that vf registration
+call comes before the vf association from host to vm.
+
+And this might break netvsc vf path, To prevent the same block
+vf registration until vf bind message comes from host.
+
+Cc: stable@vger.kernel.org
+Fixes: 00d7ddba11436 ("hv_netvsc: pair VF based on serial number")
+Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
+Signed-off-by: Gaurav Kohli <gauravkohli@linux.microsoft.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/hyperv/hyperv_net.h | 3 ++-
+ drivers/net/hyperv/netvsc.c | 4 ++++
+ drivers/net/hyperv/netvsc_drv.c | 20 ++++++++++++++++++++
+ 3 files changed, 26 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/hyperv/hyperv_net.h
++++ b/drivers/net/hyperv/hyperv_net.h
+@@ -977,7 +977,8 @@ struct net_device_context {
+ u32 vf_alloc;
+ /* Serial number of the VF to team with */
+ u32 vf_serial;
+-
++ /* completion variable to confirm vf association */
++ struct completion vf_add;
+ /* Is the current data path through the VF NIC? */
+ bool data_path_is_vf;
+
+--- a/drivers/net/hyperv/netvsc.c
++++ b/drivers/net/hyperv/netvsc.c
+@@ -1327,6 +1327,10 @@ static void netvsc_send_vf(struct net_de
+
+ net_device_ctx->vf_alloc = nvmsg->msg.v4_msg.vf_assoc.allocated;
+ net_device_ctx->vf_serial = nvmsg->msg.v4_msg.vf_assoc.serial;
++
++ if (net_device_ctx->vf_alloc)
++ complete(&net_device_ctx->vf_add);
++
+ netdev_info(ndev, "VF slot %u %s\n",
+ net_device_ctx->vf_serial,
+ net_device_ctx->vf_alloc ? "added" : "removed");
+--- a/drivers/net/hyperv/netvsc_drv.c
++++ b/drivers/net/hyperv/netvsc_drv.c
+@@ -2290,6 +2290,7 @@ static struct net_device *get_netvsc_bys
+ {
+ struct device *parent = vf_netdev->dev.parent;
+ struct net_device_context *ndev_ctx;
++ struct net_device *ndev;
+ struct pci_dev *pdev;
+ u32 serial;
+
+@@ -2316,6 +2317,18 @@ static struct net_device *get_netvsc_bys
+ return hv_get_drvdata(ndev_ctx->device_ctx);
+ }
+
++ /* Fallback path to check synthetic vf with
++ * help of mac addr
++ */
++ list_for_each_entry(ndev_ctx, &netvsc_dev_list, list) {
++ ndev = hv_get_drvdata(ndev_ctx->device_ctx);
++ if (ether_addr_equal(vf_netdev->perm_addr, ndev->perm_addr)) {
++ netdev_notice(vf_netdev,
++ "falling back to mac addr based matching\n");
++ return ndev;
++ }
++ }
++
+ netdev_notice(vf_netdev,
+ "no netdev found for vf serial:%u\n", serial);
+ return NULL;
+@@ -2406,6 +2419,11 @@ static int netvsc_vf_changed(struct net_
+ return NOTIFY_OK;
+ net_device_ctx->data_path_is_vf = vf_is_up;
+
++ if (vf_is_up && !net_device_ctx->vf_alloc) {
++ netdev_info(ndev, "Waiting for the VF association from host\n");
++ wait_for_completion(&net_device_ctx->vf_add);
++ }
++
+ netvsc_switch_datapath(ndev, vf_is_up);
+ netdev_info(ndev, "Data path switched %s VF: %s\n",
+ vf_is_up ? "to" : "from", vf_netdev->name);
+@@ -2429,6 +2447,7 @@ static int netvsc_unregister_vf(struct n
+
+ netvsc_vf_setxdp(vf_netdev, NULL);
+
++ reinit_completion(&net_device_ctx->vf_add);
+ netdev_rx_handler_unregister(vf_netdev);
+ netdev_upper_dev_unlink(vf_netdev, ndev);
+ RCU_INIT_POINTER(net_device_ctx->vf_netdev, NULL);
+@@ -2466,6 +2485,7 @@ static int netvsc_probe(struct hv_device
+
+ INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
+
++ init_completion(&net_device_ctx->vf_add);
+ spin_lock_init(&net_device_ctx->lock);
+ INIT_LIST_HEAD(&net_device_ctx->reconfig_events);
+ INIT_DELAYED_WORK(&net_device_ctx->vf_takeover, netvsc_vf_setup);
--- /dev/null
+From foo@baz Thu Oct 27 12:32:05 PM CEST 2022
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Mon, 24 Oct 2022 13:34:14 -0700
+Subject: Makefile.debug: re-enable debug info for .S files
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+This is _not_ an upstream commit and just for 5.10.y only. It is based
+on commit 32ef9e5054ec0321b9336058c58ec749e9c6b0fe upstream.
+
+Alexey reported that the fraction of unknown filename instances in
+kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down
+to assembler defined symbols, which regressed as a result of:
+
+commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1")
+
+In that commit, I allude to restoring debug info for assembler defined
+symbols in a follow up patch, but it seems I forgot to do so in
+
+commit a66049e2cf0e ("Kbuild: make DWARF version a choice")
+
+Fixes: b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1")
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Makefile | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/Makefile
++++ b/Makefile
+@@ -842,7 +842,9 @@ else
+ DEBUG_CFLAGS += -g
+ endif
+
+-ifneq ($(LLVM_IAS),1)
++ifeq ($(LLVM_IAS),1)
++KBUILD_AFLAGS += -g
++else
+ KBUILD_AFLAGS += -Wa,-gdwarf-2
+ endif
+
--- /dev/null
+From c243cecb58e3905baeace8827201c14df8481e2a Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 31 Jan 2022 09:24:49 +0200
+Subject: perf/x86/intel/pt: Relax address filter validation
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit c243cecb58e3905baeace8827201c14df8481e2a upstream.
+
+The requirement for 64-bit address filters is that they are canonical
+addresses. In other respects any address range is allowed which would
+include user space addresses.
+
+That can be useful for tracing virtual machine guests because address
+filtering can be used to advantage in place of current privilege level
+(CPL) filtering.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lore.kernel.org/r/20220131072453.2839535-2-adrian.hunter@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/intel/pt.c | 63 +++++++++++++++++++++++++++++++++++----------
+ 1 file changed, 50 insertions(+), 13 deletions(-)
+
+--- a/arch/x86/events/intel/pt.c
++++ b/arch/x86/events/intel/pt.c
+@@ -13,6 +13,8 @@
+ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+ #include <linux/types.h>
++#include <linux/bits.h>
++#include <linux/limits.h>
+ #include <linux/slab.h>
+ #include <linux/device.h>
+
+@@ -1348,11 +1350,37 @@ static void pt_addr_filters_fini(struct
+ event->hw.addr_filters = NULL;
+ }
+
+-static inline bool valid_kernel_ip(unsigned long ip)
++#ifdef CONFIG_X86_64
++static u64 canonical_address(u64 vaddr, u8 vaddr_bits)
+ {
+- return virt_addr_valid(ip) && kernel_ip(ip);
++ return ((s64)vaddr << (64 - vaddr_bits)) >> (64 - vaddr_bits);
+ }
+
++static u64 is_canonical_address(u64 vaddr, u8 vaddr_bits)
++{
++ return canonical_address(vaddr, vaddr_bits) == vaddr;
++}
++
++/* Clamp to a canonical address greater-than-or-equal-to the address given */
++static u64 clamp_to_ge_canonical_addr(u64 vaddr, u8 vaddr_bits)
++{
++ return is_canonical_address(vaddr, vaddr_bits) ?
++ vaddr :
++ -BIT_ULL(vaddr_bits - 1);
++}
++
++/* Clamp to a canonical address less-than-or-equal-to the address given */
++static u64 clamp_to_le_canonical_addr(u64 vaddr, u8 vaddr_bits)
++{
++ return is_canonical_address(vaddr, vaddr_bits) ?
++ vaddr :
++ BIT_ULL(vaddr_bits - 1) - 1;
++}
++#else
++#define clamp_to_ge_canonical_addr(x, y) (x)
++#define clamp_to_le_canonical_addr(x, y) (x)
++#endif
++
+ static int pt_event_addr_filters_validate(struct list_head *filters)
+ {
+ struct perf_addr_filter *filter;
+@@ -1367,14 +1395,6 @@ static int pt_event_addr_filters_validat
+ filter->action == PERF_ADDR_FILTER_ACTION_START)
+ return -EOPNOTSUPP;
+
+- if (!filter->path.dentry) {
+- if (!valid_kernel_ip(filter->offset))
+- return -EINVAL;
+-
+- if (!valid_kernel_ip(filter->offset + filter->size))
+- return -EINVAL;
+- }
+-
+ if (++range > intel_pt_validate_hw_cap(PT_CAP_num_address_ranges))
+ return -EOPNOTSUPP;
+ }
+@@ -1398,9 +1418,26 @@ static void pt_event_addr_filters_sync(s
+ if (filter->path.dentry && !fr[range].start) {
+ msr_a = msr_b = 0;
+ } else {
+- /* apply the offset */
+- msr_a = fr[range].start;
+- msr_b = msr_a + fr[range].size - 1;
++ unsigned long n = fr[range].size - 1;
++ unsigned long a = fr[range].start;
++ unsigned long b;
++
++ if (a > ULONG_MAX - n)
++ b = ULONG_MAX;
++ else
++ b = a + n;
++ /*
++ * Apply the offset. 64-bit addresses written to the
++ * MSRs must be canonical, but the range can encompass
++ * non-canonical addresses. Since software cannot
++ * execute at non-canonical addresses, adjusting to
++ * canonical addresses does not affect the result of the
++ * address filter.
++ */
++ msr_a = clamp_to_ge_canonical_addr(a, boot_cpu_data.x86_virt_bits);
++ msr_b = clamp_to_le_canonical_addr(b, boot_cpu_data.x86_virt_bits);
++ if (msr_b < msr_a)
++ msr_a = msr_b = 0;
+ }
+
+ filters->filter[range].msr_a = msr_a;
arm64-dts-qcom-sc7180-trogdor-fixup-modem-memory-region.patch
arm64-topology-move-store_cpu_topology-to-shared-code.patch
riscv-topology-fix-default-topology-reporting.patch
+perf-x86-intel-pt-relax-address-filter-validation.patch
+hv_netvsc-fix-race-between-vf-offering-and-vf-association-message-from-host.patch
+acpi-video-force-backlight-native-for-more-tongfang-devices.patch
+x86-kconfig-drop-check-for-mabi-ms-for-config_efi_stub.patch
+makefile.debug-re-enable-debug-info-for-.s-files.patch
--- /dev/null
+From 33806e7cb8d50379f55c3e8f335e91e1b359dc7b Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Thu, 29 Sep 2022 08:20:10 -0700
+Subject: x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 33806e7cb8d50379f55c3e8f335e91e1b359dc7b upstream.
+
+A recent change in LLVM made CONFIG_EFI_STUB unselectable because it no
+longer pretends to support -mabi=ms, breaking the dependency in
+Kconfig. Lack of CONFIG_EFI_STUB can prevent kernels from booting via
+EFI in certain circumstances.
+
+This check was added by
+
+ 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")
+
+to ensure that __attribute__((ms_abi)) was available, as -mabi=ms is
+not actually used in any cflags.
+
+According to the GCC documentation, this attribute has been supported
+since GCC 4.4.7. The kernel currently requires GCC 5.1 so this check is
+not necessary; even when that change landed in 5.6, the kernel required
+GCC 4.9 so it was unnecessary then as well.
+
+Clang supports __attribute__((ms_abi)) for all versions that are
+supported for building the kernel so no additional check is needed.
+Remove the 'depends on' line altogether to allow CONFIG_EFI_STUB to be
+selected when CONFIG_EFI is enabled, regardless of compiler.
+
+Fixes: 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Acked-by: Ard Biesheuvel <ardb@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://github.com/llvm/llvm-project/commit/d1ad006a8f64bdc17f618deffa9e7c91d82c444d
+[nathan: Fix conflict due to lack of c6dbd3e5e69c in older trees]
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/Kconfig | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -1945,7 +1945,6 @@ config EFI
+ config EFI_STUB
+ bool "EFI stub support"
+ depends on EFI && !X86_USE_3DNOW
+- depends on $(cc-option,-mabi=ms) || X86_32
+ select RELOCATABLE
+ help
+ This kernel feature allows a bzImage to be loaded directly
projects / thirdparty / kernel / stable-queue.git / commitdiff
