| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
MAINTAINERS | 4 ++--
drivers/net/tulip/21142.c | 2 +-
drivers/net/tulip/eeprom.c | 2 +-
drivers/net/tulip/interrupt.c | 2 +-
drivers/net/tulip/media.c | 2 +-
drivers/net/tulip/pnic.c | 2 +-
drivers/net/tulip/pnic2.c | 2 +-
drivers/net/tulip/timer.c | 2 +-
drivers/net/tulip/tulip_core.c | 2 +-
9 files changed, 10 insertions(+), 10 deletions(-)
|
|
|
|
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
