Thread (28 messages) flat view 28 messages, 6 authors, 2008-07-16

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

From: David Hubbard <hidden>
Date: 2008-07-14 17:55:20
Also in: lkml

Hi Hans,

On Mon, Jul 14, 2008 at 11:30 AM, Hans de Goede [off-list ref] wrote:
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.

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help