diff options
author | Grant Grundler <grundler@parisc-linux.org> | 2008-03-23 23:23:10 -0600 |
---|---|---|
committer | Jeff Garzik <jeff@garzik.org> | 2008-03-28 21:52:14 -0400 |
commit | 209261c019f56d77f6a0cc38048e9a6f25867589 (patch) | |
tree | 36824a55e62c33e4ae4c24ce824d2948a83924de /drivers/net/usb/dm9601.c | |
parent | 3480c63bdf008e9289aab94418f43b9592978fff (diff) | |
download | op-kernel-dev-209261c019f56d77f6a0cc38048e9a6f25867589.zip op-kernel-dev-209261c019f56d77f6a0cc38048e9a6f25867589.tar.gz |
[netdrvr] tulip_read_eeprom fixes for BUG 4420
If "location" is > "addr_len" bits, the high bits of location would interfere
with the READ_CMD sent to the eeprom controller.
A patch was submitted to bug:
http://bugzilla.kernel.org/show_bug.cgi?id=4420
which simply truncated the "location", read whatever was in "location
modulo addr_len", and returned that value. That avoids confusing the
eeprom but seems like the wrong solution to me.
Correct would be to not read beyond "1 << addr_len" address of the eeprom.
I am submitting two changes to implement this:
1) tulip_read_eeprom will return zero (since we can't return -EINVAL)
if this is attempted (defensive programming).
2) In tulip_core.c, fix the tulip_read_eeprom caller so they don't
iterate past addr_len bits and make sure the entire tp->eeprom[]
array is cleared.
I konw we don't strictly need both. I would prefer both in the tree
since it documents the issue and provides a second "defense" from
the bug from creeping back in.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'drivers/net/usb/dm9601.c')
0 files changed, 0 insertions, 0 deletions