[PATCH] W83627EHF driver update

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

 



Hi Jean, Rudolf,

> > +
> > +/* maps the user modes to chip modes */
>
> I don't see how this comment is related to the following data.
>
> > +static const u8 W83627EHF_PWM_MODE_SHIFT[] = { 0, 1, 0, 6 };
> > +static const u8 W83627EHF_PWM_ENABLE_SHIFT[] = { 2, 4, 1, 4 };

The PWM modes are located at different bit positions in the registers.
the PWM_MODE_SHIFT values give the bit positions. Remember that the
pwmN_mode sets PWM or DC.

The PWM_ENABLE_SHIFT values give the bit positions from the PWM enable
settings. After the emulated mode 0 (disabled) is accounted for, then
they go into the register.

So I guess we should replace the comment with a better explanation. I
think that comment is a remnant from some code that was deleted.

> > +/* FAN Duty Cycle, be used to control */
> > +static const u8 W83627EHF_REG_PWM[] = { 0x01, 0x03, 0x11, 0x61 };
> > +static const u8 W83627EHF_REG_TARGET_TEMP[] = { 0x05, 0x06, 0x13, 0x63 };
>
> 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 just realized that you are emulating pwm_enable = 0. I guess the chip
> doesn't support it? Then you don't want to implement it in the driver.
> This emulation makes your code much more complex with no gain at all.
> Drivers must implement what the chip support, they must NOT emulate
> features.
>
> I'm stopping my review here. Please fix:
> * use of w83627ehf_update_device
> * use of SENSORS_LIMIT
> * locking
> * conditional register writes
> all around the place, then test the patch again, and then I'll review
> it again.

So it looks like there are some comments to fix, a few minor things,
plus what you've listed here. Rudolf, I'll be able to spend some time
on this over the weekend. That's a way off, if you feel like working
on it before then.

Thanks for the review, Jean.

David




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

  Powered by Linux