linux-kernel - Re: [PATCH] PCI/pwrctl: reduce the amount of Kconfig noise

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgK=P_7LbCH9pzX4EZFYSd7HdJ8y=Fpt797F9XxT3ThUQ@mail.gmail.com>
Date: Tue, 16 Jul 2024 13:29:37 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI/pwrctl: reduce the amount of Kconfig noise

On Tue, 16 Jul 2024 at 13:10, Bartosz Golaszewski
<bartosz.golaszewski@...aro.org> wrote:
>
>     select PCI_PWRCTL_PWRSEQ if ARCH_QCOM
>
> in the ATH11K_PCI and ATH12K Kconfig entries? Am I getting this right?

So on the whole, I'd prefer these things to be done where they are
actually required.

But I'm not actually entirely sure what the hard _requirements_ from a
hardware - or a kernel build - standpoint actually are.

If there aren't any hard requirements at all, then maybe the whole "do
you want pweseq" should be an actual question (but limited only to
situations where it makes sense).

If the hard requirement is at the level of the driver itself, then the
"select" should be in the driver.

That doesn't seem to be the case here, since ATH11K_PCI certainly
works without it, but if that driver requires power sequencing on
ARCH_QCOM platforms, then maybe that is indeed the right thing.

And if the hard requirement comes from some SoC setup, then optimally
I think the "select" should be at that level, but we don't actually
seem to have that level of questions (but maybe something in

   drivers/soc/qcom/Kconfig

might make sense?)

Anyway, this is not necessarily something where there is "one correct
answer". This may be a somewhat gray area, and it looks like ARCH_QCOM
is a very big "any Qualcomm SoC" thing and not very specific.

So I'm not sure what the right answer is, but I *am* pretty sure of
what the wrong answer is. And this:

        default m if ((ATH11K_PCI || ATH12K) && ARCH_QCOM)

looks like it cannot possibly be right if ATH11K_PCI is built-in,
since then the probing of the device will happen long before that
PCI_PWRCTL_PWRSEQ module has been loaded.

And that doesn't sound sensible to me. Does it?

TL;DR:  I do think that the

      select PCI_PWRCTL_PWRSEQ if ARCH_QCOM

in the ATH11K_PCI and ATH12K Kconfig entries *may* be the right thing.
But again, I'm not actually 100% sure of the hard requirements here.

           Linus