Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region

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 [off-list ref] wrote:

quoted

Milton Miller wrote:

quoted

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