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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ