1. 29 5月, 2008 7 次提交
  2. 03 5月, 2008 5 次提交
  3. 29 4月, 2008 1 次提交
  4. 25 4月, 2008 1 次提交
  5. 20 4月, 2008 1 次提交
    • M
      tg3: 5701 DMA corruption fix · 41588ba1
      Matt Carlson 提交于
      Herbert Xu's commit fb93134d, entitled
      "[TCP]: Fix size calculation in sk_stream_alloc_pskb", has triggered a
      bug in the 5701 where the 5701 DMA engine will corrupt outgoing
      packets.  This problem only happens when the starting address of the
      packet matches a certain range of offsets and only when the 5701 is
      placed downstream of a particular Intel bridge.
      
      This patch detects the problematic bridge and if present, readjusts the
      starting address of the packet data to a dword aligned boundary.
      Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41588ba1
  6. 13 4月, 2008 1 次提交
    • S
      tg3: fix MMIO for PPC 44x platforms · 2de58e30
      Sergei Shtylyov 提交于
      The driver stores the PCI resource addresses into 'unsigned long' variable
      before calling ioremap_nocache() on them. This warrants kernel oops when the
      registers are accessed on PPC 44x platforms which (being 32-bit) have PCI
      memory space mapped beyond 4 GB.
      
      The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion that
      the PCI memory resource is mapped below 4 GB, but arch/powerpc/ code got rid
      of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
      
      [ Bump driver version and release date -DaveM ]
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2de58e30
  7. 04 4月, 2008 1 次提交
  8. 21 3月, 2008 1 次提交
  9. 24 2月, 2008 1 次提交
  10. 29 1月, 2008 10 次提交
  11. 20 12月, 2007 2 次提交
    • A
      [TG3]: Endianness bugfix. · 286e310f
      Al Viro 提交于
      tg3_nvram_write_block_unbuffered() is reading data from nvram into
      allocated buffer before overwriting a part of it with user-supplied
      data.  Then it feeds the entire page back to nvram.  It should be
      storing the words it had read as little-endian, not as host-endian.
      Note that tg3_set_eeprom() does exactly that for padding the same
      data to full words before it gets passed down to tg3_nvram_write_block()
      and then to tg3_nvram_write_block_unbuffered().
      
      Moreover, when we get to sending the entire thing back to nvram, we
      go through it word-by-word, doing essentially
      	writel(swab32(le32_to_cpu(word)), ...)
      so if we want them to reach the card in host-independent endianness,
      we'd better really have all that buffer filled with fixed-endian.
      For user-supplied part we obviously do have that (it's an array of
      octets memcpy'd in), ditto for padding of user-supplied part to word
      boundaries (taken care of in tg3_set_eeprom()).  The rest of the
      buffer gets filled by tg3_nvram_write_block_unbuffered() and it would
      damn better be consistent with that (and with tg3_get_eeprom(), while
      we are at it - there we also convert the words read from nvram to
      little-endian before returning the buffer to user).
      
      The bug should get triggered on big-endian boxen when set_eeprom is done
      for less than entire page.  Then the words that should've been unaffected
      at all will actually get byteswapped in place in nvram.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      286e310f
    • A
      [TG3]: Endianness annotations. · b9fc7dc5
      Al Viro 提交于
      Fixed misannotations, introduced a new helper - tg3_nvram_read_le().
      It gets __le32 * instead of u32 * and puts there the value converted
      to little-endian.  A lot of callers of tg3_nvram_read() were doing
      that; converted them to tg3_nvram_read_le().
      
      At that point the driver is practically endian-clean; the only remaining
      place is an actual bug, AFAICS; will be dealt with in the next patch.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9fc7dc5
  12. 13 11月, 2007 9 次提交