1. 27 Nov, 2011 2 commits
  2. 26 Nov, 2011 31 commits
  3. 25 Nov, 2011 2 commits
  4. 24 Nov, 2011 5 commits
    • Axel Lin's avatar
      net: mv643xx_eth: fix build error · 6f39da2c
      Axel Lin authored
      Fix below build error:
        CC      drivers/net/ethernet/marvell/mv643xx_eth.o
      drivers/net/ethernet/marvell/mv643xx_eth.c: In function 'mv643xx_eth_get_drvinfo':
      drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: 'info' undeclared (first use in this function)
      drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: (Each undeclared identifier is reported only once
      drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: for each function it appears in.)
      make[4]: *** [drivers/net/ethernet/marvell/mv643xx_eth.o] Error 1
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f39da2c
    • Li Wei's avatar
      ipv4: Save nexthop address of LSRR/SSRR option to IPCB. · ac8a4810
      Li Wei authored
      We can not update iph->daddr in ip_options_rcv_srr(), It is too early.
      When some exception ocurred later (eg. in ip_forward() when goto
      sr_failed) we need the ip header be identical to the original one as
      ICMP need it.
      
      Add a field 'nexthop' in struct ip_options to save nexthop of LSRR
      or SSRR option.
      Signed-off-by: default avatarLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac8a4810
    • Anton Blanchard's avatar
      ehea: Use round_jiffies_relative to align workqueue · 67c170a2
      Anton Blanchard authored
      Use round_jiffies_relative to align the ehea workqueue and avoid
      extra wakeups.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67c170a2
    • Anton Blanchard's avatar
      ehea: Reduce memory usage in buffer pools · aa9084a0
      Anton Blanchard authored
      Now that we enable multiqueue by default the ehea driver is using
      quite a lot of memory for its buffer pools. With 4 queues we
      consume 64MB in the jumbo packet ring, 16MB in the medium packet
      ring and 16MB in the tiny packet ring.
      
      We should only fill the jumbo ring once the MTU is increased but
      for now halve it's size so it consumes 32MB. Also reduce the tiny
      packet ring, with 4 queues we had 16k entries which is overkill.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa9084a0
    • Thadeu Lima de Souza Cascardo's avatar
      qlge: fix size of external list for TX address descriptors · 78242853
      Thadeu Lima de Souza Cascardo authored
      When transmiting a fragmented skb, qlge fills a descriptor with the
      fragment addresses, after DMA-mapping them. If there are more than eight
      fragments, it will use the eighth descriptor as a pointer to an external
      list. After mapping this external list, called OAL to a structure
      containing more descriptors, it fills it with the extra fragments.
      
      However, considering that systems with pages larger than 8KiB would have
      less than 8 fragments, which was true before commit a715dea3, it
      defined a macro for the OAL size as 0 in those cases.
      
      Now, if a skb with more than 8 fragments (counting skb->data as one
      fragment), this would start overwriting the list of addresses already
      mapped and would make the driver fail to properly unmap the right
      addresses on architectures with pages larger than 8KiB.
      
      Besides that, the list of mappings was one size too small, since it must
      have a mapping for the maxinum number of skb fragments plus one for
      skb->data and another for the OAL. So, even on architectures with page
      sizes 4KiB and 8KiB, a skb with the maximum number of fragments would
      make the driver overwrite its counter for the number of mappings, which,
      again, would make it fail to unmap the mapped DMA addresses.
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78242853