[PATCH v6 0/5] PCI: brcmstb: Configure appropriate HW CLKREQ# mode

[Cyril Brulebois]

Hi Jim,

Jim Quinlan <james.quinlan at broadcom.com> (2023-06-23):
> v6 -- No code has been changed.
>    -- Changed commit subject and comment in "#PERST" commit (Bjorn, Cyril)
>    -- Changed sign-off and author email address for all commits.
>       This was due to a change in Broadcom's upstreaming policy.

I've just run some more tests to be on the safe side, and I can confirm
everything is still looking good with the updated series and the updated
base commit.

Test setup:
-----------

 - using a $CM with the 20230111 EEPROM
 - on the same CM4 IO Board
 - with a $PCIE board (PCIe to multiple USB ports)
 - and the same Samsung USB flash drive.

where $CM is one of:

 - CM4 Lite Rev 1.0
 - CM4 8/32 Rev 1.0
 - CM4 4/32 Rev 1.1

and $PCIE is one of:

 - SupaHub PCE6U1C-R02, VER 006
 - SupaHub PCE6U1C-R02, VER 006S


Results:
--------

 1. With an unpatched kernel, I'm getting the dreaded Serror for all
    $CM/$PCIE combinations. That's reproducible with:
     - the 6.1.y kernel shipped in Debian 12;
     - a locally-built v6.4-rc7-194-g8a28a0b6f1a1d kernel.

 2. With a patched kernel (v6.4-rc7-194-g8a28a0b6f1a1d + this series),
    for all $CM/$PCIE combinations, I'm getting a system that boots,
    sees the flash drive, and gives decent read performance on the USB
    flash drive (200+ MB/s on the CM4 Lite, 220+ MB/s on the non-Lite
    versions).


In passing, since that looks like it could be merged finally: I suppose
it's fair to say this series adds support for hardware that wasn't
working before, which means it's not a candidate for inclusion via
stable@ (even if it gets rid of a nasty failure to boot depending on
what hardware is plugged in at that time)?

In other words, downstream distributions should be expected to either
adjust their build systems to pick some future Linux release or consider
backporting this series on their own, to each base Linux version they
support?


Thanks again for all the help figuring this out.


Cheers,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230629/7e17a036/attachment.sig>