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: <53F5F019.10308@nvidia.com>
Date:	Thu, 21 Aug 2014 16:11:53 +0300
From:	Mikko Perttunen <mperttunen@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>, <thierry.reding@...il.com>
CC:	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-tegra@...r.kernel.org>, <wni@...dia.com>
Subject: Re: [PATCH v2 5/5] ARM: tegra: Add thermal reset (thermtrip) support
 to PMC

On 20/08/14 23:25, Stephen Warren wrote:
> On 08/13/2014 06:41 AM, Mikko Perttunen wrote:
>> This adds a device tree controlled option to enable PMC-based
>> thermal reset in overheating situations. Thermtrip is supported on
>> Tegra30, Tegra114 and Tegra124. The thermal reset only works when
>> the thermal sensors are calibrated, so a soctherm driver is also
>> required.
>
> If calibration is required, presumably the soctherm must initialize
> before this thermtrip code can initialize, or this thermtrip logic might
> be triggered by uncalibrated sensors?

SOCTHERM requires that each sensor be explicitly enabled before it gives 
readings. If a sensor is not enabled, the temperature given by the 
register (and used to trigger thermtrip) will be zero. So in order for a 
thermtrip shutdown to be caused before soctherm is initialized, the 
thermtrip temperature would have to be programmed to below zero (the 
default value is 105C), in which case an immediate shutdown would 
probably be in order anyway (unless the user uses LN2 or something to 
cool the soc below zero).

>
> If so, then there needs to be some explicit mechanism to force the two
> drivers into probing in the right order.

Because of the above, I think it isn't necessary to probe these in order.

Cheers,
Mikko
--
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