linux-kernel - Re: [PATCH v3] PCI/pwrctrl: Move pci_pwrctrl_create_device() definition to drivers/pci/pwrctrl/

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: <pwb4g7worzsnryimt3ymdfsxu7bxvhlr74rqodmiof5auolhrc@vpi7wzrp7osh>
Date: Mon, 16 Jun 2025 19:14:50 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Lukas Wunner <lukas@...ner.de>, kernel test robot <lkp@...el.com>, 
	bhelgaas@...gle.com, oe-kbuild-all@...ts.linux.dev, linux-pci@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Jim Quinlan <james.quinlan@...adcom.com>, 
	Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [PATCH v3] PCI/pwrctrl: Move pci_pwrctrl_create_device()
 definition to drivers/pci/pwrctrl/

On Mon, Jun 16, 2025 at 03:30:27PM +0200, Bartosz Golaszewski wrote:
> On Mon, Jun 16, 2025 at 3:16 PM Lukas Wunner <lukas@...ner.de> wrote:
> >
> > On Mon, Jun 16, 2025 at 06:07:48PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Jun 16, 2025 at 08:21:20PM +0800, kernel test robot wrote:
> > > >    ld: drivers/pci/probe.o: in function `pci_scan_single_device':
> > > > >> probe.c:(.text+0x2400): undefined reference to `pci_pwrctrl_create_device'
> > >
> > > Hmm, so we cannot have a built-in driver depend on a module...
> > >
> > > Bartosz, should we make CONFIG_PCI_PWRCTRL bool then? We can still allow the
> > > individual pwrctrl drivers be tristate.
> >
> > I guess the alternative is to just leave it in probe.c.  The function is
> > optimized away in the CONFIG_OF=n case because of_pci_find_child_device()
> > returns NULL.  It's unpleasant that it lives outside of pwrctrl/core.c,
> > but it doesn't occupy any space in the compiled kernel at least on non-OF
> > (e.g. ACPI) platforms.
> >
> 
> And there's a third option of having this function live in a separate
> .c file under drivers/pci/pwrctl/ that would be always built-in even
> if PWRCTL itself is a module. The best/worst of two worlds? :)
> 

I would try to avoid the third option at any cost ;) Because the pwrctrl/core.c
would no longer be the 'core' and the code structure would look distorted.

Let's see what Bjorn thinks about option 1 and 2. I did not account for the
built-in vs modular dependency when Bjorn asked me if the move was possible. And
I now vaguely remember that I kept it in probe.c initially because of this
dependency.
 
- Mani

-- 
மணிவண்ணன் சதாசிவம்