lkml.org 
[lkml]   [2002]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [patch] PCI Cleanup
On Wed, 14 Aug 2002, Grover, Andrew wrote:

> ACPI needs access to PCI config space, and it doesn't have a struct pci_dev
> to pass to access functions. It doesn't look like your patch exposes an
> interface that 1) doesn't require a pci_dev and 2) abstracts the PCI config
> access method, does it?

I think drivers/hotplug/pci_hotplug_util.c implements something like you
need, pci_read_config_byte_nodev().

Of course that's currently only available for PCI hotplug, and for all I
can see the concept is somewhat messed up, but maybe that's an opportunity
to clean things up?

Currently, pci_read_config_byte_nodev() will construct a fake struct
pci_dev, and then use the normal pci_read_config_byte(). I think it
makes more sense to actually do things the other way around.

For reading/writing config space, we need to know (dev, fn), and need the
access method (struct pci_ops), which is a property of the bridge plus
possibly some private data (the arch's sysdata). So the member

struct pci_ops *ops;

of struct pci_dev is actually not necessary, it will always be
pdev->ops == pdev->bus->ops AFAICS.

So we could instead have

pci_bus_read_config_byte(struct pci_bus *bus, u8 dev, u8 fn, ...)

and for common use

static inline pci_read_config_byte(struct pci_dev, *pdev, ...)
{
return pci_bus_read_config_byte(pdev->bus,
PCI_SLOT(pdev->devfn),
PCI_FUNC(pdev->devfn));
}

The PCI hotplug controllers / ACPI could then use the pci_bus_* variants,
when they don't have a struct pci_dev available. They would need at least
the root bridge's struct pci_bus, though.

--Kai


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.081 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site