[+to Jim, heads-up about reverting commits to avoid the regression]
On Tue, May 10, 2022 at 10:07:09PM +0200, Cyril Brulebois wrote:
> Bjorn Helgaas <helgaas@xxxxxxxxxx> (2022-05-10):
> > What if you revert 830aa6f29f07 and the subsequent brcmstb patches?
> >
> > 11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
> > 93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
> > 67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
> > 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
> >
> > $ git revert 11ed8b8624b8 93e41f3fca3d 67211aadcb4b 830aa6f29f07
> >
> > I did that on current upstream: 9be9ed2612b5 ("Merge tag
> > 'platform-drivers-x86-v5.18-4' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86")
> > and it built fine on x86.
>
> I've done exactly that, and it boots again. Comparing kernel messages
> against an older version (5.10.106), I'm getting the same output on that
> bare CM4 on CM4 IO Board setup:
>
> # dmesg|grep -i pcie
> [ 3.368620] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
> [ 3.368654] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
> [ 3.368703] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x0603ffffff -> 0x00f8000000
> [ 3.368748] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x003fffffff -> 0x0400000000
> [ 3.421094] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
> [ 3.421341] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
>
> And with a PCIe → quad-USB board plugged in, I'm getting those
> additional lines:
>
> [ 3.426842] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
> [ 3.427072] pcieport 0000:00:00.0: PME: Signaling with IRQ 51
> [ 3.427472] pcieport 0000:00:00.0: AER: enabled with IRQ 51
>
> (It seems to be consistently IRQ 51 with 5.18.0-rc6+ while it seems to
> be consistently IRQ 52 on 5.10.106, but the output is very similar in
> both cases.)
>
> And plugging a keyboard on one of those USB ports works fine:
>
> [ 13.406351] input: Logitech USB Keyboard as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:046D:C31C.0001/input/input0
> [ 13.510144] input: Logitech USB Keyboard Consumer Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C31C.0002/input/input2
> [ 13.591345] input: Logitech USB Keyboard System Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C31C.0002/input/input3
>
>
> Wrapping up: it boots again (with or without PCIe equipment plugged in),
> and PCIe seems functional.
>
> I'm happy to test more patches (e.g. trying to fix the actual issue
> without going for a set of reverts).
We're at -rc6 already, but no word from Jim yet. I think all we can
do at this point is queue up reverts of these patches for v5.18. The
reverts on now on my for-linus branch.
If we get a fix, I can easily drop the reverts, but I don't want v5.18
to release with PCI completely broken on the Compute Module 4.
Bjorn
