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

[Manivannan Sadhasivam]

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@xxxxxxxxx> 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

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