netdev - Re: [patch] NET: remove support for Davicom 9102 from the Tulip driver

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]

Date:	Fri, 04 Apr 2008 17:59:56 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Meelis Roos <mroos@...ux.ee>
CC:	netdev@...r.kernel.org, Grant Grundler <grundler@...isc-linux.org>
Subject: Re: [patch] NET: remove support for Davicom 9102 from the Tulip driver

Meelis Roos wrote:
>>> -     { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> 
>> applied
> 
> Hmm, did you see my yesterdays answer to that patch - that dmfe should 
> first be fixed to work on all  cards with this PCI ID? Currenty dmfe 
> fails to work on at least Sun Fire V100 and Sun Netra X1 boxes, only 
> tulip works.
> 

Maybe this tulip_core.c code needs to be applied to dmfe.c?

         if (tulip_uli_dm_quirk(pdev)) {
                 csr0 &= ~0x01f100ff;
#if defined(CONFIG_SPARC)
                 csr0 = (csr0 & ~0xff00) | 0xe000;
#endif
         }

A zeroed MAC address leads me to believe that dmfe's SROM parsing isn't 
quite as capable as tulip's, though that's just a guess.

Just checked dmfe with sparse and it reports clean, though looking at 
the code it could use some cleanups.

	Jeff



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