netdev - Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner

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, 10 Nov 2022 16:32:38 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Sean Anderson <sean.anderson@...o.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Madalin Bucur <madalin.bucur@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Frank Rowand <frowand.list@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Leo Li <leoyang.li@....com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Paul Mackerras <paulus@...ba.org>,
        Rob Herring <robh+dt@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Shawn Guo <shawnguo@...nel.org>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices
 probed in the "usual" manner

On Thu, Nov 10, 2022 at 05:01:34PM +0100, Andrew Lunn wrote:
> On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> > > >> Several (later) patches in this series cannot be applied until a stable
> > > >> release has occured containing the dts updates.
> > > > 
> > > > New kernels must remain compatible with old device trees.
> > > 
> > > Well, this binding is not present in older device trees, so it needs to
> > > be added before these patches can be applied. It also could be possible
> > > to manually bind the driver using e.g. a helper function (like what is
> > > done with lynx_pcs_create_on_bus). Of course this would be tricky,
> > > because we would need to unbind any generic phy driver attached, but
> > > avoid unbinding an existing Lynx PCS driver.
> > 
> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
> > these PCS devices, would it be possible to probe them in a generic way
> > as MDIO devices, if they lack a compatible string?
> 
> That is not how it currently works. If a device on an MDIO bus has a
> compatible, it is assumed to be an mdio device, and it is probed in a
> generic way as an sort of mdio device. It could be an Ethernet switch,
> or Broadcom has some generic PHYs which are mdio devices, etc.
> 
> If there is no compatible, the ID registers are read and it is assumed
> to be a PHY. It will be probed as a PHY. The probe() function will be
> given a phydev etc.
> 
> It will need some core changes to allow an mdio device to be probed
> via the ID registers.

Yes, it would require extending struct mdio_driver with something like
what struct phy_driver has (u32 phy_id, u32 phy_id_mask), or with a more
generic phy_id_match_table (similar to maybe of_match_table).

I don't see a conceptually simpler way though.