linux-kernel - Re: [PATCH] RFC: net: phy: of phys probe/reset issue

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: <ade12434-adf2-6ea7-24ce-ce45ad2e1b5e@gmail.com>
Date:   Wed, 28 Oct 2020 14:05:35 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Grygorii Strashko <grygorii.strashko@...com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Sekhar Nori <nsekhar@...com>, linux-kernel@...r.kernel.org,
        Vignesh Raghavendra <vigneshr@...com>,
        Roger Quadros <rogerq@...com>,
        Russell King <linux@...linux.org.uk>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH] RFC: net: phy: of phys probe/reset issue



On 10/28/2020 12:32 PM, Grygorii Strashko wrote:
> hi Andrew,
> 
> On 23/10/2020 23:10, Andrew Lunn wrote:
>>> Yes there is: have your Ethernet PHY compatible string be of the form
>>> "ethernetAAAA.BBBB" and then there is no need for such hacking.
>>> of_get_phy_id() will parse that compatible and that will trigger
>>> of_mdiobus_register_phy() to take the phy_device_create() path.
>>
>> Yep. That does seem like the cleanest way to do this. Let the PHY
>> driver deal with the resources it needs.
> 
> Thanks you for your comments.
> 
> huh. I gave it try and some thinking. it works as W/A, but what does it
> mean in the long term?

I believe this was made clearer before: this is the only forward that
works across all subsystems, independently of the PHY and MDIO layers.

> 
> Neither Linux documentation, neither DT bindings suggest such solution
> in any way
> (and there is *Zero* users of ""ethernet-phy-id%4x.%4x" in the current
> LKML).
> And the main reason for this RFC is really bad customer experience while
> migrating to the new kernels, as
> mdio reset does not support multi-phys and phy resets are not working.

It is documented in the binding, but the binding is a document about a
contract, not about how Linux implements things, so I suppose you are
right that we are missing additional documentation to describe how it is
useful:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/ethernet-phy.yaml#n30

> 
> Following your comments, my understanding for the long term (to avoid
> user's confusions) is:
> "for OF case the usage of 'ethernet-phy-id%4x.%4x' compatibly is became
> mandatory for PHYs
> to avoid PHY resets dependencies from board design and bootloader".
> 
> Which in turn means - update all reference boards by adding
> ""ethernet-phy-id%4x.%4x" and add
> new DT board files for boards which are differ by only PHY version.

Well, you can have the boot loader absorb some of those board specific
details, after all, the entire point of moving ARM towards Device Tree
was to do just that. The appended DTB was offered as an interim solution.
-- 
Florian