[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <36939c30-3cbb-43cb-aacd-aeb7b1f6973e@linaro.org>
Date: Thu, 17 Apr 2025 09:55:49 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Johan Hovold <johan@...nel.org>
Cc: Johan Hovold <johan+linaro@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>, "Rob Herring (Arm)"
<robh@...nel.org>, linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH v2] cpufreq: fix compile-test defaults
On 17/04/2025 09:46, Johan Hovold wrote:
> 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.net/
>
> Sounds like you, me and Arnd and least have the same understanding of
> how COMPILE_TEST should work.
Yes. It does not make it necessarily a bug (It's not a bug, it's a
feature). Anyway, I don't mind so up to you folks.
Best regards,
Krzysztof
Powered by blists - more mailing lists