netdev - Re: dmfe/tulip device id overlap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1259585185.3709.181.camel@localhost>
Date:	Mon, 30 Nov 2009 12:46:25 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	David Miller <davem@...emloft.net>
Cc:	brandon@...p.org, grundler@...gle.com, tobias@...gis.se,
	kyle@...artin.ca, netdev@...r.kernel.org, grundler@...isc-linux.org
Subject: Re: dmfe/tulip device id overlap

On Sun, 2009-11-29 at 23:07 -0800, David Miller wrote:
> From: Brandon Philips <brandon@...p.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.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)