[PATCH v2 3/4] arm64: dts: marvell: cn9132-clearfog: fix multi-lane pci x2 and x4 ports

[Josua Mayer]

Am 18.09.25 um 16:09 schrieb Andrew Lunn:
> On Thu, Sep 18, 2025 at 10:46:03AM +0000, Josua Mayer wrote:
>> Am 12.09.25 um 00:12 schrieb Andrew Lunn:
>>> On Thu, Sep 11, 2025 at 08:28:06PM +0200, Josua Mayer wrote:
>>>> The mvebu-comphy driver does not currently know how to pass correct
>>>> lane-count to ATF while configuring the serdes lanes.
>>>>
>>>> This causes the system to hard reset during reconfiguration, if a pci
>>>> card is present and has established a link during bootloader.
>>>>
>>>> Remove the comphy handles from the respective pci nodes to avoid runtime
>>>> reconfiguration, relying solely on bootloader configuration - while
>>>> avoiding the hard reset.
>>>>
>>>> When bootloader has configured the lanes correctly, the pci ports are
>>>> functional under Linux.
>>> Does this require a specific bootloader? Can i use mainline grub or
>>> bareboot?
>> In this case it means U-Boot, i.e. before one would start grub.
>>
>> I am never quite sure if in this situation I should say "firmware" instead ...
> What you failed to answer is my question about 'mainline'? Do i need a
> specific vendor u-boot, or can i just use mainline u-boot, or mainline
> bareboot.

Ah.

There is no mainline u-boot for these boards (yet).
I submitted v1 on u-boot ml a while back but didn't have time to rework it.

U-Boot has a different comphy driver that appears to configure the lanes
correctly.

>
> I personally like to replace the bootloader, because the one shipped
> with the board often has useful features disabled, or is old. If i do
> that, will the board work?
Conversationally if the bootloader configured the board correctly,
then it also correctly configured all pci lanes considering u-boot
handles link-up itself on mvebu.
> I would much prefer the kernel makes no
> assumptions about the bootloader.
Same.
> You said:
>
>> The mvebu-comphy driver does not currently know how to pass correct
>> lane-count to ATF while configuring the serdes lanes.
> Why not just teach mvebu-comphy to pass the correct line-count? That
> sounds like the proper fix, and that makes the kernel independent of
> the bootloader.
That would be a feature on the comphy driver, not a bug-fix backported
to stable. The core goal was to fix bugs found in Debian 13.

The Linux comphy driver should be updated going forward.
I did not due it (yet) because tracing the bitmask of atf smc call is
very tedious due to layers of #define referencing each other.