linux-kernel - Re: RFC: device thermal limits represented in device tree nodes

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Jul 2013 18:33:31 +0100
From:	Pawel Moll <pawel.moll@....com>
To:	Eduardo Valentin <eduardo.valentin@...com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Mark Rutland <Mark.Rutland@....com>,
	Ian Campbell <ian.campbell@...rix.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Durgadoss R <durgadoss.r@...el.com>,
	"Zhang, Rui" <rui.zhang@...el.com>, Wei Ni <wni@...dia.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: RFC: device thermal limits represented in device tree nodes

On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
> >> 	thermal_zone {
> >> 		type = "CPU";
> > 
> > So what does this exactly mean? What is so special about CPU? What other
> > types you've got there? (Am I just lazy not looking at the numerous
> > links you provided? ;-)
> 
> Hehehe. OK. Type is supposed to describe what your zone is representing.

As in "a name"? So, for example "The board", "PSU"? What I meant to ask
was: does the string carry any meaning?

> >> 		monitoring_device = <&sensor@...x
> >> 				    &sensor@...y>;
> >>
> >> 		mask = <0x03>; /* trips writability */
> >> 		passive_delay = <250>; /* milliseconds */
> >> 		polling_delay = <1000>; /* milliseconds */
> >> 		policy = "step_wise";
> > 
> > The word "policy" doesn't sound to me like a "hardware feature",
> > wouldn't you agree?
> 
> Agreed. As I mentioned in other email, we can leave this to OS decide
> what to use, by default, for instance.

Cool, I believe it is the right thing to do.

> > 
> >> 		trips {
> >> 			alert@...000{
> >> 				temperature = <100000>; /* milliCelsius
> >> 				hysteresis = <2000>; /* milliCelsius */
> >> 				type = <THERMAL_TRIP_PASSIVE>;
> >> 			};
> >> 			crit@...000{
> >> 				temperature = <125000>; /* milliCelsius
> >> 				hysteresis = <2000>; /* milliCelsius */
> >> 				type = <THERMAL_TRIP_CRITICAL>;
> >> 			};
> >> 		};
> >> 		bind_params {
> >> 			action@0{
> >>				cooling_device = "thermal-cpufreq";
> > 
> > Why is it a string? It seems very Linux-y... (cpufreq) Is there any
> > particular reason not to have phandles to the fans that have any impact
> > on the zone? 
> 
> Because fans are not the only way to cool your system, specially those
> systems that don't feature fans. Managing the speed of your CPU is one
> example of lowering temperature without fans. Managing the load on your
> system is another way. These are obviously, virtual concepts. And
> because we have physical ways and logical ways to cool the zone, then I
> didnt put a phandle to a device there.

"virtual concepts"... This is where my problem lies... It's not hardware
so it doesn't seem to belong in the tree at the first sight. Shouldn't
it focus on "physical data" instead? As in: point at devices that have
some impact on the conditions? For example, you can say "please, do the
right thing to cool your environment down" to both CPU and fan, can't
you? The "cooling driver" for the CPU would know that it has to slow
down, while a driver for the fan would know that it has to speed up ;-)

What I'm trying to say is that in my opinion the tree should simply link
the object, the sensor and the actuator. Nothing more, nothing less.

Thanks for your time!

Pawel


--
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/