[lm-sensors] w83627hf hardware sharing

[lm-sensors] w83627hf hardware sharing

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1040 bytes --]

While looking at the w83627hf driver I noticed that there are currently
two drivers in the kernel controlling these devices: w83627hf providing
lm_sensors support and the w83627hf_wdt driver providing watchdog
support.  Due to the hardware interface provided by the chip with many
functions multiplexed via two registers this can't be done safely:
concurrent access.  This is unlikely to happen at present but it is
possible and I'm currently looking at an application which uses some
additional functionality on the chip and would run into trouble much
more readily.

The most straightforward fix appears to be to provide a multiplexing
driver for the chip.  Does this sound like a reasonable approach to
take?  I'm particularly worried about the possible effects of changing
the lm_sensors driver, causing the device to move in sysfs, though as
far as I can tell current versions of lm-sensors should not be affected
due to the sysfs class.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] w83627hf hardware sharing

[Pádraig Brady]

Mark Brown wrote:
> While looking at the w83627hf driver I noticed that there are currently
> two drivers in the kernel controlling these devices: w83627hf providing
> lm_sensors support and the w83627hf_wdt driver providing watchdog
> support.  Due to the hardware interface provided by the chip with many
> functions multiplexed via two registers this can't be done safely:
> concurrent access.  This is unlikely to happen at present but it is
> possible and I'm currently looking at an application which uses some
> additional functionality on the chip and would run into trouble much
> more readily.
> 
> The most straightforward fix appears to be to provide a multiplexing
> driver for the chip.  Does this sound like a reasonable approach to
> take?  I'm particularly worried about the possible effects of changing
> the lm_sensors driver, causing the device to move in sysfs, though as
> far as I can tell current versions of lm-sensors should not be affected
> due to the sysfs class.
> 

You're right.
Some work has been done wrt this, but I've not tried it:
http://marc.info/?l=linux-kernel&m\x115821759424601&w=2

cheers,
Pádraig.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] w83627hf hardware sharing

[Mark Brown]

On Thu, Apr 12, 2007 at 01:26:55PM +0100, Pádraig Brady wrote:
> Mark Brown wrote:

[ Currently we have multiplexing problems with multiple drivers trying
  to control SuperIO devices. ]

> > The most straightforward fix appears to be to provide a multiplexing
> > driver for the chip.  Does this sound like a reasonable approach to

> You're right.
> Some work has been done wrt this, but I've not tried it:
> http://marc.info/?l=linux-kernel&m\x115821759424601&w=2

Adding Jim Cromie who wrote the SuperIO multiplexer referenced there -
what is the current status of that work?  It looks like exactly what I
was after.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] w83627hf hardware sharing

[Jim Cromie]

Mark Brown wrote:
> On Thu, Apr 12, 2007 at 01:26:55PM +0100, Pádraig Brady wrote:
>   
>> Mark Brown wrote:
>>     
>
> [ Currently we have multiplexing problems with multiple drivers trying
>   to control SuperIO devices. ]
>
>   
>>> The most straightforward fix appears to be to provide a multiplexing
>>> driver for the chip.  Does this sound like a reasonable approach to
>>>       
>
>   
>> You're right.
>> Some work has been done wrt this, but I've not tried it:
>> http://marc.info/?l=linux-kernel&m\x115821759424601&w=2
>>     
>
> Adding Jim Cromie who wrote the SuperIO multiplexer referenced there -
> what is the current status of that work?  It looks like exactly what I
> was after.
>
>   

hi Mark, Padraig,
thanks for searching, and finding something relevant.
and sorry for the delay.

$job is demanding my attention these days.
I also owe a platform_driver patch for pc87360,
which should come 1st, since its already late :-(

Ive evidently done something with the patchset since 9/14
probably as talked about in the thread.

-rw-rw-r-- 1 jimc jimc   9536 Oct  6  2006 diff.locks-superio
-rw-rw-r-- 1 jimc jimc   5739 Oct  6  2006 diff.locks-superio-usein-pc87360
-rw-rw-r-- 1 jimc jimc   6288 Oct  6  2006 
diff.locks-superio-usein-pc8736x_gpio

in case you havent already seen it
http://search.gmane.org/?query=superio&group=gmane.linux.drivers.sensors

comments, experiments, trials welcome.
thanks
jimc



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors