[lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Titus]

Hi all,

I'm new to this mailing list and I have some questions to the fscscy 
module. I have searchted the archives and this subject does not seem to 
have been posted already, so I hope I don't bother you with issues 
already discussed.

- I did not manage to load the fscscy kernel module into kernel 2.6.18 
(Debian Etch) and 2.6.21 (current kernel from kernel.org). Although all 
seems to be compiled correctly, this kernel module was not built. Is 
there any way to fix that?

- Does the lm-sensors fscscy support monitoring the status of two 
redundant power supplies (I have read the docs carefully but there seems 
to be only temperatures and fan rpms, no PSU status support)? If not, is 
it planned for the near future to support this?

- Is there any way to port lm-sensors to freebsd or is there an 
affiliate *BSD project where the fscscy module can be adapted to with 
not too much effort?


Thanks in adavance!

Greets,

Titus

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

Re: [lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Jean Delvare]

Hi Titus,

On Tue, 10 Jul 2007 09:30:00 +0200, Titus wrote:
> I'm new to this mailing list and I have some questions to the fscscy 
> module. I have searchted the archives and this subject does not seem to 
> have been posted already, so I hope I don't bother you with issues 
> already discussed.
> 
> - I did not manage to load the fscscy kernel module into kernel 2.6.18 
> (Debian Etch) and 2.6.21 (current kernel from kernel.org). Although all 
> seems to be compiled correctly, this kernel module was not built. Is 
> there any way to fix that?

The fscscy driver was not ported to Linux 2.6 yet. There was a first
request one year and a half ago:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-February/015319.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-March/015489.html

Nobody volunteered yet to do the work. I've added your request on our
wiki/Devices page, but don't hold your breath. The FSC Scylla is an old
and rare chip, it's unlikely that anyone will volunteer to port it for
free.

> - Does the lm-sensors fscscy support monitoring the status of two 
> redundant power supplies (I have read the docs carefully but there seems 
> to be only temperatures and fan rpms, no PSU status support)? If not, is 
> it planned for the near future to support this?

The Scylla chip (as all other hardware monitoring chips) has a number
of sensor inputs (voltages, temperatures and fans). It has no idea what
these signals correspond to nor where they do come from. This really
depends on how the manufacturer wired the chip on the motherboard. So
the general answer is that no hwmon driver specifically handles
redundant PSUs because they don't have to.

> - Is there any way to port lm-sensors to freebsd or is there an 
> affiliate *BSD project where the fscscy module can be adapted to with 
> not too much effort?

lm-sensors is heavily based on procfs on Linux 2.4 and sysfs on Linux
2.6. As BSDs don't have anything like that as far as I know, there
really isn't anything to port. I seem to remember that one of the BSDs
has support for a limited number of popular hardware monitoring chips,
but the implementation is completely different. Anyway, this is really
a question you want to ask on a BSD list if you want a more accurate
answer.

-- 
Jean Delvare

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

Re: [lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Hans de Goede]

Jean Delvare wrote:
> Hi Titus,
> 
> On Tue, 10 Jul 2007 09:30:00 +0200, Titus wrote:
>> I'm new to this mailing list and I have some questions to the fscscy 
>> module. I have searchted the archives and this subject does not seem to 
>> have been posted already, so I hope I don't bother you with issues 
>> already discussed.
>>
>> - I did not manage to load the fscscy kernel module into kernel 2.6.18 
>> (Debian Etch) and 2.6.21 (current kernel from kernel.org). Although all 
>> seems to be compiled correctly, this kernel module was not built. Is 
>> there any way to fix that?
> 
> The fscscy driver was not ported to Linux 2.6 yet. There was a first
> request one year and a half ago:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-February/015319.html
> http://lists.lm-sensors.org/pipermail/lm-sensors/2006-March/015489.html
> 
> Nobody volunteered yet to do the work. I've added your request on our
> wiki/Devices page, but don't hold your breath. The FSC Scylla is an old
> and rare chip, it's unlikely that anyone will volunteer to port it for
> free.
> 

Well actually, I would like to volunteer, as it fits within my current fscher / 
fscpos driver activities. I've done some checking and the fscscy is very much 
like the fscher / fscpos, and it has the tempX_limit registers right were my 
reverse engineering found them in the fscher :) As always if anyone has a 
datasheet for the fscscy, that would be very welcome.

With the possibility to add fscscy support to the driver and with my wish to 
rip out the watchdog support (for now, I might redo it with the official kernel 
api later, esp. if there are requests for it) + the possibility for many other 
cleanups, I'm starting to think that it would be (much) easier to add a new 
fscxxx driver to the kernel, based on my current fscher work, with added fscscy 
support and cleanups.

Jean & Mark, were do you stand with regards to this., I see 2 options:

1) * Many smaller patches with incremental improvements to the fscher
    * essentially making it an fscxxx driver
    * with the current pseudo watchdog support left in for compatibility
    * with other uglies like raw export of status registers left in for
      compatibility, while also exporting the exact same info with _alarm and
      _fault files

2) A new fscxxx driver tackling all the issues at once, based on my current
    fscher work, with some major cleanup and added fscscy support

As I type this, and also remind myself that the current driver has to keep 
carying the tempX_status ugliness, my vote strongly goes to the new driver 
approach. Then we can mark the fscpos and fscher drivers as obsolete for a 
while and remove them eventually.

Titus, would you be willing to test fscscy support for us?

Regards,

Hans

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

Re: [lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Jean Delvare]

Hi Hans,

On Sun, 22 Jul 2007 11:27:55 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > The fscscy driver was not ported to Linux 2.6 yet. There was a first
> > request one year and a half ago:
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2006-February/015319.html
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2006-March/015489.html
> > 
> > Nobody volunteered yet to do the work. I've added your request on our
> > wiki/Devices page, but don't hold your breath. The FSC Scylla is an old
> > and rare chip, it's unlikely that anyone will volunteer to port it for
> > free.
> 
> Well actually, I would like to volunteer, as it fits within my current fscher / 
> fscpos driver activities. I've done some checking and the fscscy is very much 
> like the fscher / fscpos, and it has the tempX_limit registers right were my 
> reverse engineering found them in the fscher :) As always if anyone has a 
> datasheet for the fscscy, that would be very welcome.

I don't have it. You may try asking the author of the Linux 2.4 fscscy
driver.

> With the possibility to add fscscy support to the driver and with my wish to 
> rip out the watchdog support (for now, I might redo it with the official kernel 
> api later, esp. if there are requests for it) + the possibility for many other 
> cleanups, I'm starting to think that it would be (much) easier to add a new 
> fscxxx driver to the kernel, based on my current fscher work, with added fscscy 
> support and cleanups.

You may also want to take a look at the pending driver for the new FSC
Heimdall chip:
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018629.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018787.html
I wonder if it is also similar. I just added an entry to wiki/Devices.

> Jean & Mark, were do you stand with regards to this., I see 2 options:
> 
> 1) * Many smaller patches with incremental improvements to the fscher
>     * essentially making it an fscxxx driver
>     * with the current pseudo watchdog support left in for compatibility
>     * with other uglies like raw export of status registers left in for
>       compatibility, while also exporting the exact same info with _alarm and
>       _fault files
> 
> 2) A new fscxxx driver tackling all the issues at once, based on my current
>     fscher work, with some major cleanup and added fscscy support
> 
> As I type this, and also remind myself that the current driver has to keep 
> carying the tempX_status ugliness, my vote strongly goes to the new driver 
> approach. Then we can mark the fscpos and fscher drivers as obsolete for a 
> while and remove them eventually.

I agree that having a single driver for all similar chips would be
great, as it would lower the maintenance effort. I don't really care
which road you take, but here are my random thoughts:

* I discourage the use of "x" in the driver names. It looks great only
until the day a new chip is released, those name matches the mask, but
which isn't compatible at all. For hardware monitoring drivers, we tend
to name the driver after the first supported chip, and consider the
others as "mostly foo-compatible."

* If you go for a new driver, without watchdog support, then we will
have to keep all the other drivers around for at least some time
anyway. So the watchdog problem is more or less independent from your
decision.

* If you start from one of the existing drivers, at least the users of
this driver are guaranteed to have an easy upgrade path.

But all it all, I'd say: whatever makes it easier for you.

-- 
Jean Delvare

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

Re: [lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> You may also want to take a look at the pending driver for the new FSC
> Heimdall chip:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018629.html
> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018787.html
> I wonder if it is also similar. I just added an entry to wiki/Devices.
> 

It is indeed similar too, for some reason FSC keeps changes fan and temp 
register addresses, but that can easily be handled with an array addressed with 
the chip-type.

Also they seem to have done strange things with temp sensor numbers, for the 
fscpos and fscher the temp sensors are identical, however the fscscy adds a 
fourth sensor, but in the 2.4 sensors puts that in as temp2 moving temp2 and 3 
to temp3 and 4 when compared to the fscher / fscpos, I guess its best to just 
clone this erm "interesting" numbering in the 2.6 driver.

>> Jean & Mark, were do you stand with regards to this., I see 2 options:
>>
>> 1) * Many smaller patches with incremental improvements to the fscher
>>     * essentially making it an fscxxx driver
>>     * with the current pseudo watchdog support left in for compatibility
>>     * with other uglies like raw export of status registers left in for
>>       compatibility, while also exporting the exact same info with _alarm and
>>       _fault files
>>
>> 2) A new fscxxx driver tackling all the issues at once, based on my current
>>     fscher work, with some major cleanup and added fscscy support
>>
>> As I type this, and also remind myself that the current driver has to keep 
>> carying the tempX_status ugliness, my vote strongly goes to the new driver 
>> approach. Then we can mark the fscpos and fscher drivers as obsolete for a 
>> while and remove them eventually.
> 
> I agree that having a single driver for all similar chips would be
> great, as it would lower the maintenance effort. I don't really care
> which road you take, but here are my random thoughts:
> 
> * I discourage the use of "x" in the driver names. It looks great only
> until the day a new chip is released, those name matches the mask, but
> which isn't compatible at all. For hardware monitoring drivers, we tend
> to name the driver after the first supported chip, and consider the
> others as "mostly foo-compatible."
> 

Okay, so I will call it fscpos_new then.

> * If you go for a new driver, without watchdog support, then we will
> have to keep all the other drivers around for at least some time
> anyway. So the watchdog problem is more or less independent from your
> decision.
> 

I know, but doing a new driver is in my mind way easier then juggling a lot of 
incremental patches to an existing driver, and there is more then just the 
watchdog, the current drivers also have old alarm files and various exports of 
status registers in raw formats, the fscpos also has very interesting 
rempX_reset sysfs entries, which can be written to reset the alarms for temps, etc.

So I'll start working on a new clean unified driver for the 4, without watchdog 
support for starters, but watchdog support according to the standard API's will 
be on my roadmap.

I'm actually planning to make writing the watchdog support a lab assignment for 
a device driver class I will be teaching starting september.

AFAIK I already asked, but let me ask again: I could really use some ideas / 
suggestion for chips/devices which come with docs and need a 2.6 driver 
written. So that I can use this as assignments, don't worry I will review, 
submit (if usable) and maintain any resulting drivers myself. Unless ofcourse a 
student likes writing the driver so much he pledges to maintain it himself.

I'm currently thinking about trying to get some adm1024 chips for example, but 
I wonder is the statement on the devices wiki-page that the adm1024 is not 
supported with 2.6 still accurate?

Thanks & Regards,

Hans

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

Re: [lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Jean Delvare]

Hi Hans,

On Mon, 23 Jul 2007 16:33:12 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > Hi Hans,
> > 
> > You may also want to take a look at the pending driver for the new FSC
> > Heimdall chip:
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018629.html
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018787.html
> > I wonder if it is also similar. I just added an entry to wiki/Devices.
> 
> It is indeed similar too, for some reason FSC keeps changes fan and temp 
> register addresses, but that can easily be handled with an array addressed with 
> the chip-type.

It depends on how different they are, but in general, different
register maps is the reason #1 for writing different drivers.

> Also they seem to have done strange things with temp sensor numbers, for the 
> fscpos and fscher the temp sensors are identical, however the fscscy adds a 
> fourth sensor, but in the 2.4 sensors puts that in as temp2 moving temp2 and 3 
> to temp3 and 4 when compared to the fscher / fscpos, I guess its best to just 
> clone this erm "interesting" numbering in the 2.6 driver.

If you're going for a new driver, and it makes it easier to number them
differently, go for it.

> > * I discourage the use of "x" in the driver names. It looks great only
> > until the day a new chip is released, those name matches the mask, but
> > which isn't compatible at all. For hardware monitoring drivers, we tend
> > to name the driver after the first supported chip, and consider the
> > others as "mostly foo-compatible."
> 
> Okay, so I will call it fscpos_new then.

If you're going to include Scylla support in it, it might make sense to
name it fscscy instead, as this driver doesn't yet exist in 2.6, this
will save us the pain of renaming the driver at a later date.

> > * If you go for a new driver, without watchdog support, then we will
> > have to keep all the other drivers around for at least some time
> > anyway. So the watchdog problem is more or less independent from your
> > decision.
> 
> I know, but doing a new driver is in my mind way easier then juggling a lot of 
> incremental patches to an existing driver, and there is more then just the 
> watchdog, the current drivers also have old alarm files and various exports of 
> status registers in raw formats, the fscpos also has very interesting 
> rempX_reset sysfs entries, which can be written to reset the alarms for temps, etc.
> 
> So I'll start working on a new clean unified driver for the 4, without watchdog 
> support for starters, but watchdog support according to the standard API's will 
> be on my roadmap.
> 
> I'm actually planning to make writing the watchdog support a lab assignment for 
> a device driver class I will be teaching starting september.

Good plan :)

> AFAIK I already asked, but let me ask again: I could really use some ideas / 
> suggestion for chips/devices which come with docs and need a 2.6 driver 
> written. So that I can use this as assignments, don't worry I will review, 
> submit (if usable) and maintain any resulting drivers myself. Unless ofcourse a 
> student likes writing the driver so much he pledges to maintain it himself.
> 
> I'm currently thinking about trying to get some adm1024 chips for example, but 
> I wonder is the statement on the devices wiki-page that the adm1024 is not 
> supported with 2.6 still accurate?

Yes, this statement is still accurate.

In general, I suggest that you avoid pushing in the kernel support for
random chips which are not known to be in use in real-world hardware.
Even if you maintain them yourself, you won't do it forever, and having
unused drivers only slows things down and lower the average quality. So
better pick chips from the Devices page where at least one user
requested support already (as the ADM1024, ADT7475/76, F75387SG/RG or
MAX6648/92.)

If your 1st year students learn how to write drivers, maybe in 2nd year
you can teach them how to review drivers? ;) That's what we need the
most.

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On Mon, 23 Jul 2007 16:33:12 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> Hi Hans,
>>>
>>> You may also want to take a look at the pending driver for the new FSC
>>> Heimdall chip:
>>> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018629.html
>>> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-February/018787.html
>>> I wonder if it is also similar. I just added an entry to wiki/Devices.
>> It is indeed similar too, for some reason FSC keeps changes fan and temp 
>> register addresses, but that can easily be handled with an array addressed with 
>> the chip-type.
> 
> It depends on how different they are, but in general, different
> register maps is the reason #1 for writing different drivers.
> 

I understand, but in this case a simple 2d lookup table addressed with the 
chiptype and sensor number is all thats needed as the contents of the registers 
haven't changed (same scaling / same bits used in status registers), for some 
reason FSC has just shuffled them around a bit, and then really only a bit, 
just enough to make the lookup tabel the easiest solution, see below.

>> Also they seem to have done strange things with temp sensor numbers, for the 
>> fscpos and fscher the temp sensors are identical, however the fscscy adds a 
>> fourth sensor, but in the 2.4 sensors puts that in as temp2 moving temp2 and 3 
>> to temp3 and 4 when compared to the fscher / fscpos, I guess its best to just 
>> clone this erm "interesting" numbering in the 2.6 driver.
> 
> If you're going for a new driver, and it makes it easier to number them
> differently, go for it.
> 

Well, for example lets look at the fan registers, here is what my WIP has for 
them now:

static const u8 FSCPOS_REG_FAN_MIN[4][6] = {
	{ 0x55, 0x65 },					/* pos */
	{ 0x55, 0x65, 0xb5 },				/* her */
	{ 0x65, 0x65, 0x55, 0xa5, 0x55, 0xa5 },		/* scy */
	{ 0x55, 0x65, 0xa5, 0xb5, 0xc5 } };		/* hmd */

/* actual fan speed */	
static const u8 FSCPOS_REG_FAN_ACT[4][6] = {
	{ 0x0e, 0x6b, 0xab },				/* pos */
	{ 0x0e, 0x6b, 0xbb },				/* her */
	{ 0x6b, 0x6c, 0x0e, 0xab, 0x5c, 0xbb },		/* scy */
	{ 0x5b, 0x6b, 0xab, 0xbb, 0xcb } };		/* hmd */

/* fan status registers */
static const u8 FSCPOS_REG_FAN_STATE[4][6] = {
	{ 0x0d, 0x62, 0xa2 },				/* pos */
	{ 0x0d, 0x62, 0xb2 },				/* her */
	{ 0x62, 0x61, 0x0d, 0xa2, 0x52, 0xb2 },		/* scy */
	{ 0x52, 0x62, 0xa2, 0xb2, 0xc2 } };		/* hmd */
	
/* fan ripple / divider registers */	
static const u8 FSCPOS_REG_FAN_RIPPLE[] = {
	{ 0x0f, 0x6f, 0xaf },				/* pos */
	{ 0x0f, 0x6f, 0xbf },				/* her */
	{ 0x6f, 0x6f, 0x0f, 0xaf, 0x0f, 0xbf },		/* scy */
	{ 0x5f, 0x6f, 0xaf, 0xbf, 0xcf } };		/* hmd */

And when I reshuffle the scy to match the pos and her you get:

static const u8 FSCPOS_REG_FAN_MIN[4][6] = {
	{ 0x55, 0x65 },					/* pos */
	{ 0x55, 0x65, 0xb5 },				/* her */
	{ 0x55, 0x65, 0xa5, 0x65, 0x55, 0xa5 },		/* scy */
	{ 0x55, 0x65, 0xa5, 0xb5, 0xc5 } };		/* hmd */

/* actual fan speed */	
static const u8 FSCPOS_REG_FAN_ACT[4][6] = {
	{ 0x0e, 0x6b, 0xab },				/* pos */
	{ 0x0e, 0x6b, 0xbb },				/* her */
	{ 0x0e, 0x6b, 0xab, 0x6c, 0x5c, 0xbb },		/* scy */
	{ 0x5b, 0x6b, 0xab, 0xbb, 0xcb } };		/* hmd */

/* fan status registers */
static const u8 FSCPOS_REG_FAN_STATE[4][6] = {
	{ 0x0d, 0x62, 0xa2 },				/* pos */
	{ 0x0d, 0x62, 0xb2 },				/* her */
	{ 0x0d, 0x62, 0xa2, 0x61, 0x52, 0xb2 },		/* scy */
	{ 0x52, 0x62, 0xa2, 0xb2, 0xc2 } };		/* hmd */
	
/* fan ripple / divider registers */	
static const u8 FSCPOS_REG_FAN_RIPPLE[] = {
	{ 0x0f, 0x6f, 0xaf },				/* pos */
	{ 0x0f, 0x6f, 0xbf },				/* her */
	{ 0x0f, 0x6f, 0xaf, 0x6f, 0x0f, 0xbf },		/* scy */
	{ 0x5f, 0x6f, 0xaf, 0xbf, 0xcf } };		/* hmd */

Notice that for the first 3 fans, all chips are almost identical. Thr only 
differences are that the hmd uses 0x5* instead of 0x0* for the 3 of the 4 fan1 
registers and that the fscher uses 0xb* instead of 0xa*. Also the 4th and 5th 
fan of the scy and hmd are much more different from one another.

To me the almost the same and same register contents warrents using a unified 
driver, especially since for example the voltage registers are on the same 
place for all. However taking all these smalle register map differences 
together, the easiest path for a unified driver is to use the lookup tables 
above, and once the lookup tables are there, its really easy to keep the order 
of the sensors in the fscscy as with the 2.4 driver. Let me know if you prefer 
the hussled order, as that does make it clearer that they are one and the same 
family of chips.

>>> * I discourage the use of "x" in the driver names. It looks great only
>>> until the day a new chip is released, those name matches the mask, but
>>> which isn't compatible at all. For hardware monitoring drivers, we tend
>>> to name the driver after the first supported chip, and consider the
>>> others as "mostly foo-compatible."
>> Okay, so I will call it fscpos_new then.
> 
> If you're going to include Scylla support in it, it might make sense to
> name it fscscy instead, as this driver doesn't yet exist in 2.6, this
> will save us the pain of renaming the driver at a later date.
> 

Good idea, I'll do that.

> In general, I suggest that you avoid pushing in the kernel support for
> random chips which are not known to be in use in real-world hardware.
> Even if you maintain them yourself, you won't do it forever, and having
> unused drivers only slows things down and lower the average quality. So
> better pick chips from the Devices page where at least one user
> requested support already (as the ADM1024, ADT7475/76, F75387SG/RG or
> MAX6648/92.)
> 

Good point, I fully agree and thanks for the input. I haven't checked all the 
links on the device wiki yet, will do, but you don't happen to know motherboard 
models which come with these chips do you? Or even better have a spare one you 
can miss (I have a small budget for the labs, so I can pay for shipping + 
something extra).

> If your 1st year students learn how to write drivers, maybe in 2nd year
> you can teach them how to review drivers? ;) That's what we need the
> most.

Erm, they are 4th year students, but if the want to stay another year I can try :)

Thanks & Regards,

Hans

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

Re: [lm-sensors] Fujitsu-Siemens Scylla (fscscy)

[Jean Delvare]

Hi Hans,

On Tue, 24 Jul 2007 16:40:08 +0200, Hans de Goede wrote:
> To me the almost the same and same register contents warrents using a unified 
> driver, especially since for example the voltage registers are on the same 
> place for all. However taking all these smalle register map differences 
> together, the easiest path for a unified driver is to use the lookup tables 
> above, and once the lookup tables are there, its really easy to keep the order 
> of the sensors in the fscscy as with the 2.4 driver. Let me know if you prefer 
> the hussled order, as that does make it clearer that they are one and the same 
> family of chips.

It's up to you, really, I don't care either way.

> > In general, I suggest that you avoid pushing in the kernel support for
> > random chips which are not known to be in use in real-world hardware.
> > Even if you maintain them yourself, you won't do it forever, and having
> > unused drivers only slows things down and lower the average quality. So
> > better pick chips from the Devices page where at least one user
> > requested support already (as the ADM1024, ADT7475/76, F75387SG/RG or
> > MAX6648/92.)
> 
> Good point, I fully agree and thanks for the input. I haven't checked all the 
> links on the device wiki yet, will do, but you don't happen to know motherboard 
> models which come with these chips do you? Or even better have a spare one you 
> can miss (I have a small budget for the labs, so I can pay for shipping + 
> something extra).

No, I don't. But the wiki/Devices page may have pointers to people with
such motherboards.

-- 
Jean Delvare

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