linux-kernel - Re: [PATCH 2/4] dt-bindings: net: dsa: document internal MDIO bus

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: <CAJq09z6eghuHY+b2y-kGmjKnLiEEOABXGKhjnB-PxJ=-GtYD4w@mail.gmail.com>
Date:   Mon, 4 Sep 2023 23:42:19 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Arınç ÜNAL <arinc.unal@...nc9.com>
Cc:     Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Woojung Huh <woojung.huh@...rochip.com>,
        UNGLinuxDriver@...rochip.com,
        Linus Walleij <linus.walleij@...aro.org>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Daniel Golle <daniel@...rotopia.org>,
        Landen Chao <Landen.Chao@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>, mithat.guner@...ont.com,
        erkin.bozoglu@...ont.com, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 2/4] dt-bindings: net: dsa: document internal MDIO bus

> > [1] ...this. The SMI-controlled and MDIO-controlled Realtek switches are
> > otherwise the same, right? So why would they have different dt-bindings?
>
> Honestly, I'm wondering the answer to this as well. For some reason, when
> probing the SMI controlled Realtek switches, instead of just letting
> dsa_switch_setup() populate ds->slave_mii_bus, on realtek_smi_setup_mdio()
> on realtek-smi.c:
>
> - priv->slave_mii_bus is allocated.
> - mdio_np = of_get_compatible_child(priv->dev->of_node, "realtek,smi-mdio");
> - priv->slave_mii_bus->dev.of_node = mdio_np;
> - ds->slave_mii_bus = priv->slave_mii_bus;

I might be able to help here. The Realtek SMI version created a custom
slave_mii driver because it was the only way to associate it with an
MDIO DT node. And that DT node was required to specify the interrupts
for each phy0.
It would work without that mdio node, letting DSA setup handle the
slave bus, but it would rely only on polling for port status.

As we only have a single internal MDIO, the compatible string
"realtek,smi-mdio" would not be necessary if the driver checks for a
"mdio"-named child node. Maybe the code was just inspired by another
DSA driver that uses more MDIO buses or external ones. The "mdio" name
is suggested by docs since it was committed
(https://www.kernel.org/doc/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt).
That name was also kept in the YAML translation
(https://www.kernel.org/doc/Documentation/devicetree/bindings/net/dsa/realtek.yaml).

The Realtek MDIO driver was merged at the same release that included
the change that allows dsa_switch_setup() to reference the "mdio"
OF-node if present. That way, it could avoid creating a custom
slave_mii_bus driver.

I submitted a small series of patches to unify that behavior between
those two drivers:

https://lore.kernel.org/netdev/CAJq09z44SNGFkCi_BCpQ+3DuXhKfGVsMubRYE7AezJsGGOboVA@mail.gmail.com/
(This is my answer to the series opening message to include the first
paragraph ate by the editor)

There was some discussion but not NAC, ACK or RFC. It would have
dropped some lines of code. I can revive it if there is interest.

Regards,

Luiz