On Tue, 3 Dec 2002, Manfred Spraul wrote: > Donald Becker wrote: > > >No. See what set_bit() (and set_bit_le() in this case) does. It works > >on a bit arry and handles any byte arithmetic/shifting internally. > > > >The dp83815 chip is quirky: > > the filter index is a byte address, > > the filter entries must be written as pairs of bytes > > the filter entry write must be a 32 bit operation. > > > >You may note that the natsemi.c driver in the kernel does not write > >registers using the correct bit width. > Where? The register writes are identical to your driver: ... > > writew(HASH_TABLE + i, ioaddr + RxFilterAddr); > > writew((mc_filter[i+1]<<8) + mc_filter[i], > > ioaddr + RxFilterData); RxFilterAddr and RxFilterData are 32 bit registers. Writing the upper 16 bits of RxFilterAddr will impact the receive mode. It's not clear if it's best to do "| rx_mode" or leave the mode as no-accept when changing the multicast filter. > > writel(rx_mode, ioaddr + RxFilterAddr); This is correct. > Back to the bug: Is the crc function correct? My notes indicate that I did a lot of checking, especially on fencepost values. The notes were on checking with the x86, although the natsemi driver was likely checked on the Alpha last year. > Who wrote the comment > /** > * dp83815_crc - computer CRC for hash table entries > * > * Note - this is, for some reason, *not* the same function > * as ether_crc_le() or ether_crc(), though it uses the > * same big-endian polynomial. > */ Not me... the function is obviously derived from my original version but has been changed. I hope someone had a reason, but many driver changes seem to be done without good reason. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
