[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e0d6081-f777-4f40-b0be-a12171f772f4@lunn.ch>
Date: Tue, 2 Jan 2024 20:49:15 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Ezra Buehler <ezra@...yb.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Tristram Ha <Tristram.Ha@...rochip.com>,
Michael Walle <michael@...le.cc>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
netdev@...r.kernel.org
Subject: Re: [PATCH net] net: mdio: Prevent Clause 45 scan on SMSC PHYs
> By skimming over some datasheets for similar SMSC/Microchip PHYs, I
> could not find any evidence that they support Clause 45 scanning
> (other than not responding).
Do you find any reference to Clause 22 scanning being supported in the
datasheets?
What we expect is that C22 registers 2 and 3 contain ID values. If
there is no device at the address on the bus, nothing should respond,
and the pull up on the bus should result in a read of 0xffff. If we
get a value other than 0xffff, we know there is a device there. The
same is basically true for C45, but because each address has 32 MMD
spaces, its a bit more complex. But still, if there is no device
there, it should return 0xffff when reading an ID register. This is
all part of IEEE 802.3, so there is no real need to specific this in
the datasheet, other than to say its conformance to 802.3, or list
where it does not conform.
>
> > drivers/net/phy/smsc.c has a number of phy_write_mmd()/phy_read_mmd()
> > in it. But that device has a different OUI.
>
> I guess I am confused here, AFAICT all PHYs in smsc.c have the same OUI
> (phy_id >> 10).
My error. I forgot about the odd shift. So smsc.c does use the 01f0
OUI.
> > However, the commit message says:
> >
> > > Running a Clause 45 scan on an SMSC/Microchip LAN8720A PHY will (at
> > > least with our setup) considerably slow down kernel startup and
> > > ultimately result in a board reset.
> >
> > So we need to clarify the real issue here. Does the C45 scan work
> > correctly, but the board watchdog timer is too short and fires? We
> > should not be extended this workaround when its a bad watchdog
> > configuration issue...
>
> Changing the watchdog configuration is not an option here. We are
> talking about a slowdown of several seconds here, that is not acceptable
> on its own.
I'm with Russell here, we should understand why its so slow. And by
fixing that, you might find access in general gets better.
Andrew
Powered by blists - more mailing lists