netdev - Re: [PATCH net] net: dsa: microchip: keep compatibility with device tree blobs with no phy-mode

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: <Yv5XL4KTLxukVhck@lunn.ch>
Date:   Thu, 18 Aug 2022 17:13:51 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <vladimir.oltean@....com>,
        Russell King <rmk+kernel@...linux.org.uk>
Cc:     netdev@...r.kernel.org, Woojung Huh <woojung.huh@...rochip.com>,
        UNGLinuxDriver@...rochip.com,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Russell King <linux@...linux.org.uk>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Craig McQueen <craig@...ueen.id.au>
Subject: Re: [PATCH net] net: dsa: microchip: keep compatibility with device
 tree blobs with no phy-mode

> It is important to note that phy_device_create() initializes
> dev->interface = PHY_INTERFACE_MODE_GMII, and so, when we use
> phylink_create(PHY_INTERFACE_MODE_NA), no one will override this, and we
> will end up with a PHY_INTERFACE_MODE_GMII interface inherited from the
> PHY.

Is this actually a bug?

With pure phylib, you should call one of the connect functions, which
underneath calls phy_attach_direct() which has a phy_interface_t. So
the default in practice does not matter.

> All this means that in order to maintain compatibility with device tree
> blobs where the phy-mode property is missing, we need to allow the
> "gmii" phy-mode and treat it as "internal".

of_get_phy_mode() returns PHY_INTERFACE_MODE_NA if the property is
missing, which also suggests this is a bug.

I wonder if we have any ports which actually rely on
PHY_INTERFACE_MODE_GMII?

	 Andrew