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: <da824cf30911300914p2d08b87cr4625e9bc30ec7e5b@mail.gmail.com>
Date:	Mon, 30 Nov 2009 09:14:01 -0800
From:	Grant Grundler <grundler@...gle.com>
To:	Brandon Philips <brandon@...p.org>
Cc:	David Miller <davem@...emloft.net>, tobias@...gis.se,
	kyle@...artin.ca, netdev@...r.kernel.org, grundler@...isc-linux.org
Subject: Re: dmfe/tulip device id overlap

On Sun, Nov 29, 2009 at 10:55 PM, Brandon Philips <brandon@...p.org> wrote:
> Hello Dave-
>
> On 00:30 Sun 29 Nov 2009, David Miller wrote:
>> From: Grant Grundler <grundler@...gle.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@...isc-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
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html