[lm-sensors] superio lock coordinator

Jim Cromie jim.cromie at gmail.com
Tue Jul 15 09:56:00 CEST 2008

hi Hans,

thanks for the personal invite to this thread. 
I messed up a laptop update last nov, and lost my mail folders
(several gig had piled up so the purge was needed anyway)

hi everyone else too,
apologies for being out of it for so long, and for things left half done.

> David Hubbard wrote:
>> Hi Hans,
>> I can pick it up again and push it forward. IIRC we wanted to know
>> what was the best way to encode the enter and exit sequences for a
>> SuperIO because the w83627ehf is different than pretty much any other.
>> That was the tricky part.
> If you look at the latest version posted by Jim:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2007-October/021562.html
> You will see that it already has configurable enter / exit sequences. 
> AFAIK the winbond chips are not unique in having differen enter / exit 
> sequences as other superio's have, so having to specify the enter / 
> exit sequence in the driver using the super io coordinator seems correct.

I have recently been revisiting the patches, but havent been entirely 
happy with them,
and didnt really like them enough to propose again.

This thread certainly ups it from a background muse.
Happily, I got my soekris back, and have a box that can actually
use 2 superio-client-drivers (ghod this needs a shorter name)

these are on my current todo / partly done

- struct superio_common - stuff thats copied from struct superio-search 
to struct superio when reservation is taken

- add a u8 flags to struct superio
-- carries bit for tracking enter/exit state -
    should support warnings on situations like enter-on-entered, 
 - could carry a toggle bit for a union superio_exit { fnptr; 
exit_seq[X] } or somesuch.

-- following another thread - we'd
--- reserve region when reservation taken, after devid is validated,
    might help keep other semi-rogue drivers out.

= sort out enter / exit

As David noted in this thread, the ehf driver has an odd exit sequence,

The combined combined superio_exit() function I have coded currently is 
really quite hideous,
and has me thinking towards  David's function-pointer idea.

- the other alternative is that David's driver should include its own 
custom exit-fn, which
he would use instead of the regular superio_exit().  It could use the 
superio_enter routine as-is iirc.

my stall points - (fishing for answers;)

- enter / exit should be tracked by superio-locks, in flags bit.   
(recent idea, seems sound)
- enter / exit should be vaguely discouraged in kernel-doc - due to 
expectations of isadump etc.

I guess I gotta stop overcomplicating things, and get busy on the patch-set.

> More interesting questions IMHO are:
> 1) is hwmon the correct subsystem to put the .c file in (somewhat 
> superfical
>   really, but we need a place to put the lock coordinator (and enable 
> / disable
>   its building).

I put it here for proximity to the center-of-mass of the drivers I found.

> 2) non hwmon drivers need to be edited for superio register use too, 
> and then
>   modified to use the lock coordinator if they touch the superio 
> registers.
>   This will also be a good exercise to see if our API is generic enough.
I guess there are drivers I missed ?

> Regards,
> Hans

thanks again Hans for pulling me back into this, I'll commit to staying 
with it now.
Should I infer from your comments that the code at the link incorporates 
your feedback ?
They seem to have aquired some momentum recently 8-)

Jean, you raised the idea of a sysfs interface.
Does the October patchset look to fit with what youre thinking ?
- the most simple I can think of :
--expose the kzalloced array of superio-fields as readonly attributes.
--values go non-zero when superio-port is registered by some user-driver
--it would be nice to see client-drivers list on each slot, but that 
involves more code and mem

do you have a preference wrt fn-ptr ? and if so, a single fn with 1 arg 
:  0,1,2 for enter/exit/query ?
do you have any use for a flag bit ?  is there generality in it ?

does anyone think s/superio/sio/g is appropriate ?
anything else ?


More information about the lm-sensors mailing list