linux-kernel - Re: [PATCH v2 4/5] dt-bindings: net: Add documentation for optional regulators

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]

Date:   Thu, 19 May 2022 13:58:18 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Corentin Labbe <clabbe@...libre.com>,
        calvin.johnson@....nxp.com, davem@...emloft.net,
        edumazet@...gle.com, hkallweit1@...il.com,
        jernej.skrabec@...il.com, krzysztof.kozlowski+dt@...aro.org,
        kuba@...nel.org, lgirdwood@...il.com, linux@...linux.org.uk,
        pabeni@...hat.com, robh+dt@...nel.org, samuel@...lland.org,
        wens@...e.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...ts.linux.dev, netdev@...r.kernel.org
Subject: Re: [PATCH v2 4/5] dt-bindings: net: Add documentation for optional
 regulators

On Thu, May 19, 2022 at 01:33:21PM +0200, Krzysztof Kozlowski wrote:
> On 19/05/2022 13:31, Mark Brown wrote:
> > On Thu, May 19, 2022 at 11:55:28AM +0200, Krzysztof Kozlowski wrote:
> >> On 18/05/2022 22:09, Corentin Labbe wrote:
> > 
> >>> +  regulators:
> >>> +    description:
> >>> +       List of phandle to regulators needed for the PHY
> > 
> >> I don't understand that... is your PHY defining the regulators or using
> >> supplies? If it needs a regulator (as a supply), you need to document
> >> supplies, using existing bindings.
> > 
> > They're trying to have a generic driver which works with any random PHY
> > so the binding has no idea what supplies it might need.
> 
> OK, that makes sense, but then question is why not using existing
> naming, so "supplies" and "supply-names"?

I'm not saying it is not possible, but in general, the names are not
interesting. All that is needed is that they are all on, or
potentially all off to save power on shutdown. We don't care how many
there are, or what order they are enabled.

Ethernet PHY can have multiple supplies. For example there can be two
digital voltages and one analogue. Most designs just hard wire them
always on. It would not be unreasonable to have one GPIO which
controls all three. Or there could be one GPIO for the two digital
supplies, and one for the analogue. Or potentially, three GPIOs.

Given all the different ways the board could be designed, i doubt any
driver is going to want to control its supplies in an way other than
all on, or all off. 802.3 clause 22 defines a standardized way to put
a PHY into a low power mode. Using that one bit is much simpler than
trying to figure out how a board is wired.

However, the API/binding should be generic, usable for other use
cases. Nobody has needed an API like this before, but it is not to say
it might have other uses in the future. So maybe "supplies" and
"supply-names" is useful, but we still need a way to enumerate them as
a list without caring how many there are, or what their names are.

  Andrew