On Tue, 16 Jul 2024 at 21:02, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 16 Jul 2024 at 11:48, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> >
> > But this patch does it. PCI_PWRCTL_PWRSEQ becomes a hidden symbol and
> > the entire submenu for PCI_PWRCTL disappears. There's no question in
> > Kconfig anymore.
>
> Yes, but look here:
>
> default m if ((ATH11K_PCI || ATH12K) && ARCH_QCOM)
>
> That has at least two issues:
>
> - what if ATH11K_PCI or ATH12K is built-in and needs this driver?
> "default m" is *NOT* valid.
>
> - what happens when you add new drivers? You keep making this line
> longer and more complicated?
>
> See why I say "use select" instead? It means that the drivers that
> need it can select it, and you avoid complicated "list X drivers"
> things, but you can also get the *right* selection criteria, so that a
> built-in driver will select a built-in PCI_PWRCTL_PWRSEQ option.
>
> Linus
Should we do:
select PCI_PWRCTL_PWRSEQ if ARCH_QCOM
in the ATH11K_PCI and ATH12K Kconfig entries? Am I getting this right?
Because unconditional select here makes no sense - 99,9% users of ATH
drivers don't need PCI_PWRCTL_PWRSEQ.
Or add a new symbol like ARCH_NEED_PWRCTL_PWRSEQ and select it from
ARCH_QCOM (and later from any other arch that will use it) and do:
select PCI_PWRCTL_PWRSEQ if ARCH_NEED_PWRCTL_PWRSEQ
in ATH entries?
Bartosz
