linux-kernel - Re: [PATCH v4 2/8] PCI/pwrctrl: Add 'struct pci_pwrctrl::power

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: <20260114161706.GA809548@bhelgaas>
Date: Wed, 14 Jan 2026 10:17:06 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: manivannan.sadhasivam@....qualcomm.com
Cc: Manivannan Sadhasivam <mani@...nel.org>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Bartosz Golaszewski <brgl@...ev.pl>, linux-pci@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Chen-Yu Tsai <wens@...nel.org>,
	Brian Norris <briannorris@...omium.org>,
	Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
	Niklas Cassel <cassel@...nel.org>, Alex Elder <elder@...cstar.com>,
	Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
	Chen-Yu Tsai <wenst@...omium.org>
Subject: Re: [PATCH v4 2/8] PCI/pwrctrl: Add 'struct
 pci_pwrctrl::power_{on/off}' callbacks

On Sun, Jan 11, 2026 at 09:27:11PM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 05, 2026 at 07:25:42PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
> > 
> > To allow the pwrctrl core to control the power on/off sequences of the
> > pwrctrl drivers, add the 'struct pci_pwrctrl::power_{on/off}' callbacks and
> > populate them in the respective pwrctrl drivers.
> > 
> > The pwrctrl drivers still power on the resources on their own now. So there
> > is no functional change.
> > 
> > Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
> > Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
> > Tested-by: Chen-Yu Tsai <wenst@...omium.org>
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
> > ---
> >  drivers/pci/pwrctrl/pci-pwrctrl-pwrseq.c | 27 ++++++++++++++---
> >  drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c | 22 ++++++++++----
> >  drivers/pci/pwrctrl/slot.c               | 50 +++++++++++++++++++++++---------
> >  include/linux/pci-pwrctrl.h              |  4 +++
> >  4 files changed, 79 insertions(+), 24 deletions(-)

> > +++ b/drivers/pci/pwrctrl/slot.c
> > @@ -17,13 +17,38 @@ struct pci_pwrctrl_slot_data {
> >  	struct pci_pwrctrl ctx;
> >  	struct regulator_bulk_data *supplies;
> >  	int num_supplies;
> > +	struct clk *clk;
> >  };
> >  
> > -static void devm_pci_pwrctrl_slot_power_off(void *data)
> > +static int pci_pwrctrl_slot_power_on(struct pci_pwrctrl *ctx)
> >  {
> > -	struct pci_pwrctrl_slot_data *slot = data;
> > +	struct pci_pwrctrl_slot_data *slot = container_of(ctx, struct pci_pwrctrl_slot_data, ctx);
> > +	int ret;
> > +
> > +	ret = regulator_bulk_enable(slot->num_supplies, slot->supplies);
> > +	if (ret < 0) {
> > +		dev_err(slot->ctx.dev, "Failed to enable slot regulators\n");
> > +		return ret;
> > +	}
> > +
> > +	return clk_prepare_enable(slot->clk);
> 
> It would be nice if we could add a preparatory patch to factor out
> pci_pwrctrl_slot_power_on() before this one.  Then the slot.c patch
> would look more like the pwrseq and tc9563 ones.

tc9563 implements power control functions:

  tc9563_pwrctrl_bring_up(struct tc9563_pwrctrl_ctx *ctx)
  tc9563_pwrctrl_power_off(struct pci_pwrctrl_tc9563 *tc9563)

and this patch updates these to make the signature generic so they can
be used as callbacks:

  tc9563_pwrctrl_power_on(struct pci_pwrctrl *pwrctrl)
  tc9563_pwrctrl_power_off(struct pci_pwrctrl *pwrctrl)

This part of the patch is super straightforward -- make the signature
generic and extract the per-driver struct using the generic pointer.

I was thinking that if a preparatory patch factored out the slot power
on/off, e.g.:

  pci_pwrctrl_slot_power_on(struct pci_pwrctrl_slot_data *slot)

Then the slot.c part of this patch wouldn't move any code around, so
the structure would be identical to the tc9563 part.

pwrseq doesn't currently have the power-on/off functions factored out
either because they're so trivial, but I might even consider factoring
those out first, e.g.:

  pci_pwrctrl_pwrseq_power_on(struct pci_pwrctrl_pwrseq *pwrseq)

If we did that, this patch would be strictly conversion from
driver-specific pointer to "struct pci_pwrctrl *pwrctrl" followed by
"<driver-specific pointer = container_of(...)", so all three driver
changes would be identical and trivial to describe and review:

  - pci_pwrctrl_pwrseq_power_on(struct pci_pwrctrl_pwrseq *pwrseq)
  + pci_pwrctrl_pwrseq_power_on(struct pci_pwrctrl *pwrctrl)
  +   struct pci_pwrctrl_pwrseq *pwrseq = container_of(...);

  - tc9563_pwrctrl_bring_up(struct pci_pwrctrl_tc9563 *tc9563)
  + tc9563_pwrctrl_power_on(struct pci_pwrctrl *pwrctrl)
  +   struct pci_pwrctrl_tc9563 *tc9563 = container_of(...);

  - pci_pwrctrl_slot_power_on(struct pci_pwrctrl_slot *slot)
  + pci_pwrctrl_slot_power_on(struct pci_pwrctrl *pwrctrl)
  +   struct pci_pwrctrl_slot *slot = container_of(...);