linux-kernel - Re: [PATCH 3/3] arm64: dts: qcom: x1e80100-qcp: Add WiFi/BT pwrseq

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=MddPDFaw6vYo1FzXHbUsLyr2QKT6oy2i68ZCdJdFWCJww@mail.gmail.com>
Date: Thu, 17 Oct 2024 13:28:00 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Mark Brown <broonie@...nel.org>
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 12:59 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Thu, Oct 17, 2024 at 11:28:18AM +0200, Bartosz Golaszewski wrote:
>
> > How do others deal with it? I'm asking because I've been seeing these
> > warnings for years on many platforms which makes me think they are not
> > a high priority for anyone.
>
> > The best approach would be to provide an optional bulk get for the
> > regulator API. Or extend struct regulator_bulk_data with bool optional
> > and take this into account.
>
> > Mark: Any thoughts on this?
>
> 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?

Bartosz