Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 19 May 2022 13:58:18 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Mark Brown <broonie@kernel.org>,
        Corentin Labbe <clabbe@baylibre.com>,
        calvin.johnson@oss.nxp.com, davem@davemloft.net,
        edumazet@google.com, hkallweit1@gmail.com,
        jernej.skrabec@gmail.com, krzysztof.kozlowski+dt@linaro.org,
        kuba@kernel.org, lgirdwood@gmail.com, linux@armlinux.org.uk,
        pabeni@redhat.com, robh+dt@kernel.org, samuel@sholland.org,
        wens@csie.org, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-sunxi@lists.linux.dev, netdev@vger.kernel.org
Subject: Re: [PATCH v2 4/5] dt-bindings: net: Add documentation for optional
 regulators
Message-ID: <YoYw2lKbgCiDXP0A@lunn.ch>
References: <20220518200939.689308-1-clabbe@baylibre.com>
 <20220518200939.689308-5-clabbe@baylibre.com>
 <95f3f0a4-17e6-ec5f-6f2f-23a5a4993a44@linaro.org>
 <YoYqmAB3P7fNOSVG@sirena.org.uk>
 <c74b0524-60c6-c3af-e35f-13521ba2b02e@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c74b0524-60c6-c3af-e35f-13521ba2b02e@linaro.org>
Precedence: bulk

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