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

Florian Fainelli f.fainelli at gmail.com
Fri Apr 14 05:27:01 PDT 2023



On 4/14/2023 5:14 AM, Jim Quinlan wrote:
> On Thu, Apr 13, 2023 at 4:06 PM Cyril Brulebois <kibi at debian.org> wrote:
>>
>> Hi Jim,
>>
>> Jim Quinlan <jim2101024 at gmail.com> (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



More information about the linux-arm-kernel mailing list