Re: [PATCH v2 2/3] PCI: brcmstb: CLKREQ# accomodations of downstream device

From: Florian Fainelli
Date: Fri Apr 14 2023 - 08:27:13 EST




On 4/14/2023 5:14 AM, Jim Quinlan wrote:
On Thu, Apr 13, 2023 at 4:06 PM Cyril Brulebois <kibi@xxxxxxxxxx> wrote:

Hi Jim,

Jim Quinlan <jim2101024@xxxxxxxxx> (2023-04-13):
Can you provide (a) the full boot log prior to applying the patch
series and (b) full boot log after applying the series, using an
IDENTICAL setup. If it fails on both then it has little to do with my
patch series.

Just to be clear, the issue I reported was with:
- Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage)
- Raspberry Pi Compute Module 4 IO Board
- SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S

This was my minimal reproducer for the kernel panic at boot-up, which
goes away with either v1 or v2. When I realized I didn't actually check
whether the SupaHub board was working correctly, I plugged 2 devices to
obtain this setup:
- Raspberry Pi Compute Module 4 (Rev 1.1, 4G RAM, 32G storage)
- Raspberry Pi Compute Module 4 IO Board
- SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S
- Kingston DataTraveler G4 32GB on USB-A port #1 of the SupaHub board.
- Logitech K120 keyboard on USB-A port #2 of the SupaHub board.

It turns out that this particular revision of the SupaHub board isn't
supported by xhci_hcd directly (failing to probe with error -110) and
one needs to enable CONFIG_USB_XHCI_PCI_RENESAS=m and also ship its
accompanying firmware (/lib/firmware/renesas_usb_fw.mem). With this
updated kernel config, I'm able to use the keyboard and to read data
from the memory stick without problems (70 MB/s).

In my last series your testing somehow conflated the effect of an
unrelated MMC interrupt issue so please be precise.

I wish things would be simpler and didn't involve combinatorics, let
alone other bugs/regressions at times, but I'm really trying my best to
navigate and report issues and test patches when I can spare some time…

Hi Cyril,

I want to encourage you and others doing testing and bug reporting:
everyone wins when a bug or issue is reported, fixed, and tested.
I'm just asking that when you have negative results, that you provide
information on the "before" and "after" test results of
the patch series, and run both on the same test environment.

Cyril, based upon the table and logs you provided whereby you have used the following:

- Raspberry Pi Compute Module 4 (Rev 1.0, 8G RAM, 32G storage)
- Raspberry Pi Compute Module 4 IO Board
- SupaHub PCIe-to-multiple-USB adapter, reference PCE6U1C-R02, VER 006S

in the before/unpatched case we have a PCIe link down and in the after/patched we have a PCIe link up but a kernel panic. Neither are great nor resulting in a fully functional PCIe device.

Looking at:

https://www.amazon.co.uk/SupaHub-Express-BandWidth-Capable-Expanding/dp/B092ZQWG5B

it would appear that it can accept an external power supply, do you have one connected to that USB expansion card by any chance? Are you able to boot the kernel before/after if you disconnect any USB peripheral?

This looks like a broader electrical problem than the scope of this patch, though it would be neat if we could find a combination that works. At least with Jim's patch we have a PCIe link with uni-directional CLKREQ# so we could try a variety of things.

Does that SupaHub board plugged to the CM4 1.0 system work fine in the Raspberry Pi kernel tree?
--
Florian