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.2275@angie.orcam.me.uk/.
Maciej