Thread (14 messages) 14 messages, 2 authors, 2021-06-06

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

From: Andrew Lunn <andrew@lunn.ch>
Date: 2021-06-01 13:04:59
Also in: lkml

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:
quoted
On Tue, May 25, 2021 at 01:58:03PM +0800, Wong Vee Khee wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help