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]

Date:   Thu, 30 Jun 2022 20:04:23 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Luiz Angelo Daros de Luca <luizluca@...il.com>
CC:     "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        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" <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

On Thu, Jun 30, 2022 at 02:05:39PM -0300, Luiz Angelo Daros de Luca wrote:
> > If you want to avoid that debate, what you could do instead is add a
> > const char *slave_mii_compatible; member to struct dsa_switch, and try
> > searching in dsa_switch_setup() for a child node with that compatible if
> > the lookup of a node named "mdio" fails. I don't know if this would help
> > you do the same thing with other drivers.
> 
> The DSA change to accept "mdio" was an improvement to avoid adding a
> custom slave mdio when you already have a single mdio and just need to
> point to a DT node. Adding compatible strings for that situation does
> not make much sense as a compatible string is not necessary when you
> are already restricting your case to a single mdio. For more complex
> setups, you still need to create your own slave mdio implementation.
> Some drivers already depend on the "mdio" name and this series is also
> a suggestion for them to try their drivers dropping their custom slave
> mdio implementations.

It was just a suggestion for how to achieve what you want (less code in
the driver) without breaking backward compatibility. Obviously newly
submitted drivers shouldn't use the interface for the reasons you just
gave.

Whether it is a good idea to add such an interface to the DSA core,
idk. Personally I think it's fair enough, but I also don't mind the
status quo. The code you're removing is not exactly doing any harm.

I think my suggestion only makes sense if you can show that other
drivers can benefit as well.

Kind regards,
Alvin