1. 26 6月, 2012 5 次提交
  2. 23 6月, 2012 6 次提交
    • Y
      net: sh_eth: fix the condition to fix the cur_tx/dirty_rx · a18e08bd
      Yoshihiro Shimoda 提交于
      The following commit couldn't work if the RMCR is not set to 1.
      
      "net: sh_eth: fix the rxdesc pointer when rx descriptor empty happens"
      commit id 79fba9f5
      
      If RMCR is not set, the controller will clear the EDRRR after it received
      a frame. In this case, the driver doesn't need to fix the value of
      cur_rx/dirty_rx. The driver only needs it when the controll detects
      receive descriptors are empty.
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a18e08bd
    • F
      r8169: RxConfig hack for the 8168evl. · eb2dc35d
      françois romieu 提交于
      The 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards
      are very prone to NETDEV watchdog problems without this change. See
      https://bugzilla.kernel.org/show_bug.cgi?id=42899 for instance.
      
      I don't know why it *works*. It's depressingly effective though.
      
      For the record:
      - the problem may go along IOMMU (AMD-Vi) errors but it really looks
        like a red herring.
      - the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide,
        the chipset now fetches several Rx descriptors at a time.
      - long ago the driver ignored the RX_MULTI_EN bit.
        e542a226 changed the RxConfig
        settings. Whatever the problem it's now labeled a regression.
      - Realtek's own driver can identify two different 8168evl devices
        (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only
        sees one. It sucks.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb2dc35d
    • M
      usbnet: handle remote wakeup asap · 65841fd5
      Ming Lei 提交于
      If usbnet is resumed by remote wakeup, generally there are
      some packets comming to be handled, so allocate and submit
      rx URBs in usbnet_resume to avoid delays introduced by tasklet.
      Otherwise, usbnet may have been runtime suspended before the
      usbnet_bh is executed to schedule Rx URBs.
      
      Without the patch, usbnet can't recieve any packets from peer
      in runtime suspend state if runtime PM is enabled and
      autosuspend_delay is set as zero.
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65841fd5
    • M
      usbnet: decrease suspend count if returning -EBUSY for runtime suspend · 5eeb3132
      Ming Lei 提交于
      This patch decreases dev->suspend_count in the -EBUSY failure path
      of usbnet_suspend. Without the change, the later runtime suspend
      will do nothing except for increasing dev->suspend_count.
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5eeb3132
    • M
      usbnet: clear OPEN flag in failure path · fb13c47b
      Ming Lei 提交于
      Without clearing OPEN flag in failure path, runtime or system resume
      may submit interrupt/rx URB and start tx queue mistakenly on a
      interface in DOWN state.
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb13c47b
    • B
      net: qmi_wwan: fix Gobi device probing · b9f90eb2
      Bjørn Mork 提交于
      Ignoring interfaces with additional descriptors is not a reliable
      method for locating the correct interface on Gobi devices.  There
      is at least one device where this method fails:
      https://bbs.archlinux.org/viewtopic.php?id=143506
      
      The result is that the AT command port (interface #2) is hidden
      from qcserial, preventing traditional serial modem usage:
      
      [   15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device
      [   15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
      [   15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22
      [   15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device
      [   15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
      [   15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22
      [   15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected
      [   15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0
      [   15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected
      [   15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1
      
      Use static interface numbers taken from the interface map in
      qcserial for all Gobi devices instead:
      
      	Gobi 1K USB layout:
      	0: serial port (doesn't respond)
      	1: serial port (doesn't respond)
      	2: AT-capable modem port
      	3: QMI/net
      
      	Gobi 2K+ USB layout:
      	0: QMI/net
      	1: DM/DIAG (use libqcdm from ModemManager for communication)
      	2: AT-capable modem port
      	3: NMEA
      
      This should be more reliable over all, and will also prevent the
      noisy "probe failed" messages.  The whitelisting logic is expected
      to be replaced by direct interface number matching in 3.6.
      Reported-by: NHeinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de>
      Cc: <stable@vger.kernel.org> # v3.4: 00001880 USB: qmi_wwan: Make forced int 4 whitelist generic
      Cc: <stable@vger.kernel.org> # v3.4: f7142e6c USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
      Cc: <stable@vger.kernel.org> # v3.4
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9f90eb2
  3. 21 6月, 2012 6 次提交
  4. 20 6月, 2012 9 次提交
  5. 19 6月, 2012 2 次提交
  6. 18 6月, 2012 6 次提交
  7. 17 6月, 2012 2 次提交
  8. 16 6月, 2012 3 次提交
  9. 14 6月, 2012 1 次提交
    • E
      bnx2x: fix checksum validation · d6cb3e41
      Eric Dumazet 提交于
      bnx2x driver incorrectly sets ip_summed to CHECKSUM_UNNECESSARY on
      encapsulated segments. TCP stack happily accepts frames with bad
      checksums, if they are inside a GRE or IPIP encapsulation.
      
      Our understanding is that if no IP or L4 csum validation was done by the
      hardware, we should leave ip_summed as is (CHECKSUM_NONE), since
      hardware doesn't provide CHECKSUM_COMPLETE support in its cqe.
      
      Then, if IP/L4 checksumming was done by the hardware, set
      CHECKSUM_UNNECESSARY if no error was flagged.
      
      Patch based on findings and analysis from Robert Evans
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Eilon Greenstein <eilong@broadcom.com>
      Cc: Yaniv Rosner <yanivr@broadcom.com>
      Cc: Merav Sicron <meravs@broadcom.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Robert Evans <evansr@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Acked-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6cb3e41