On Tue, 2007-12-18 at 12:37 +0300, Ivan Kokshaysky wrote:
> On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote:
> > +EXPORT_SYMBOL(pci_enable_device_io);
> > +EXPORT_SYMBOL(pci_enable_device_mem);
> > EXPORT_SYMBOL(pci_enable_device);
>
> Wouldn't it be better to export only
On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote:
> +EXPORT_SYMBOL(pci_enable_device_io);
> +EXPORT_SYMBOL(pci_enable_device_mem);
> EXPORT_SYMBOL(pci_enable_device);
Wouldn't it be better to export only the pci_enable_device_flags()
and make these three just "static
On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote:
+EXPORT_SYMBOL(pci_enable_device_io);
+EXPORT_SYMBOL(pci_enable_device_mem);
EXPORT_SYMBOL(pci_enable_device);
Wouldn't it be better to export only the pci_enable_device_flags()
and make these three just static inline
On Tue, 2007-12-18 at 12:37 +0300, Ivan Kokshaysky wrote:
On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote:
+EXPORT_SYMBOL(pci_enable_device_io);
+EXPORT_SYMBOL(pci_enable_device_mem);
EXPORT_SYMBOL(pci_enable_device);
Wouldn't it be better to export only the
On Tue, 2007-12-18 at 00:49 +0100, Johannes Weiner wrote:
> These two functions should be refactored, the only difference is the
> flag checking.
FYI. Here's what it looks like in my next version of the patch:
Index: linux-work/drivers/pci/pci.c
On Tue, 2007-12-18 at 00:49 +0100, Johannes Weiner wrote:
>
> These two functions should be refactored, the only difference is the
> flag checking.
Yeah, I somewhat though about it... anyway, it's not important right
now, I'm waiting for feedback on the approach itself. I'll send a new
patch
Hi Benjamin,
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> --- linux-work.orig/drivers/pci/pci.c 2007-12-18 09:37:56.0 +1100
> +++ linux-work/drivers/pci/pci.c 2007-12-18 09:38:25.0 +1100
> [...]
> +int pci_enable_device_io(struct pci_dev *dev)
> +{
> + int err;
>
The pci_enable_device_bars() interface isn't well suited to PCI
because you can't actually enable/disable BARs individually on
a device. So for example, if a device has 2 memory BARs 0 and 1,
and one of them (let's say 1) has not been successfully allocated
by the firmware or the kernel, then
The pci_enable_device_bars() interface isn't well suited to PCI
because you can't actually enable/disable BARs individually on
a device. So for example, if a device has 2 memory BARs 0 and 1,
and one of them (let's say 1) has not been successfully allocated
by the firmware or the kernel, then
Hi Benjamin,
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
--- linux-work.orig/drivers/pci/pci.c 2007-12-18 09:37:56.0 +1100
+++ linux-work/drivers/pci/pci.c 2007-12-18 09:38:25.0 +1100
[...]
+int pci_enable_device_io(struct pci_dev *dev)
+{
+ int err;
+
On Tue, 2007-12-18 at 00:49 +0100, Johannes Weiner wrote:
These two functions should be refactored, the only difference is the
flag checking.
Yeah, I somewhat though about it... anyway, it's not important right
now, I'm waiting for feedback on the approach itself. I'll send a new
patch with
On Tue, 2007-12-18 at 00:49 +0100, Johannes Weiner wrote:
These two functions should be refactored, the only difference is the
flag checking.
FYI. Here's what it looks like in my next version of the patch:
Index: linux-work/drivers/pci/pci.c
12 matches
Mail list logo
