Re: [PATCH 2/3] pci: Remove users of pci_enable_device_bars()
On Thu, Jan 31, 2008 at 04:14:45PM -0800, Andrew Vasquez wrote: > On Tue, 08 Jan 2008, Benjamin Herrenschmidt wrote: > > > On Mon, 2008-01-07 at 11:42 -0800, Andrew Vasquez wrote: > > > That's fine. I take it these patches will be funneled via > > > gregkh/pci-2.6.git. There's some qla2xxx updates which are queued for > > > post-2.6.24 consumption in jejb/scsi-misc-2.6.git which don't appear > > > to have any conflicts. > > > > > > I do though have a series of patches which I'll hold off on submitting > > > to linux-scsi until these PCI changes are merged, as there's some > > > minor conflicts merging the three branches. James B, will that be > > > fine? > > > > > > The patches themselves appear to be working fine within several of our > > > test rings. I hold off on some of the cleanup post-merge time... > > > > Thanks for testing ! They should be queued with Greg indeed. > > Just curious, this patch-set hasn't made it upstream to linux-2.6.git, > will the work be deferred to 2.6.26?? It's less than one week into the merge window, and people are getting worried, sheesh :) Yes, this is queued up to go to Linus, been busy working on other issues at the moment, don't worry, I'll make the window. Hopefully get them all out tomorrow... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] pci: Remove users of pci_enable_device_bars()
On Tue, 08 Jan 2008, Benjamin Herrenschmidt wrote: > On Mon, 2008-01-07 at 11:42 -0800, Andrew Vasquez wrote: > > That's fine. I take it these patches will be funneled via > > gregkh/pci-2.6.git. There's some qla2xxx updates which are queued for > > post-2.6.24 consumption in jejb/scsi-misc-2.6.git which don't appear > > to have any conflicts. > > > > I do though have a series of patches which I'll hold off on submitting > > to linux-scsi until these PCI changes are merged, as there's some > > minor conflicts merging the three branches. James B, will that be > > fine? > > > > The patches themselves appear to be working fine within several of our > > test rings. I hold off on some of the cleanup post-merge time... > > Thanks for testing ! They should be queued with Greg indeed. Just curious, this patch-set hasn't made it upstream to linux-2.6.git, will the work be deferred to 2.6.26?? -- av -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] pci: Remove users of pci_enable_device_bars()
On Mon, 2008-01-07 at 11:42 -0800, Andrew Vasquez wrote: > That's fine. I take it these patches will be funneled via > gregkh/pci-2.6.git. There's some qla2xxx updates which are queued for > post-2.6.24 consumption in jejb/scsi-misc-2.6.git which don't appear > to have any conflicts. > > I do though have a series of patches which I'll hold off on submitting > to linux-scsi until these PCI changes are merged, as there's some > minor conflicts merging the three branches. James B, will that be > fine? > > The patches themselves appear to be working fine within several of our > test rings. I hold off on some of the cleanup post-merge time... Thanks for testing ! They should be queued with Greg indeed. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] pci: Remove users of pci_enable_device_bars()
On Thu, 20 Dec 2007, Benjamin Herrenschmidt wrote:
> This patch converts users of pci_enable_device_bars() to the new
> pci_enable_device_{io,mem} interface.
>
> The new API fits nicely, except maybe for the QLA case where a bit of
> code re-organization might be a good idea but I prefer sticking to the
> simple patch as I don't have hardware to test on.
That's fine. I take it these patches will be funneled via
gregkh/pci-2.6.git. There's some qla2xxx updates which are queued for
post-2.6.24 consumption in jejb/scsi-misc-2.6.git which don't appear
to have any conflicts.
I do though have a series of patches which I'll hold off on submitting
to linux-scsi until these PCI changes are merged, as there's some
minor conflicts merging the three branches. James B, will that be
fine?
The patches themselves appear to be working fine within several of our
test rings. I hold off on some of the cleanup post-merge time...
Thanks,
Andrew Vasquez
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
>
> drivers/ata/pata_cs5520.c |2 +-
> drivers/i2c/busses/scx200_acb.c |2 +-
> drivers/ide/pci/cs5520.c| 10 --
> drivers/ide/setup-pci.c |6 --
> drivers/scsi/lpfc/lpfc_init.c |3 +--
> drivers/scsi/qla2xxx/qla_os.c | 12 +---
Acked-by: Andrew Vasquez <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] pci: Remove users of pci_enable_device_bars()
This patch converts users of pci_enable_device_bars() to the new
pci_enable_device_{io,mem} interface.
The new API fits nicely, except maybe for the QLA case where a bit of
code re-organization might be a good idea but I prefer sticking to the
simple patch as I don't have hardware to test on.
I'll also need some feedback on the cs5520 change.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/ata/pata_cs5520.c |2 +-
drivers/i2c/busses/scx200_acb.c |2 +-
drivers/ide/pci/cs5520.c| 10 --
drivers/ide/setup-pci.c |6 --
drivers/scsi/lpfc/lpfc_init.c |3 +--
drivers/scsi/qla2xxx/qla_os.c | 12 +---
6 files changed, 24 insertions(+), 11 deletions(-)
--- linux-work.orig/drivers/ata/pata_cs5520.c 2007-12-18 09:37:55.0
+1100
+++ linux-work/drivers/ata/pata_cs5520.c2007-12-18 09:39:03.0
+1100
@@ -229,7 +229,7 @@ static int __devinit cs5520_init_one(str
return -ENOMEM;
/* Perform set up for DMA */
- if (pci_enable_device_bars(pdev, 1<<2)) {
+ if (pci_enable_device_io(pdev)) {
printk(KERN_ERR DRV_NAME ": unable to configure BAR2.\n");
return -ENODEV;
}
Index: linux-work/drivers/i2c/busses/scx200_acb.c
===
--- linux-work.orig/drivers/i2c/busses/scx200_acb.c 2007-12-18
09:37:55.0 +1100
+++ linux-work/drivers/i2c/busses/scx200_acb.c 2007-12-18 09:39:03.0
+1100
@@ -492,7 +492,7 @@ static __init int scx200_create_pci(cons
iface->pdev = pdev;
iface->bar = bar;
- rc = pci_enable_device_bars(iface->pdev, 1 << iface->bar);
+ rc = pci_enable_device_io(iface->pdev);
if (rc)
goto errout_free;
Index: linux-work/drivers/ide/pci/cs5520.c
===
--- linux-work.orig/drivers/ide/pci/cs5520.c2007-12-18 09:37:55.0
+1100
+++ linux-work/drivers/ide/pci/cs5520.c 2007-12-18 09:39:03.0 +1100
@@ -160,8 +160,14 @@ static int __devinit cs5520_init_one(str
ide_setup_pci_noise(dev, d);
/* We must not grab the entire device, it has 'ISA' space in its
- BARS too and we will freak out other bits of the kernel */
- if (pci_enable_device_bars(dev, 1<<2)) {
+* BARS too and we will freak out other bits of the kernel
+*
+* pci_enable_device_bars() is going away. I replaced it with
+* IO only enable for now but I'll need confirmation this is
+* allright for that device. If not, it will need some kind of
+* quirk. --BenH.
+*/
+ if (pci_enable_device_io(dev)) {
printk(KERN_WARNING "%s: Unable to enable 55x0.\n", d->name);
return -ENODEV;
}
Index: linux-work/drivers/ide/setup-pci.c
===
--- linux-work.orig/drivers/ide/setup-pci.c 2007-12-18 09:37:55.0
+1100
+++ linux-work/drivers/ide/setup-pci.c 2007-12-18 09:40:07.0 +1100
@@ -236,7 +236,9 @@ EXPORT_SYMBOL_GPL(ide_setup_pci_noise);
* @d: IDE port info
*
* Enable the IDE PCI device. We attempt to enable the device in full
- * but if that fails then we only need BAR4 so we will enable that.
+ * but if that fails then we only need IO space. The PCI code should
+ * have setup the proper resources for us already for controllers in
+ * legacy mode.
*
* Returns zero on success or an error code
*/
@@ -246,7 +248,7 @@ static int ide_pci_enable(struct pci_dev
int ret;
if (pci_enable_device(dev)) {
- ret = pci_enable_device_bars(dev, 1 << 4);
+ ret = pci_enable_device_io(dev);
if (ret < 0) {
printk(KERN_WARNING "%s: (ide_setup_pci_device:) "
"Could not enable device.\n", d->name);
Index: linux-work/drivers/scsi/lpfc/lpfc_init.c
===
--- linux-work.orig/drivers/scsi/lpfc/lpfc_init.c 2007-12-18
09:37:55.0 +1100
+++ linux-work/drivers/scsi/lpfc/lpfc_init.c2007-12-18 09:39:03.0
+1100
@@ -2100,10 +2100,9 @@ static pci_ers_result_t lpfc_io_slot_res
struct Scsi_Host *shost = pci_get_drvdata(pdev);
struct lpfc_hba *phba = ((struct lpfc_vport *)shost->hostdata)->phba;
struct lpfc_sli *psli = &phba->sli;
- int bars = pci_select_bars(pdev, IORESOURCE_MEM);
dev_printk(KERN_INFO, &pdev->dev, "recovering from a slot reset.\n");
- if (pci_enable_device_bars(pdev, bars)) {
+ if (pci_enable_device_mem(pdev)) {
printk(KERN_ERR "lpfc: Cannot re-enable "
"PCI device after reset.\n");
return PCI_ERS_RESULT_DISCONNECT;
Index: linux-work/drivers/scsi/qla2x
