> From: Lee, Jung-Ik [mailto:[email protected]]
> 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.
When the PCI Config stuff got revamped a few months ago, Greg KH, myself,
and some other people discussed this, and the conclusion seemed to be that
it was less ugly to make the code that needs bare PCI config access use fake
structs, than to have the bare functions exposed. Greg, am I remembering
correctly?
Regards -- Andy
On Thu, Oct 31, 2002 at 01:07:08PM -0800, Grover, Andrew wrote:
> > From: Lee, Jung-Ik [mailto:[email protected]]
> > 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.
>
> When the PCI Config stuff got revamped a few months ago, Greg KH, myself,
> and some other people discussed this, and the conclusion seemed to be that
> it was less ugly to make the code that needs bare PCI config access use fake
> structs, than to have the bare functions exposed. Greg, am I remembering
> correctly?
No. Well, I don't think so anyway. In 2.5 we now have a pci_bus_read_*
and pci_bus_write_* functions, which the pci hotplug drivers use, as
they at least know the bus on which the devices they are looking for are
on. I also had to convert over some ACPI code that was using the
pci_read_config functions to get everything to work properly, but I
don't seem to be able to find that code in the latest 2.5 tree, so I
guess you don't need to do that anymore?
(For the LKML readers, this is a spill-over from the pci hotplug and
ia64 mailing lists, where on 2.4 we now have a problem with pci hotplug
drivers as ia64 uses a pci "segment" and the existing pci_*_nodev
functions in the pci hotplug core don't properly set up this field. See
the archives for either of those lists for more info.)
thanks,
greg k-h
On Thu, 31 Oct 2002, Grover, Andrew wrote:
> > From: Lee, Jung-Ik [mailto:[email protected]]
> > 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.
>
> When the PCI Config stuff got revamped a few months ago, Greg KH, myself,
> and some other people discussed this, and the conclusion seemed to be that
> it was less ugly to make the code that needs bare PCI config access use fake
> structs, than to have the bare functions exposed. Greg, am I remembering
> correctly?
As one of the other people involved, I think the solution which was agreed
on was to have the lower level functions provided with (struct pci_bus *,
u8 dev, u8 fn) since that is what's really needed to implement the config
accesses. The standard PCI config functions, taking struct pci_dev * are
merely a wrapper around these. Greg did a patch to implement it, and it
looks like it got merged.
pci_bus_{read,write}_config_{byte,word,dword}()
--Kai