linux-kernel - Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

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: <20220517004704.GA3654797-robh@kernel.org>
Date:   Mon, 16 May 2022 19:47:04 -0500
From:   Rob Herring <robh@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Mark Brown <broonie@...nel.org>,
        LABBE Corentin <clabbe@...libre.com>,
        alexandre.torgue@...s.st.com, calvin.johnson@....nxp.com,
        davem@...emloft.net, edumazet@...gle.com, hkallweit1@...il.com,
        jernej.skrabec@...il.com, joabreu@...opsys.com,
        krzysztof.kozlowski+dt@...aro.org, kuba@...nel.org,
        lgirdwood@...il.com, linux@...linux.org.uk, pabeni@...hat.com,
        peppe.cavallaro@...com, samuel@...lland.org, wens@...e.org,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote:
> > No, that's not a thing - the supplies are individual, named properties
> > and even if there were a list we'd still want them to be named so it's
> > clear what's going on.
> 
> So we have a collection of regulators, varying in numbers between
> different PHYs, with different vendor names and purposes. In general,
> they all should be turned on. Yet we want them named so it is clear
> what is going on.

In what order do we turn the supplies on? How much time in between each 
one? Does an external clock need to be running before or after (and how 
long after). Oh, and what about resets and the order and timing of them 
relative to everything else?

This always happens in the same order. First, it's just one resource 
like a regulator or reset. Then one more. Then another device with some 
timing constraints. If we wanted a generic solution in DT, it would need 
to be able to describe any power sequencing waveform. But we don't have 
that because we don't want it. 

> Is there a generic solution here so that the phylib core can somehow
> enumerate them and turn them on, without actually knowing what they
> are called because they have vendor specific names in order to be
> clear what they are?

Other devices have specific compatibles so that the device can be 
identified and powered up. Once again, MDIO should not be special here.

> There must be a solution to this, phylib cannot be the first subsystem
> to have this requirement, so if you could point to an example, that
> would be great.

Well, no one seems to want to make non-discoverable devices on 
'discoverable' buses work. Still an issue for PCI and USB. I thought 
MDIO had a solution here to probe any devices in the DT even if not 
discovered.

Rob