linux-kernel - Re: [PATCH] i8k: Add support for temperature sensor labels

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: <201411301900.48898@pali>
Date:	Sun, 30 Nov 2014 19:00:48 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>
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 Sunday 30 November 2014 18:54:21 Guenter Roeck wrote:
> 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

Yes, you are right. I will create new patches.

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)