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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eab0cc63-de1b-4b41-bcce-7a2308d4f446@solid-run.com>
Date: Thu, 18 Sep 2025 14:18:24 +0000
From: Josua Mayer <josua@...id-run.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Gregory Clement <gregory.clement@...tlin.com>, Sebastian Hesselbarth
	<sebastian.hesselbarth@...il.com>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Frank
 Wunderlich <frank-w@...lic-files.de>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] arm64: dts: marvell: cn9132-clearfog: fix
 multi-lane pci x2 and x4 ports

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.