1. 23 6月, 2012 3 次提交
    • 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
  2. 21 6月, 2012 6 次提交
  3. 20 6月, 2012 9 次提交
  4. 19 6月, 2012 1 次提交
    • J
      phy/micrel: change phy_id_mask for KSZ9021 and KS8001 · 48d7d0ad
      Jason Wang 提交于
      On a freescale imx6q platform, a hardware phy chip KSZ9021 is
      recognized as a KS8001 chip by the current driver like this:
      eth0: Freescale FEC PHY driver [Micrel KS8001 or KS8721]
      
      KSZ9021 has phy_id 0x00221610, while KSZ8001 has phy_id
      0x0022161a, the current phy_id_mask (0x00fffff0/0x00ffff10) can't
      distinguish them. So change phy_id_mask to resolve this problem.
      
      Although the micrel datasheet says that the 4 LSB of phyid2 register
      contains the chip revision number and the current driver is designed
      to follow this rule, in reality the chip implementation doesn't follow
      it.
      
      Cc: David J. Choi <david.choi@micrel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Signed-off-by: NHui Wang <jason77.wang@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48d7d0ad
  5. 18 6月, 2012 6 次提交
  6. 17 6月, 2012 2 次提交
  7. 16 6月, 2012 3 次提交
  8. 14 6月, 2012 2 次提交
    • 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
    • M
      ath9k: Fix softlockup in AR9485 · bcb7ad7b
      Mohammed Shafi Shajakhan 提交于
      steps to recreate:
      load latest ath9k driver with AR9485
      stop the network-manager and wpa_supplicant
      bring the interface up
      
      	Call Trace:
      	[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
      	[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
      	[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
      	[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
      	[<ffffffff810744fe>] process_one_work+0x11e/0x470
      	[<ffffffff8107530f>] worker_thread+0x15f/0x360
      	[<ffffffff810751b0>] ? manage_workers+0x230/0x230
      	[<ffffffff81079af3>] kthread+0x93/0xa0
      	[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
      	[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
      	[<ffffffff815fd3a0>] ? gs_change+0x13/0x13
      
      ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
      associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
      is needed to recover from some rare beacon stuck during stress testing.
      Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
      always seem to have zero even though we had configured PLL3(0x16188) to
      query about PLL's locking status. When we keep on polling infinitely PLL4's
      8th bit(ie check for PLL locking measurements is done), machine hangs
      due to softlockup.
      
      fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142Reported-by: NRolf Offermanns <rolf.offermanns@gmx.net>
      Cc: stable@vger.kernel.org [3.0+]
      Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bcb7ad7b
  9. 13 6月, 2012 3 次提交
    • E
      bonding: Fix corrupted queue_mapping · 5ee31c68
      Eric Dumazet 提交于
      In the transmit path of the bonding driver, skb->cb is used to
      stash the skb->queue_mapping so that the bonding device can set its
      own queue mapping.  This value becomes corrupted since the skb->cb is
      also used in __dev_xmit_skb.
      
      When transmitting through bonding driver, bond_select_queue is
      called from dev_queue_xmit.  In bond_select_queue the original
      skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
      and skb->queue_mapping is overwritten with the bond driver queue.
      
      Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
      the packet length into skb->cb, thereby overwriting the stashed
      queue mappping.  In bond_dev_queue_xmit (called from hard_start_xmit),
      the queue mapping for the skb is set to the stashed value which is now
      the skb length and hence is an invalid queue for the slave device.
      
      If we want to save skb->queue_mapping into skb->cb[], best place is to
      add a field in struct qdisc_skb_cb, to make sure it wont conflict with
      other layers (eg : Qdiscc, Infiniband...)
      
      This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8
      bytes :
      
      netem qdisc for example assumes it can store an u64 in it, without
      misalignment penalty.
      
      Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[].
      The largest user is CHOKe and it fills it.
      
      Based on a previous patch from Tom Herbert.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NTom Herbert <therbert@google.com>
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Roland Dreier <roland@kernel.org>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ee31c68
    • W
      bonding:record primary when modify it via sysfs · 8a93664d
      Weiping Pan 提交于
      If we modify primary via sysfs and it is not a valid slave,
      we should record it for future use, and this behavior is the same with
      bond_check_params().
      Signed-off-by: NWeiping Pan <wpan@redhat.com>
      Acked-by: NNicolas de Pesloüan <nicolas.2p.debian@free.fr>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a93664d
    • A
      mwifiex: fix incorrect privacy setting in beacon and probe response · 6ddcd464
      Avinash Patil 提交于
      Test procedure:
      1. Start AP with security setting (e.g. WPA2)
      2. Stop AP
      3. Start AP with open security
      
      Here it's observed that privacy is enabled in beacons and
      probe responses.
      
      This patch fixes it by checking the privacy parameter from
      cfg80211_ap_settings. If privacy is not set in cfg80211_ap_settings,
      set open authentication and no encryption in FW.
      Signed-off-by: NAvinash Patil <patila@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6ddcd464
  10. 12 6月, 2012 5 次提交