On Tue, 30 Aug 2022, Pali Rohár wrote: > > Agreed. But I also understand the reasoning from Maciej, at least in > > parts. Thinking a bit more about this, my preference would be to still > > include this workaround per default in U-Boot proper though. To not > > make things too complicated here. > > > > Just my 0.02$. > > I understand it. > > Anyway, I would really to know where is the issue (in which part of PCIe > hierarchy) and what exactly is affected.
Here's the hierarchy tree of the system affected: -[0000:00]---00.0-[01-0b]----00.0-[02-0b]--+-00.0-[03]-- +-02.0-[04]----00.0 +-03.0-[05-09]----00.0-[06-09]--+-01.0-[07]--+-00.0 | | \-00.3 | \-02.0-[08-09]----00.0-[09]--+-01.0 | \-02.0 +-04.0-[0a]----00.0 \-08.0-[0b]--+-00.0 \-00.1 and the issue is between 0000:02:03.0 and 0000:05:00.0. This has nothing to do with the host CPU and the ASM2824 part is a generic PCIe switch also available on option cards with slots. So it can be plugged by a user into any system out there that has PCIe slot connectivity (also a conventional PCI system via a PCI-to-PCIe reverse bridge or IIUC a Thunderbolt bridge). Of course if a given system has no external PCI/e connectivity and no affected devices onboard, then there is no point in having the workaround included in the firmware. > I think that deep understanding of the issue is important or at least > confirmation from the vendor (which we know that it would not come). Indeed that would help a lot, but we need to live with what we have. FWIW I have finally found time and an availability slot with my HiFive Unmatched hardware to get an updated version of the Linux fix made, verified and posted upstream; cf. <https://lore.kernel.org/linux-pci/alpine.deb.2.21.2209061238050.2...@angie.orcam.me.uk/>. Maciej