1. 20 Apr, 2011 3 commits
  2. 19 Apr, 2011 1 commit
  3. 18 Apr, 2011 5 commits
  4. 13 Apr, 2011 1 commit
  5. 12 Apr, 2011 2 commits
    • Sujith Manoharan's avatar
      ath9k_htc: Fix ethtool reporting · 50f68712
      Sujith Manoharan authored
      Pass the correct module name and device interface so that
      ethtool can display the proper values.
      
      The firmware version will be fixed later on when the FW
      can actually report a version. :)
      Reported-by: default avatarRichard Farina <sidhayn@gmail.com>
      Signed-off-by: default avatarSujith Manoharan <Sujith.Manoharan@atheros.com>
      Tested-by: default avatarRichard Farina <sidhayn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      50f68712
    • Felix Fietkau's avatar
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      Felix Fietkau authored
      During PHY errors, the MAC can sometimes fail to enter an idle state on older
      hardware (before AR9380) after an rx stop has been requested.
      
      This typically shows up in the kernel log with messages like these:
      
      ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
      ------------[ cut here ]------------
      WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
      Call Trace:
      [<8023f0e8>] dump_stack+0x8/0x34
      [<80075050>] warn_slowpath_common+0x78/0xa4
      [<80075094>] warn_slowpath_null+0x18/0x24
      [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
      [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
      [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]
      
      When this happens, the state that the MAC enters is easy to identify and
      does not result in bogus DMA traffic, however to ensure a working state
      after a channel change, the hardware should still be reset.
      
      This patch adds detection for this specific MAC state, after which the above
      warnings completely disappear in my tests.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5882da02
  6. 11 Apr, 2011 1 commit
  7. 08 Apr, 2011 2 commits
  8. 07 Apr, 2011 3 commits
  9. 04 Apr, 2011 13 commits
  10. 02 Apr, 2011 7 commits
    • Ilpo Järvinen's avatar
      tcp: len check is unnecessarily devastating, change to WARN_ON · 2fceec13
      Ilpo Järvinen authored
      All callers are prepared for alloc failures anyway, so this error
      can safely be boomeranged to the callers domain without super
      bad consequences. ...At worst the connection might go into a state
      where each RTO tries to (unsuccessfully) re-fragment with such
      a mis-sized value and eventually dies.
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fceec13
    • Wei Yongjun's avatar
      sctp: malloc enough room for asconf-ack chunk · 2cab86be
      Wei Yongjun authored
      Sometime the ASCONF_ACK parameters can equal to the fourfold of
      ASCONF parameters, this only happend in some special case:
      
        ASCONF parameter is :
          Unrecognized Parameter (4 bytes)
        ASCONF_ACK parameter should be:
          Error Cause Indication parameter (8 bytes header)
           + Error Cause (4 bytes header)
             + Unrecognized Parameter (4bytes)
      
      Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic.
      
      Pid: 0, comm: swapper Not tainted 2.6.38-next+ #22 Bochs Bochs
      EIP: 0060:[<c0717eae>] EFLAGS: 00010246 CPU: 0
      EIP is at skb_put+0x60/0x70
      EAX: 00000077 EBX: c09060e2 ECX: dec1dc30 EDX: c09469c0
      ESI: 00000000 EDI: de3c8d40 EBP: dec1dc58 ESP: dec1dc2c
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=dec1c000 task=c09aef20 task.ti=c0980000)
      Stack:
       c09469c0 e1894fa4 00000044 00000004 de3c8d00 de3c8d00 de3c8d44 de3c8d40
       c09060e2 de25dd80 de3c8d40 dec1dc7c e1894fa4 dec1dcb0 00000040 00000004
       00000000 00000800 00000004 00000004 dec1dce0 e1895a2b dec1dcb4 de25d960
      Call Trace:
       [<e1894fa4>] ? sctp_addto_chunk+0x4e/0x89 [sctp]
       [<e1894fa4>] sctp_addto_chunk+0x4e/0x89 [sctp]
       [<e1895a2b>] sctp_process_asconf+0x32f/0x3d1 [sctp]
       [<e188d554>] sctp_sf_do_asconf+0xf8/0x173 [sctp]
       [<e1890b02>] sctp_do_sm+0xb8/0x159 [sctp]
       [<e18a2248>] ? sctp_cname+0x0/0x52 [sctp]
       [<e189392d>] sctp_assoc_bh_rcv+0xac/0xe3 [sctp]
       [<e1897d76>] sctp_inq_push+0x2d/0x30 [sctp]
       [<e18a21b2>] sctp_rcv+0x7a7/0x83d [sctp]
       [<c077a95c>] ? ipv4_confirm+0x118/0x125
       [<c073a970>] ? nf_iterate+0x34/0x62
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c0747992>] ip_local_deliver_finish+0xf5/0x194
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
       [<c0747ab3>] ip_local_deliver+0x3e/0x44
       [<c074789d>] ? ip_local_deliver_finish+0x0/0x194
       [<c074775c>] ip_rcv_finish+0x29f/0x2c7
       [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
       [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44
       [<c0747cae>] ip_rcv+0x1f5/0x233
       [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7
       [<c071dce3>] __netif_receive_skb+0x310/0x336
       [<c07221f3>] netif_receive_skb+0x4b/0x51
       [<e0a4ed3d>] cp_rx_poll+0x1e7/0x29c [8139cp]
       [<c072275e>] net_rx_action+0x65/0x13a
       [<c0445a54>] __do_softirq+0xa1/0x149
       [<c04459b3>] ? __do_softirq+0x0/0x149
       <IRQ>
       [<c0445891>] ? irq_exit+0x37/0x72
       [<c040a7e9>] ? do_IRQ+0x81/0x95
       [<c07b3670>] ? common_interrupt+0x30/0x38
       [<c0428058>] ? native_safe_halt+0xa/0xc
       [<c040f5d7>] ? default_idle+0x58/0x92
       [<c0408fb0>] ? cpu_idle+0x96/0xb2
       [<c0797989>] ? rest_init+0x5d/0x5f
       [<c09fd90c>] ? start_kernel+0x34b/0x350
       [<c09fd0cb>] ? i386_start_kernel+0xba/0xc1
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cab86be
    • Wei Yongjun's avatar
      sctp: fix auth_hmacs field's length of struct sctp_cookie · 028dba0a
      Wei Yongjun authored
      auth_hmacs field of struct sctp_cookie is used for store
      Requested HMAC Algorithm Parameter, and each HMAC Identifier
      is 2 bytes, so the length should be:
        SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      028dba0a
    • Michał Mirosław's avatar
      net: Fix dev dev_ethtool_get_rx_csum() for forced NETIF_F_RXCSUM · 4dd5ffe4
      Michał Mirosław authored
      dev_ethtool_get_rx_csum() won't report rx checksumming when it's not
      changeable and driver is converted to hw_features and friends. Fix this.
      
      (dev->hw_features & NETIF_F_RXCSUM) check is dropped - if the
      ethtool_ops->get_rx_csum is set, then driver is not coverted, yet.
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd5ffe4
    • Arnd Bergmann's avatar
      usbnet: use eth%d name for known ethernet devices · c261344d
      Arnd Bergmann authored
      The documentation for the USB ethernet devices suggests that
      only some devices are supposed to use usb0 as the network interface
      name instead of eth0. The logic used there, and documented in
      Kconfig for CDC is that eth0 will be used when the mac address
      is a globally assigned one, but usb0 is used for the locally
      managed range that is typically used on point-to-point links.
      
      Unfortunately, this has caused a lot of pain on the smsc95xx
      device that is used on the popular pandaboard without an
      EEPROM to store the MAC address, which causes the driver to
      call random_ether_address().
      
      Obviously, there should be a proper MAC addressed assigned to
      the device, and discussions are ongoing about how to solve
      this, but this patch at least makes sure that the default
      interface naming gets a little saner and matches what the
      user can expect based on the documentation, including for
      new devices.
      
      The approach taken here is to flag whether a device might be a
      point-to-point link with the new FLAG_POINTTOPOINT setting in
      the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
      and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
      of the two.  The usbnet framework only looks at the MAC address
      for device naming if both flags are set, otherwise it trusts the
      flag.
      Signed-off-by: default avatarArnd Bergmann <arnd.bergmann@linaro.org>
      Tested-by: default avatarAndy Green <andy.green@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c261344d
    • FUJITA Tomonori's avatar
      starfire: clean up dma_addr_t size test · 1591cb60
      FUJITA Tomonori authored
      Now we have CONFIG_ARCH_DMA_ADDR_T_64BIT. We can fix the hacky
      dma_addr_t size test cleanly.
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1591cb60
    • David S. Miller's avatar
  11. 01 Apr, 2011 1 commit
  12. 31 Mar, 2011 1 commit