On 01/06, Sudeep Holla wrote:
> Currently we add the virtual cpufreq device unconditionally even when
> the SCPI DVFS clock provider node is disabled. This will cause cpufreq
> driver to throw errors when it gets initailised on boot/modprobe and
> also when the CPUs are hot-plugged back in.
>
> Th
Of course.
W dniu 09.01.2017 o 10:58, Sudeep Holla pisze:
>
>
> On 07/01/17 00:44, Michał Zegan wrote:
>> seems the patch works as intended.
>>
>
> So, can we take this as
> Tested-by: Michał Zegan ?
>
>> W dniu 06.01.2017 o 13:34, Sudeep Holla pisze:
>>> Currently we add the virtual cpufreq
On 07/01/17 00:44, Michał Zegan wrote:
> seems the patch works as intended.
>
So, can we take this as
Tested-by: Michał Zegan ?
> W dniu 06.01.2017 o 13:34, Sudeep Holla pisze:
>> Currently we add the virtual cpufreq device unconditionally even when
>> the SCPI DVFS clock provider node is dis
seems the patch works as intended.
W dniu 06.01.2017 o 13:34, Sudeep Holla pisze:
> Currently we add the virtual cpufreq device unconditionally even when
> the SCPI DVFS clock provider node is disabled. This will cause cpufreq
> driver to throw errors when it gets initailised on boot/modprobe and
Currently we add the virtual cpufreq device unconditionally even when
the SCPI DVFS clock provider node is disabled. This will cause cpufreq
driver to throw errors when it gets initailised on boot/modprobe and
also when the CPUs are hot-plugged back in.
This patch fixes the issue by adding the vir
5 matches
Mail list logo