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]
Date:	Sun, 30 Nov 2014 09:54:21 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Pali Rohár <pali.rohar@...il.com>
CC:	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Steven Honeyman <stevenhoneyman@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i8k: Add support for temperature sensor labels

On 11/30/2014 09:44 AM, Pali Rohár wrote:
> On Sunday 30 November 2014 17:00:18 Guenter Roeck wrote:
>> On 11/30/2014 01:53 AM, Pali Rohár wrote:
>> [ ... ]
>>
>>>>> Original Dell DOS executable ignores all temperature
>>>>> sensors if type SMM function fails (if I decoded and
>>>>> understand that DOS assembler code correctly). So maybe
>>>>> we should do same...
>>>>>
>>>>> But because our i8k.c code ignores sensor only if it
>>>>> returns invalid temperature, there could be possible
>>>>> regression that on same machines type SMM function is not
>>>>> implemented or not working...
>>>>>
>>>>> What do you think?
>>>>
>>>> Tested with XPS13, Studio 1555 (with GPU), and XPS M140.
>>>> Reading the type works with all of them. The Studio 1555
>>>> reports the GPU temperature in temp4. The M140 is quite old
>>>> (about 10 years), so I guess we can be reasonably sure that
>>>> all laptops currently in use support reporting the type.
>>>
>>> Good. Then I will split this patch into two parts. One which
>>> adds labels and one which change init code to register only
>>> those sensors which have valid type.
>>
>> Ok.
>>
>>>> Do you know what is returned for the type if the GPU is
>>>> turned off on a system with GPU ? I think that is the only
>>>> open question.
>>>
>>> Yes, on my E6440 in both cases when GPU is turned off and on
>>> is returned same type (GPU). So this does not help us.
>>
>> Unless I misunderstand you, it does help us; it simplifies
>> sensor detection since we don't have to handle the special
>> case that the GPU is turned off anymore.
>>
>> Thanks,
>> Guenter
>
> Yes, sensor type is returned always correctly, so this is good.
>
> I mean that it cannot be used for detecting if GPU is turned on
> or off.
>

Yes, but that is a good thing, because it helps us figuring out
if the GPU sensor should be enabled or not during probe,
so we no longer need to try reading the temperature, and we
no longer have to handle the case of "GPU supported, but turned
off" during probe.

When reading the temperature, returning -ENODATA if the GPU
is turned off is the best we can do.

Thanks,
Guenter

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