About both and beyond :)
> For 2.5 I think
> everything is covered, right?
Right.
> > 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.
>
> No, I do not think so. I think the way 2.5 does this is the correct
> way.
access method to the object(pci, pci-express, ...) ala we're in that object
context.
But with the same object concept, mandating pci_bus struct for any pci
config access seems cruel, because others could be affected on changes in
pci objects as we are seeing between 2.4 and 2.5.
Tome, pci config access is simply about PCI/PCI-Express specs, and hence
access should be made with just what it takes - seg, bus, dev, ..., w/o any
implementation dependencies.
> But as I did that patch, I might be a bit biased :)
>
> We could just force every arch to export the same functions that i386
> and ia64 does, that shouldn't be a big deal.
Right. It becomes just a matter of unifying APIs if other architecture have
own low level bare pci config access functions.
> I think this would solve
> the problem on 2.4 for pci hotplug, as ACPI is already "cheating" and
> doing this right now...
>
> thanks,
>
> greg k-h
>
-
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/