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, 4 Jun 2024 21:13:46 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	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>,
	Balakrishna Godavarthi <quic_bgodavar@...cinc.com>,
	Rocky Liao <quic_rjliao@...cinc.com>, Kalle Valo <kvalo@...nel.org>,
	Jeff Johnson <jjohnson@...nel.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Srini Kandagatla <srinivas.kandagatla@...aro.org>,
	Elliot Berman <quic_eberman@...cinc.com>,
	Caleb Connolly <caleb.connolly@...aro.org>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Alex Elder <elder@...nel.org>, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org, ath11k@...ts.infradead.org,
	Jeff Johnson <quic_jjohnson@...cinc.com>,
	ath12k@...ts.infradead.org, linux-pm@...r.kernel.org,
	linux-pci@...r.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
	kernel@...cinc.com, Amit Pundir <amit.pundir@...aro.org>
Subject: Re: [PATCH v8 16/17] PCI/pwrctl: add a PCI power control driver for
 power sequenced devices

On Wed, Jun 05, 2024 at 02:34:52AM +0300, Dmitry Baryshkov wrote:
> On Wed, 5 Jun 2024 at 02:23, Bjorn Helgaas <helgaas@...nel.org> wrote:
> >
> > On Tue, May 28, 2024 at 09:03:24PM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > >
> > > Add a PCI power control driver that's capable of correctly powering up
> > > devices using the power sequencing subsystem. The first users of this
> > > driver are the ath11k module on QCA6390 and ath12k on WCN7850.

> > > +static const struct of_device_id pci_pwrctl_pwrseq_of_match[] = {
> > > +     {
> > > +             /* ATH11K in QCA6390 package. */
> > > +             .compatible = "pci17cb,1101",
> > > +             .data = "wlan",
> > > +     },
> > > +     {
> > > +             /* ATH12K in WCN7850 package. */
> > > +             .compatible = "pci17cb,1107",
> > > +             .data = "wlan",
> > > +     },
> >
> > IIUC, "pci17cb,1101" and "pci17cb,1107" exist partly so we can check
> > that a DTS conforms to the schema, e.g., a "pci17cb,1101" node
> > contains all the required regulators.  For that use, we obviously need
> > a very specific "compatible" string.
> >
> > Is there any opportunity to add a more generic "compatible" string in
> > addition to those so this list doesn't have to be updated for every
> > PMU?  The .data here is "wlan" in both cases, and for this purpose, we
> > don't care whether it's "pci17cb,1101" or "pci17cb,1107".
> 
> These two devices have different set of regulators and different
> requirements to power them on.

Right, but I don't think pci_pwrctl_pwrseq_probe() knows about those
different sets.  It basically looks like:

  pci_pwrctl_pwrseq_probe(struct platform_device *pdev)
  {
    struct pci_pwrctl_pwrseq_data *data;
    struct device *dev = &pdev->dev;

    data->pwrseq = devm_pwrseq_get(dev, of_device_get_match_data(dev));
    pwrseq_power_on(data->pwrseq);
    data->ctx.dev = dev;
    devm_pci_pwrctl_device_set_ready(dev, &data->ctx);
  }

I think of_device_get_match_data(dev) will return "wlan" for both
"pci17cb,1101" and "pci17cb,1107", so devm_pwrseq_get(),
pwrseq_power_on(), and devm_pci_pwrctl_device_set_ready() don't see
the distinction between them.

Of course, they also get "dev", so they can find the device-specifc
stuff that way, but I think that's on the drivers/power/sequencing/
side, not in this pci-pwrctl-pwrseq driver itself.

So what if there were a more generic "compatible" string, e.g., if the
DT contained something like this:

  wifi@0 {
    compatible = "pci17cb,1101", "wlan-pwrseq";
    ...
  }

and pci_pwrctl_pwrseq_of_match[] had this:

  { .compatible = "wlan-pwrseq", .data = "wlan", }

Wouldn't this pci-pwrctl-pwrseq driver work the same?  I'm not a DT
whiz, so likely I'm missing something, but it would be nice if we
didn't have to update this very generic-looking driver to add every
device that needs it.

Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ