From: Rob Herring <robh@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Mark Brown <broonie@kernel.org>,
LABBE Corentin <clabbe@baylibre.com>,
alexandre.torgue@foss.st.com, calvin.johnson@oss.nxp.com,
davem@davemloft.net, edumazet@google.com, hkallweit1@gmail.com,
jernej.skrabec@gmail.com, joabreu@synopsys.com,
krzysztof.kozlowski+dt@linaro.org, kuba@kernel.org,
lgirdwood@gmail.com, linux@armlinux.org.uk, pabeni@redhat.com,
peppe.cavallaro@st.com, samuel@sholland.org, wens@csie.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply
Date: Mon, 16 May 2022 19:47:04 -0500 [thread overview]
Message-ID: <20220517004704.GA3654797-robh@kernel.org> (raw)
In-Reply-To: <YnlDbbegQ1IbbaHy@lunn.ch>
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
next prev parent reply other threads:[~2022-05-17 0:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 7:48 [PATCH 0/6] arm64: add ethernet to orange pi 3 Corentin Labbe
2022-05-09 7:48 ` [PATCH 1/6] phy: handle optional regulator for PHY Corentin Labbe
2022-05-09 7:48 ` [PATCH 2/6] net: stmmac: dwmac-sun8i: remove regulator Corentin Labbe
2022-05-09 14:09 ` Andre Przywara
2022-05-09 14:38 ` LABBE Corentin
2022-05-09 7:48 ` [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply Corentin Labbe
2022-05-09 12:17 ` Andrew Lunn
2022-05-09 13:26 ` LABBE Corentin
2022-05-09 16:02 ` Andrew Lunn
2022-05-09 16:12 ` Mark Brown
2022-05-09 16:38 ` Andrew Lunn
2022-05-09 16:56 ` Mark Brown
2022-05-11 8:02 ` LABBE Corentin
2022-05-11 12:50 ` Mark Brown
2022-05-17 0:47 ` Rob Herring [this message]
2022-05-09 7:48 ` [PATCH 4/6] ARM: dts: sunxi: move phy regulator in PHY node Corentin Labbe
2022-05-09 10:55 ` Andre Przywara
2022-05-09 11:16 ` LABBE Corentin
2022-05-09 7:48 ` [PATCH 5/6] arm64: dts: allwinner: " Corentin Labbe
2022-05-09 7:48 ` [PATCH 6/6] arm64: dts: allwinner: orange-pi-3: Enable ethernet Corentin Labbe
2022-05-09 12:20 ` [PATCH 0/6] arm64: add ethernet to orange pi 3 Andrew Lunn
2022-05-09 13:27 ` LABBE Corentin
2022-05-09 15:19 ` Andrew Lunn
2022-05-09 15:24 ` LABBE Corentin
2022-05-09 15:56 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220517004704.GA3654797-robh@kernel.org \
--to=robh@kernel.org \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew@lunn.ch \
--cc=broonie@kernel.org \
--cc=calvin.johnson@oss.nxp.com \
--cc=clabbe@baylibre.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=joabreu@synopsys.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=samuel@sholland.org \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).