Re: [PATCH v2] PCI: release empty sibling bridge windows during rebar expansion

Geramy Loveless
2026-04-11T16:30:26Z

Mario,

Yeah I would consider this a bios bug but it seems the MS-S1 isn’t the
only one with it. I’m not sure how bios development goes together or
who standardizes the ACPI table that would be the right way to fix
this.

I would think the faster way is to adapt the AMD driver to use the
Thunderbolt provided function in the kernel to detect if it’s on a hot
plug table port. Which would only work on driver versions that where
introduced during the time the kernel had that new capability. It
could get backported / patched. That in my eyes would be the fastest
resolution, correct or not. We could update the ACPI table during
kernel load but that seems a lot more hacky then using pre-existing
thunderbolt provided functionality for detecting if the device is on
Thunderbolt.

I already patched the driver with the additional thunderbolt function
call, I’m not seeing any problems at all. My kernel loaded with the
devices connected and made it the primary display PITA but Linux has
always been a PITA for displays haha. :) once done what is your
recommendations for submitting all 8 patches I believe or should I
just do one for adding “is thunderbolt” function call?

Sorry about the last reply my phone doesnt like text only mode.

Thanks!

Geramy L. Loveless
Founder & Chief Innovation Officer

JQluv.net, Inc.
Site: JQluv.com
Mobile: 559.999.1557
Office: 1 (877) 44 JQluv

On Fri, Apr 10, 2026 at 8:28 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 4/10/26 18:21, Cristian Cocos wrote:
> > [You don't often get email from cristi@ieee.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > In *Windows*, yes, GPUs have indeed been supported in eGPU
> > configuration, though not so much in Linux(!). The troubles we are
> > currently experiencing, esp. concerning hot-plugging, have not been
> > reported simply because eGPUs in Linux has, so far, been a very niche,
> > limited application. In other words, it's not that these issues have
> > not been around, it's just that they have not been REPORTED due to a
> > very limited pool of users running Linux in eGPU configuration. GPU
> > manufacturers have thus focused on patching up bugs in Windows, while
> > hot-plugging-Thunderbolt-eGPUs-in-Linux has fallen onto the back burner
> > due to its small market share. As such, I doubt that TB5 has anything
> > to do with all this.
> >
> > On Fri, 2026-04-10 at 16:01 -0700, Geramy Loveless wrote:
> >> So after a while of doing investigations I keep thinking, gpus have
> >> supported hotplug or so i would believe for a while ever since at
> >> least thunderbolt 4 and possibly older styles too of hotplug as well
> >> as dual gpu machines like laptops that have a dedicated and
> >> integrated. I would think all of these problems we are seeing is most
> >> likely due to something very specific to thunderbolt 5. So here is a
> >> theory.
> >>
> >> Root port ACPI device: \_SB_.PCI0.GP10 at address 0x00030002 = PCI
> >> 00:03.2
> >> Its _DSD (Device-Specific Data) contains only:
> >> "FundamentalDeviceResetTriggeredOnD3ToD0" = 1
> >>
> >> No ExternalFacingPort property. The firmware gives it a D3-to-D0
> >> reset
> >> hint but never declares it as external-facing.
> >> For comparison, a properly configured system would have:
> >>
> >> Package {"ExternalFacingPort", 1},
> >> Package {"DmaProperty", 1},
> >>
> >> The complete proof chain:
> >>
> >> DSDT (/tmp/dsdt.dsl:4194-4205): GP10 (00:03.2) _DSD has no
> >> ExternalFacingPort
> >> pci_acpi_set_external_facing() (pci-acpi.c:1422):
> >> device_property_read_u8("ExternalFacingPort") fails → external_facing
> >> stays 0
> >> pci_set_removable() (probe.c:1780): parent not removable → falls
> >> through
> >> arch_pci_dev_is_removable() (arch/x86/pci/acpi.c:353):
> >> !root->external_facing → returns false
> >> Result: dev->removable never set to DEVICE_REMOVABLE on any device in
> >> the chain
> >>
> >> Sysfs proof:
> >> 00:03.2: removable=N/A, external_facing=N/A
> >> 65:00.0: removable=N/A
> >> 66:03.0: removable=N/A (TB bridge with HotPlug+ Surprise+)
> >> 93:00.0: removable=N/A
> >> 97:00.0: removable=N/A (eGPU — dev_is_removable() returns false)
> >>
> >> I'm not sure its correct so much but I have patched up the amdgpu
> >> driver myself to use what its using now and "||
> >> pci_is_thunderbolt_attached"
> >> This might be entirely completely wrong :D but I figured I would see
> >> what happens.
> >>
>
> I would say it's wrong. We explicitly moved away from this because it's
> only indicating there is an Intel VSEC:
>
> commit 7b1c6263eaf4f ("drm/amdgpu: don't use pci_is_thunderbolt_attached()")
>
> Isn't what you point out a BIOS bug?
>
> If the BIOS has an externally facing port without ExternalFacingPort or
> DmaProperty it's going to cause problems in Windows too.
>
> https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
>
> Now granted; in Linux we might be using this a little bit differently.
>
> If we were going to do /anything/ in Linux - I would say adding
> pci_is_thunderbolt_attached() as another criteria that marks devices as
> removable is what makes sense.
>
>