netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
@ 2010-01-05  3:03 Ben Hutchings
  2010-01-05 16:58 ` Grant Grundler
  0 siblings, 1 reply; 7+ messages in thread
From: Ben Hutchings @ 2010-01-05  3:03 UTC (permalink / raw)
  To: David Miller; +Cc: brandon, grundler, tobias, kyle, netdev, grundler

The Davicom DM9100 and DM9102 chips are used on the motherboards of
some SPARC systems (supported by the tulip driver) and also in PCI
expansion cards (supported by the dmfe driver).  There is no
difference in the PCI device ids for the two different configurations,
so these drivers both claim the device ids.  However, it is possible
to distinguish the two configurations by the presence of Open Firmware
properties for them, so we do that.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Changes from v1, as you requested:
- Downgraded log messages from ERR to INFO
- Removed dummy length parameter to of_get_property()

Ben.

 drivers/net/tulip/Kconfig      |    4 ++++
 drivers/net/tulip/dmfe.c       |   17 +++++++++++++++++
 drivers/net/tulip/tulip_core.c |   32 +++++++++++++++++++++++++-------
 3 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/drivers/net/tulip/Kconfig b/drivers/net/tulip/Kconfig
index 1cc8cf4..516713f 100644
--- a/drivers/net/tulip/Kconfig
+++ b/drivers/net/tulip/Kconfig
@@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION
 
 	  If in doubt, say Y.
 
+config TULIP_DM910X
+	def_bool y
+	depends on TULIP && SPARC
+
 config DE4X5
 	tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA"
 	depends on PCI || EISA
diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
index ad63621..b2273a1 100644
--- a/drivers/net/tulip/dmfe.c
+++ b/drivers/net/tulip/dmfe.c
@@ -377,6 +377,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
 	if (!printed_version++)
 		printk(version);
 
+	/*
+	 *	SPARC on-board DM910x chips should be handled by the main
+	 *	tulip driver, except for early DM9100s.
+	 */
+#ifdef CONFIG_TULIP_DM910X
+	if (ent->driver_data == PCI_DM9100_ID && pdev->revision >= 0x30 ||
+	    ent->driver_data == PCI_DM9102_ID) {
+		struct device_node *dp = pci_device_to_OF_node(pdev);
+
+		if (dp && of_get_property(dp, "local-mac-address", NULL)) {
+			printk(KERN_INFO DRV_NAME
+			       ": skipping on-board DM910x (use tulip)\n");
+			return -ENODEV;
+		}
+	}
+#endif
+
 	/* Init network device */
 	dev = alloc_etherdev(sizeof(*db));
 	if (dev == NULL)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 0fa3140..595777d 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = {
 	| HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },
 
   /* DM910X */
+#ifdef CONFIG_TULIP_DM910X
   { "Davicom DM9102/DM9102A", 128, 0x0001ebef,
 	HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
 	tulip_timer, tulip_media_task },
+#else
+  { NULL },
+#endif
 
   /* RS7112 */
   { "Conexant LANfinity", 256, 0x0001ebef,
@@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = {
 	{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
 	{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
+#ifdef CONFIG_TULIP_DM910X
 	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
 	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
+#endif
 	{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
 	{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
@@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
 	}
 
 	/*
-	 *	Early DM9100's need software CRC and the DMFE driver
+	 *	DM910x chips should be handled by the dmfe driver, except
+	 *	on-board chips on SPARC systems.  Also, early DM9100s need
+	 *	software CRC which only the dmfe driver supports.
 	 */
 
-	if (pdev->vendor == 0x1282 && pdev->device == 0x9100)
-	{
-		/* Read Chip revision */
-		if (pdev->revision < 0x30)
-		{
-			printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n");
+#ifdef CONFIG_TULIP_DM910X
+	if (chip_idx == DM910X) {
+		struct device_node *dp;
+
+		if (pdev->vendor == 0x1282 && pdev->device == 0x9100 &&
+		    pdev->revision < 0x30) {
+			printk(KERN_INFO PFX
+			       "skipping early DM9100 with Crc bug (use dmfe)\n");
+			return -ENODEV;
+		}
+
+		dp = pci_device_to_OF_node(pdev);
+		if (!(dp && of_get_property(dp, "local-mac-address", NULL))) {
+			printk(KERN_INFO PFX
+			       "skipping DM910x expansion card (use dmfe)\n");
 			return -ENODEV;
 		}
 	}
+#endif
 
 	/*
 	 *	Looks for early PCI chipsets where people report hangs
-- 
1.6.5.7



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
  2010-01-05  3:03 [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips Ben Hutchings
@ 2010-01-05 16:58 ` Grant Grundler
  2010-01-07  8:51   ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: Grant Grundler @ 2010-01-05 16:58 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: David Miller, brandon, grundler, tobias, kyle, netdev, grundler

On Tue, Jan 05, 2010 at 03:03:08AM +0000, Ben Hutchings wrote:
> The Davicom DM9100 and DM9102 chips are used on the motherboards of
> some SPARC systems (supported by the tulip driver) and also in PCI
> expansion cards (supported by the dmfe driver).  There is no
> difference in the PCI device ids for the two different configurations,
> so these drivers both claim the device ids.  However, it is possible
> to distinguish the two configurations by the presence of Open Firmware
> properties for them, so we do that.
> 
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

thanks for respinning this several times!
grant

> ---
> Changes from v1, as you requested:
> - Downgraded log messages from ERR to INFO
> - Removed dummy length parameter to of_get_property()
> 
> Ben.
> 
>  drivers/net/tulip/Kconfig      |    4 ++++
>  drivers/net/tulip/dmfe.c       |   17 +++++++++++++++++
>  drivers/net/tulip/tulip_core.c |   32 +++++++++++++++++++++++++-------
>  3 files changed, 46 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/tulip/Kconfig b/drivers/net/tulip/Kconfig
> index 1cc8cf4..516713f 100644
> --- a/drivers/net/tulip/Kconfig
> +++ b/drivers/net/tulip/Kconfig
> @@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION
>  
>  	  If in doubt, say Y.
>  
> +config TULIP_DM910X
> +	def_bool y
> +	depends on TULIP && SPARC
> +
>  config DE4X5
>  	tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA"
>  	depends on PCI || EISA
> diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
> index ad63621..b2273a1 100644
> --- a/drivers/net/tulip/dmfe.c
> +++ b/drivers/net/tulip/dmfe.c
> @@ -377,6 +377,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
>  	if (!printed_version++)
>  		printk(version);
>  
> +	/*
> +	 *	SPARC on-board DM910x chips should be handled by the main
> +	 *	tulip driver, except for early DM9100s.
> +	 */
> +#ifdef CONFIG_TULIP_DM910X
> +	if (ent->driver_data == PCI_DM9100_ID && pdev->revision >= 0x30 ||
> +	    ent->driver_data == PCI_DM9102_ID) {
> +		struct device_node *dp = pci_device_to_OF_node(pdev);
> +
> +		if (dp && of_get_property(dp, "local-mac-address", NULL)) {
> +			printk(KERN_INFO DRV_NAME
> +			       ": skipping on-board DM910x (use tulip)\n");
> +			return -ENODEV;
> +		}
> +	}
> +#endif
> +
>  	/* Init network device */
>  	dev = alloc_etherdev(sizeof(*db));
>  	if (dev == NULL)
> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
> index 0fa3140..595777d 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
> @@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = {
>  	| HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },
>  
>    /* DM910X */
> +#ifdef CONFIG_TULIP_DM910X
>    { "Davicom DM9102/DM9102A", 128, 0x0001ebef,
>  	HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
>  	tulip_timer, tulip_media_task },
> +#else
> +  { NULL },
> +#endif
>  
>    /* RS7112 */
>    { "Conexant LANfinity", 256, 0x0001ebef,
> @@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = {
>  	{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>  	{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
>  	{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
> +#ifdef CONFIG_TULIP_DM910X
>  	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>  	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> +#endif
>  	{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>  	{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
>  	{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
> @@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
>  	}
>  
>  	/*
> -	 *	Early DM9100's need software CRC and the DMFE driver
> +	 *	DM910x chips should be handled by the dmfe driver, except
> +	 *	on-board chips on SPARC systems.  Also, early DM9100s need
> +	 *	software CRC which only the dmfe driver supports.
>  	 */
>  
> -	if (pdev->vendor == 0x1282 && pdev->device == 0x9100)
> -	{
> -		/* Read Chip revision */
> -		if (pdev->revision < 0x30)
> -		{
> -			printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n");
> +#ifdef CONFIG_TULIP_DM910X
> +	if (chip_idx == DM910X) {
> +		struct device_node *dp;
> +
> +		if (pdev->vendor == 0x1282 && pdev->device == 0x9100 &&
> +		    pdev->revision < 0x30) {
> +			printk(KERN_INFO PFX
> +			       "skipping early DM9100 with Crc bug (use dmfe)\n");
> +			return -ENODEV;
> +		}
> +
> +		dp = pci_device_to_OF_node(pdev);
> +		if (!(dp && of_get_property(dp, "local-mac-address", NULL))) {
> +			printk(KERN_INFO PFX
> +			       "skipping DM910x expansion card (use dmfe)\n");
>  			return -ENODEV;
>  		}
>  	}
> +#endif
>  
>  	/*
>  	 *	Looks for early PCI chipsets where people report hangs
> -- 
> 1.6.5.7
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
  2010-01-05 16:58 ` Grant Grundler
@ 2010-01-07  8:51   ` David Miller
  2010-01-07  9:06     ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: David Miller @ 2010-01-07  8:51 UTC (permalink / raw)
  To: grundler; +Cc: ben, brandon, grundler, tobias, kyle, netdev

From: Grant Grundler <grundler@parisc-linux.org>
Date: Tue, 5 Jan 2010 09:58:17 -0700

> On Tue, Jan 05, 2010 at 03:03:08AM +0000, Ben Hutchings wrote:
>> The Davicom DM9100 and DM9102 chips are used on the motherboards of
>> some SPARC systems (supported by the tulip driver) and also in PCI
>> expansion cards (supported by the dmfe driver).  There is no
>> difference in the PCI device ids for the two different configurations,
>> so these drivers both claim the device ids.  However, it is possible
>> to distinguish the two configurations by the presence of Open Firmware
>> properties for them, so we do that.
>> 
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> 
> Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

Applied, thanks everyone.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
  2010-01-07  8:51   ` David Miller
@ 2010-01-07  9:06     ` David Miller
  2010-01-07 12:41       ` [PATCH v3] " Ben Hutchings
  0 siblings, 1 reply; 7+ messages in thread
From: David Miller @ 2010-01-07  9:06 UTC (permalink / raw)
  To: grundler; +Cc: ben, brandon, grundler, tobias, kyle, netdev

From: David Miller <davem@davemloft.net>
Date: Thu, 07 Jan 2010 00:51:25 -0800 (PST)

> From: Grant Grundler <grundler@parisc-linux.org>
> Date: Tue, 5 Jan 2010 09:58:17 -0700
> 
>> On Tue, Jan 05, 2010 at 03:03:08AM +0000, Ben Hutchings wrote:
>>> The Davicom DM9100 and DM9102 chips are used on the motherboards of
>>> some SPARC systems (supported by the tulip driver) and also in PCI
>>> expansion cards (supported by the dmfe driver).  There is no
>>> difference in the PCI device ids for the two different configurations,
>>> so these drivers both claim the device ids.  However, it is possible
>>> to distinguish the two configurations by the presence of Open Firmware
>>> properties for them, so we do that.
>>> 
>>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>> 
>> Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
> 
> Applied, thanks everyone.

Sorry, had to revert, doesn't build:

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-sparc
  CALL    scripts/checksyscalls.sh
  CC [M]  drivers/net/tulip/dmfe.o
drivers/net/tulip/dmfe.c: In function 'dmfe_init_one':
drivers/net/tulip/dmfe.c:386: warning: suggest parentheses around && within ||
drivers/net/tulip/dmfe.c:389: error: implicit declaration of function 'of_get_property'
make[1]: *** [drivers/net/tulip/dmfe.o] Error 1
make: *** [drivers/net/tulip/dmfe.o] Error 2

Please fix this up and resubmit, thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH v3] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
  2010-01-07  9:06     ` David Miller
@ 2010-01-07 12:41       ` Ben Hutchings
  2010-01-07 18:46         ` Grant Grundler
  0 siblings, 1 reply; 7+ messages in thread
From: Ben Hutchings @ 2010-01-07 12:41 UTC (permalink / raw)
  To: David Miller; +Cc: grundler, brandon, grundler, tobias, kyle, netdev

The Davicom DM9100 and DM9102 chips are used on the motherboards of
some SPARC systems (supported by the tulip driver) and also in PCI
expansion cards (supported by the dmfe driver).  There is no
difference in the PCI device ids for the two different configurations,
so these drivers both claim the device ids.  However, it is possible
to distinguish the two configurations by the presence of Open Firmware
properties for them, so we do that.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
On Thu, 2010-01-07 at 01:06 -0800, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 07 Jan 2010 00:51:25 -0800 (PST)
[...]
> > Applied, thanks everyone.
> 
> Sorry, had to revert, doesn't build:
[...]

When I asked for testing on SPARC, I intended that testers should
actually build both drivers!

Here's one more try.  I added conditional inclusion of <linux/of.h> in
dmfe.c.  It has to be conditional because that header doesn't compile on
architectures without OF support.  I also added parentheses to keep the
compiler happy.

Ben.

drivers/net/tulip/Kconfig      |    4 ++++
 drivers/net/tulip/dmfe.c       |   21 +++++++++++++++++++++
 drivers/net/tulip/tulip_core.c |   32 +++++++++++++++++++++++++-------
 3 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/drivers/net/tulip/Kconfig b/drivers/net/tulip/Kconfig
index 1cc8cf4..516713f 100644
--- a/drivers/net/tulip/Kconfig
+++ b/drivers/net/tulip/Kconfig
@@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION
 
 	  If in doubt, say Y.
 
+config TULIP_DM910X
+	def_bool y
+	depends on TULIP && SPARC
+
 config DE4X5
 	tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA"
 	depends on PCI || EISA
diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
index ad63621..6f44ebf 100644
--- a/drivers/net/tulip/dmfe.c
+++ b/drivers/net/tulip/dmfe.c
@@ -92,6 +92,10 @@
 #include <asm/uaccess.h>
 #include <asm/irq.h>
 
+#ifdef CONFIG_TULIP_DM910X
+#include <linux/of.h>
+#endif
+
 
 /* Board/System/Debug information/definition ---------------- */
 #define PCI_DM9132_ID   0x91321282      /* Davicom DM9132 ID */
@@ -377,6 +381,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
 	if (!printed_version++)
 		printk(version);
 
+	/*
+	 *	SPARC on-board DM910x chips should be handled by the main
+	 *	tulip driver, except for early DM9100s.
+	 */
+#ifdef CONFIG_TULIP_DM910X
+	if ((ent->driver_data == PCI_DM9100_ID && pdev->revision >= 0x30) ||
+	    ent->driver_data == PCI_DM9102_ID) {
+		struct device_node *dp = pci_device_to_OF_node(pdev);
+
+		if (dp && of_get_property(dp, "local-mac-address", NULL)) {
+			printk(KERN_INFO DRV_NAME
+			       ": skipping on-board DM910x (use tulip)\n");
+			return -ENODEV;
+		}
+	}
+#endif
+
 	/* Init network device */
 	dev = alloc_etherdev(sizeof(*db));
 	if (dev == NULL)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 0fa3140..595777d 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = {
 	| HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },
 
   /* DM910X */
+#ifdef CONFIG_TULIP_DM910X
   { "Davicom DM9102/DM9102A", 128, 0x0001ebef,
 	HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
 	tulip_timer, tulip_media_task },
+#else
+  { NULL },
+#endif
 
   /* RS7112 */
   { "Conexant LANfinity", 256, 0x0001ebef,
@@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = {
 	{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
 	{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
+#ifdef CONFIG_TULIP_DM910X
 	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
 	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
+#endif
 	{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
 	{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
 	{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
@@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
 	}
 
 	/*
-	 *	Early DM9100's need software CRC and the DMFE driver
+	 *	DM910x chips should be handled by the dmfe driver, except
+	 *	on-board chips on SPARC systems.  Also, early DM9100s need
+	 *	software CRC which only the dmfe driver supports.
 	 */
 
-	if (pdev->vendor == 0x1282 && pdev->device == 0x9100)
-	{
-		/* Read Chip revision */
-		if (pdev->revision < 0x30)
-		{
-			printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n");
+#ifdef CONFIG_TULIP_DM910X
+	if (chip_idx == DM910X) {
+		struct device_node *dp;
+
+		if (pdev->vendor == 0x1282 && pdev->device == 0x9100 &&
+		    pdev->revision < 0x30) {
+			printk(KERN_INFO PFX
+			       "skipping early DM9100 with Crc bug (use dmfe)\n");
+			return -ENODEV;
+		}
+
+		dp = pci_device_to_OF_node(pdev);
+		if (!(dp && of_get_property(dp, "local-mac-address", NULL))) {
+			printk(KERN_INFO PFX
+			       "skipping DM910x expansion card (use dmfe)\n");
 			return -ENODEV;
 		}
 	}
+#endif
 
 	/*
 	 *	Looks for early PCI chipsets where people report hangs
-- 
1.6.5.7



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
  2010-01-07 12:41       ` [PATCH v3] " Ben Hutchings
@ 2010-01-07 18:46         ` Grant Grundler
  2010-01-08  1:27           ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: Grant Grundler @ 2010-01-07 18:46 UTC (permalink / raw)
  To: Ben Hutchings
  Cc: David Miller, grundler, brandon, grundler, tobias, kyle, netdev

On Thu, Jan 07, 2010 at 12:41:51PM +0000, Ben Hutchings wrote:
> The Davicom DM9100 and DM9102 chips are used on the motherboards of
> some SPARC systems (supported by the tulip driver) and also in PCI
> expansion cards (supported by the dmfe driver).  There is no
> difference in the PCI device ids for the two different configurations,
> so these drivers both claim the device ids.  However, it is possible
> to distinguish the two configurations by the presence of Open Firmware
> properties for them, so we do that.
> 
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

thanks,
grant

> ---
> On Thu, 2010-01-07 at 01:06 -0800, David Miller wrote:
> > From: David Miller <davem@davemloft.net>
> > Date: Thu, 07 Jan 2010 00:51:25 -0800 (PST)
> [...]
> > > Applied, thanks everyone.
> > 
> > Sorry, had to revert, doesn't build:
> [...]
> 
> When I asked for testing on SPARC, I intended that testers should
> actually build both drivers!
> 
> Here's one more try.  I added conditional inclusion of <linux/of.h> in
> dmfe.c.  It has to be conditional because that header doesn't compile on
> architectures without OF support.  I also added parentheses to keep the
> compiler happy.
> 
> Ben.
> 
> drivers/net/tulip/Kconfig      |    4 ++++
>  drivers/net/tulip/dmfe.c       |   21 +++++++++++++++++++++
>  drivers/net/tulip/tulip_core.c |   32 +++++++++++++++++++++++++-------
>  3 files changed, 50 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/tulip/Kconfig b/drivers/net/tulip/Kconfig
> index 1cc8cf4..516713f 100644
> --- a/drivers/net/tulip/Kconfig
> +++ b/drivers/net/tulip/Kconfig
> @@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION
>  
>  	  If in doubt, say Y.
>  
> +config TULIP_DM910X
> +	def_bool y
> +	depends on TULIP && SPARC
> +
>  config DE4X5
>  	tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA"
>  	depends on PCI || EISA
> diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
> index ad63621..6f44ebf 100644
> --- a/drivers/net/tulip/dmfe.c
> +++ b/drivers/net/tulip/dmfe.c
> @@ -92,6 +92,10 @@
>  #include <asm/uaccess.h>
>  #include <asm/irq.h>
>  
> +#ifdef CONFIG_TULIP_DM910X
> +#include <linux/of.h>
> +#endif
> +
>  
>  /* Board/System/Debug information/definition ---------------- */
>  #define PCI_DM9132_ID   0x91321282      /* Davicom DM9132 ID */
> @@ -377,6 +381,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
>  	if (!printed_version++)
>  		printk(version);
>  
> +	/*
> +	 *	SPARC on-board DM910x chips should be handled by the main
> +	 *	tulip driver, except for early DM9100s.
> +	 */
> +#ifdef CONFIG_TULIP_DM910X
> +	if ((ent->driver_data == PCI_DM9100_ID && pdev->revision >= 0x30) ||
> +	    ent->driver_data == PCI_DM9102_ID) {
> +		struct device_node *dp = pci_device_to_OF_node(pdev);
> +
> +		if (dp && of_get_property(dp, "local-mac-address", NULL)) {
> +			printk(KERN_INFO DRV_NAME
> +			       ": skipping on-board DM910x (use tulip)\n");
> +			return -ENODEV;
> +		}
> +	}
> +#endif
> +
>  	/* Init network device */
>  	dev = alloc_etherdev(sizeof(*db));
>  	if (dev == NULL)
> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
> index 0fa3140..595777d 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
> @@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = {
>  	| HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },
>  
>    /* DM910X */
> +#ifdef CONFIG_TULIP_DM910X
>    { "Davicom DM9102/DM9102A", 128, 0x0001ebef,
>  	HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
>  	tulip_timer, tulip_media_task },
> +#else
> +  { NULL },
> +#endif
>  
>    /* RS7112 */
>    { "Conexant LANfinity", 256, 0x0001ebef,
> @@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = {
>  	{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>  	{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
>  	{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
> +#ifdef CONFIG_TULIP_DM910X
>  	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>  	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> +#endif
>  	{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>  	{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
>  	{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
> @@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
>  	}
>  
>  	/*
> -	 *	Early DM9100's need software CRC and the DMFE driver
> +	 *	DM910x chips should be handled by the dmfe driver, except
> +	 *	on-board chips on SPARC systems.  Also, early DM9100s need
> +	 *	software CRC which only the dmfe driver supports.
>  	 */
>  
> -	if (pdev->vendor == 0x1282 && pdev->device == 0x9100)
> -	{
> -		/* Read Chip revision */
> -		if (pdev->revision < 0x30)
> -		{
> -			printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n");
> +#ifdef CONFIG_TULIP_DM910X
> +	if (chip_idx == DM910X) {
> +		struct device_node *dp;
> +
> +		if (pdev->vendor == 0x1282 && pdev->device == 0x9100 &&
> +		    pdev->revision < 0x30) {
> +			printk(KERN_INFO PFX
> +			       "skipping early DM9100 with Crc bug (use dmfe)\n");
> +			return -ENODEV;
> +		}
> +
> +		dp = pci_device_to_OF_node(pdev);
> +		if (!(dp && of_get_property(dp, "local-mac-address", NULL))) {
> +			printk(KERN_INFO PFX
> +			       "skipping DM910x expansion card (use dmfe)\n");
>  			return -ENODEV;
>  		}
>  	}
> +#endif
>  
>  	/*
>  	 *	Looks for early PCI chipsets where people report hangs
> -- 
> 1.6.5.7
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
  2010-01-07 18:46         ` Grant Grundler
@ 2010-01-08  1:27           ` David Miller
  0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2010-01-08  1:27 UTC (permalink / raw)
  To: grundler; +Cc: ben, brandon, grundler, tobias, kyle, netdev

From: Grant Grundler <grundler@parisc-linux.org>
Date: Thu, 7 Jan 2010 11:46:24 -0700

> On Thu, Jan 07, 2010 at 12:41:51PM +0000, Ben Hutchings wrote:
>> The Davicom DM9100 and DM9102 chips are used on the motherboards of
>> some SPARC systems (supported by the tulip driver) and also in PCI
>> expansion cards (supported by the dmfe driver).  There is no
>> difference in the PCI device ids for the two different configurations,
>> so these drivers both claim the device ids.  However, it is possible
>> to distinguish the two configurations by the presence of Open Firmware
>> properties for them, so we do that.
>> 
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> 
> Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

Applied.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-01-08  1:27 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-05  3:03 [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips Ben Hutchings
2010-01-05 16:58 ` Grant Grundler
2010-01-07  8:51   ` David Miller
2010-01-07  9:06     ` David Miller
2010-01-07 12:41       ` [PATCH v3] " Ben Hutchings
2010-01-07 18:46         ` Grant Grundler
2010-01-08  1:27           ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).