netdev - Re: [PATCH net-next RFC 0/3] net: dsa: realtek: drop custom slave MII

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: <CAJq09z44SNGFkCi_BCpQ+3DuXhKfGVsMubRYE7AezJsGGOboVA@mail.gmail.com>
Date:   Wed, 29 Jun 2022 13:43:45 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>, krzk+dt@...nel.org,
        Arınç ÜNAL <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next RFC 0/3] net: dsa: realtek: drop custom slave MII

This RFC patch series cleans realtek-smi custom slave mii bus. Since
fe7324b932, dsa generic code provides everything needed for
realtek-smi driver. For extra caution, this series should be applied
in two steps: the first 2 patches introduce the new code path that
uses dsa generic code. It will show a warning message if the tree
contains deprecated references. It will still fall back to the old
code path if an "mdio"
is not found.

>
> The last patch cleans all the deprecated code while keeping the kernel
> messages. However, if there is no "mdio" node but there is a node with
> the old compatible stings "realtek,smi-mdio", it will show an error. It
> should still work but it will use polling instead of interruptions.
>
> My idea, if accepted, is to submit patches 1 and 2 now. After a
> reasonable period, submit patch 3.
>
> I don't have an SMI-connected device and I'm asking for testers. It
> would be nice to test the first 2 patches with:
> 1) "mdio" without a compatible string. It should work without warnings.
> 2) "mdio" with a compatible string. It should work with a warning asking
> to remove the compatible string
> 3) "xxx" node with compatible string. It should work with a warning
> asking to rename "xxx" to "mdio" and remove the compatible string
>
> In all those cases, the switch should still keep using interruptions.
>
> After that, the last patch can be applied. The same tests can be
> performed:
> 1) "mdio" without a compatible string. It should work without warnings.
> 2) "mdio" with a compatible string. It should work with a warning asking
> to remove the compatible string
> 3) "xxx" node with compatible string. It should work with an error
> asking to rename "xxx" to "mdio" and remove the compatible string. The
> switch will use polling instead of interruptions.
>
> This series might inspire other drivers as well. Currently, most dsa
> driver implements a custom slave mii, normally only defining a
> phy_{read,write} and loading properties from an "mdio" OF node. Since
> fe7324b932, dsa generic code can do all that if the mdio node is named
> "mdio".  I believe most drivers could simply drop their slave mii
> implementations and add phy_{read,write} to the dsa_switch_ops. For
> drivers that look for an "mdio-like" node using a compatible string, it
> might need some type of transition to let vendors update their OF tree.
>
> Regards,
>
> Luiz
>

I might have forgotten to add a new line after the subject. It ate the
first paragraph. I'm top-posting it.

Regards,

Luiz