netdev - Re: [RFC net-next 0/2] Introduce MDIO probe order C45 over C22

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: <YLYwcx3aHXFu4n5C@lunn.ch>
Date:   Tue, 1 Jun 2021 15:04:51 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Wong Vee Khee <vee.khee.wong@...ux.intel.com>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC net-next 0/2] Introduce MDIO probe order C45 over C22

On Tue, Jun 01, 2021 at 06:47:34PM +0800, Wong Vee Khee wrote:
> On Tue, May 25, 2021 at 03:34:34PM +0200, Andrew Lunn wrote:
> > On Tue, May 25, 2021 at 01:58:03PM +0800, Wong Vee Khee wrote:
> > > Synopsys MAC controller is capable of pairing with external PHY devices
> > > that accessible via Clause-22 and Clause-45.
> > > 
> > > There is a problem when it is paired with Marvell 88E2110 which returns
> > > PHY ID of 0 using get_phy_c22_id(). We can add this check in that
> > > function, but this will break swphy, as swphy_reg_reg() return 0. [1]
> > 
> > Is it possible to identify it is a Marvell PHY? Do any of the other
> > C22 registers return anything unique? I'm wondering if adding
> > .match_phy_device to genphy would work to identify it is a Marvell PHY
> > and not bind to it. Or we can turn it around, make the
> > .match_phy_device specifically look for the fixed-link device by
> > putting a magic number in one of the vendor registers.
> >
> 
> I checked the Marvell and did not see any unique register values.
> Also, since get_phy_c22_id() returns a *phy_id== 0, it is not bind to
> any PHY driver, so I don't think adding the match_phy_device check in
> getphy would help.

It has a Marvell ID in C45 space. So maybe we need to special case for
ID 0. If we get that, go look in C45 space. If we find a valid ID, use
it. If we get EOPNOTSUP because the MDIO bus is not C45 capable, or we
don't find a vendor ID in C45 space, keep with id == 0 and load
genphy?

The other option is consider the PHY broken, and require that you put
the correct ID in DT as the compatible string. The correct driver will
then be loaded, based on the compatible string, rather than what is
found by probing.

      Andrew