RFC: bare pci configuration access functions ?

From: Lee, Jung-Ik (jung-ik.lee@intel.com)
Date: Thu Oct 31 2002 - 14:29:19 EST


Need:
====
        Some kernel drivers/components such as hotplug pci/io-node drivers,
ACPI driver, some console drivers, etc **need bare pci configuration space
access** before either pci driver is initialized or struct pci_dev is
constructed.

ACPI needs this for ACPI/PCI population, hotplug pci driver for populating
hot-added pci hierarchy. As more drivers are cross ported over to wider
architectures, this would become wider need. Help me if others need this
too.

Current pci configuration access functions:
==========================================
        Current pci configuration access functions is based on "struct
pci_ops" from "struct pci_bus".
 pci_{read|write}_config_{byte|word|dword}(pci_dev, where, val);
 pci_bus_{read|write}_config_{byte|word|dword}(pci_bus, devfn, where, val);

Issue:
=====
        Current functions need pci_ops and pci_bus struct, which are not
constructed yet for the above cases.

Current solutions:
=================
(1) i386 and ia64 kernel provides global bare pci config access functions
like:
 pci_config_{read|write}(seg, bus, dev, func, where, size, val);
        Acpi driver uses these.

(2) Alternative is to allocate temporary pci_dev/pci_bus structs and copy
parent's or root's, and modify the struct.
        Hotplug pci driver uses this.

Question:
========
Will it be desirable to have bare global pci config access functions as seen
in i386/ia64 pci codes ? It's clean and needs just what it takes - seg, bus,
dev, func, where, value, and size.
Or, do we keep original functions with temporary structs ? It takes extra
care for temporary structs, but it's with pci context.

Request for comments.
thanks,
J.I.
-
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/



This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:56 EST