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]

Message-ID: <DS7PR10MB4926A59970F3DEAE76542FFFFA8E9@DS7PR10MB4926.namprd10.prod.outlook.com>
Date:   Thu, 30 Mar 2023 07:46:13 +0000
From:   "Buzarra, Arturo" <Arturo.Buzarra@...i.com>
To:     Russell King <linux@...linux.org.uk>, Andrew Lunn <andrew@...n.ch>
CC:     Heiner Kallweit <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: RE: [PATCH] net: phy: return EPROBE_DEFER if PHY is not accessible

Hi,

" Which clock is it exactly? Both for the MAC and the PHY?"
Yes, you can clock both from a crystal or like in this case from the SoC.

" Is eth-ck being fed to both the MAC and the PHY? Is this the missing clock?"
Yes, It is the clock that only is available when the second Ethernet MAC (RMII) is initialized

" What exactly is this clock?"
This clock cames from the SoC, it is initialized in stm32mp1_set_mode() with the register value " val |= dwmac->ops->pmcsetr.eth2_ref_clk_sel;"

" Maybe meson8b_dwmac_register_clk() is a useful example?"
After reviewing your suggestion, I saw that the MAC driver "dwmac-stm32.c" doesn't have devm_clk_register(), so I'm assuming it doesn't register it as a clock provider. 

I will try to work on that way to create a clock dependency between MAC and PHY.

Regardless, what do you think reading 0x0000 or 0xFFFF should be considered as a PHY error?

Thanks,

Arturo.

-----Original Message-----
From: Russell King <linux@...linux.org.uk> 
Sent: jueves, 23 de marzo de 2023 15:36
To: Andrew Lunn <andrew@...n.ch>
Cc: Buzarra, Arturo <Arturo.Buzarra@...i.com>; Heiner Kallweit <hkallweit1@...il.com>; netdev@...r.kernel.org; Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH] net: phy: return EPROBE_DEFER if PHY is not accessible

[EXTERNAL E-MAIL] Warning! This email originated outside of the organization! Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Thu, Mar 23, 2023 at 03:19:21PM +0100, Andrew Lunn wrote:
> > Gigabit PHY has its own Crystal, however the 10/100 PHY uses a clock 
> > from the CPU and it is the root cause of the issue because when 
> > Linux asks the PHY capabilities the clock is not ready yet.
>
> O.K, now we are getting closer.
>
> Which clock is it exactly? Both for the MAC and the PHY?

Just a passing observation but... considering stmmac needs the clock from the PHY in order to do even basic things, it doesn't surprise me that there's a PHY out there that doesn't work without a clock provided from the "other side" to also do the most basic things such as read the IDs!

Hardware folk always find wonderful ways to break stuff and then need software to fix it... :/

That all said, if the clock that's being discussed is the MDC signal (MDIO interface clock) then /really/ (and obviously) that's a matter for the MDIO driver to ensure that clock is available to run before registering itself.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!