[PATCH 0/1] Fix Thunderbolt enumeration

[PATCH 0/1] Fix Thunderbolt enumeration

[Nicholas Johnson]

I have an Alienware 8950HK with the Thunderbolt 3 port (JHL6340) and OS Native 
Enumeration. Unless the Thunderbolt device was attached at boot time, it was 
failing to enumerate. I have not bisected the kernel to find out what commit 
caused this, but I offer this fix, which I verify fixes the problem.

Here is the problem without the fix applied:

-[0000:00]-+-00.0  Intel Corporation 8th/9th Gen Core Processor Host Bridge / DRAM Registers
           +-01.0-[01]--+-00.0  NVIDIA Corporation GP104M [GeForce GTX 1080 Mobile]
           |            \-00.1  NVIDIA Corporation GP104 High Definition Audio Controller
           +-01.1-[02-09]--
           +-01.2-[0a-42]----00.0-[0b-0e]--+-00.0-[0c]----00.0  Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016]
           |                               +-01.0-[0d]----00.0-[0e]--
           |                               \-02.0-[0e]----00.0  Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016]

And here we are with the fix applied:

-[0000:00]-+-00.0  Intel Corporation 8th/9th Gen Core Processor Host Bridge / DRAM Registers
           +-01.0-[01]--+-00.0  NVIDIA Corporation GP104M [GeForce GTX 1080 Mobile]
           |            \-00.1  NVIDIA Corporation GP104 High Definition Audio Controller
           +-01.1-[02-09]--
           +-01.2-[0a-42]----00.0-[0b-42]--+-00.0-[0c]----00.0  Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016]
           |                               +-01.0-[0d-41]----00.0-[0e-10]--+-00.0-[0f]----00.0  PreSonus Audio Electronics Inc. Quantum 2626
           |                               |                               \-01.0-[10]--
           |                               \-02.0-[42]----00.0  Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016]


I was hoping to get this into Linux v7.2 as a last minute bugfix, but if not, we 
can aim for 7.3 hopefully.

Kind regards,

Nicholas Johnson (1):
  PCI: Fix bus number allocation for switches with multiple downstream
    ports

 drivers/pci/probe.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

-- 
2.53.0

[PATCH 1/1] PCI: Fix bus number allocation for switches with multiple downstream ports

[Nicholas Johnson]

When scanning a PCIe switch with multiple downstream ports, the kernel currently
fails to allocate bus numbers beyond the first downstream port.

The issue occurs in pci_scan_bridge_extend() when scanning an already configured
bridge in pass 1. The code updates 'max' using the old 'subordinate' value from
pass 0 instead of 'cmax', the actual subordinate bus number returned from
scanning the child bus. This causes the parent bridge to never advance past the
first downstream port.

Fix this by updating 'max' with 'cmax' instead of 'subordinate', ensuring the
parent bridge correctly tracks the bus numbers consumed by all its downstream
ports.

Without this fix, only the first downstream port of a switch is enumerated,
breaking Thunderbolt daisy chaining and other multi-port PCIe switch
configurations where bus numbers need to be allocated beyond the first port.

For example, on an Alienware 15 R4 with an Intel Core i9-8950HK, the built-in
JHL6340 Thunderbolt controller fails to enumerate beyond the first downstream
port during native OS enumeration, preventing proper Thunderbolt device tree
discovery and hotplug functionality.

Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
---
 drivers/pci/probe.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b63cd0c31..8fb09cbb6 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -3124,6 +3124,17 @@ static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
 			normal_bridges++;
 	}
 
+	/*
+	 * Some host bridge scan paths pass available_buses == 0 even though
+	 * the bus-number resource contains space reserved for descendants.
+	 * Preserve that space when this bus has a hotplug-capable bridge so
+	 * it can be distributed during the second bridge scan.
+	 */
+	if (!available_buses && hotplug_bridges &&
+	    bus->busn_res.end > bus->busn_res.start)
+		available_buses =
+			bus->busn_res.end - bus->busn_res.start;
+
 	/*
 	 * Scan bridges that are already configured. We don't touch them
 	 * unless they are misconfigured (which will be done in the second
-- 
2.53.0