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: <CAMRc=Mf=Z+d3UKdwEXkw1Xm9G=qVwh6=fXsfgS6JiOM6Z7H50w@mail.gmail.com>
Date: Mon, 16 Jun 2025 15:30:27 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Lukas Wunner <lukas@...ner.de>
Cc: Manivannan Sadhasivam <mani@...nel.org>, 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 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? :)

Bart