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: <57518c46-2e92-4689-80a3-ae4c99b9fc32@prolan.hu>
Date: Wed, 3 Sep 2025 09:57:17 +0200
From: Csókás Bence <csokas.bence@...lan.hu>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
	Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam
	<festevam@...il.com>
CC: <devicetree@...r.kernel.org>, <imx@...ts.linux.dev>, Csaba Buday
	<buday.csaba@...lan.hu>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: dts: imx6ul-tx6ul: Switch away from deprecated
 `phy-reset-gpios`

Hi,

On 2025. 09. 03. 9:50, Ahmad Fatoum wrote:
> Hi,
> 
> On 03.09.25 09:43, Csókás Bence wrote:
>> Hi,
>>
>> On 2025. 09. 03. 9:28, Ahmad Fatoum wrote:
>>> Hello,
>>>
>>> On 15.08.25 17:17, Bence Csókás wrote:
>>>> The Ethernet PHY's reset GPIO should be specified in the node of the PHY
>>>> itself, instead of the MAC (`fec`). The latter is deprecated, and was an
>>>> i.MX-specific extension, incompatible with the new reset controller
>>>> subsystem.
>>>
>>> One reason to do it this way is that the PHY is in reset when the OS starts
>>> and the external phy-reset-gpios allows MAC probe to get the PHY out of
>>> reset, so it can be probed after reading its vendor/device IDs.
>>>
>>> Does switching to this new binding address this scenario? If so, it should
>>> be noted in the commit message.
>>
>> Yes, but after it has been reset, if the platform supports Power Management, the PHY's clock will be turned off, which some PHYs (in our case the LAN8710) don't tolerate. This has been reported many times, just search LKML for "lan8710 reset".
>>
>> So we want a more general solution [1] where the PHY subsystem resets them before enumerating. However, if the MAC driver claims the GPIO, then it can't be used by the PHY.
> 
> I agree that it makes sense for a PHY reset to be associated with the PHY
> device and controlled by the PHY driver. I am wary of regressions though,
> which is why I wanted the commit message to clearly spell out the implications.

You're right. We'll put this all in the message.

>> I will clarify the commit msg with this in mind.
> 
> Thanks.
> 
>> [1] https://lore.kernel.org/lkml/20250709133222.48802-4-buday.csaba@prolan.hu/
> 
> Is this mainline yet?

Unfortunately, no. It apparently still needs some polish.

Bence


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ