Re: [PATCH] hwmon: (jc42) Add support for AT30TS00, TS3000GB2, TSE2002GB2, and MCP9804

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2012-03-07 at 11:51 -0500, Jean Delvare wrote:
> Hi Guenter,
> 
> On Wed,  7 Mar 2012 08:17:19 -0800, Guenter Roeck wrote:
> > Also update IDT datasheet locations.
> > 
> > Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> > ---
> >  Documentation/hwmon/jc42 |   18 +++++++++++++-----
> >  drivers/hwmon/Kconfig    |    6 +++---
> >  drivers/hwmon/jc42.c     |   18 ++++++++++++++++++
> >  3 files changed, 34 insertions(+), 8 deletions(-)
> > 
> > diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42
> > index e713375..fd70d23 100644
> > --- a/Documentation/hwmon/jc42
> > +++ b/Documentation/hwmon/jc42
> > @@ -7,21 +7,29 @@ Supported chips:
> >      Addresses scanned: I2C 0x18 - 0x1f
> >      Datasheets:
> >  	http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
> > +  * Atmel AT30TS00
> > +    Prefix: 'at30ts00'
> > +    Addresses scanned: I2C 0x18 - 0x1f
> > +    Datasheets:
> > +	http://www.atmel.com/Images/doc8585.pdf
> >    * IDT TSE2002B3, TS3000B3
> > -    Prefix: 'tse2002b3', 'ts3000b3'
> > +    Prefix: 'tse2002b3', 'tse2002gb2', 'ts3000b3', 'ts300gb2'
> 
> You mean ts3000gb2 not ts300gb2. But do we really want to have 4
> different prefixes for only 2 device IDs anyway?
> 
> I'm not even sure why we defined that many different prefixes in the
> first place when we treat them all the same, and autodetection doesn't
> even bother setting the prefix right. All these chips are
> register-compatible by definition, so I really wouldn't mind dropping
> all these different prefixes (which I don't think anyone is using
> today) and going with "jc42" for everyone.

Thinking about it and looking into NetBSD code - some of the chips have
fixed sensor resolution, others have configurable resolution. In the
latter case, the NetBSD driver configures it. Before I drop the
capability to separate chips based on the prefix, it might make sense to
first determine if that is something we want or should support.

Thoughts ?

Guenter



_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors


[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux