On Mon, 29 Mar 2010 19:29:57 +0100 Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
