Alex | 1 Sep 2007 10:54
Picon
Favicon

Philips PCA9540 sensor not included ?

My pc motherboard (DFI Infinity) is equipped with a PCA9540 I2C device.
I use Ubuntu 7.04 with original kernel 2.6.20

sensor-detect detects it but module is not present in kernel tree (in drivers/i2c/chips/ ) but there is a
pca9539.c (useless).

I've found this post http://lists.lm-sensors.org/pipermail/lm-sensors/2006-March/015743.html
that propose the code for pca954x .
Just now I'm trying to recompile my kernel with this patch.

There is a chance that code for pca954x will be included in future ?

      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

_______________________________________________
lm-sensors mailing list
lm-sensors <at> lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Jeff Garzik | 1 Sep 2007 16:27
Favicon

[PATCH] drivers/firmware: const-ify DMI API and internals


commit 457b6eb3bf3341d2e143518a0bb99ffbb8d754c4
Author: Jeff Garzik <jeff <at> garzik.org>
Date:   Sat Sep 1 10:16:45 2007 -0400

    drivers/firmware: const-ify DMI API and internals

    Three main sets of changes:

    1) dmi_get_system_info() return value should have been marked const,
       since callers should not be changing that data.

    2) const-ify DMI internals, since DMI firmware tables should,
       whenever possible, be marked const to ensure we never ever write to
       that data area.

    3) const-ify DMI API, to enable marking tables const where possible
       in low-level drivers.

    And if we're really lucky, this might enable some additional
    optimizations on the part of the compiler.

    The bulk of the changes are #2 and #3, which are interrelated.  #1 could
    have been a separate patch, but it was so small compared to the others,
    it was easier to roll it into this changeset.

    Signed-off-by: Jeff Garzik <jeff <at> garzik.org>

 arch/i386/kernel/apm.c                      |   18 ++++----
 arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c |    4 -
(Continue reading)

Greg KH | 1 Sep 2007 17:36
Gravatar

Re: [PATCH] drivers/firmware: const-ify DMI API and internals

On Sat, Sep 01, 2007 at 10:27:19AM -0400, Jeff Garzik wrote:
> 
> commit 457b6eb3bf3341d2e143518a0bb99ffbb8d754c4
> Author: Jeff Garzik <jeff <at> garzik.org>
> Date:   Sat Sep 1 10:16:45 2007 -0400
> 
>     drivers/firmware: const-ify DMI API and internals
>     
>     Three main sets of changes:
>     
>     1) dmi_get_system_info() return value should have been marked const,
>        since callers should not be changing that data.
>     
>     2) const-ify DMI internals, since DMI firmware tables should,
>        whenever possible, be marked const to ensure we never ever write to
>        that data area.
>     
>     3) const-ify DMI API, to enable marking tables const where possible
>        in low-level drivers.
>     
>     And if we're really lucky, this might enable some additional
>     optimizations on the part of the compiler.
>     
>     The bulk of the changes are #2 and #3, which are interrelated.  #1 could
>     have been a separate patch, but it was so small compared to the others,
>     it was easier to roll it into this changeset.

Looks great to me, do you want me to take this through my driver tree?
I'd be glad to do so.

(Continue reading)

Jeff Garzik | 1 Sep 2007 18:01
Favicon

Re: [PATCH] drivers/firmware: const-ify DMI API and internals

Greg KH wrote:
> On Sat, Sep 01, 2007 at 10:27:19AM -0400, Jeff Garzik wrote:
>> commit 457b6eb3bf3341d2e143518a0bb99ffbb8d754c4
>> Author: Jeff Garzik <jeff <at> garzik.org>
>> Date:   Sat Sep 1 10:16:45 2007 -0400
>>
>>     drivers/firmware: const-ify DMI API and internals
>>     
>>     Three main sets of changes:
>>     
>>     1) dmi_get_system_info() return value should have been marked const,
>>        since callers should not be changing that data.
>>     
>>     2) const-ify DMI internals, since DMI firmware tables should,
>>        whenever possible, be marked const to ensure we never ever write to
>>        that data area.
>>     
>>     3) const-ify DMI API, to enable marking tables const where possible
>>        in low-level drivers.
>>     
>>     And if we're really lucky, this might enable some additional
>>     optimizations on the part of the compiler.
>>     
>>     The bulk of the changes are #2 and #3, which are interrelated.  #1 could
>>     have been a separate patch, but it was so small compared to the others,
>>     it was easier to roll it into this changeset.
> 
> 
> Looks great to me, do you want me to take this through my driver tree?
> I'd be glad to do so.
(Continue reading)

Andi Kleen | 1 Sep 2007 18:33
Picon

Re: [PATCH] drivers/firmware: const-ify DMI API and internals


>     And if we're really lucky, this might enable some additional
>     optimizations on the part of the compiler.

Only if the kernel was compiled C++. C compilers generally ignore constness
for optimization purposes because it can be so easily casted away.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pavel Machek | 1 Sep 2007 19:10
Picon

Re: [PATCH] hwmon: Add power meters to Documentation/hwmon/sysfs-interface

Hi!

> diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
> index b3a9e1b..da546ce 100644
> --- a/Documentation/hwmon/sysfs-interface
> +++ b/Documentation/hwmon/sysfs-interface
>  <at>  <at>  -304,6 +304,21  <at>  <at>  curr[1-*]_input	Current input value
>  		Unit: milliampere
>  		RO
>  
> +*********
> +* Power *
> +*********
> +
> +power[1-*]_input	Current power use
> +			Unit: milliWatt
> +			RO
> +
> +power[1-*]_max_input	Historical maximum power use
> +			Unit: milliWatt
> +			RO
> +
> +power[1-*]_min_input	Historical minimum power use
> +			Unit: milliWatt
> +			RO

Should we add power?_10sec_avg_input? IIRC thinkpads export that,
too.
							Pavel
--

-- 
(Continue reading)

Shem Multinymous | 1 Sep 2007 20:05
Picon

Re: [PATCH] hwmon: Add power meters to Documentation/hwmon/sysfs-interface

On 9/1/07, Pavel Machek <pavel <at> ucw.cz> wrote:
> > diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
> > index b3a9e1b..da546ce 100644
> > --- a/Documentation/hwmon/sysfs-interface
> > +++ b/Documentation/hwmon/sysfs-interface
> >  <at>  <at>  -304,6 +304,21  <at>  <at>  curr[1-*]_input  Current input value
> >               Unit: milliampere
> >               RO
> >
> > +*********
> > +* Power *
> > +*********
> > +
> > +power[1-*]_input     Current power use
> > +                     Unit: milliWatt
> > +                     RO
> > +
> > +power[1-*]_max_input Historical maximum power use
> > +                     Unit: milliWatt
> > +                     RO
> > +
> > +power[1-*]_min_input Historical minimum power use
> > +                     Unit: milliWatt
> > +                     RO
>
> Should we add power?_10sec_avg_input? IIRC thinkpads export that,
> too.

Indeed, ThinkPads report both instantaneous power/current and a
rolling average (exponentially decaying, I think) over the last ~10
(Continue reading)

Picon
Favicon

Re: [lm-sensors] [PATCH] hwmon: Add power meters to Documentation/hwmon/sysfs-interface

On Sat, 01 Sep 2007, Shem Multinymous wrote:
> > Should we add power?_10sec_avg_input? IIRC thinkpads export that,
> > too.

I'd say it is enough to know it is an average, you don't need to specify HOW
it is averaged.

But there is a real need to export both instantaneous and averaged values in
power supplies/power sources, so we should have a standard way to do so in
hwmon, and power_supply class should use it (or the opposite, it doesn't
matter, as long as everyone does it the same way).

> It would be nice if the power meter interface uses the same
> conventions as the power supply interface, since the former is
> essentially a subset of the latter. Userspace app that read power
> meters via sysfs should work for power supplies too.

Agreed.

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
Satyam Sharma | 1 Sep 2007 23:21
Favicon

Re: [PATCH] drivers/firmware: const-ify DMI API and internals


On Sat, 1 Sep 2007, Andi Kleen wrote:
> 
> >     And if we're really lucky, this might enable some additional
> >     optimizations on the part of the compiler.
> 
> Only if the kernel was compiled C++. C compilers generally ignore constness
> for optimization purposes because it can be so easily casted away.

???

I can't speak for the exact const-ification that Jeff did in this
particular patch, but if you intended your comment up there to be a
blanket statement, then you're totally and horribly wrong. There's a
whole plethora of optimizations that gcc does when dealing with const-
marked data. If you've seen / experienced otherwise, please post some
testcases.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Krzysztof Helt | 2 Sep 2007 13:37
Picon
Favicon

[PATCH] adm1021: dynamic sysfs callbacks conversion (2nd rev)

From: Krzysztof Helt <krzysztof.h1 <at> wp.pl>

This is conversion of the driver  to the dynamic sysfs callbacks.

Signed-off-by: Krzysztof Helt <krzysztof.h1 <at> wp.pl>

---

This is the patch I posted some time ago. 
This revision is redone after applying the patch which fixes negative
value writes.

Regards,
Krzysztof

--- linux-2.6.23.orig/drivers/hwmon/adm1021.c	2007-09-02 13:11:35.000000000 +0200
+++ linux-2.6.23/drivers/hwmon/adm1021.c	2007-09-02 13:17:32.878031937 +0200
 <at>  <at>  -25,6 +25,7  <at>  <at> 
 #include <linux/jiffies.h>
 #include <linux/i2c.h>
 #include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
 #include <linux/err.h>
 #include <linux/mutex.h>

 <at>  <at>  -73,14 +74,6  <at>  <at>  I2C_CLIENT_INSMOD_8(adm1021, adm1023, ma
 /* write-only */
 #define ADM1021_REG_ONESHOT		0x0F

-
(Continue reading)


Gmane