1. 29 3月, 2008 2 次提交
    • P
      dm9601: Fix multicast hash table handling · 47df976c
      Peter Korsgaard 提交于
      The loop forgot to walk the net->mc_list list, so only the first
      multicast address was programmed into the hash table.
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      47df976c
    • G
      [netdrvr] tulip_read_eeprom fixes for BUG 4420 · 209261c0
      Grant Grundler 提交于
      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: NGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      209261c0
  2. 28 3月, 2008 8 次提交
  3. 27 3月, 2008 2 次提交
  4. 26 3月, 2008 28 次提交