All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: David Miller <davem@davemloft.net>
Cc: brandon@ifup.org, grundler@google.com, tobias@ringis.se,
	kyle@mcmartin.ca, netdev@vger.kernel.org,
	grundler@parisc-linux.org
Subject: Re: dmfe/tulip device id overlap
Date: Mon, 30 Nov 2009 12:46:25 +0000	[thread overview]
Message-ID: <1259585185.3709.181.camel@localhost> (raw)
In-Reply-To: <20091129.230703.206229796.davem@davemloft.net>

[-- 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 --]

  reply	other threads:[~2009-11-30 12:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25  4:36 dmfe/tulip device id overlap Brandon Philips
2009-11-25  4:49 ` Brandon Philips
2009-11-25 17:24   ` Grant Grundler
2009-11-29  8:30     ` David Miller
2009-11-30  6:55       ` Brandon Philips
2009-11-30  7:07         ` David Miller
2009-11-30 12:46           ` Ben Hutchings [this message]
2009-11-30 20:21             ` David Miller
2009-11-30 17:14         ` Grant Grundler
2009-11-30 20:26           ` David Miller
2009-11-30 22:22             ` Brandon Philips
2009-11-30 22:29               ` David Miller
2009-12-29 18:22                 ` [PATCH] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips Ben Hutchings
2009-12-29 18:41                   ` Grant Grundler
2010-01-04  5:36                     ` David Miller
2009-11-25 13:08 ` dmfe/tulip device id overlap Ben Hutchings

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1259585185.3709.181.camel@localhost \
    --to=ben@decadent.org.uk \
    --cc=brandon@ifup.org \
    --cc=davem@davemloft.net \
    --cc=grundler@google.com \
    --cc=grundler@parisc-linux.org \
    --cc=kyle@mcmartin.ca \
    --cc=netdev@vger.kernel.org \
    --cc=tobias@ringis.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.