| Message ID | 9e68cba2bf41923630ea93de7c3d17637f175895.1403772686.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
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, since they will be more visible now. > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > drivers/cpufreq/cpufreq.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 62259d2..63d8f8f 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2468,7 +2468,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data) > } > > register_hotcpu_notifier(&cpufreq_cpu_notifier); > - pr_debug("driver %s up and running\n", driver_data->name); > + pr_info("driver %s up and running\n", driver_data->name); How about "Registered cpufreq driver: %s\n" > > return 0; > err_if_unreg: > @@ -2499,7 +2499,7 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver) > if (!cpufreq_driver || (driver != cpufreq_driver)) > return -EINVAL; > > - pr_debug("unregistering driver %s\n", driver->name); > + pr_info("unregistering driver %s\n", driver->name); And "Unregistered cpufreq driver: %s\n" (Also, its probably a good idea to have 2 prints here, just like we have for cpufreq_register_driver() - one with pr_debug() at the beginning of the function which tells us that we are *about* to register the driver, and then a second print with pr_info() at the end of the function that tells us that we successfully registered the driver. We can do the same thing for unregistration as well.) > > subsys_interface_unregister(&cpufreq_interface); > if (cpufreq_boost_supported()) > Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <bp@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 make it visible in logs. > > And we want this because...? So that it appears in boot logs and we know cpufreq registered properly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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.
On 10 July 2014 17:29, Borislav Petkov <bp@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 failed. Like the rest of the code does it. The problem with that is: CPUFreq may not be compiled in at all and we wouldn't know the difference between success and absence. And so tried to add a print, like any other driver would do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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/
On 10 July 2014 19:37, Borislav Petkov <bp@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: /sys/devices/system/cpu/cpufreq/ Yeah, with a local board its easily detectable. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 tests instead.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 62259d2..63d8f8f 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -2468,7 +2468,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data) } register_hotcpu_notifier(&cpufreq_cpu_notifier); - pr_debug("driver %s up and running\n", driver_data->name); + pr_info("driver %s up and running\n", driver_data->name); return 0; err_if_unreg: @@ -2499,7 +2499,7 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver) if (!cpufreq_driver || (driver != cpufreq_driver)) return -EINVAL; - pr_debug("unregistering driver %s\n", driver->name); + pr_info("unregistering driver %s\n", driver->name); subsys_interface_unregister(&cpufreq_interface); if (cpufreq_boost_supported())
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.kumar@linaro.org> --- drivers/cpufreq/cpufreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)