Re: [PATCH 3/3] hwmon: (w83627ehf) Add support for the W83627UHG

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

 



On Tue, Nov 01, 2011 at 05:35:59AM -0400, Jean Delvare wrote:
> On Mon, 31 Oct 2011 14:27:31 -0700, Guenter Roeck wrote:
> > On Mon, 2011-10-31 at 17:03 -0400, Jean Delvare wrote:
> > > The W83627UHG is clearly on the side of the W83627DHG. The decision of
> > > splitting NCT677[56] support to a separate driver is unrelated IMHO.
> > > The rationale is that the w83627ehf driver code has become quite
> > > complex (it's the 3rd hwmon driver by size out of 117!) and a lot of the
> > > code recently added only applies to the NCT677[56]. If future devices
> > > are almost compatible with the NCT677[56] but not quite, things will
> > > only become worse.
> >
> > There is at least one new Nuvoton chip which is completely microcode
> > programmed (NCT6681D). Nuvoton advertises it as "the first IC of
> > Nuvoton`s new product line, or eSIO". Not entirely sure what that means,
> > but it almost looks like we may have reached the end of the hard-core
> > LPC devices.
> 
> Abit has been using a similar Winbond chip in the past (W83L950D) for
> its µGuru line of hardware monitoring chips. They have since then
> reverted to more conventional Super-I/O chips.
> 
> From our perspective, programmable chips are likely to be a problem, as
> getting specifications for these will be even harder than getting
> datasheets for traditional chips. As a matter of fact, µGuru support
> was made by reverse engineering and trial and error. Pretty painful.
> 
Yes, the NCT6681D datasheet doesn't say anything about supported registers;
everything is programmable. I assume they have a "default" or standard program
for the microcontroller; maybe they would be willing to share that. But even
with that there will be no guarantee that vendors don't play with it and add extra
functionality. So this might become a per-vendor programming nightmare.

> But anyway I wouldn't jump to a conclusion too quickly, let's see what
> happens in the months to come first.
> 
> > Two other currently not supported chips are NCT5577D, which seems to be
> > a variant of NCT677[56]F, and W83527HG, which seems to be somewhere in
> > between NCT6775F and earlier chips.
> 
> I'm a little skeptical about the W83527HG, according to its datasheet
> it has the same device ID as the W83627DHG-P. I'll ask Nuvoton.
> 
Maybe it is the same chip relabeled. Would not be the first time.

Guenter

> Anyway, even adding support for one or two additional chips to the
> w83627ehf driver as it exists today could be challenging, if they are
> somewhat significantly different from what we support today.
> 
> > > With separate drivers, the code would become easier to read IMHO.
> > > Obviously this implies some code duplication but I believe we reached
> > > the point where this should be considered. Another benefit is that we
> > > could then have separate maintainers for the two drivers, so better
> > > load balancing.
> >
> > Agreed.
> 
> -- 
> Jean Delvare

_______________________________________________
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