[lkml]   [2008]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 <> 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.


    Jean Delvare

     \ /
      Last update: 2008-07-15 10:39    [W:0.048 / U:29.492 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site