netdev - Re: [PATCH] lan743x: Added fixed link and RGMII support / Options for proceeding ?

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>] [day] [month] [year] [list]

Date:   Wed, 3 Jun 2020 17:10:49 +0200
From:   Roelof Berg <rberg@...g-solutions.de>
To:     "rberg@...g-solutions.de" <rberg@...g-solutions.de>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Bryan Whitehead <bryan.whitehead@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lan743x: Added fixed link and RGMII support / Options for
 proceeding ?

Hi,

we need to decide how to continue with the lan743x patch for fixed phy support. Thanks everyone for the valuable time.

Summary of the development steps so far:
The patch initially had low influence on the installed base, but lacked some compatibility to Linux best practices. During the review process we found improvement potential. We decided to make the patch more similar to the majority of Linux drivers, by avoiding a special autodetection silicon feature that is unique. However, now, with more test hardware available, this road becomes more difficult than we initially assumed.

Would it be ok to split the topics into two distinct patches ?

Topic a: New feature: Add fixed link and RGMII support in a minimal invasive way. (Including fixing a reboot-issue that the last patch fixed.)

Topic b: Refactor old driver: Understand, and if possible remove, the silicon’s Mac-Phy auto-negotiation feature.

Maybe splitting distinct features into distinct patches is the most defensive approach, now that device testing disconfirmed our promising approach ?

Thanks everyone for cooperating on this feature,
Roelof

> Roelof Berg <rberg@...g-solutions.de>:
> 
> Testing note [...]
> - Different from prior approaches it affects the installed base. So we need some more testing (with hardware I don’t have available yet) and I’m in contact with Microchip already.
> 
> Thanks for guiding us to a proper solution,
> Roelof Berg
> 
>> . The automatic speed and duplex detection of the lan743x silicon
>> between mac and phy is disabled.