On Thu, Apr 17, 2025 at 09:28:43AM +0200, Krzysztof Kozlowski wrote:
On 17/04/2025 09:22, Johan Hovold wrote:
Fix the default values for drivers that can be compile tested and that should be enabled by default when not compile testing.
Fixes: 3f66425a4fc8 ("cpufreq: Enable COMPILE_TEST on Arm drivers")
Fixes: d4f610a9bafd ("cpufreq: Do not enable by default during compile testing")
That's not correct tag - it introduced no new issues, did not make things worse, so nothing to fix there, if I understand correctly.
Fair enough, I could have used dependency notation for this one.
Let me do that in v3.
OK. I have doubts that this should be marked as a fix in the first place
- even skipping my commit. Some (several?) people were always
considering COMPILE_TEST as enable everything, thus for them this was the intention, even if it causes such S3C64xx cpufreq warnings:
https://lore.kernel.org/all/8b6ede05-281a-4fb1-bcdc-457e6f2610ff@roeck-us.ne...
Sounds like you, me and Arnd and least have the same understanding of how COMPILE_TEST should work.
I use it all the time when fixing issues that have been reproduced in several drivers which I then enable manually. And I usually keep them enabled in my development kernels for a while after in case something needs to be reworked.
If you want to compile everything as well you should do an allmodconfig build.
I had also talks about this in the past that one should never boot compile test kernel.
I have never noticed any issues with that until the other day with the cpufreq driver, but yeah, I can imagine that other "default y" entries could potentially cause issues.
Johan