<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/hwmon/coretemp.c, branch v3.14.31</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>Revert "hwmon: (coretemp) Refine TjMax detection"</title>
<updated>2014-06-07T17:28:11+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2014-04-30T21:08:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f35f0047951663702d21e430c9e986a22c4ddd69'/>
<id>f35f0047951663702d21e430c9e986a22c4ddd69</id>
<content type='text'>
commit c0940e95f7a78be0525c8d31df0b1f71e149e57e upstream.

This reverts commit 9fb6c9c73b11bef65ba80a362547fd116c1e1c9d.

Tjmax on some Intel CPUs is below 85 degrees C. One known example is
L5630 with Tjmax of 71 degrees C. There are other Xeon processors with
Tjmax of 70 or 80 degrees C. Also, the Intel IA32 System Programming
document states that the temperature target is in bits 23:16 of MSR 0x1a2
(MSR_TEMPERATURE_TARGET), which is 8 bits, not 7.

So even if turbostat uses similar checks to validate Tjmax, there is no
evidence that the checks are actually required. On the contrary, the
checks are known to cause problems and therefore need to be removed.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75071.

Fixes: 9fb6c9c hwmon: (coretemp) Refine TjMax detection
Reviewed-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c0940e95f7a78be0525c8d31df0b1f71e149e57e upstream.

This reverts commit 9fb6c9c73b11bef65ba80a362547fd116c1e1c9d.

Tjmax on some Intel CPUs is below 85 degrees C. One known example is
L5630 with Tjmax of 71 degrees C. There are other Xeon processors with
Tjmax of 70 or 80 degrees C. Also, the Intel IA32 System Programming
document states that the temperature target is in bits 23:16 of MSR 0x1a2
(MSR_TEMPERATURE_TARGET), which is 8 bits, not 7.

So even if turbostat uses similar checks to validate Tjmax, there is no
evidence that the checks are actually required. On the contrary, the
checks are known to cause problems and therefore need to be removed.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75071.

Fixes: 9fb6c9c hwmon: (coretemp) Refine TjMax detection
Reviewed-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (coretemp) Do not return -EAGAIN for low temperatures</title>
<updated>2014-01-15T05:36:52+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2013-11-20T18:25:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=bf6ea084ebb54cf8e1d6e60aac3c727cf45bf6c7'/>
<id>bf6ea084ebb54cf8e1d6e60aac3c727cf45bf6c7</id>
<content type='text'>
Some Intel CPUs do not set the 'valid' bit in IA32_THERM_STATUS if the
temperature is too low to be measured. This condition will not change until
the CPU is hot enough for its temperature to be measured. Returning an error
in such conditions is not very useful. Drop checking the valid bit and just
return the reported temperature instead.

Reviewed-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some Intel CPUs do not set the 'valid' bit in IA32_THERM_STATUS if the
temperature is too low to be measured. This condition will not change until
the CPU is hot enough for its temperature to be measured. Returning an error
in such conditions is not very useful. Drop checking the valid bit and just
return the reported temperature instead.

Reviewed-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (coretemp) Refine TjMax detection</title>
<updated>2014-01-15T05:36:31+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2013-11-09T17:38:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9fb6c9c73b11bef65ba80a362547fd116c1e1c9d'/>
<id>9fb6c9c73b11bef65ba80a362547fd116c1e1c9d</id>
<content type='text'>
Intel's turbostat code uses only 7 bits from MSR_IA32_TEMPERATURE_TARGET to
read TjMax, and also only accepts it if the reported temperature is at least
85 degrees C. Play safe and do the same.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Intel's turbostat code uses only 7 bits from MSR_IA32_TEMPERATURE_TARGET to
read TjMax, and also only accepts it if the reported temperature is at least
85 degrees C. Play safe and do the same.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (coretemp) Add PCI device ID for CE41x0 CPUs</title>
<updated>2014-01-15T05:36:31+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2013-05-27T21:17:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=347c16cfdecf9b4cfb94137b47bf6a05b3ff57d5'/>
<id>347c16cfdecf9b4cfb94137b47bf6a05b3ff57d5</id>
<content type='text'>
Since we now have to use PCI IDs to detect CPU types anyway, use this mechanism
to detect CE41x0 CPUs. Advantage is that it only requires a single entry and
covers all variants of CE41x0, including those unknown to us.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since we now have to use PCI IDs to detect CPU types anyway, use this mechanism
to detect CE41x0 CPUs. Advantage is that it only requires a single entry and
covers all variants of CE41x0, including those unknown to us.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (coretemp) Use PCI host bridge ID to identify CPU if necessary</title>
<updated>2014-01-15T05:36:30+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2013-05-27T19:20:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=14513ee696a0cd12a19318e433b75a786808adc3'/>
<id>14513ee696a0cd12a19318e433b75a786808adc3</id>
<content type='text'>
Atom S12x0 CPUs are identified by the CPU host bridge ID. Add an override
table based on PCI IDs as well as code to detect it.

PCI access functions can now be called with PCI disabled, so unlike previous
attempts to use PCI IDs, the code no longer depends on it. If PCI is disabled,
the CPU will not be identified correctly. Since it is unlikely that anything
will work in this case, this is an acceptable limitation.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Atom S12x0 CPUs are identified by the CPU host bridge ID. Add an override
table based on PCI IDs as well as code to detect it.

PCI access functions can now be called with PCI disabled, so unlike previous
attempts to use PCI IDs, the code no longer depends on it. If PCI is disabled,
the CPU will not be identified correctly. Since it is unlikely that anything
will work in this case, this is an acceptable limitation.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (coretemp) Fix truncated name of alarm attributes</title>
<updated>2014-01-14T17:47:52+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>khali@linux-fr.org</email>
</author>
<published>2014-01-14T14:59:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3f9aec7610b39521c7c69d754de7265f6994c194'/>
<id>3f9aec7610b39521c7c69d754de7265f6994c194</id>
<content type='text'>
When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute name is
truncated. This causes libsensors to skip these attributes as the
truncated name is not recognized.

Reported-by: Andreas Hollmann &lt;hollmann@in.tum.de&gt;
Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute name is
truncated. This causes libsensors to skip these attributes as the
truncated name is not recognized.

Reported-by: Andreas Hollmann &lt;hollmann@in.tum.de&gt;
Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (coretemp) Atom CPUs don't support TjMax; no warning needed</title>
<updated>2013-08-12T05:10:38+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2013-05-27T21:12:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1c2faa22472fedf2c420041033700c700a1dfc96'/>
<id>1c2faa22472fedf2c420041033700c700a1dfc96</id>
<content type='text'>
Display warning "Unable to read TjMax from CPU x" only if the CPU
is supposed to support it. This is not the case for the various Atom CPUs.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Display warning "Unable to read TjMax from CPU x" only if the CPU
is supposed to support it. This is not the case for the various Atom CPUs.

Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: delete __cpuinit usage from all hwmon files</title>
<updated>2013-07-14T23:36:57+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2013-06-19T18:02:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=d23e2ae1aae52bb80bd90525179375817db99809'/>
<id>d23e2ae1aae52bb80bd90525179375817db99809</id>
<content type='text'>
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the drivers/hwmon uses of the __cpuinit macros
from all C files.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Cc: lm-sensors@lm-sensors.org
Acked-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the drivers/hwmon uses of the __cpuinit macros
from all C files.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Cc: lm-sensors@lm-sensors.org
Acked-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (coretemp) Remove redundant platform_set_drvdata()</title>
<updated>2013-06-21T17:05:08+00:00</updated>
<author>
<name>Sachin Kamat</name>
<email>sachin.kamat@linaro.org</email>
</author>
<published>2013-05-03T09:43:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=807f730105e986b3b2da711cfd94f22b92532f79'/>
<id>807f730105e986b3b2da711cfd94f22b92532f79</id>
<content type='text'>
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat &lt;sachin.kamat@linaro.org&gt;
Cc: Rudolf Marek &lt;r.marek@assembler.cz&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat &lt;sachin.kamat@linaro.org&gt;
Cc: Rudolf Marek &lt;r.marek@assembler.cz&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: Fix checkpatch warning 'quoted string split across lines'</title>
<updated>2013-04-08T04:16:40+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2013-01-10T18:01:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b55f375725ff85aada394da488802b0a3cc99e88'/>
<id>b55f375725ff85aada394da488802b0a3cc99e88</id>
<content type='text'>
Cc: Corentin Labbe &lt;corentin.labbe@geomatys.fr&gt;
Cc: Mark M. Hoffman &lt;mhoffman@lightlink.com&gt;
Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Cc: Juerg Haefliger &lt;juergh@gmail.com&gt;
Cc: Andreas Herrmann &lt;herrmann.der.user@googlemail.com&gt;
Cc: Rudolf Marek &lt;r.marek@assembler.cz&gt;
Cc: Jim Cromie &lt;jim.cromie@gmail.com&gt;
Cc: Roger Lucas &lt;vt8231@hiddenengine.co.uk&gt;
Cc: Marc Hulsman &lt;m.hulsman@tudelft.nl&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Cc: Corentin Labbe &lt;corentin.labbe@geomatys.fr&gt;
Cc: Mark M. Hoffman &lt;mhoffman@lightlink.com&gt;
Cc: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Cc: Juerg Haefliger &lt;juergh@gmail.com&gt;
Cc: Andreas Herrmann &lt;herrmann.der.user@googlemail.com&gt;
Cc: Rudolf Marek &lt;r.marek@assembler.cz&gt;
Cc: Jim Cromie &lt;jim.cromie@gmail.com&gt;
Cc: Roger Lucas &lt;vt8231@hiddenengine.co.uk&gt;
Cc: Marc Hulsman &lt;m.hulsman@tudelft.nl&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
