Re: [RFC][PATCH] PCI bridge driver rewrite (rev 02)

From: Adam Belay (abelay_at_novell.com)
Date: 03/08/05

  • Next message: Junfeng Yang: "Re: [Ext2-devel] Re: [CHECKER] crash after fsync causing serious FS corruptions (ext2, 2.6.11)" 
    To: Jon Smirl <jonsmirl@gmail.com>
Date:	Mon, 07 Mar 2005 19:20:05 -0500

    On Mon, 2005-03-07 at 18:03 -0500, Jon Smirl wrote:
    > What about a bridge driver for ISA LPC bridges? That would also
    > provide a logical place to hang serial ports, floppy, parallel port,
    > ps2 port, etc. Things in /sys/bus/platform are really attached to the
    > LPC bridge.
    >

    I agree that /sys/bus/platform isn't really the right place. It doesn't
    show the correct parent device, among other issues. I've done some work
    on this issue in the past, and it turns out to be a very complicated
    problem.

    Basically there are many protocols that feed into the pool of devices
    known as *legacy hardware*. The include the following:

    1.) ACPI
          * provides resource information
          * provides identification information
          * the only protocol that accurately describes topology
          * often provides power management features
          * sometimes a few device specific methods (e.g. floppy drives)
    2.) PnPBIOS
          * outdated by ACPI, generally useful for x86 boxes before 2000
          * provides resource information
          * provides identification information, and a class code not found
            in ACPI
          * all devices reported are considered root devices, no sense of
            true topology
          * In theory could handle some hotplugging of these devices (e.g.
            docking stations)
    3.) ISAPnP
          * Even more outdated.
          * Provides resource information.
          * provides identification, including a card id not found in
            PnPBIOS or ACPI (obviously).
          * Only used for ISA expansion cards
    4.) SuperIO drivers
          * In theory it is possible to determine configuration information
            from the SuperIO directly.
          * Some, but very limited, work has been done in this area.
          * ACPI generally handles this because there is little
            standardization at this level.
    5.) Legacy Probing
          * Driver attempts to find the hardware directly by reading various
            ports.
          * Can be dangerous.
          * Drivers of this type encourage vendors to include legacy
            compatibility (which in the long run holds us back).
          * Very difficult to integrate with the driver model.
    6.) Open Firmware
          * I don't know much about it, but I believe it does do similar
            things to ACPI.
          * Hopefully it uses EISA ids, but not really sure. If not, it
            wouldn't be included.

    So basically we have to handle all (or most) of these. The question
    becomes should driver developers have to write code for all 6 of these
    interfaces (which seems a little overwhelming), or should they share a
    common layer. If so, the driver model would need a way to represent
    this. One idea I had was to make "buses" a special type of "class".
    And then allow classes to be layered. So it would look something like
    ISA/LPC ->ACPI
            ->PnPBIOS
            ->ISAPnP
            ->SuperIO
            ->legacy
            ->Open Firmware

    Where each of the 6 classes inherit characteristics from "ISA/LPC".

    A driver could then choose to bind to the more general "ISA/LPC"
    interfaces, or if necessary a more specific interface like "ACPI".
    "ISA/LPC" would be sort of a least common denominator.

    Of course this would require big changes to the driver model, so it
    would have to be really worth it. I look forward to any comments or
    suggestions for alternative approaches.

    Thanks,
    Adam

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Junfeng Yang: "Re: [Ext2-devel] Re: [CHECKER] crash after fsync causing serious FS corruptions (ext2, 2.6.11)"

    Relevant Pages