netdev - Re: [PATCH] net: phy: return EPROBE_DEFER if PHY is not accessible

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:   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