> 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. Alan _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
