[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a14e5488-d0e8-4f04-b419-0b4c566219bf@sirena.org.uk>
Date: Thu, 17 Oct 2024 13:00:53 +0100
From: Mark Brown <broonie@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>,
Johan Hovold <johan@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Abel Vesa <abel.vesa@...aro.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH 3/3] arm64: dts: qcom: x1e80100-qcp: Add WiFi/BT pwrseq
On Thu, Oct 17, 2024 at 01:28:00PM +0200, Bartosz Golaszewski wrote:
> On Thu, Oct 17, 2024 at 12:59 PM Mark Brown <broonie@...nel.org> wrote:
> > Fix your driver to request the supplies that actually exist on the
> > device rather than just some random supplies you hope will work?
> Let me rephrase: the device has this supply but on this particular
> board nothing is connected to it. It does sound to me like an example
> of an "optional" supply. Do you have anything against making it
> possible to define optional supplies when using the bulk regulator
> APIs?
Oh, right - please if asking questions ask a complete question rather
than having a long email thread and adding an "any thoughts" at the end
which makes it unclear what the actual question is. In general the
expectation for optional supplies is that you will need to do something
different depending on if the supply is there, that will tend to mean
that it's fairly natural to do a separate request for it as well.
What's the concrete use case here?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists