Re: [Bug 215925] New: PCIe regression on Raspberry Pi Compute Module 4 (CM4) breaks booting

[Bjorn Helgaas <helgaas@kernel.org>]

[+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@kernel.org> (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