Hi Hans, On Mon, Jul 14, 2008 at 11:30 AM, Hans de Goede <j.w.r.degoede at hhs.nl> wrote: > Milton Miller wrote: >> I haven't done the research, but it might be keep superio as >> a platform driver, and keep the clients as platform drivers. Only >> have the superio driver probe and discover the subcomponent >> addresses and then create the platform devices as children >> instead of having each driver create its own platform device. >> (This all assumes they are all platform devices in sysfs, I have >> not looked). >> >> This is all because in the platform bus the bus driver does not >> discover the addresses but relies on drivers or platform setup code. >> > > This sounds like a good plan, rather then add a new bus type add a superio > platform driver which does superio probing and registering of platform devices > for discovered logical devices. > > This superio platform driver then needs to also export some functions of those > few logical devices which need access to the superio registers for more then > just finding out their own base address. > > I guess that it then would be best to load this superio driver by default on > most systems. > > How does this all mix and match with isapnp, it feels to me we're doing > somewhat the same as isapnp here. Is there any way to use lspci and start at the LPC bridge, then find the SuperIO chip's IO address? What about ACPI tables? Perhaps probing logic could look for an LPC bridge before probing certain IO addresses even if the addresses are not in the LPC bridge config. A superio platform driver is a good way to go -- it fits with the way the platform bus does things. Also, Jim's patches are almost there already. Thanks, David
