linux-kernel - Re: [PATCH] riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64

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: <434a7a39-de2d-4053-aed7-df556b5c385d@freeshell.de>
Date: Tue, 22 Oct 2024 18:12:45 -0700
From: E Shattow <e@...eshell.de>
To: Conor Dooley <conor@...nel.org>
Cc: Henry Bell <dmoo_dv@...tonmail.com>,
 Emil Renner Berthing <kernel@...il.dk>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: dts: starfive: Update ethernet phy0 delay
 parameter values for Star64

On 10/22/24 09:41, Conor Dooley wrote:
> On Mon, Oct 21, 2024 at 11:09:51PM -0700, E Shattow wrote:
>> Improve function of Star64 bottom network port phy0 with updated delay values.
>> Initial upstream patches supporting Star64 use the same vendor board support
>> package parameters known to result in an unreliable bottom network port.
> Should I add:
> Fixes: 2606bf583b962 ("riscv: dts: starfive: add Star64 board devicetree")
> CC: stable@...r.kernel.org
> ?
>
> "unreliable" sounds to me like something that is worthy of going to
> fixes/stable

Applying as a fix to stable sounds reasonable, thanks. The bottom 
network port has always been known by Star64 users in reviews and 
discussions to be affected by dropped packets and low network 
throughput. If we want to prove correctness does this require expertise 
and use of an oscilloscope to characterize the signal timing? Though I 
am not sure I got it right, it's not worse than previously was on any of 
these Star64 boards in the wild and probably is better for at least some 
(if not all).

Notable aside is to mention the re-worked motorcomm driver of 
more-recent Linux kernel releases (when compared to the vendor board 
support package) dropped the Fast Ethernet configuration parameters on 
the reasoning that Fast Ethernet (as compared to Gigabit Ethernet) is 
relatively slow enough of a signal that a default delay parameter is 
good enough for all use cases. The non-default Fast Ethernet delay 
parameter values missing from the upstream effort are not possible to 
implement or test for in my effort here, but are no worse or better for 
having this patch applied.

-E