lkml.org 
[lkml]   [2010]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] resource: shared I/O region support
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@mortis.eu>
> Signed-off-by: Alan Cox <alan@linux.intel.com>

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


\
 
 \ /
  Last update: 2010-03-29 19:59    [W:0.219 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site