netdev - Re: [PATCH v5 16/18] power: pwrseq: add a driver for the QCA6390 PMU module

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]

Message-ID: <CAMRc=Mdsg5gDCKD-=ok=mfYJoFpUVpTGFUE+om+WPYvQOc0rzA@mail.gmail.com>
Date: Sat, 17 Feb 2024 20:09:08 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
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>, 
	Mark Brown <broonie@...nel.org>, 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>, 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 16/18] power: pwrseq: add a driver for the QCA6390 PMU module

On Sat, Feb 17, 2024 at 12:17 AM Dmitry Baryshkov
<dmitry.baryshkov@...aro.org> wrote:
>
> On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@...ev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >
> > This adds the power sequencing driver for the QCA6390's PMU module. It
> > uses the pwrseq subsystem and knows how to match the sequencer to the
> > consumer device by verifying the relevant properties and DT layout.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > ---

[snip]

> > +
> > +static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_common[] = {
> > +       {
> > +               .name = "vddio",
> > +               .load_uA = 20000,
> > +       },
> > +       {
> > +               .name = "vddaon",
> > +               .load_uA = 100000,
> > +       },
> > +       {
> > +               .name = "vddpmu",
> > +               .load_uA = 1250000,
> > +       },
> > +       {
> > +               .name = "vddrfa0p95",
> > +               .load_uA = 200000,
> > +       },
> > +       {
> > +               .name = "vddrfa1p3",
> > +               .load_uA = 400000,
> > +       },
> > +       {
> > +               .name = "vddrfa1p9",
> > +               .load_uA = 400000,
> > +       },
> > +};
> > +
> > +static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_wlan[] = {
> > +       {
> > +               .name = "vddpcie1p3",
> > +               .load_uA = 35000,
> > +       },
> > +       {
> > +               .name = "vddpcie1p9",
> > +               .load_uA = 15000,
> > +       },
> > +};
>
> I thought that we had discussed this already. According to the docs,
> all PMU supplies should be powered on when the chip is being switched
> on, no matter whether it is for the WiFi or for the BT.
>

I know, I mostly did it to make Bjorn happy because he was adamant we
don't need the PCIe regulators for BT and when I checked, it does work
in practice so I thought: whatever. But indeed, the docs say
otherwise. Noted for v6.

[snip]

> > +
> > +static const struct pwrseq_unit_data pwrseq_qca6390_bt_unit_data = {
> > +       .name = "bluetooth-enable",
> > +       .deps = pwrseq_qca6390_unit_deps,
>
> Can we call corresponding regulator_bulk functions from bt and wlan
> enable/disable? This will save us from building the tree-like
> structures (and possible loops inside that tree).
>

Can we? Sure, but the dependency graph (yeah, we should enforce it to
be acyclic) is what makes this code future-proof and allows it to
avoid repeating calls in different targets.

[snip]

Bart