dmfe/tulip device id overlap

dmfe/tulip device id overlap

[Brandon Philips]

Hello All-

dmfe and tulip have an overlap of device IDs and it has been discussed
before without resolution[1][2].

The device ID in particular is:

	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },

Users of Fedora[3] and openSUSE[4] are feeling pain from this but
Ubuntu users are avoiding the issue do to the patch below.

This patch comes almost directly from the discussion on the
linux-sparc thread[2]. So, can we merge that patch? Or can one of the
maintainers come up with a less hacky solution (e.g. fix tulip)?

Cheers,

	Brandon

[1] http://www.mail-archive.com/debian-sparc@lists.debian.org/msg21647.html
[2] http://marc.info/?l=linux-sparc&m=123698905214250&w=2
[3] https://bugzilla.redhat.com/show_bug.cgi?id=277731
[4] https://bugzilla.novell.com/show_bug.cgi?id=537016

From: Ben Collins <bcollins@ubuntu.com>
Date: Wed, 18 Jul 2007 17:48:25 +0000 (-0400)
Subject: UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc
X-Git-Tag: Ubuntu-2.6.31-10.31~680
X-Git-Url: http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-karmic.git;a=commitdiff_plain;h=886595ab493b5c5fcf23b55b3ebf46bfe219a5d0

UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc

Signed-off-by: Ben Collins <ben.collins@canonical.com>
---

diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 4cf9a65..b75f65c 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -228,8 +228,12 @@ 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 },
+	/* Ubuntu: On non-sparc, this seems to be handled better by the
+	 * dmfe driver. */
+#ifdef __sparc__
 	{ 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 },

Re: dmfe/tulip device id overlap

[Brandon Philips]

Adding Tobias and Grant under (hopefully) working email addresses. 

Can you please submit patches to update MAINTAINERS with your
preferred email?

On 20:36 Tue 24 Nov 2009, Brandon Philips wrote:
> Hello All-
> 
> dmfe and tulip have an overlap of device IDs and it has been discussed
> before without resolution[1][2].
> 
> The device ID in particular is:
> 
> 	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> 	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> 
> Users of Fedora[3] and openSUSE[4] are feeling pain from this but
> Ubuntu users are avoiding the issue do to the patch below.
> 
> This patch comes almost directly from the discussion on the
> linux-sparc thread[2]. So, can we merge that patch? Or can one of the
> maintainers come up with a less hacky solution (e.g. fix tulip)?
> 
> Cheers,
> 
> 	Brandon
> 
> [1] http://www.mail-archive.com/debian-sparc@lists.debian.org/msg21647.html
> [2] http://marc.info/?l=linux-sparc&m=123698905214250&w=2
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=277731
> [4] https://bugzilla.novell.com/show_bug.cgi?id=537016
> 
> From: Ben Collins <bcollins@ubuntu.com>
> Date: Wed, 18 Jul 2007 17:48:25 +0000 (-0400)
> Subject: UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc
> X-Git-Tag: Ubuntu-2.6.31-10.31~680
> X-Git-Url: http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-karmic.git;a=commitdiff_plain;h=886595ab493b5c5fcf23b55b3ebf46bfe219a5d0
> 
> UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc
> 
> Signed-off-by: Ben Collins <ben.collins@canonical.com>
> ---
> 
> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
> index 4cf9a65..b75f65c 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
> @@ -228,8 +228,12 @@ 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 },
> +	/* Ubuntu: On non-sparc, this seems to be handled better by the
> +	 * dmfe driver. */
> +#ifdef __sparc__
>  	{ 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 },

Re: dmfe/tulip device id overlap

[Grant Grundler]

On Tue, Nov 24, 2009 at 8:49 PM, Brandon Philips <brandon@ifup.org> wrote:
> Adding Tobias and Grant under (hopefully) working email addresses.
>
> Can you please submit patches to update MAINTAINERS with your
> preferred email?

grundler@parisc-linux.org is my preferred email for tulip driver
issues. Is that bouncing? :(


> On 20:36 Tue 24 Nov 2009, Brandon Philips wrote:
>> Hello All-
>>
>> dmfe and tulip have an overlap of device IDs and it has been discussed
>> before without resolution[1][2].
>>
>> The device ID in particular is:
>>
>>       { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>>       { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>>
>> Users of Fedora[3] and openSUSE[4] are feeling pain from this but
>> Ubuntu users are avoiding the issue do to the patch below.
>>
>> This patch comes almost directly from the discussion on the
>> linux-sparc thread[2]. So, can we merge that patch? Or can one of the
>> maintainers come up with a less hacky solution (e.g. fix tulip)?

I'm totally ok with "clipping" the DMFE ids so tulip and dmfe drivers
have no overlap. I just can't test it since I don't have those cards.
It sounds like people know which driver works on sparc.


>>
>> Cheers,
>>
>>       Brandon
>>
>> [1] http://www.mail-archive.com/debian-sparc@lists.debian.org/msg21647.html
>> [2] http://marc.info/?l=linux-sparc&m=123698905214250&w=2
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=277731
>> [4] https://bugzilla.novell.com/show_bug.cgi?id=537016
>>
>> From: Ben Collins <bcollins@ubuntu.com>
>> Date: Wed, 18 Jul 2007 17:48:25 +0000 (-0400)
>> Subject: UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc
>> X-Git-Tag: Ubuntu-2.6.31-10.31~680
>> X-Git-Url: http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-karmic.git;a=commitdiff_plain;h=886595ab493b5c5fcf23b55b3ebf46bfe219a5d0
>>
>> UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc
>>
>> Signed-off-by: Ben Collins <ben.collins@canonical.com>

I'm ok with this patch except the mention of Ubuntu in the comment is
superfluous. All the distro's will share this problem. I trust davem
to rewrite the comment and plase add my:
    Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

cheers,
grant

>> ---
>>
>> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
>> index 4cf9a65..b75f65c 100644
>> --- a/drivers/net/tulip/tulip_core.c
>> +++ b/drivers/net/tulip/tulip_core.c
>> @@ -228,8 +228,12 @@ 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 },
>> +     /* Ubuntu: On non-sparc, this seems to be handled better by the
>> +      * dmfe driver. */
>> +#ifdef __sparc__
>>       { 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 },
>

Re: dmfe/tulip device id overlap

[David Miller]

From: Grant Grundler <grundler@google.com>
Date: Wed, 25 Nov 2009 09:24:54 -0800

> I'm ok with this patch except the mention of Ubuntu in the comment is
> superfluous. All the distro's will share this problem. I trust davem
> to rewrite the comment and plase add my:
>     Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

Please remove the comment and the __sparc__ ifdef.

If tulip doesn't work on some sparc systems we simply need to fix it.

Thanks.

Re: dmfe/tulip device id overlap

[Brandon Philips]

Hello Dave-

On 00:30 Sun 29 Nov 2009, David Miller wrote:
> From: Grant Grundler <grundler@google.com>
> Date: Wed, 25 Nov 2009 09:24:54 -0800
> 
> > I'm ok with this patch except the mention of Ubuntu in the comment is
> > superfluous. All the distro's will share this problem. I trust davem
> > to rewrite the comment and plase add my:
> >     Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
> 
> Please remove the comment and the __sparc__ ifdef.

The comment and the __sparc__ ifdef is the entire patch... so you NACK
the whole patch?? ;)

> If tulip doesn't work on some sparc systems we simply need to fix
> it.

Tulip works on sparc as described in the linux-sparc[1] thread.  The
problem as I understand it:

tulip works for the 0x9100 and 0x9102 parts that were onboard a few
sparc motherboards.

But, those same device IDs are used by a set of Davicom PCI cards that
only work with the dmfe driver.

Thus, the patch only lets tulip handle 0x9100 and 0x9102 if __sparc__.

Perhaps someone knows if there is a way to tell the PCI card from the
sparc builtin machine?

Cheers,

	Brandon

[1] http://marc.info/?l=linux-sparc&m=123698696912216&w=2

Re: dmfe/tulip device id overlap

[David Miller]

From: Brandon Philips <brandon@ifup.org>
Date: Sun, 29 Nov 2009 22:55:12 -0800

> Thus, the patch only lets tulip handle 0x9100 and 0x9102 if __sparc__.
> 
> Perhaps someone knows if there is a way to tell the PCI card from the
> sparc builtin machine?

We should get both cases working in one of the two drivers,
preferrably Tulip.

That's the outcome I'm trying to say is the only legitimate one.

Re: dmfe/tulip device id overlap

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Sun, 2009-11-29 at 23:07 -0800, David Miller wrote:
> From: Brandon Philips <brandon@ifup.org>
> Date: Sun, 29 Nov 2009 22:55:12 -0800
> 
> > Thus, the patch only lets tulip handle 0x9100 and 0x9102 if __sparc__.
> > 
> > Perhaps someone knows if there is a way to tell the PCI card from the
> > sparc builtin machine?
> 
> We should get both cases working in one of the two drivers,
> preferrably Tulip.
> 
> That's the outcome I'm trying to say is the only legitimate one.

If the problem is that the drivers are not portable, then this makes
sense.  However, as I understand it, the problem is that the same device
ids have been assigned to significantly different controllers/boards.
In this case it may be better for both of the drivers to claim the
device ids and to distinguish them at probe time.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: dmfe/tulip device id overlap

[David Miller]

From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 30 Nov 2009 12:46:25 +0000

> If the problem is that the drivers are not portable, then this makes
> sense.  However, as I understand it, the problem is that the same device
> ids have been assigned to significantly different controllers/boards.
> In this case it may be better for both of the drivers to claim the
> device ids and to distinguish them at probe time.

It is going to be so easy to tell them apart.

Simply because onboard devices on Sparc are going to have
openfirmware, so there are going to be OF device properties and
whatnot we can probe for if necessary.

And the only difference the chips can have at this level is what kind
of PHY et al. are attached to the MAC.  Fundamentally the devices are
going to be the same.

Re: dmfe/tulip device id overlap

[Grant Grundler]

On Sun, Nov 29, 2009 at 10:55 PM, Brandon Philips <brandon@ifup.org> wrote:
> Hello Dave-
>
> On 00:30 Sun 29 Nov 2009, David Miller wrote:
>> From: Grant Grundler <grundler@google.com>
>> Date: Wed, 25 Nov 2009 09:24:54 -0800
>>
>> > I'm ok with this patch except the mention of Ubuntu in the comment is
>> > superfluous. All the distro's will share this problem. I trust davem
>> > to rewrite the comment and plase add my:
>> >     Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
>>
>> Please remove the comment and the __sparc__ ifdef.
>
> The comment and the __sparc__ ifdef is the entire patch... so you NACK
> the whole patch?? ;)
>
>> If tulip doesn't work on some sparc systems we simply need to fix
>> it.
>
> Tulip works on sparc as described in the linux-sparc[1] thread.  The
> problem as I understand it:
>
> tulip works for the 0x9100 and 0x9102 parts that were onboard a few
> sparc motherboards.

Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
V100" motherboards?

I'm asking because I'm hoping it's possible to disambiguate the add-on
cards from
LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
If we are lucky, those subsystem ID to use "Sun Microsystems" Vendor IDs:
    http://www.pcidatabase.com/vendor_details.php?id=526

and this will be easy to resolve.

> But, those same device IDs are used by a set of Davicom PCI cards that
> only work with the dmfe driver.
>
> Thus, the patch only lets tulip handle 0x9100 and 0x9102 if __sparc__.
>
> Perhaps someone knows if there is a way to tell the PCI card from the
> sparc builtin machine?

Do any add-on DMFE devices have OpenBOOT firmware support?
(e.g. for the Mac?) My expectation is the SPARC motherboard
devices do but that needs to be confirmed.

To be clear, I have no interest in merging dmfe driver support into
tulip driver.
I'm open to review patches that do that (and test them). Right now, I'd
only like to resolve the immediate problem SPARC users are seeing
since that seems to be pretty straight forward.

hth,
grant

>
> Cheers,
>
>        Brandon
>
> [1] http://marc.info/?l=linux-sparc&m=123698696912216&w=2
>

Re: dmfe/tulip device id overlap

[David Miller]

From: Grant Grundler <grundler@google.com>
Date: Mon, 30 Nov 2009 09:14:01 -0800

> Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
> V100" motherboards?
> 
> I'm asking because I'm hoping it's possible to disambiguate the add-on
> cards from
> LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.

I think more likely OF properties will help here.

Have a look at:

	git://git.kernel.org/pub/scm/linux/kernel/git/davem/prtconfs.git

In particular 'v100' which has a network device OF node with properties:

        Node 0xf007fae8
            .node:  f007fae8
            local-mac-address:  0003ba11.b371
            assigned-addresses:  81006010.00000000.00010000.00000000.00000100.82006014.00000000.00000000.00000000.00002000.82006030.00000000.00040000.00000000.00040000
            version: '1.0'
            compatible:  70636934.3535342c.34333465.00706369.31323868.2c393130.32007063.69313238.322c3931.30320070.6369636c.6173732c.30323030.303000
            device_type: 'network'
            subsystem-id:  0000434e
            subsystem-vendor-id:  00004554
            reg:  00006000.00000000.00000000.00000000.00000000.01006010.00000000.00000000.00000000.00000100.02006014.00000000.00000000.00000000.00000100
            name: 'ethernet'
            devsel-speed:  00000001
            class-code:  00020000
            interrupts:  00000001
            max-latency:  00000028
            min-grant:  00000014
            revision-id:  00000031
            device-id:  00009102
            vendor-id:  00001282

Hmmm, what vendor is '0x4554'? :-)

Re: dmfe/tulip device id overlap

[Brandon Philips]

On 12:26 Mon 30 Nov 2009, David Miller wrote:
> From: Grant Grundler <grundler@google.com>
> Date: Mon, 30 Nov 2009 09:14:01 -0800
> > Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
> > V100" motherboards?
> > 
> > I'm asking because I'm hoping it's possible to disambiguate the add-on
> > cards from
> > LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
> 
>             subsystem-id:  0000434e
>             subsystem-vendor-id:  00004554
>
> Hmmm, what vendor is '0x4554'? :-)

Whoever it is it is the same as the expansion card on non-sparc
boards: SubVendor: pci 0x4554 [1]

Hrm, dead end I guess.

Cheers,

	Brandon

[1] https://bugzilla.novell.com/show_bug.cgi?id=537016#c5

Re: dmfe/tulip device id overlap

[David Miller]

From: Brandon Philips <brandon@ifup.org>
Date: Mon, 30 Nov 2009 14:22:20 -0800

> On 12:26 Mon 30 Nov 2009, David Miller wrote:
>> From: Grant Grundler <grundler@google.com>
>> Date: Mon, 30 Nov 2009 09:14:01 -0800
>> > Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
>> > V100" motherboards?
>> > 
>> > I'm asking because I'm hoping it's possible to disambiguate the add-on
>> > cards from
>> > LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
>> 
>>             subsystem-id:  0000434e
>>             subsystem-vendor-id:  00004554
>>
>> Hmmm, what vendor is '0x4554'? :-)
> 
> Whoever it is it is the same as the expansion card on non-sparc
> boards: SubVendor: pci 0x4554 [1]
> 
> Hrm, dead end I guess.

We still have the OF properties.  So we can simply look for
merely the existence of a 'compatible' OF property on the
device and from that we'll know that it's a Sparc onboard
instance of this thing.

[PATCH] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips

[Ben Hutchings]

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 Mon, 2009-11-30 at 14:29 -0800, David Miller wrote:
> From: Brandon Philips <brandon@ifup.org>
> Date: Mon, 30 Nov 2009 14:22:20 -0800
> 
> > On 12:26 Mon 30 Nov 2009, David Miller wrote:
> >> From: Grant Grundler <grundler@google.com>
> >> Date: Mon, 30 Nov 2009 09:14:01 -0800
> >> > Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
> >> > V100" motherboards?
> >> > 
> >> > I'm asking because I'm hoping it's possible to disambiguate the add-on
> >> > cards from
> >> > LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
> >> 
> >>             subsystem-id:  0000434e
> >>             subsystem-vendor-id:  00004554
> >>
> >> Hmmm, what vendor is '0x4554'? :-)
> > 
> > Whoever it is it is the same as the expansion card on non-sparc
> > boards: SubVendor: pci 0x4554 [1]
> > 
> > Hrm, dead end I guess.
> 
> We still have the OF properties.  So we can simply look for
> merely the existence of a 'compatible' OF property on the
> device and from that we'll know that it's a Sparc onboard
> instance of this thing.

Here's my attempt at solving this.  It is untested since I do not have
any DM910x hardware.  It will need to be tested on SPARC for both
configurations (on-board vs expansion card).

The DM9100 revision check in tulip is probably redundant, but I have
left it in place.

Dave, does the OF property check look reasonable?  I have never dealt
with OF before.

Ben.

 drivers/net/tulip/Kconfig      |    4 ++++
 drivers/net/tulip/dmfe.c       |   18 ++++++++++++++++++
 drivers/net/tulip/tulip_core.c |   30 ++++++++++++++++++++++++------
 3 files changed, 46 insertions(+), 6 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..004d285 100644
--- a/drivers/net/tulip/dmfe.c
+++ b/drivers/net/tulip/dmfe.c
@@ -377,6 +377,24 @@ 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);
+		int len;
+
+		if (dp && of_get_property(dp, "local-mac-address", &len)) {
+			printk(KERN_ERR 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..e9d1cf0 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)
-		{
+#ifdef CONFIG_TULIP_DM910X
+	if (chip_idx == DM910X) {
+		struct device_node *dp;
+		int len;
+
+		if (pdev->vendor == 0x1282 && pdev->device == 0x9100 &&
+		    pdev->revision < 0x30) {
 			printk(KERN_ERR 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", &len))) {
+			printk(KERN_ERR PFX
+			       "skipping DM910x expansion card (use dmfe)\n");
+			return -ENODEV;
+		}
 	}
+#endif
 
 	/*
 	 *	Looks for early PCI chipsets where people report hangs
-- 
1.6.5.7

Re: [PATCH] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips

[Grant Grundler]

On Tue, Dec 29, 2009 at 06:22:28PM +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>

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

I've reviewed the code and it looks fine to me.

Only thing I'm not sure about is if "KERN_ERR" is
the right priority for what are essentially warning
messages. Not harmful. But could be annoying to some
Sparc users who get this on every boot when both modules
are present and loaded in the "wrong" order.

thanks!
grant

> ---
> On Mon, 2009-11-30 at 14:29 -0800, David Miller wrote:
> > From: Brandon Philips <brandon@ifup.org>
> > Date: Mon, 30 Nov 2009 14:22:20 -0800
> > 
> > > On 12:26 Mon 30 Nov 2009, David Miller wrote:
> > >> From: Grant Grundler <grundler@google.com>
> > >> Date: Mon, 30 Nov 2009 09:14:01 -0800
> > >> > Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
> > >> > V100" motherboards?
> > >> > 
> > >> > I'm asking because I'm hoping it's possible to disambiguate the add-on
> > >> > cards from
> > >> > LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
> > >> 
> > >>             subsystem-id:  0000434e
> > >>             subsystem-vendor-id:  00004554
> > >>
> > >> Hmmm, what vendor is '0x4554'? :-)
> > > 
> > > Whoever it is it is the same as the expansion card on non-sparc
> > > boards: SubVendor: pci 0x4554 [1]
> > > 
> > > Hrm, dead end I guess.
> > 
> > We still have the OF properties.  So we can simply look for
> > merely the existence of a 'compatible' OF property on the
> > device and from that we'll know that it's a Sparc onboard
> > instance of this thing.
> 
> Here's my attempt at solving this.  It is untested since I do not have
> any DM910x hardware.  It will need to be tested on SPARC for both
> configurations (on-board vs expansion card).
> 
> The DM9100 revision check in tulip is probably redundant, but I have
> left it in place.

I think it's fine.

> 
> Dave, does the OF property check look reasonable?  I have never dealt
> with OF before.
> 
> Ben.
> 
>  drivers/net/tulip/Kconfig      |    4 ++++
>  drivers/net/tulip/dmfe.c       |   18 ++++++++++++++++++
>  drivers/net/tulip/tulip_core.c |   30 ++++++++++++++++++++++++------
>  3 files changed, 46 insertions(+), 6 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..004d285 100644
> --- a/drivers/net/tulip/dmfe.c
> +++ b/drivers/net/tulip/dmfe.c
> @@ -377,6 +377,24 @@ 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);
> +		int len;
> +
> +		if (dp && of_get_property(dp, "local-mac-address", &len)) {
> +			printk(KERN_ERR 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..e9d1cf0 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)
> -		{
> +#ifdef CONFIG_TULIP_DM910X
> +	if (chip_idx == DM910X) {
> +		struct device_node *dp;
> +		int len;
> +
> +		if (pdev->vendor == 0x1282 && pdev->device == 0x9100 &&
> +		    pdev->revision < 0x30) {
>  			printk(KERN_ERR 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", &len))) {
> +			printk(KERN_ERR PFX
> +			       "skipping DM910x expansion card (use dmfe)\n");
> +			return -ENODEV;
> +		}
>  	}
> +#endif
>  
>  	/*
>  	 *	Looks for early PCI chipsets where people report hangs
> -- 
> 1.6.5.7
> 

Re: [PATCH] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips

[David Miller]

From: Grant Grundler <grundler@parisc-linux.org>
Date: Tue, 29 Dec 2009 11:41:52 -0700

> On Tue, Dec 29, 2009 at 06:22:28PM +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>
> 
> Acked-by: Grant Grundler <grundler@parisc-linux.org>
> 
> I've reviewed the code and it looks fine to me.
> 
> Only thing I'm not sure about is if "KERN_ERR" is
> the right priority for what are essentially warning
> messages. Not harmful. But could be annoying to some
> Sparc users who get this on every boot when both modules
> are present and loaded in the "wrong" order.

I agree, KERN_INFO is more appropriate here.

Also, for the of_get_property() calls, you don't need to pass
in a dummy "&len", just pass NULL.  This will avoid the dummy
local variable 'len'.

Make these two fixups and I'll apply this to net-2.6

Thanks!

Re: dmfe/tulip device id overlap

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Tue, 2009-11-24 at 20:36 -0800, Brandon Philips wrote:
> Hello All-
> 
> dmfe and tulip have an overlap of device IDs and it has been discussed
> before without resolution[1][2].
> 
> The device ID in particular is:
> 
> 	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> 	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> 
> Users of Fedora[3] and openSUSE[4] are feeling pain from this but
> Ubuntu users are avoiding the issue do to the patch below.
[...]

Also an open bug in Debian (#515533).  Thanks for pushing this issue.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]