tech-kern archive

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

Re: wbsio(4): Winbond Super I/O driver for lm(4) over wbsio(4) attachment

On Wed, 17 Feb 2010, Constantine Aleksandrovich Murenin wrote:

1. Does it make sense to extend this to any other functions of the
  super-IO chip?  Are any others likely to ever show up on non-
  standard ISA ports?

Yes, wbsio(4) could later provide Watchdog Timer support, but such
timer is accessed directly through the Super I/O ports, not through a
separate set of ports as is the case with Hardware Monitor.


2. In the man page, please change the statement

       +driver provides support for the Winbond LPC Super I/O ICs.


       +driver provides configuration support for the Winbond LPC
       +Super I/O ICs.

Interesting point, but perhaps this is being too specific?
Specifically since it could later even support the watchdog timer? :-)


3. As written, wbsio_print() assumes that the ir_size of the lm(4)'s
  isa_attach_args is the same as the size of the wbsio(4)'s ir_size.
  Is this really correct?  Or should we explicitly set the ir_size
  member before calling config_found()?

I don't see such assumption anywhere in wbsio(4).  In any case,
ir_size is always set in the match procedure of the respective
matching driver, e.g. it is still set to 8 for lm(4) in

wbsio0 at isa0 port 0x2e-0x2f: Winbond LPC Super I/O W83627DHG rev 0x23
lm0 at wbsio0 port 0x290-0x297
lm0: Using default temp sensors
lm0: Winbond W83627DHG Hardware monitor

OK, I was not aware that each device's *_match() routine would set the ir_size. Thanks for clarifying.

I will confess that I'm writing this section without datasheets in
front of me...  But I notice that there are some differences in the
lists of devices between wbsio(4) and lm(4).  A few IDs are the same,
but most are different.

I also notice that wbsio(4) uses the device-ID, while lm(4) uses the

4. So, would it make sense to be consistent and use the same xxx-ID in
  both drivers?  (In which case, wbsio(4) could simply include
 nslm7xvar.h rather than having its own ID definitions.)

Your observation is correct- the namespace for IDs is different, so
it would not make much sense to unify this with nslm7xvar.h in any


5. And, does the list of devices in wbsio(4) deliberately exclude the
  rest of the lm(4) devices?  Or could some/all of the remaining
  chips from lm(4) be added to wbsio(4)?

I think all supported devices were actually already included, and
since wbsio(4) was written, no new devices were introduced to lm(4).
Obviously, not all of those supported by lm(4) could ever show up on
the isa bus - for example, W83792D and a few others are SMBus-only.


You've addressed all my concerns. Let's give a couple days for others to comment.

|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index