[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <otrstq3g55ddtlbelzgyirpt5ahfirgkhrrietyrgbhxbueiwp@hyu4pgj6m4eo>
Date: Fri, 30 May 2025 08:46:30 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Jim Quinlan <james.quinlan@...adcom.com>
Cc: Bjorn Helgaas <helgaas@...nel.org>, Lukas Wunner <lukas@...ner.de>,
linux-pci@...r.kernel.org, Cyril Brulebois <kibi@...ian.org>,
Nicolas Saenz Julienne <nsaenz@...nel.org>, Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Krzysztof Wilczy??ski <kwilczynski@...nel.org>, Bartosz Golaszewski <brgl@...ev.pl>,
bcm-kernel-feedback-list@...adcom.com, linux-kernel@...r.kernel.org,
Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH] PCI/pwrctrl: Skip creating platform device unless
CONFIG_PCI_PWRCTL enabled
On Thu, May 29, 2025 at 03:23:29PM -0400, Jim Quinlan wrote:
> On Tue, May 27, 2025 at 6:25 PM Bjorn Helgaas <helgaas@...nel.org> wrote:
> >
> > On Sat, May 24, 2025 at 02:21:04PM +0530, Manivannan Sadhasivam wrote:
> > > On Sat, May 24, 2025 at 08:29:46AM +0200, Lukas Wunner wrote:
> > > > On Fri, May 23, 2025 at 09:42:07PM -0500, Bjorn Helgaas wrote:
> > > > > What I would prefer is something like the first paragraph in that
> > > > > section: the #ifdef in a header file that declares the function and
> > > > > defines a no-op stub, with the implementation in some pwrctrl file.
> > > >
> > > > pci_pwrctrl_create_device() is static, but it is possible to #ifdef
> > > > the whole function in the .c file and provide the stub in an #else
> > > > branch. That's easier to follow than #ifdef'ing portions of the
> > > > function.
> > > >
> > >
> > > +1
> >
> > I dropped the ball here and didn't get any fix for this in v6.15.
>
> :-(
>
> >
> >
> > Why do we need pci_pwrctrl_create_device() in drivers/pci/probe.c?
> > The obvious thing would have been to put the implementation in
> > drivers/pci/pwrctrl with a stub in drivers/pci/pci.h, so I assume
> > there's some reason we can't do that?
>
> I was wondering if we could confine PWRCTL/_SLOT to work on a per PCIe
> controller basis. For example, if we allow the port DT node to have
> boolean "pwrctrl;" property, it would direct the PWRCTL code to
> operate on the regulators within that node. This would allow
> CONFIG_PWRCTL/_SLOT and the pcie-brcmstb.c way of controlling
> regulators to happily coexist.
>
> One could argue that "pwrctrl;" does not describe the HW as a DT
> property should, but I think it should be considered nevertheless.
>
No. There were a lot of attempts previously before the advent of pwrctrl
framework to add a DT property for powering the devices, but DT maintainer
clearly said that there should be no DT property for this purpose. So we came up
with this approach.
- Mani
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists