linux-kernel - RE: [PATCH 2/8] Thermal: Create zone level APIs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4D68720C2E767A4AA6A8796D42C8EB5927AAB1@BGSMSX101.gar.corp.intel.com>
Date:	Fri, 8 Feb 2013 08:54:12 +0000
From:	"R, Durgadoss" <durgadoss.r@...el.com>
To:	"Zhang, Rui" <rui.zhang@...el.com>
CC:	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"eduardo.valentin@...com" <eduardo.valentin@...com>,
	"hongbo.zhang@...aro.org" <hongbo.zhang@...aro.org>,
	"wni@...dia.com" <wni@...dia.com>
Subject: RE: [PATCH 2/8] Thermal: Create zone level APIs

Hi Rui,

> -----Original Message-----
> From: Zhang, Rui
> Sent: Friday, February 08, 2013 1:42 PM
> To: R, Durgadoss
> Cc: linux-pm@...r.kernel.org; linux-kernel@...r.kernel.org;
> eduardo.valentin@...com; hongbo.zhang@...aro.org; wni@...dia.com
> Subject: Re: [PATCH 2/8] Thermal: Create zone level APIs
> 
> On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
> > This patch adds a new thermal_zone structure to
> > thermal.h. Also, adds zone level APIs to the thermal
> > framework.
> >

[snip.]

> > +
> > +struct thermal_sensor *get_sensor_by_name(const char *name)
> > +{
> > +	struct thermal_sensor *pos;
> > +	struct thermal_sensor *ts = NULL;
> > +
> > +	mutex_lock(&sensor_list_lock);
> > +	for_each_thermal_sensor(pos) {
> > +		if (!strnicmp(pos->name, name, THERMAL_NAME_LENGTH))
> {
> > +			ts = pos;
> > +			break;
> 
> this function depends on the assumption that all the sensor names are
> unique.
> thus I prefer to go through all the list and return -EINVAL if duplicate
> names found, because in this case, the pointer returned may be not the
> sensor we want to get.

Yes, I agree with you. But I prefer having this check in the register API
itself, which then will not allow duplicates.

The reason being, we use this get* API (comparatively) a lot more than
the register APIs. And putting this check in the register APIs means doing
this check only once. Let me know what you think.

And the same for cooling devices too.

Thanks,
Durga