Message ID | 1df9dda1-1f40-4e13-b79b-350690295ab5@app.fastmail.com (mailing list archive) |
---|---|
State | Mainlined |
Headers | show |
Series | soc tree for 6.11 | expand |
The pull request you sent on Mon, 15 Jul 2024 23:05:40 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-drivers-6.11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cc0f7c3f97bc6e888bf4be28a9da9dbd3735d2b4
Thank you!
On Mon, 15 Jul 2024 at 13:59, Arnd Bergmann <arnd@arndb.de> wrote: > > soc: driver updates for 6.11 Christ people, am I the only one actually testing any of this? > Bartosz Golaszewski (14): > firmware: qcom: add a dedicated TrustZone buffer allocator This causes me to get a new and COMPLETELY NONSENSICAL question on my regular AMD Threadripper workstation config. I'm getting quite fed up with all the constant complete disregard for any sanity in Kconfig files. People are putting in COMPLETE GARBAGE here, and apparently nobody bothers to test it for any kind of sanity. This kind of crap needs to stop. I think the fix is to just add a depends on QCOM_TZMEM to that thing, but on my Altra machine even that doesn't fix this horror, because it turns out that everybody and their dog ends up doing select QCOM_SCM and we have QCOM_SCM doing select QCOM_TZMEM so it's hard as hell to actually get rid of that pointless churn, because you have to figure out which random driver ends up allegedly "needing" this. Are any of these actually _needed_? Because while I like automatic "select" things just picking the infrastructure that a driver actually requires to work, this all does *NOT* smell like "required infrastructure". This smells like random "do you actually want this?" to me. And the answer is "No. No I damn well do not". Particularly on my AMD machine that most definitely does not have some Qualcomm TrustZone thing. Linus
On Tue, 16 Jul 2024 at 21:53, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, 15 Jul 2024 at 13:59, Arnd Bergmann <arnd@arndb.de> wrote: > > > > soc: driver updates for 6.11 > > Christ people, am I the only one actually testing any of this? > TBH it never occurred to me to test pure `make config`. I use `make menuconfig` almost exclusively and never noticed this issue for that reason. > > Bartosz Golaszewski (14): > > firmware: qcom: add a dedicated TrustZone buffer allocator > > This causes me to get a new and COMPLETELY NONSENSICAL question on my > regular AMD Threadripper workstation config. > > I'm getting quite fed up with all the constant complete disregard for > any sanity in Kconfig files. People are putting in COMPLETE GARBAGE > here, and apparently nobody bothers to test it for any kind of sanity. > > This kind of crap needs to stop. > > I think the fix is to just add a > > depends on QCOM_TZMEM > > to that thing, but on my Altra machine even that doesn't fix this > horror, because it turns out that everybody and their dog ends up > doing > > select QCOM_SCM > > and we have QCOM_SCM doing > > select QCOM_TZMEM > > so it's hard as hell to actually get rid of that pointless churn, > because you have to figure out which random driver ends up allegedly > "needing" this. > > Are any of these actually _needed_? Because while I like automatic > "select" things just picking the infrastructure that a driver actually > requires to work, this all does *NOT* smell like "required > infrastructure". > > This smells like random "do you actually want this?" to me. > > And the answer is "No. No I damn well do not". Particularly on my AMD > machine that most definitely does not have some Qualcomm TrustZone > thing. > > Linus There's a patch from Geert already on the list[1] that should address this. Bartosz [1] https://lore.kernel.org/lkml/74947f7f132a811cc951749907b01bd25dcf23e6.1721135509.git.geert+renesas@glider.be/
On Tue, 16 Jul 2024 at 13:16, Bartosz Golaszewski <bartosz.golaszewski@linaro.org> wrote: > > TBH it never occurred to me to test pure `make config`. I use `make > menuconfig` almost exclusively and never noticed this issue for that > reason. I use "make oldconfig" for every single machine I boot, because why wouldn't I? Isn't that what everybody does? I'm surprised that anybody would re-make their config from scratch every time, or use some GUI tool. But yes, I'm also perhaps a bit odd in that I do a *lot* of rebooting on several machines, and I do it with all these things that come from outside. So I see all those cases where random developers added new Kconfig options, and then I have to go look at *why* it's asking me for some new driver or whatever, when my hardware hasn't changed. If I see anything that doesn't default to "n", it immediately raises my hackles. Why is somebody trying to push new code on my machine that worked just fine without it? And if I see the same question repeated multiple times (in just slightly different guises) for a new feature, I get annoyed. Linus
On Tue, 16 Jul 2024 at 22:34, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Tue, 16 Jul 2024 at 13:16, Bartosz Golaszewski > <bartosz.golaszewski@linaro.org> wrote: > > > > TBH it never occurred to me to test pure `make config`. I use `make > > menuconfig` almost exclusively and never noticed this issue for that > > reason. > > I use "make oldconfig" for every single machine I boot, because why wouldn't I? > > Isn't that what everybody does? > I just do `make olddefconfig` hoping that the defaults are sane. Or build the arm64 defconfig. > I'm surprised that anybody would re-make their config from scratch > every time, or use some GUI tool. > Nah, not from scratch. I just take the defaults and reuse them. > But yes, I'm also perhaps a bit odd in that I do a *lot* of rebooting > on several machines, and I do it with all these things that come from > outside. > Yep, that's a totally different workflow from most developers I imagine. > So I see all those cases where random developers added new Kconfig > options, and then I have to go look at *why* it's asking me for some > new driver or whatever, when my hardware hasn't changed. > > If I see anything that doesn't default to "n", it immediately raises > my hackles. Why is somebody trying to push new code on my machine that > worked just fine without it? > > And if I see the same question repeated multiple times (in just > slightly different guises) for a new feature, I get annoyed. > > Linus I will pay attention to new config options in the future. Thanks for bringing this to my attention. Bartosz