linux-kernel - Re: [PATCH v2 7/9] arm64: dts: rockchip: use generic Ethernet PHY reset bindings for Lunzn Fastrhino R68S

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] [day] [month] [year] [list]

Message-ID: <08cc4f4c-5c26-4dbd-8fbc-5686fbc06b80@kwiboo.se>
Date: Wed, 10 Jul 2024 17:07:22 +0200
From: Jonas Karlman <jonas@...boo.se>
To: Chukun Pan <amadeus@....edu.cn>
Cc: conor+dt@...nel.org, devicetree@...r.kernel.org, heiko@...ech.de,
 krzk+dt@...nel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
 robh@...nel.org
Subject: Re: [PATCH v2 7/9] arm64: dts: rockchip: use generic Ethernet PHY
 reset bindings for Lunzn Fastrhino R68S

On 2024-07-10 16:50, Chukun Pan wrote:
>> Where do you find the 72ms in the datasheet?
> 
> I refer to this commit:
> https://github.com/torvalds/linux/commit/1c7412530d5d0e0a0b27f1642f5c13c8b9f36f05
> BTW I found that some boards use the RTL8211F-VD PHY,
> but I can't find the datasheet.

Thanks, I can also see in RTL8211F-VD-CG (Rev 1.0 - 08 February 2022):

  For a complete PHY reset, this pin must be asserted low for at least
  10ms for the internal regulator. Wait for at least 72ms* before
  accessing the PHY register. * Note: Not included the 0.9V rise time.

So using 80-100ms may be the best option to be on the safe side, should
probably send a fix for recently added boards where I used 50ms.

Regards,
Jonas

> 
>> In RTL8211F-CG v1.1 I see 10ms and minimum of 30ms, in v1.2 and v1.4
>> I see 10ms and minimum of 50ms.
> 
>> I have used 50ms on a few recently added boards and they seem to all
>> work fine with 50ms, wonder if the deassert delay should be changed for
>> those boards.
> 
> Thanks,
> Chukun
>