[lm-sensors] [PATCH] W83627EHF driver update
david.c.hubbard at gmail.com
Tue Jun 13 18:03:41 CEST 2006
On 6/13/06, Jean Delvare <khali at linux-fr.org> wrote:
> Hi David,
> > > The name is not very well chosen, these registers can hold both a target
> > > temperature or a target fan speed depending on the control mode (even
> > > if we don't support the latter at the moment.) What about just
> > > W83627EHF_REG_TARGET?
> > This is a good suggestion. In the near future, the registers will hold
> > one or the other value, and the driver will support both modes. Rudolf
> > and I talked about storing both values in the driver, with separate
> > sysfs files so libsensors could read either value, the one on the chip
> > or the one that will replace the value on the chip if the mode
> > switched. Advantages to doing it this way: we can set a reasonable
> > default for the value that's not on the chip, so when the mdoe
> > switches, the value in the register is not left unchanged (and
> > probably not reasonable); also, from userspace, it looks like there
> > are two registers, even though in hardware there's only one.
> > Disadvantages: well, emulation is bad, isn't it? But here I would
> > argue for emulating separate registers in the driver because the
> > register sharing in the hardware is impossible to map directly to a
> > sysfs file. If we're going to have two sysfs files with different
> > meanings, then can we just emulate separate registers?
> I'm fine with having two sets of internal variables, the reasons you
> give in that sense are good ones. I don't think doing so qualifies as
> "emulation". The hardware designers took an unfortunate shortcut by
> using the same registers for different functions, we need to deal with
Okay, that won't show up in the code this week. I'd like to see the
new features we have working signed off. I think that's Rudolf opinion
too. Then we'll add the other features, including that one.
More information about the lm-sensors