Kai Germaschewski wrote:
> I still think it's probably a good idea to replace pci_enable_device()
> by a more fine-grained API, which allows a driver author to specify
> which exact resources he needs.
To repeat, pci_enable_device is not _just_ resource assignment.
It also provides:
1) power state management (wakes up the device)
2) an entry point which guarantees the bus layer that the driver is not
interested in the hardware at all before that point. Or IOW,
pci_enable_device is a bus layer hook for whatever "device
wakeup/appearing" needs that bus has. Sure, we are talking about moving
some of that functionality to other functions (pci_request_<foo>), but
that doesn't mean we should ditch the hook altogether.
Remember, we have a matching pair here: pci_enable_device,
pci_disable_device. Update the code that goes on between those two
calls, sure. But leave the calls there.
> So a complete API would be
>
> pci_request_{irq,io,mmio}
> pci_release_{irq,io,mmio}
> pci_enable_{irq,io,mmio}
> pci_assign_{irq,io,mmio}
>
> but normally a driver would just use pci_request/release_*() + maybe
> pci_assign_irq(), which will take care of the appropriate assign/enable
> internally.
That seems like a decent enough API, pending a bit of driver conversion
to see how well it works out in practice. So I'm ok with it (with the
pci_enable_device proviso, above)
Jeff
-
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 : Sat Jun 15 2002 - 22:00:33 EST