--- /dev/null
+From 963e22c084c2b6097e1e635d29c6336881f67708 Mon Sep 17 00:00:00 2001
+From: Armin Wolf <W_Armin@gmx.de>
+Date: Tue, 29 Jul 2025 08:20:38 +0200
+Subject: ACPI: EC: Relax sanity check of the ECDT ID string
+
+From: Armin Wolf <W_Armin@gmx.de>
+
+commit 963e22c084c2b6097e1e635d29c6336881f67708 upstream.
+
+It turns out that the ECDT table inside the ThinkBook 14 G7 IML
+contains a valid EC description but an invalid ID string
+("_SB.PC00.LPCB.EC0"). Ignoring this ECDT based on the invalid
+ID string prevents the kernel from detecting the built-in touchpad,
+so relax the sanity check of the ID string and only reject ECDTs
+with empty ID strings.
+
+Reported-by: Ilya K <me@0upti.me>
+Fixes: 7a0d59f6a913 ("ACPI: EC: Ignore ECDT tables with an invalid ID string")
+Signed-off-by: Armin Wolf <W_Armin@gmx.de>
+Tested-by: Ilya K <me@0upti.me>
+Link: https://patch.msgid.link/20250729062038.303734-1-W_Armin@gmx.de
+Cc: 6.16+ <stable@vger.kernel.org> # 6.16+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/ec.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
+index 75c7db8b156a..7855bbf752b1 100644
+--- a/drivers/acpi/ec.c
++++ b/drivers/acpi/ec.c
+@@ -2033,7 +2033,7 @@ void __init acpi_ec_ecdt_probe(void)
+ goto out;
+ }
+
+- if (!strstarts(ecdt_ptr->id, "\\")) {
++ if (!strlen(ecdt_ptr->id)) {
+ /*
+ * The ECDT table on some MSI notebooks contains invalid data, together
+ * with an empty ID string ("").
+@@ -2042,9 +2042,13 @@ void __init acpi_ec_ecdt_probe(void)
+ * a "fully qualified reference to the (...) embedded controller device",
+ * so this string always has to start with a backslash.
+ *
+- * By verifying this we can avoid such faulty ECDT tables in a safe way.
++ * However some ThinkBook machines have a ECDT table with a valid EC
++ * description but an invalid ID string ("_SB.PC00.LPCB.EC0").
++ *
++ * Because of this we only check if the ID string is empty in order to
++ * avoid the obvious cases.
+ */
+- pr_err(FW_BUG "Ignoring ECDT due to invalid ID string \"%s\"\n", ecdt_ptr->id);
++ pr_err(FW_BUG "Ignoring ECDT due to empty ID string\n");
+ goto out;
+ }
+
+--
+2.50.1
+
--- /dev/null
+From d33bd88ac0ebb49e7f7c8f29a8c7ee9eae85d765 Mon Sep 17 00:00:00 2001
+From: Jiayi Li <lijiayi@kylinos.cn>
+Date: Mon, 21 Jul 2025 11:26:06 +0800
+Subject: ACPI: processor: perflib: Fix initial _PPC limit application
+
+From: Jiayi Li <lijiayi@kylinos.cn>
+
+commit d33bd88ac0ebb49e7f7c8f29a8c7ee9eae85d765 upstream.
+
+If the BIOS sets a _PPC frequency limit upfront, it will fail to take
+effect due to a call ordering issue. Namely, freq_qos_update_request()
+is called before freq_qos_add_request() for the given request causing
+the constraint update to be ignored. The call sequence in question is
+as follows:
+
+cpufreq_policy_online()
+ acpi_cpufreq_cpu_init()
+ acpi_processor_register_performance()
+ acpi_processor_get_performance_info()
+ acpi_processor_get_platform_limit()
+ freq_qos_update_request(&perflib_req) <- inactive QoS request
+ blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
+ CPUFREQ_CREATE_POLICY)
+ acpi_processor_notifier()
+ acpi_processor_ppc_init()
+ freq_qos_add_request(&perflib_req) <- QoS request activation
+
+Address this by adding an acpi_processor_get_platform_limit() call
+to acpi_processor_ppc_init(), after the perflib_req activation via
+freq_qos_add_request(), which causes the initial _PPC limit to be
+picked up as appropriate. However, also ensure that the _PPC limit
+will not be picked up in the cases when the cpufreq driver does not
+call acpi_processor_register_performance() by adding a pr->performance
+check to the related_cpus loop in acpi_processor_ppc_init().
+
+Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
+Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
+Link: https://patch.msgid.link/20250721032606.3459369-1-lijiayi@kylinos.cn
+[ rjw: Consolidate pr-related checks in acpi_processor_ppc_init() ]
+[ rjw: Subject and changelog adjustments ]
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+: 2d8b39a62a5d ACPI: processor: Avoid NULL pointer dereferences at init time
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+: 3000ce3c52f8 cpufreq: Use per-policy frequency QoS
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+: a1bb46c36ce3 ACPI: processor: Add QoS requests for all CPUs
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/processor_perflib.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/acpi/processor_perflib.c
++++ b/drivers/acpi/processor_perflib.c
+@@ -173,11 +173,14 @@ void acpi_processor_ppc_init(struct cpuf
+ {
+ unsigned int cpu;
+
++ if (ignore_ppc == 1)
++ return;
++
+ for_each_cpu(cpu, policy->related_cpus) {
+ struct acpi_processor *pr = per_cpu(processors, cpu);
+ int ret;
+
+- if (!pr)
++ if (!pr || !pr->performance)
+ continue;
+
+ /*
+@@ -193,6 +196,11 @@ void acpi_processor_ppc_init(struct cpuf
+ if (ret < 0)
+ pr_err("Failed to add freq constraint for CPU%d (%d)\n",
+ cpu, ret);
++
++ ret = acpi_processor_get_platform_limit(pr);
++ if (ret)
++ pr_err("Failed to update freq constraint for CPU%d (%d)\n",
++ cpu, ret);
+ }
+ }
+
--- /dev/null
+From d405ec23df13e6df599f5bd965a55d13420366b8 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Tue, 12 Aug 2025 14:57:06 +0200
+Subject: ACPI: processor: perflib: Move problematic pr->performance check
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit d405ec23df13e6df599f5bd965a55d13420366b8 upstream.
+
+Commit d33bd88ac0eb ("ACPI: processor: perflib: Fix initial _PPC limit
+application") added a pr->performance check that prevents the frequency
+QoS request from being added when the given processor has no performance
+object. Unfortunately, this causes a WARN() in freq_qos_remove_request()
+to trigger on an attempt to take the given CPU offline later because the
+frequency QoS object has not been added for it due to the missing
+performance object.
+
+Address this by moving the pr->performance check before calling
+acpi_processor_get_platform_limit() so it only prevents a limit from
+being set for the CPU if the performance object is not present. This
+way, the frequency QoS request is added as it was before the above
+commit and it is present all the time along with the CPU's cpufreq
+policy regardless of whether or not the CPU is online.
+
+Fixes: d33bd88ac0eb ("ACPI: processor: perflib: Fix initial _PPC limit application")
+Tested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Link: https://patch.msgid.link/2801421.mvXUDI8C0e@rafael.j.wysocki
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/processor_perflib.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/acpi/processor_perflib.c
++++ b/drivers/acpi/processor_perflib.c
+@@ -180,7 +180,7 @@ void acpi_processor_ppc_init(struct cpuf
+ struct acpi_processor *pr = per_cpu(processors, cpu);
+ int ret;
+
+- if (!pr || !pr->performance)
++ if (!pr)
+ continue;
+
+ /*
+@@ -197,6 +197,9 @@ void acpi_processor_ppc_init(struct cpuf
+ pr_err("Failed to add freq constraint for CPU%d (%d)\n",
+ cpu, ret);
+
++ if (!pr->performance)
++ continue;
++
+ ret = acpi_processor_get_platform_limit(pr);
+ if (ret)
+ pr_err("Failed to update freq constraint for CPU%d (%d)\n",
--- /dev/null
+From 3f66ccbaaef3a0c5bd844eab04e3207b4061c546 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Wed, 25 Jun 2025 18:33:23 +0900
+Subject: block: Make REQ_OP_ZONE_FINISH a write operation
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 3f66ccbaaef3a0c5bd844eab04e3207b4061c546 upstream.
+
+REQ_OP_ZONE_FINISH is defined as "12", which makes
+op_is_write(REQ_OP_ZONE_FINISH) return false, despite the fact that a
+zone finish operation is an operation that modifies a zone (transition
+it to full) and so should be considered as a write operation (albeit
+one that does not transfer any data to the device).
+
+Fix this by redefining REQ_OP_ZONE_FINISH to be an odd number (13), and
+redefine REQ_OP_ZONE_RESET and REQ_OP_ZONE_RESET_ALL using sequential
+odd numbers from that new value.
+
+Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20250625093327.548866-2-dlemoal@kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/blk_types.h | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/include/linux/blk_types.h
++++ b/include/linux/blk_types.h
+@@ -350,11 +350,11 @@ enum req_op {
+ /* Close a zone */
+ REQ_OP_ZONE_CLOSE = (__force blk_opf_t)11,
+ /* Transition a zone to full */
+- REQ_OP_ZONE_FINISH = (__force blk_opf_t)12,
++ REQ_OP_ZONE_FINISH = (__force blk_opf_t)13,
+ /* reset a zone write pointer */
+- REQ_OP_ZONE_RESET = (__force blk_opf_t)13,
++ REQ_OP_ZONE_RESET = (__force blk_opf_t)15,
+ /* reset all the zone present on the device */
+- REQ_OP_ZONE_RESET_ALL = (__force blk_opf_t)15,
++ REQ_OP_ZONE_RESET_ALL = (__force blk_opf_t)17,
+
+ /* Driver private requests */
+ REQ_OP_DRV_IN = (__force blk_opf_t)34,
--- /dev/null
+From e65cb011349e653ded541dddd6469c2ca813edcf Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Thu, 10 Jul 2025 20:00:23 +0300
+Subject: Documentation: ACPI: Fix parent device references
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit e65cb011349e653ded541dddd6469c2ca813edcf upstream.
+
+The _CRS resources in many cases want to have ResourceSource field
+to be a type of ACPI String. This means that to compile properly
+we need to enclosure the name path into double quotes. This will
+in practice defer the interpretation to a run-time stage, However,
+this may be interpreted differently on different OSes and ACPI
+interpreter implementations. In particular ACPICA might not correctly
+recognize the leading '^' (caret) character and will not resolve
+the relative name path properly. On top of that, this piece may be
+used in SSDTs which are loaded after the DSDT and on itself may also
+not resolve relative name paths outside of their own scopes.
+With this all said, fix documentation to use fully-qualified name
+paths always to avoid any misinterpretations, which is proven to
+work.
+
+Fixes: 8eb5c87a92c0 ("i2c: add ACPI support for I2C mux ports")
+Reported-by: Yevhen Kondrashyn <e.kondrashyn@gmail.com>
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://patch.msgid.link/20250710170225.961303-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/firmware-guide/acpi/i2c-muxes.rst | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/Documentation/firmware-guide/acpi/i2c-muxes.rst
++++ b/Documentation/firmware-guide/acpi/i2c-muxes.rst
+@@ -14,7 +14,7 @@ Consider this topology::
+ | | | 0x70 |--CH01--> i2c client B (0x50)
+ +------+ +------+
+
+-which corresponds to the following ASL::
++which corresponds to the following ASL (in the scope of \_SB)::
+
+ Device (SMB1)
+ {
+@@ -24,7 +24,7 @@ which corresponds to the following ASL::
+ Name (_HID, ...)
+ Name (_CRS, ResourceTemplate () {
+ I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
+- AddressingMode7Bit, "^SMB1", 0x00,
++ AddressingMode7Bit, "\\_SB.SMB1", 0x00,
+ ResourceConsumer,,)
+ }
+
+@@ -37,7 +37,7 @@ which corresponds to the following ASL::
+ Name (_HID, ...)
+ Name (_CRS, ResourceTemplate () {
+ I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
+- AddressingMode7Bit, "^CH00", 0x00,
++ AddressingMode7Bit, "\\_SB.SMB1.CH00", 0x00,
+ ResourceConsumer,,)
+ }
+ }
+@@ -52,7 +52,7 @@ which corresponds to the following ASL::
+ Name (_HID, ...)
+ Name (_CRS, ResourceTemplate () {
+ I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
+- AddressingMode7Bit, "^CH01", 0x00,
++ AddressingMode7Bit, "\\_SB.SMB1.CH01", 0x00,
+ ResourceConsumer,,)
+ }
+ }
--- /dev/null
+From cce35103135c7ffc7bebc32ebfc74fe1f2c3cb5d Mon Sep 17 00:00:00 2001
+From: Li Zhijian <lizhijian@fujitsu.com>
+Date: Tue, 10 Jun 2025 14:27:51 +0800
+Subject: mm/memory-tier: fix abstract distance calculation overflow
+
+From: Li Zhijian <lizhijian@fujitsu.com>
+
+commit cce35103135c7ffc7bebc32ebfc74fe1f2c3cb5d upstream.
+
+In mt_perf_to_adistance(), the calculation of abstract distance (adist)
+involves multiplying several int values including
+MEMTIER_ADISTANCE_DRAM.
+
+*adist = MEMTIER_ADISTANCE_DRAM *
+ (perf->read_latency + perf->write_latency) /
+ (default_dram_perf.read_latency + default_dram_perf.write_latency) *
+ (default_dram_perf.read_bandwidth + default_dram_perf.write_bandwidth) /
+ (perf->read_bandwidth + perf->write_bandwidth);
+
+Since these values can be large, the multiplication may exceed the
+maximum value of an int (INT_MAX) and overflow (Our platform did),
+leading to an incorrect adist.
+
+User-visible impact:
+The memory tiering subsystem will misinterpret slow memory (like CXL)
+as faster than DRAM, causing inappropriate demotion of pages from
+CXL (slow memory) to DRAM (fast memory).
+
+For example, we will see the following demotion chains from the dmesg, where
+Node0,1 are DRAM, and Node2,3 are CXL node:
+ Demotion targets for Node 0: null
+ Demotion targets for Node 1: null
+ Demotion targets for Node 2: preferred: 0-1, fallback: 0-1
+ Demotion targets for Node 3: preferred: 0-1, fallback: 0-1
+
+Change MEMTIER_ADISTANCE_DRAM to be a long constant by writing it with
+the 'L' suffix. This prevents the overflow because the multiplication
+will then be done in the long type which has a larger range.
+
+Link: https://lkml.kernel.org/r/20250611023439.2845785-1-lizhijian@fujitsu.com
+Link: https://lkml.kernel.org/r/20250610062751.2365436-1-lizhijian@fujitsu.com
+Fixes: 3718c02dbd4c ("acpi, hmat: calculate abstract distance with HMAT")
+Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
+Reviewed-by: Huang Ying <ying.huang@linux.alibaba.com>
+Acked-by: Balbir Singh <balbirs@nvidia.com>
+Reviewed-by: Donet Tom <donettom@linux.ibm.com>
+Reviewed-by: Oscar Salvador <osalvador@suse.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/memory-tiers.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/memory-tiers.h
++++ b/include/linux/memory-tiers.h
+@@ -18,7 +18,7 @@
+ * adistance value (slightly faster) than default DRAM adistance to be part of
+ * the same memory tier.
+ */
+-#define MEMTIER_ADISTANCE_DRAM ((4 * MEMTIER_CHUNK_SIZE) + (MEMTIER_CHUNK_SIZE >> 1))
++#define MEMTIER_ADISTANCE_DRAM ((4L * MEMTIER_CHUNK_SIZE) + (MEMTIER_CHUNK_SIZE >> 1))
+
+ struct memory_tier;
+ struct memory_dev_type {
--- /dev/null
+From 6cff20ce3b92ffbf2fc5eb9e5a030b3672aa414a Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Sun, 13 Jul 2025 16:31:01 +0200
+Subject: PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable ports
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 6cff20ce3b92ffbf2fc5eb9e5a030b3672aa414a upstream.
+
+pci_bridge_d3_possible() is called from both pcie_portdrv_probe() and
+pcie_portdrv_remove() to determine whether runtime power management shall
+be enabled (on probe) or disabled (on remove) on a PCIe port.
+
+The underlying assumption is that pci_bridge_d3_possible() always returns
+the same value, else a runtime PM reference imbalance would occur. That
+assumption is not given if the PCIe port is inaccessible on remove due to
+hot-unplug: pci_bridge_d3_possible() calls pciehp_is_native(), which
+accesses Config Space to determine whether the port is Hot-Plug Capable.
+An inaccessible port returns "all ones", which is converted to "all
+zeroes" by pcie_capability_read_dword(). Hence the port no longer seems
+Hot-Plug Capable on remove even though it was on probe.
+
+The resulting runtime PM ref imbalance causes warning messages such as:
+
+ pcieport 0000:02:04.0: Runtime PM usage count underflow!
+
+Avoid the Config Space access (and thus the runtime PM ref imbalance) by
+caching the Hot-Plug Capable bit in struct pci_dev.
+
+The struct already contains an "is_hotplug_bridge" flag, which however is
+not only set on Hot-Plug Capable PCIe ports, but also Conventional PCI
+Hot-Plug bridges and ACPI slots. The flag identifies bridges which are
+allocated additional MMIO and bus number resources to allow for hierarchy
+expansion.
+
+The kernel is somewhat sloppily using "is_hotplug_bridge" in a number of
+places to identify Hot-Plug Capable PCIe ports, even though the flag
+encompasses other devices. Subsequent commits replace these occurrences
+with the new flag to clearly delineate Hot-Plug Capable PCIe ports from
+other kinds of hotplug bridges.
+
+Document the existing "is_hotplug_bridge" and the new "is_pciehp" flag
+and document the (non-obvious) requirement that pci_bridge_d3_possible()
+always returns the same value across the entire lifetime of a bridge,
+including its hot-removal.
+
+Fixes: 5352a44a561d ("PCI: pciehp: Make pciehp_is_native() stricter")
+Reported-by: Laurent Bigonville <bigon@bigon.be>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220216
+Reported-by: Mario Limonciello <mario.limonciello@amd.com>
+Closes: https://lore.kernel.org/r/20250609020223.269407-3-superm1@kernel.org/
+Link: https://lore.kernel.org/all/20250620025535.3425049-3-superm1@kernel.org/T/#u
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Rafael J. Wysocki <rafael@kernel.org>
+Cc: stable@vger.kernel.org # v4.18+
+Link: https://patch.msgid.link/fe5dcc3b2e62ee1df7905d746bde161eb1b3291c.1752390101.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci-acpi.c | 4 +---
+ drivers/pci/pci.c | 6 +++++-
+ drivers/pci/probe.c | 2 +-
+ include/linux/pci.h | 6 ++++++
+ 4 files changed, 13 insertions(+), 5 deletions(-)
+
+--- a/drivers/pci/pci-acpi.c
++++ b/drivers/pci/pci-acpi.c
+@@ -816,13 +816,11 @@ int pci_acpi_program_hp_params(struct pc
+ bool pciehp_is_native(struct pci_dev *bridge)
+ {
+ const struct pci_host_bridge *host;
+- u32 slot_cap;
+
+ if (!IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE))
+ return false;
+
+- pcie_capability_read_dword(bridge, PCI_EXP_SLTCAP, &slot_cap);
+- if (!(slot_cap & PCI_EXP_SLTCAP_HPC))
++ if (!bridge->is_pciehp)
+ return false;
+
+ if (pcie_ports_native)
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -3030,8 +3030,12 @@ static const struct dmi_system_id bridge
+ * pci_bridge_d3_possible - Is it possible to put the bridge into D3
+ * @bridge: Bridge to check
+ *
+- * This function checks if it is possible to move the bridge to D3.
+ * Currently we only allow D3 for some PCIe ports and for Thunderbolt.
++ *
++ * Return: Whether it is possible to move the bridge to D3.
++ *
++ * The return value is guaranteed to be constant across the entire lifetime
++ * of the bridge, including its hot-removal.
+ */
+ bool pci_bridge_d3_possible(struct pci_dev *bridge)
+ {
+--- a/drivers/pci/probe.c
++++ b/drivers/pci/probe.c
+@@ -1678,7 +1678,7 @@ void set_pcie_hotplug_bridge(struct pci_
+
+ pcie_capability_read_dword(pdev, PCI_EXP_SLTCAP, ®32);
+ if (reg32 & PCI_EXP_SLTCAP_HPC)
+- pdev->is_hotplug_bridge = 1;
++ pdev->is_hotplug_bridge = pdev->is_pciehp = 1;
+ }
+
+ static void set_pcie_thunderbolt(struct pci_dev *dev)
+--- a/include/linux/pci.h
++++ b/include/linux/pci.h
+@@ -328,6 +328,11 @@ struct rcec_ea;
+ * determined (e.g., for Root Complex Integrated
+ * Endpoints without the relevant Capability
+ * Registers).
++ * @is_hotplug_bridge: Hotplug bridge of any kind (e.g. PCIe Hot-Plug Capable,
++ * Conventional PCI Hot-Plug, ACPI slot).
++ * Such bridges are allocated additional MMIO and bus
++ * number resources to allow for hierarchy expansion.
++ * @is_pciehp: PCIe Hot-Plug Capable bridge.
+ */
+ struct pci_dev {
+ struct list_head bus_list; /* Node in per-bus list */
+@@ -451,6 +456,7 @@ struct pci_dev {
+ unsigned int is_physfn:1;
+ unsigned int is_virtfn:1;
+ unsigned int is_hotplug_bridge:1;
++ unsigned int is_pciehp:1;
+ unsigned int shpc_managed:1; /* SHPC owned by shpchp */
+ unsigned int is_thunderbolt:1; /* Thunderbolt controller */
+ /*
lib-crypto-x86-poly1305-fix-register-corruption-in-no-simd-contexts.patch
lib-crypto-x86-poly1305-fix-performance-regression-on-short-messages.patch
fs-prevent-file-descriptor-table-allocations-exceeding-int_max.patch
+documentation-acpi-fix-parent-device-references.patch
+acpi-processor-perflib-fix-initial-_ppc-limit-application.patch
+pci-acpi-fix-runtime-pm-ref-imbalance-on-hot-plug-capable-ports.patch
+acpi-ec-relax-sanity-check-of-the-ecdt-id-string.patch
+acpi-processor-perflib-move-problematic-pr-performance-check.patch
+block-make-req_op_zone_finish-a-write-operation.patch
+mm-memory-tier-fix-abstract-distance-calculation-overflow.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
