On Thu, Jul 10, 2014 at 07:43:07PM +0530, Viresh Kumar wrote:
> But I faced the issue when I had to see some test reports from the
> automated stuff and wanted to see if cpufreq is up and running.
Sorry, this is a very specialized usage to enforce meaningless spew in
dmesg on *everybody*. Fix
On 10 July 2014 19:37, Borislav Petkov wrote:
> On Thu, Jul 10, 2014 at 05:38:23PM +0530, Viresh Kumar wrote:
>> The problem with that is: CPUFreq may not be compiled in at all and we
>> wouldn't know the difference between success and absence.
>
> Of course you would:
On Thu, Jul 10, 2014 at 05:38:23PM +0530, Viresh Kumar wrote:
> The problem with that is: CPUFreq may not be compiled in at all and we
> wouldn't know the difference between success and absence.
Of course you would: /sys/devices/system/cpu/cpufreq/
--
Regards/Gruss,
Boris.
Sent from a fat
On 10 July 2014 17:29, Borislav Petkov wrote:
> On Thu, Jul 10, 2014 at 05:21:43PM +0530, Viresh Kumar wrote:
>> So that it appears in boot logs and we know cpufreq registered properly.
>
> So flip that logic: Don't say anything in the success case and issue an
> error only when it failed. Like
On Thu, Jul 10, 2014 at 05:21:43PM +0530, Viresh Kumar wrote:
> So that it appears in boot logs and we know cpufreq registered properly.
So flip that logic: Don't say anything in the success case and issue an
error only when it failed. Like the rest of the code does it.
--
Regards/Gruss,
On 10 July 2014 17:18, Borislav Petkov wrote:
> On Thu, Jun 26, 2014 at 02:21:30PM +0530, Viresh Kumar wrote:
>> We do report driver's successful {un}registration from cpufreq core, but is
>> done
>> with pr_debug() and so this doesn't appear in boot logs.
>>
>> Convert this to pr_info() to make
On Thu, Jun 26, 2014 at 02:21:30PM +0530, Viresh Kumar wrote:
> We do report driver's successful {un}registration from cpufreq core, but is
> done
> with pr_debug() and so this doesn't appear in boot logs.
>
> Convert this to pr_info() to make it visible in logs.
And we want this because...?
On 06/26/2014 02:21 PM, Viresh Kumar wrote:
> We do report driver's successful {un}registration from cpufreq core, but is
> done
> with pr_debug() and so this doesn't appear in boot logs.
>
> Convert this to pr_info() to make it visible in logs.
>
While at it, let's also standardize those
On 06/26/2014 02:21 PM, Viresh Kumar wrote:
We do report driver's successful {un}registration from cpufreq core, but is
done
with pr_debug() and so this doesn't appear in boot logs.
Convert this to pr_info() to make it visible in logs.
While at it, let's also standardize those messages,
On Thu, Jun 26, 2014 at 02:21:30PM +0530, Viresh Kumar wrote:
We do report driver's successful {un}registration from cpufreq core, but is
done
with pr_debug() and so this doesn't appear in boot logs.
Convert this to pr_info() to make it visible in logs.
And we want this because...?
--
On 10 July 2014 17:18, Borislav Petkov b...@alien8.de wrote:
On Thu, Jun 26, 2014 at 02:21:30PM +0530, Viresh Kumar wrote:
We do report driver's successful {un}registration from cpufreq core, but is
done
with pr_debug() and so this doesn't appear in boot logs.
Convert this to pr_info() to
On Thu, Jul 10, 2014 at 05:21:43PM +0530, Viresh Kumar wrote:
So that it appears in boot logs and we know cpufreq registered properly.
So flip that logic: Don't say anything in the success case and issue an
error only when it failed. Like the rest of the code does it.
--
Regards/Gruss,
On 10 July 2014 17:29, Borislav Petkov b...@alien8.de wrote:
On Thu, Jul 10, 2014 at 05:21:43PM +0530, Viresh Kumar wrote:
So that it appears in boot logs and we know cpufreq registered properly.
So flip that logic: Don't say anything in the success case and issue an
error only when it
On Thu, Jul 10, 2014 at 05:38:23PM +0530, Viresh Kumar wrote:
The problem with that is: CPUFreq may not be compiled in at all and we
wouldn't know the difference between success and absence.
Of course you would: /sys/devices/system/cpu/cpufreq/
--
Regards/Gruss,
Boris.
Sent from a fat
On 10 July 2014 19:37, Borislav Petkov b...@alien8.de wrote:
On Thu, Jul 10, 2014 at 05:38:23PM +0530, Viresh Kumar wrote:
The problem with that is: CPUFreq may not be compiled in at all and we
wouldn't know the difference between success and absence.
Of course you would:
On Thu, Jul 10, 2014 at 07:43:07PM +0530, Viresh Kumar wrote:
But I faced the issue when I had to see some test reports from the
automated stuff and wanted to see if cpufreq is up and running.
Sorry, this is a very specialized usage to enforce meaningless spew in
dmesg on *everybody*. Fix your
We do report driver's successful {un}registration from cpufreq core, but is done
with pr_debug() and so this doesn't appear in boot logs.
Convert this to pr_info() to make it visible in logs.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2
We do report driver's successful {un}registration from cpufreq core, but is done
with pr_debug() and so this doesn't appear in boot logs.
Convert this to pr_info() to make it visible in logs.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file
18 matches
Mail list logo
