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

Powered by blists - more mailing lists