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]
Message-ID: <1374773611.3213.44.camel@hornet>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ