Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus

[Meelis Roos]

Forwarded from linux-scsi.

---------- Forwarded message ----------
Date: Mon, 17 Apr 2006 10:30:50 -0400
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Meelis Roos <mroos@linux.ee>
Cc: linux-scsi@vger.kernel.org
Subject: Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus

On Mon, 2006-04-17 at 13:22 +0300, Meelis Roos wrote:
> WARNING: /lib/modules/2.6.17-rc1-gc19f7a9e/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko needs unknown symbol pcibios_resource_to_bus
>
> Is is something missing from sparc64, or is sym53c8xx using something
> arch-specific (pcibios sounds like it)?

pcibios_resource_to_bus is a new function which is inline in
asm-generic/pci.h.   However, sparc64 overrides it as an external
function which is in arch/sparc64/kernel/pci.c, so this looks like some
type of sparc issue.

James

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus (fwd)

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Mon, 17 Apr 2006 18:49:41 +0300 (EEST)

Putting linux-scsi and James back on the CC:

> Forwarded from linux-scsi.
 ...
> pcibios_resource_to_bus is a new function which is inline in
> asm-generic/pci.h.   However, sparc64 overrides it as an external
> function which is in arch/sparc64/kernel/pci.c, so this looks like some
> type of sparc issue.

Why does the SYM2 driver possible even need this symbol?
That's what I'd like to have explained.

When this slipped into the Ubuntu kernel, I pushed back on it because
the usage was bogus, and I fear this is the same exact thing rearing
it's ugly head.

There is no reason to export this symbol outside of the generic PCI
code, which does not require a module symbol export.

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Mon, 17 Apr 2006 18:49:41 +0300 (EEST)

Putting linux-scsi and James back on the CC:

> Forwarded from linux-scsi.
 ...
> pcibios_resource_to_bus is a new function which is inline in
> asm-generic/pci.h.   However, sparc64 overrides it as an external
> function which is in arch/sparc64/kernel/pci.c, so this looks like some
> type of sparc issue.

Why does the SYM2 driver possible even need this symbol?
That's what I'd like to have explained.

When this slipped into the Ubuntu kernel, I pushed back on it because
the usage was bogus, and I fear this is the same exact thing rearing
it's ugly head.

There is no reason to export this symbol outside of the generic PCI
code, which does not require a module symbol export.

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus (fwd)

[David S. Miller]

From: "David S. Miller" <davem@davemloft.net>
Date: Mon, 17 Apr 2006 13:17:05 -0700 (PDT)

> From: Meelis Roos <mroos@linux.ee>
> Date: Mon, 17 Apr 2006 18:49:41 +0300 (EEST)
> 
> Putting linux-scsi and James back on the CC:
> 
> > Forwarded from linux-scsi.
>  ...
> > pcibios_resource_to_bus is a new function which is inline in
> > asm-generic/pci.h.   However, sparc64 overrides it as an external
> > function which is in arch/sparc64/kernel/pci.c, so this looks like some
> > type of sparc issue.
> 
> Why does the SYM2 driver possible even need this symbol?
> That's what I'd like to have explained.

Ok, here is the changeset in question.

If you're going to do stuff like this, being that you're the
first driver to ever make direct usage of this interface,
please double check the exports on all platforms so that you
haven't broken the build of the driver as you have on sparc64.

diff-tree b6d105d7ee188040a6e5eb86101e7476d94b3076 (from 1f61d82490a26dbcde903b33e24f6d11b758b64c)
Author: Matthew Wilcox <matthew@wil.cx>
Date:   Tue Mar 28 11:03:44 2006 -0500

    [SCSI] Use pcibios_resource_to_bus()
    
    We had our own code (pci_get_base_address()) to get the bus address of
    a BAR.  We can get this using pcibios_resource_to_bus() instead.
    
    Signed-off-by: Matthew Wilcox <matthew@wil.cx>
    Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
index ec9d93a..e6ff89a 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -134,45 +134,6 @@ static void sym2_setup_params(void)
 	}
 }
 
-/*
- * We used to try to deal with 64-bit BARs here, but don't any more.
- * There are many parts of this driver which would need to be modified
- * to handle a 64-bit base address, including scripts.  I'm uncomfortable
- * with making those changes when I have no way of testing it, so I'm
- * just going to disable it.
- *
- * Note that some machines (eg HP rx8620 and Superdome) have bus addresses
- * below 4GB and physical addresses above 4GB.  These will continue to work.
- */
-static int __devinit
-pci_get_base_address(struct pci_dev *pdev, int index, unsigned long *basep)
-{
-	u32 tmp;
-	unsigned long base;
-#define PCI_BAR_OFFSET(index) (PCI_BASE_ADDRESS_0 + (index<<2))
-
-	pci_read_config_dword(pdev, PCI_BAR_OFFSET(index++), &tmp);
-	base = tmp;
-	if ((tmp & 0x7) == PCI_BASE_ADDRESS_MEM_TYPE_64) {
-		pci_read_config_dword(pdev, PCI_BAR_OFFSET(index++), &tmp);
-		if (tmp > 0) {
-			dev_err(&pdev->dev,
-				"BAR %d is 64-bit, disabling\n", index - 1);
-			base = 0;
-		}
-	}
-
-	if ((base & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
-		base &= PCI_BASE_ADDRESS_IO_MASK;
-	} else {
-		base &= PCI_BASE_ADDRESS_MEM_MASK;
-	}
-
-	*basep = base;
-	return index;
-#undef PCI_BAR_OFFSET
-}
-
 static struct scsi_transport_template *sym2_transport_template = NULL;
 
 /*
@@ -1866,13 +1827,23 @@ static int __devinit sym_set_workarounds
 static void __devinit
 sym_init_device(struct pci_dev *pdev, struct sym_device *device)
 {
-	int i;
+	int i = 2;
+	struct pci_bus_region bus_addr;
 
 	device->host_id = SYM_SETUP_HOST_ID;
 	device->pdev = pdev;
 
-	i = pci_get_base_address(pdev, 1, &device->mmio_base);
-	pci_get_base_address(pdev, i, &device->ram_base);
+	pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[1]);
+	device->mmio_base = bus_addr.start;
+
+	/*
+	 * If the BAR is 64-bit, resource 2 will be occupied by the
+	 * upper 32 bits
+	 */
+	if (!pdev->resource[i].flags)
+		i++;
+	pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[i]);
+	device->ram_base = bus_addr.start;
 
 #ifdef CONFIG_SCSI_SYM53C8XX_MMIO
 	if (device->mmio_base)

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus

[David S. Miller]

From: "David S. Miller" <davem@davemloft.net>
Date: Mon, 17 Apr 2006 13:17:05 -0700 (PDT)

> From: Meelis Roos <mroos@linux.ee>
> Date: Mon, 17 Apr 2006 18:49:41 +0300 (EEST)
> 
> Putting linux-scsi and James back on the CC:
> 
> > Forwarded from linux-scsi.
>  ...
> > pcibios_resource_to_bus is a new function which is inline in
> > asm-generic/pci.h.   However, sparc64 overrides it as an external
> > function which is in arch/sparc64/kernel/pci.c, so this looks like some
> > type of sparc issue.
> 
> Why does the SYM2 driver possible even need this symbol?
> That's what I'd like to have explained.

Ok, here is the changeset in question.

If you're going to do stuff like this, being that you're the
first driver to ever make direct usage of this interface,
please double check the exports on all platforms so that you
haven't broken the build of the driver as you have on sparc64.

diff-tree b6d105d7ee188040a6e5eb86101e7476d94b3076 (from 1f61d82490a26dbcde903b33e24f6d11b758b64c)
Author: Matthew Wilcox <matthew@wil.cx>
Date:   Tue Mar 28 11:03:44 2006 -0500

    [SCSI] Use pcibios_resource_to_bus()
    
    We had our own code (pci_get_base_address()) to get the bus address of
    a BAR.  We can get this using pcibios_resource_to_bus() instead.
    
    Signed-off-by: Matthew Wilcox <matthew@wil.cx>
    Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
index ec9d93a..e6ff89a 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -134,45 +134,6 @@ static void sym2_setup_params(void)
 	}
 }
 
-/*
- * We used to try to deal with 64-bit BARs here, but don't any more.
- * There are many parts of this driver which would need to be modified
- * to handle a 64-bit base address, including scripts.  I'm uncomfortable
- * with making those changes when I have no way of testing it, so I'm
- * just going to disable it.
- *
- * Note that some machines (eg HP rx8620 and Superdome) have bus addresses
- * below 4GB and physical addresses above 4GB.  These will continue to work.
- */
-static int __devinit
-pci_get_base_address(struct pci_dev *pdev, int index, unsigned long *basep)
-{
-	u32 tmp;
-	unsigned long base;
-#define PCI_BAR_OFFSET(index) (PCI_BASE_ADDRESS_0 + (index<<2))
-
-	pci_read_config_dword(pdev, PCI_BAR_OFFSET(index++), &tmp);
-	base = tmp;
-	if ((tmp & 0x7) = PCI_BASE_ADDRESS_MEM_TYPE_64) {
-		pci_read_config_dword(pdev, PCI_BAR_OFFSET(index++), &tmp);
-		if (tmp > 0) {
-			dev_err(&pdev->dev,
-				"BAR %d is 64-bit, disabling\n", index - 1);
-			base = 0;
-		}
-	}
-
-	if ((base & PCI_BASE_ADDRESS_SPACE) = PCI_BASE_ADDRESS_SPACE_IO) {
-		base &= PCI_BASE_ADDRESS_IO_MASK;
-	} else {
-		base &= PCI_BASE_ADDRESS_MEM_MASK;
-	}
-
-	*basep = base;
-	return index;
-#undef PCI_BAR_OFFSET
-}
-
 static struct scsi_transport_template *sym2_transport_template = NULL;
 
 /*
@@ -1866,13 +1827,23 @@ static int __devinit sym_set_workarounds
 static void __devinit
 sym_init_device(struct pci_dev *pdev, struct sym_device *device)
 {
-	int i;
+	int i = 2;
+	struct pci_bus_region bus_addr;
 
 	device->host_id = SYM_SETUP_HOST_ID;
 	device->pdev = pdev;
 
-	i = pci_get_base_address(pdev, 1, &device->mmio_base);
-	pci_get_base_address(pdev, i, &device->ram_base);
+	pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[1]);
+	device->mmio_base = bus_addr.start;
+
+	/*
+	 * If the BAR is 64-bit, resource 2 will be occupied by the
+	 * upper 32 bits
+	 */
+	if (!pdev->resource[i].flags)
+		i++;
+	pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[i]);
+	device->ram_base = bus_addr.start;
 
 #ifdef CONFIG_SCSI_SYM53C8XX_MMIO
 	if (device->mmio_base)

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus (fwd)

[Matthew Wilcox]

On Mon, Apr 17, 2006 at 01:26:38PM -0700, David S. Miller wrote:
> From: "David S. Miller" <davem@davemloft.net>
> Date: Mon, 17 Apr 2006 13:17:05 -0700 (PDT)
> 
> > > Forwarded from linux-scsi.
> >  ...
> > > pcibios_resource_to_bus is a new function which is inline in
> > > asm-generic/pci.h.   However, sparc64 overrides it as an external
> > > function which is in arch/sparc64/kernel/pci.c, so this looks like some
> > > type of sparc issue.

"new" in the sense of "2 years old"?
2003-03-16 	rmk 	[PCI] pci-8: pci_resource_to_bus()

> > Why does the SYM2 driver possible even need this symbol?
> > That's what I'd like to have explained.

Because the firmware needs to be programmed with the bus address.  It's
not unique in this; the Emulex lpfc driver should also be using this
function.

> If you're going to do stuff like this, being that you're the
> first driver to ever make direct usage of this interface,
> please double check the exports on all platforms so that you
> haven't broken the build of the driver as you have on sparc64.

Er, pcmcia was already using it:

./drivers/pcmcia/i82092.c:      pcibios_resource_to_bus(sock_info->dev,
&region, mem->res);
./drivers/pcmcia/yenta_socket.c:
pcibios_resource_to_bus(socket->dev, &region, mem->res);
./drivers/pcmcia/yenta_socket.c:
pcibios_resource_to_bus(socket->dev, &region, &dev->resource[0]);

I suppose you don't test pci-pcmcia adapters very often on sparc64.

Is there a problem with adding the symbol export?  I noticed that v850
also doesn't export that symbol.

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus (fwd)

[Matthew Wilcox]

On Mon, Apr 17, 2006 at 01:26:38PM -0700, David S. Miller wrote:
> From: "David S. Miller" <davem@davemloft.net>
> Date: Mon, 17 Apr 2006 13:17:05 -0700 (PDT)
> 
> > > Forwarded from linux-scsi.
> >  ...
> > > pcibios_resource_to_bus is a new function which is inline in
> > > asm-generic/pci.h.   However, sparc64 overrides it as an external
> > > function which is in arch/sparc64/kernel/pci.c, so this looks like some
> > > type of sparc issue.

"new" in the sense of "2 years old"?
2003-03-16 	rmk 	[PCI] pci-8: pci_resource_to_bus()

> > Why does the SYM2 driver possible even need this symbol?
> > That's what I'd like to have explained.

Because the firmware needs to be programmed with the bus address.  It's
not unique in this; the Emulex lpfc driver should also be using this
function.

> If you're going to do stuff like this, being that you're the
> first driver to ever make direct usage of this interface,
> please double check the exports on all platforms so that you
> haven't broken the build of the driver as you have on sparc64.

Er, pcmcia was already using it:

./drivers/pcmcia/i82092.c:      pcibios_resource_to_bus(sock_info->dev,
&region, mem->res);
./drivers/pcmcia/yenta_socket.c:
pcibios_resource_to_bus(socket->dev, &region, mem->res);
./drivers/pcmcia/yenta_socket.c:
pcibios_resource_to_bus(socket->dev, &region, &dev->resource[0]);

I suppose you don't test pci-pcmcia adapters very often on sparc64.

Is there a problem with adding the symbol export?  I noticed that v850
also doesn't export that symbol.

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus (fwd)

[David S. Miller]

From: Matthew Wilcox <matthew@wil.cx>
Date: Tue, 18 Apr 2006 21:59:08 -0600

> I suppose you don't test pci-pcmcia adapters very often on sparc64.
> 
> Is there a problem with adding the symbol export?  I noticed that v850
> also doesn't export that symbol.

I added it already.

Re: 2.6.17-rc1+git, Sym2: unknown symbol pcibios_resource_to_bus

[David S. Miller]

From: Matthew Wilcox <matthew@wil.cx>
Date: Tue, 18 Apr 2006 21:59:08 -0600

> I suppose you don't test pci-pcmcia adapters very often on sparc64.
> 
> Is there a problem with adding the symbol export?  I noticed that v850
> also doesn't export that symbol.

I added it already.