Re: [PATCH v6 3/8] cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common boost solution

Viresh Kumar
2013-07-26T09:24:07Z

On 26 July 2013 13:39, Lukasz Majewski <l.majewski@samsung.com> wrote:
> On Fri, 26 Jul 2013 12:58:02 +0530 Viresh Kumar wrote,
>> On 25 July 2013 22:03, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> > diff --git a/drivers/cpufreq/acpi-cpufreq.c
>> > b/drivers/cpufreq/acpi-cpufreq.c
>>
>> > static void __init acpi_cpufreq_boost_init(void)
>> > {
>> > + acpi_cpufreq_driver.boost_supported = false;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [*]
>>
>> Would be better if we do this in else of below if.
>
> We need to set boost_supported = false at [*] for the case when:
> 1. msrs_alloc fails
> or
> 2. acpi_cpufreq is built as a module and can be inserted and removed
> several times. Without [*] we could end up with wrong (not false)
> initial state.

Hmm.. Now that I see the code again, we don't need to set it to false
as it is a global variable and this field is already set to false..

>> > if (boot_cpu_has(X86_FEATURE_CPB) ||
>> > boot_cpu_has(X86_FEATURE_IDA)) { msrs = msrs_alloc();
>>
>>
>> > @@ -1021,12 +995,11 @@ static int __init acpi_cpufreq_init(void)
>> > *iter = &cpb;
>> > }
>> > #endif
>> > + acpi_cpufreq_boost_init();
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [**]
>>
>> We are calling it before registering cpufreq driver. Will this have
>> any complications?
>
> When we call [**] after the cpufreq_register_driver [***] we end up with
> sysfs boost attribute not exported at x86.
> The boost attribute is exported at [***] only when
> acpi_cpufreq.boost_supported = true. However support for boost at x86
> is evaluated at acpi_cpufreq_boost_init().

I understand why you moved it above cpufreq driver register. I was thinking
if there can be few side effects of this..