On Wed, Mar 24, 2010 at 05:20:59PM +0100, Hans de Goede wrote: > On 03/24/2010 04:51 PM, Alan Cox wrote: >>> hold on the SIO port range. This would thus interfere with the >>> operation of the f71882fg driver. I.e. it would prevent the device >>> probing stage from working, thus preventing it from loading *after* >>> my in-development watchdog driver. >> >> There are two ways to deal with that really >> >> 1. Add a multi-function driver - it finds the chip and claims the >> port regions and then provides methods for locked access to them as >> well as creating other device instances that the drivers map to >> (probably platform devices ?) which in turn trigger the >> loading/binding of the relevant low level devices. >> >> 2. Fix the kernel request_resource stuff to support a sleeping non >> exclusive resource so request/free of regions can be used as a >> resource semaphore by co-operative devices. >> >> #2 is actually not hard but when I did the patch originally it then >> wasn't needed by the driver I had in mind for other reasons. >> >> See http://groups.google.com/group/linux.kernel/msg/1425fc2aad32e6ea >> >> Maybe its worth resurrecting ? > > Or, a bit more specific solution would be to resurrect the superio > lock coordinator patches, which were written (but never merged) 2 > years ago to solve exactly this problem: > http://lists.lm-sensors.org/pipermail/lm-sensors/2008-July/023743.html When performing some searches I find messages going back to at least september 2006 [1] [2]. With multiple occurences of these patches being "dusted off". They never got applied though, and for that (*not* applying them) I cannot find any reason. Is there any? Or did people just become uninterested and let the patches "collect dust"? Then regarding Alan's patch. The fact that it is a *lot* simpler than Jim Cromie's SuperIO locks coordinator is IMHO a significant advantage over the latter. Furthermore, "lock coordinator" seems like a bad name to me, since those patches seem especially concerned with centralising the way that SuperIO devices are probed for. Thus if the only thing required is to serialize resource access I think plain-ol' locking (with the ability to block on the lock, rather than polling for it). [1] http://lists.lm-sensors.org/pipermail/lm-sensors/2006-June/016476.html [2] http://lkml.org/lkml/2006/9/14/20 -- Met vriendelijke groet, With kind regards, Giel van Schijndel
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
