[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <245d1cc7-9059-4a94-992f-ad37108df366@lunn.ch>
Date: Fri, 17 Mar 2023 18:24:09 +0100
From: Andrew Lunn <andrew@...n.ch>
To: arturo.buzarra@...i.com
Cc: netdev@...r.kernel.org, Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH] net: phy: return EPROBE_DEFER if PHY is not accessible
On Fri, Mar 17, 2023 at 01:16:46PM +0100, arturo.buzarra@...i.com wrote:
> From: Arturo Buzarra <arturo.buzarra@...i.com>
>
> A PHY driver can dynamically determine the devices features, but in some
> circunstances, the PHY is not yet ready and the read capabilities does not fail
> but returns an undefined value, so incorrect capabilities are assumed and the
> initialization process fails. This commit postpones the PHY probe to ensure the
> PHY is accessible.
In additional to Florians comments i have a few questions.
Are you resetting the device via a GPIO? Turning a regulator off/one
etc?
Is there anything in the data sheet about how long you need to wait
before accessing the device after power on, HW reset, or software
reset etc?
Does the device reliably enumerate on the bus, i.e. reading registers
2 and 3 to get its ID?
If the PHY is broken, by some yet to be determined definition of
broken, we try to limit the workaround to as narrow as possible. So it
should not be in the core probe code. It should be in the PHY specific
driver, and ideally for only its ID, not the whole vendors family of
PHYs.
Andrew
Powered by blists - more mailing lists