Messages in this thread | | | Date | Fri, 2 Apr 2010 13:29:12 -0700 | From | Jesse Barnes <> | Subject | Re: [PATCH 1/3] resource: shared I/O region support |
| |
On Mon, 29 Mar 2010 19:29:57 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Well that does keep it simple, and with just one user that's probably > > best. > > > > But why not use the common bus driver method? Muxing at the resource > > level only seems to solve part of the problem... It doesn't guarantee > > for example that driver A does something to a shared region that breaks > > driver B; it just makes sure they don't access the same region at the > > same time. > > The obvious reason for not doing that kind of grand over-engineering is > that you are assuming the devices involved are remotely related. On quite > a few systems we have a collection of superio config interfaces on random > low ports all with their own lock/unlock rituals. They range from > parallel devices to watchdogs and god knows what else. Right now we have > various bits of driver code (parport is a good one) that exist on a cross > fingers, pray and poke model. It would be nice to fix that. > > For most super I/O devices the muxing is basically a glorified chip select > line. There isn't any structure to impose over it. Where you have > structure there are better ways to do it, but one does not exclude the > other.
Well I'm not sure such over-engineering would be "grand", but it does seem like overkill for the devices you're covering here. At any rate, the patch is in my linux-next tree, so it'll head to Linus next merge cycle unless some big new objections arise.
-- Jesse Barnes, Intel Open Source Technology Center
| |