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

[Constantine Aleksandrovich Murenin <C++%Cns.SU@localhost>]

On 17 February 2010 07:57, Paul Goyette <paul%whooppee.com@localhost> wrote:
> On Tue, 16 Feb 2010, Constantine Aleksandrovich Murenin wrote:
>
>> Hi,
>>
>> The wbsio(4) driver allows one to attach lm(4) on non-standard IO ports,
>> or, alternatively, discover the said non-standard ports, so that an ap-
>> propriate lm0 configuration line could be devised for the configuration
>> file of the kernel.
>>
>> Best regards,
>> Constantine.
>
> Kewl...
>
> Question:
>
> 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.


> Suggestion:
> 2. In the man page, please change the statement
>
>        +driver provides support for the Winbond LPC Super I/O ICs.
>
>   to
>
>        +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? :-)


> Question:
> 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
lm_isa_match():

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


> Curiosity:
> 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
> chip-ID.
>
> Question:
> 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
way.


> Question:
> 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.


Cheers,
Constantine.SU.