On Mon, 14 Jul 2008 11:55:01 -0600, David Hubbard wrote: > 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. I always assumed that there was no way to know in advance if a Super-I/O (LPC) chip was present or not, let alone the exact model of the chip. The I/O addresses are decoded by the Super-I/O chip itself, and in general it has no relation to PCI. And I've never seen ports 0x2e/0x2f nor 0x4e/0x4f listed in /proc/ioports. But of course if there is a way to know, we should use it. Avoiding random access to I/O ports, even if they are relatively standard in this case, is always good. > 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. Good. -- Jean Delvare
