[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f125c7d5-5f85-4ff6-999b-2098ff3103f9@sirena.org.uk>
Date: Thu, 17 Oct 2024 14:22:01 +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 02:21:08PM +0200, Bartosz Golaszewski wrote:
> A device is wired differently on different platforms. It requests a
> bunch of supplies using devm_regulator_bulk_get(). One of them is
> unconnected on one of the platforms resulting in the "using dummy
> regulator" warning.
> Concrete use-case is: make all but one regulator mandatory when
> calling regulator_bulk_get(). My proposal is extending struct
> regulator_bulk_data with a boolean flag called "optional" which would
> result in the underlying _regulator_get() receiving the OPTIONAL_GET
> flag only for the regulators that are marked as such.
Sure, but doesn't the device need to know that this supply isn't
connected - if we can just ignore the result then why bother powering
the supply on at all?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists