Re: [PATCH v2] cpufreq: fix compile-test defaults

[Johan Hovold]

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@xxxxxxxxxxxx/

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