Nat Ersoz wrote:
Fellows,
I'm debugging a problem in the natsemi.c driver which has the symptom
that muticast reception quits for no apparent reason. Unicast still
works fine, the multicast stream is being sent, but no packets make it
past the hash filter. In versions of the driver, 2.4.19 and before, we
"fixed" this problem by setting ifconfig "allmuti" on the device.
As I'm writing a debug routine, I notice that:
static void __set_rx_mode(struct net_device *dev)
{
...
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
i++, mclist = mclist->next) {
set_bit_le(
dp83815_crc(ETH_ALEN, mclist->dmi_addr) & 0x1ff,
mc_filter); /* WHOOPS!! Shouldn't this be &mc_filter[i*2] ?? */
}
...
}
(see the comment containnig WHOOPS)
Nope. You're setting the bit from 0 to ((8*64)-1), where bit 0 starts at mc_filter offset zero. So, setting bit 400 via this code is just fine.
Perfectly legal to do since you know your boundaries, but a bit scary to be intentionally overrunning the bounds of an unsigned long :) Also I _think_ in 2.5.x kernels this slips into the category of abuse, since the compiler started warning about the use of set_bit on things that were not strictly unsigned long.
I am, however, a bit curious why this code differs from Becker's natsemi.c in the use of set_bit versus set_bit_le. writel() and outl() do byte-swapping for us, so I wonder if this code is correct on big-endian.
Jeff
-
: 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
