linux-kernel - Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869

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: <0bba1378-0847-491f-8f21-ac939ac48820@ti.com>
Date:   Wed, 20 May 2020 15:02:24 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Florian Fainelli <f.fainelli@...il.com>, <hkallweit1@...il.com>,
        <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal
 delay for DP83869

Andrew

On 5/20/20 2:27 PM, Andrew Lunn wrote:
> Hi Dan
>
>> UGH I think I just got volunteered to do make them common.
> There is code you can copy from PHY drivers. :-)
>
> What would be kind of nice is if the validate was in the core as
> well. Pass a list of possible delays in pS, and it will do a
> phydev_err() if what is in DT does not match one of the listed
> delays. Take a look around at what current drivers do and see if you
> can find a nice abstraction which will work for a few drivers. We
> cannot easily convert existing drivers without breaking DT, but a
> design which works in theory for what we currently have has a good
> chance of working for any new PHY driver.

I think adding it in the core would be a bit of a challenge.  I think 
each PHY driver needs to handle parsing and validating this property on 
its own (like fifo-depth).  It is a PHY specific setting.

Take the DP83867/9 and the ADIN1200/ADIN1300.

The 8386X devices has a delta granularity of 250pS and the AD devices is 
200pS per each setting

And the 867/9 has 3x more values (15) vs only 5 for the AD PHY.

And the Atheros AR803x PHY does use rgmii-id in the yaml, which I guess 
is what you were pointing out, that if set the PHY uses a default 2nS 
delay and it is not configurable.

Same with the Broadcomm.

Ack to not changing already existing drivers which is only 2 the AD PHY 
and the DP83867 PHY.  But I can update the yaml for the 83867 and mark 
the TI specific properties as deprecated in favor of the new properties 
like I did with fifo-depth.

Dan

>       Andrew