On Wed, Mar 24, 2010 at 03:51:51PM +0000, 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 > > ... snip ... > > 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 ? In this particular case I most definitely think it's worth resurrecting. Using your patch (I had to change the IORESOURCE_MUXED constant's value though) I can completely solve the I/O sharing issue for the f71882fg + watchdog case with only a single line modification to the f71882fg driver. One question regarding your patch though: how will it function when driver (A) locks an I/O region using request_region() then driver (B) comes along and tries to lock it using request_muxed_region()? One problem I imagine might occur is that driver (A)'s 'struct resource' doesn't have the IORESOURCE_MUXED flags set, thus simply won't wake up driver (B) on the 'muxed_resource_wait' queue. -- 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