Re: [PATCH] drm/amdgpu: Remove pci address checks from acpi_vfct_bios

[Kurt Kartaltepe <kkartaltepe@gmail.com>]

On Wed, Mar 20, 2024 at 6:31 AM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:

> Can you provide the full output of lspci -vvvv. As far as I can see that doesn't looks so invalid to me.

I've added the relevant pci probing debug output without assign-busses
and the lspci -vvvv for a boot with all devices visible.
https://gist.github.com/kkartaltepe/2f01f33c7e7af33cf0d28678e91f50fb

> Well that is just a very very old workaround for a buggy BIOS on 20 year old laptops. The last reference I could find for hardware which actually needed it is this:
>
> commit 8c4b2cf9af9b4ecc29d4f0ec4ecc8e94dc4432d7
> Author: Bernhard Kaindl <bk@suse.de>
> Date:   Sat Feb 18 01:36:55 2006 -0800
>
>     [PATCH] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
>
>
> So as far as I know nobody had to use that in ages and I wouldn't expect that this option actually works correctly on any modern hardware.
>
> Especially not anything PCIe based since it messes up the ACPI to PCIe device mappings. That amdgpu doesn't work is just the tip of the iceberg here.
>
> The bus assignment code in the PCI subsystem is made to support hotplug, not completely re-number the root hubs from scratch. That is just a hack somebody came up with two decades ago to get some Cardbus slots in laptops working.
>
> I'm not sure yet what's going wrong with the Thunderbold controller, but completely re-assigning bus numbers is certainly the wrong approach.

I was referring to the work outlined in
https://ostconf.com/system/attachments/files/000/001/698/original/Sergei_Miroshnichenko_linux_piter_2019_presentation.pdf?1570136708
for nvme enclosures. Which maybe referncing more the movable BARs than
the renumbering that occurs with assign-busses, but also on power with
device trees which may behave differently as it mentions assign-busses
to get this same renumbering of buses. This makes me think at least
modern non-x86 devices expect to behave this way, which may not be
relevant to ACPI/x86 systems but at least this shared pci code should
be solid.

> I'm not sure yet what's going wrong with the Thunderbold controller, but completely re-assigning bus numbers is certainly the wrong approach.

I agree, it is just what is currently available in the kernel. A less
disruptive approach seems needed.

--Kurt Kartaltepe