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

[Mario Limonciello <mario.limonciello@amd.com>]

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.