linux-kernel - Re: [PATCH V5 0/7] cpufreq: suspend early/resume late: dpm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <530B7EAF.9060502@wwwdotorg.org>
Date:	Mon, 24 Feb 2014 10:17:35 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nishanth Menon <nm@...com>, Kgene Kim <kgene.kim@...sung.com>,
	"jinchoi@...adcom.com" <jinchoi@...adcom.com>,
	Lan Tianyu <tianyu.lan@...el.com>,
	Sebastian Capella <sebastian.capella@...aro.org>,
	Jonghwan Choi <jhbird.choi@...sung.com>
Subject: Re: [PATCH V5 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()

On 02/23/2014 11:43 PM, Viresh Kumar wrote:
> On 20 February 2014 23:10, Stephen Warren <swarren@...dotorg.org> wrote:
>> Well, except that still leaves a bunch of errors in the kernel log, and
>> I have to remember to ignore them:-/
> 
> Just for few releases, before this patchset goes in.
> 
>> It'd be nice if the cpufreq core didn't keep changing its behaviour and
>> adding new error prints. It really should be up to the cpufreq drivers
>> to log the errors if they experience any.
> 
> Hmm... not sure.. Its better to do error prints at a single place, i.e. cpufreq
> core on behalf of all drivers. If there is a error being returned from some
> routine, we better print a message for that. Rather than living in the illusion
> that everything is fine :)

As a general rule, I think it's better to report the error right where
it happened. That's the only place where the code knows exactly what the
error was. Further up the call stack, we have to guess why there was an
error from the return code, which isn't very much information.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/