On 03/29/2010 10:38 AM, Giel van Schijndel wrote: > > Patch after this line: > ======================================================================== > resource: shared I/O region support > > SuperIO devices share regions and use lock/unlock operations to chip > select. We therefore need to be able to request a resource and wait for > it to be freed by whichever other SuperIO device currently hogs it. > Right now you have to poll which is horrible. > > Add a MUXED field to IO port resources. If the MUXED field is set on the > resource and on the request (via request_muxed_region) then we block > until the previous owner of the muxed resource releases their region. > > This allows us to implement proper resource sharing and locking for > superio chips using code of the form > > enable_my_superio_dev() { > request_muxed_region(0x44, 0x02, "superio:watchdog"); > outb() ..sequence to enable chip > } > > disable_my_superio_dev() { > outb() .. sequence of disable chip > release_region(0x44, 0x02); > } > > Signed-off-by: Giel van Schijndel <me@xxxxxxxxx> > Signed-off-by: Alan Cox <alan@xxxxxxxxxxxxxxx> I have to question this approach a bit. I would much rather see this as a two-step process, where multiple devices request the same region with a "sharable" flag, and then have a mutex associated with the struct resource (perhaps we need an outer container called "struct muxed_resource" or some such.) What I *really* object to with this patch is that it inherently assumes that there is only one multiplexed resource in the entire system... but of course nowhere enforces that. -hpa _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors