netdev - Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Tue, 20 Feb 2024 13:31:25 +0000
From: Mark Brown <broonie@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Marcel Holtmann <marcel@...tmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@...il.com>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>, Kalle Valo <kvalo@...nel.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Saravana Kannan <saravanak@...gle.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Arnd Bergmann <arnd@...db.de>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Alex Elder <elder@...aro.org>,
	Srini Kandagatla <srinivas.kandagatla@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Abel Vesa <abel.vesa@...aro.org>,
	Manivannan Sadhasivam <mani@...nel.org>,
	Lukas Wunner <lukas@...ner.de>,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-pci@...r.kernel.org,
	linux-pm@...r.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of
 the QCA6391

On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@...nel.org> wrote:
> > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:

> > > No, the users don't request any regulators (or rather: software
> > > representations thereof) because - as per the cover letter - no
> > > regulators are created by the PMU driver. This is what is physically
> > > on the board - as the schematics and the datasheet define it. I took

> > The above makes no sense.  How can constraints be "what is physically on
> > the board", particularly variable constrants when there isn't even a
> > consumer?  What values are you taking from which documentation?

> The operating conditions for PMU outputs. I took them from a
> confidential datasheet. There's a table for input constraints and
> possible output values.

That sounds like you're just putting the maximum range of voltages that
the PMU can output in there.  This is a fundamental misunderstanding of
what the constraints are for, the constraints exist to specify what is
safe on a specific board which will in essentially all cases be much
more restricted.  The regulator driver should describe whatever the PMU
can support by itself, the constraints whatever is actually safe and
functional on the specific board.

> And what do you mean by there not being any consumers? The WLAN and BT
> *are* the consumers.

There are no drivers that bind to the regulators and vary the voltages
at runtime.

> > > the values from the docs verbatim. In C, we create a power sequencing
> > > provider which doesn't use the regulator framework at all.

> > For something that doesn't use the regulator framework at all what
> > appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> > the QCA6390 PMU module") seems to have a lot of regualtor API calls?

> This driver is a power sequencing *provider* but also a regulator
> *consumer*. It gets regulators from the host and exposes a power
> sequencer to *its* consumers (WLAN and BT). On DT it exposes
> regulators (LDO outputs of the PMU) but we don't instantiate them in
> C.

Right, which sounds a lot like being a user of the regualtor framework.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)