1. 17 5月, 2014 4 次提交
  2. 14 5月, 2014 4 次提交
    • B
      net: cdc_ncm/cdc_mbim: rework probing of NCM/MBIM functions · 50a0ffaf
      Bjørn Mork 提交于
      The NCM class match in the cdc_mbim driver is confusing and
      cause unexpected behaviour. The USB core guarantees that a
      USB interface is in altsetting 0 when probing starts. This
      means that devices implementing a NCM 1.0 backwards
      compatible MBIM function (a "NCM/MBIM function") always hit
      the NCM entry in the cdc_mbim driver match table. Such
      functions will never match any of the MBIM entries.
      
      This causes unexpeced behaviour for cases where the NCM and
      MBIM entries are differet, which is currently the case for
      all except Ericsson devices.
      
      Improve the probing of NCM/MBIM functions by looking up the
      device again in the cdc_mbim match table after switching to
      the MBIM identity.
      
      The shared altsetting selection is updated to better
      accommodate the new probing logic, returning the preferred
      altsetting for the control interface instead of the data
      interface. The control interface altsetting update is moved
      to the cdc_mbim driver. It is never necessary to change the
      control interface altsetting for NCM.
      
      Cc: Greg Suarez <gsuarez@smithmicro.com>
      Reported by: Yu-an Shih <yshih@nvidia.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50a0ffaf
    • B
      net: cdc_mbim: reject IP packets on DSS VLANs · 6e1b3095
      Bjørn Mork 提交于
      DSS VLANs are pseudo network interfaces representing arbitrary
      data streams, and specifically not IP. Preventing spurious IP
      packets can sometimes be a hassle. The kernel will for example
      send an IPv6 Router Solicit when the interface is brought up
      unless the user has been careful enough to disable IPv6 first.
      Such packets forwared to a MBIM DSS session will look like
      spurious noise to the device, and can cause it to log an error
      or even malfunction.
      
      Drop all IP packets on the designated DSS VLANs to prevent such
      unwanted spurious transmissions.
      
      Cc: Greg Suarez <gsuarez@smithmicro.com>
      Reported-by: NArnaud Desmier <adesmier@sequans.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e1b3095
    • B
      net: cdc_mbim: optionally use VLAN ID 4094 for IP session 0 · 146a08d2
      Bjørn Mork 提交于
      The cdc_mbim driver maps 802.1q VLANs to MBIM IP and DSS
      sessions. MBIM IP session 0 is handled as an exception and
      is mapped to untagged frames.
      
      This patch adds optional support for remapping MBIM IP
      session 0 to 802.1q VLAN ID 4094 instead. The default
      behaviour is not changed. The new behaviour is triggered
      by adding a link for this previously unsupported VLAN.
      
      The untagged mapping was chosen initially to support the
      assumed most common use case: Most current MBIM devices only
      support a single IP session (i.e. session 0 only), and using
      untagged frames lets the users completely ignore the
      additonal complexity of the multiplexing layer.
      
      But when the multiplexing features of MBIM are used, then
      this netdev gets a double meaning: It becomes the master
      interface for all the VLAN subdevs the additional sessions
      are mapped to, while still serving as the untagged IP
      interface for session 0.
      
      This can be problematic, especially when using Device Service
      Streams (DSS), as have become apparent recently with the
      availability of devices with real DSS support. Some use cases
      need to e.g set a MTU which is higher than allowed for IP
      Session 0. The dual role also leads to the situation where
      the IP Session 0 interface cannot be taken down without
      breaking unrelated IP or DSS sessions - a devastating side
      effect which applications managing a simple IP session cannot
      be expected to be aware of. A typical DHCP client will assume
      that it should bring the interface down after releasing the
      IP lease.
      
      These problems can be avoided by tagging IP session 0 packets
      too, making this session similar to all other multiplexed
      sessions. This redefines the main netdev as an upper master
      interface only.
      
      Cc: Greg Suarez <gsuarez@smithmicro.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      146a08d2
    • W
      net: get rid of SET_ETHTOOL_OPS · 7ad24ea4
      Wilfried Klaebe 提交于
      net: get rid of SET_ETHTOOL_OPS
      
      Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone.
      This does that.
      
      Mostly done via coccinelle script:
      @@
      struct ethtool_ops *ops;
      struct net_device *dev;
      @@
      -       SET_ETHTOOL_OPS(dev, ops);
      +       dev->ethtool_ops = ops;
      
      Compile tested only, but I'd seriously wonder if this broke anything.
      Suggested-by: NDave Miller <davem@davemloft.net>
      Signed-off-by: NWilfried Klaebe <w-lkml@lebenslange-mailadresse.de>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ad24ea4
  3. 13 5月, 2014 1 次提交
  4. 10 5月, 2014 1 次提交
    • B
      net: cdc_mbim: handle unaccelerated VLAN tagged frames · 6b5eeb7f
      Bjørn Mork 提交于
      This driver maps 802.1q VLANs to MBIM sessions. The mapping is based on
      a bogus assumption that all tagged frames will use the acceleration API
      because we enable NETIF_F_HW_VLAN_CTAG_TX. This fails for e.g. frames
      tagged in userspace using packet sockets. Such frames will erroneously
      be considered as untagged and silently dropped based on not being IP.
      
      Fix by falling back to looking into the ethernet header for a tag if no
      accelerated tag was found.
      
      Fixes: a82c7ce5 ("net: cdc_ncm: map MBIM IPS SessionID to VLAN ID")
      Cc: Greg Suarez <gsuarez@smithmicro.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b5eeb7f
  5. 08 5月, 2014 1 次提交
    • B
      net: cdc_mbim: __vlan_find_dev_deep need rcu_read_lock · 4f4178f3
      Bjørn Mork 提交于
      Fixes this warning introduced by commit 5b8f15f7
      ("net: cdc_mbim: handle IPv6 Neigbor Solicitations"):
      
      ===============================
      [ INFO: suspicious RCU usage. ]
      3.15.0-rc3 #213 Tainted: G        W  O
      -------------------------------
      net/8021q/vlan_core.c:69 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 1
      no locks held by ksoftirqd/0/3.
      
      stack backtrace:
      CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G        W  O  3.15.0-rc3 #213
      Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
       0000000000000001 ffff880232533bf0 ffffffff813a5ee6 0000000000000006
       ffff880232530090 ffff880232533c20 ffffffff81076b94 0000000000000081
       0000000000000000 ffff8802085ac000 ffff88007fc8ea00 ffff880232533c50
      Call Trace:
       [<ffffffff813a5ee6>] dump_stack+0x4e/0x68
       [<ffffffff81076b94>] lockdep_rcu_suspicious+0xfa/0x103
       [<ffffffff813978a6>] __vlan_find_dev_deep+0x54/0x94
       [<ffffffffa04a1938>] cdc_mbim_rx_fixup+0x379/0x66a [cdc_mbim]
       [<ffffffff813ab76f>] ? _raw_spin_unlock_irqrestore+0x3a/0x49
       [<ffffffff81079671>] ? trace_hardirqs_on_caller+0x192/0x1a1
       [<ffffffffa059bd10>] usbnet_bh+0x59/0x287 [usbnet]
       [<ffffffff8104067d>] tasklet_action+0xbb/0xcd
       [<ffffffff81040057>] __do_softirq+0x14c/0x30d
       [<ffffffff81040237>] run_ksoftirqd+0x1f/0x50
       [<ffffffff8105f13e>] smpboot_thread_fn+0x172/0x18e
       [<ffffffff8105efcc>] ? SyS_setgroups+0xdf/0xdf
       [<ffffffff810594b0>] kthread+0xb5/0xbd
       [<ffffffff813a84b1>] ? __wait_for_common+0x13b/0x170
       [<ffffffff810593fb>] ? __kthread_parkme+0x5c/0x5c
       [<ffffffff813b147c>] ret_from_fork+0x7c/0xb0
       [<ffffffff810593fb>] ? __kthread_parkme+0x5c/0x5c
      
      Fixes: 5b8f15f7 ("net: cdc_mbim: handle IPv6 Neigbor Solicitations")
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f4178f3
  6. 06 5月, 2014 1 次提交
    • B
      net: cdc_ncm: fix buffer overflow · 9becd707
      Bjørn Mork 提交于
      Commit 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs
      if we send ZLPs") changed the padding logic for devices with the ZLP
      flag set.  This meant that frames of any size will be sent without
      additional padding, except for the single byte added if the size is
      a multiple of the USB packet size. But if the unpadded size is
      identical to the maximum frame size, and the maximum size is a
      multiplum of the USB packet size, then this one-byte padding will
      overflow the buffer.
      
      Prevent padding if already at maximum frame size, letting usbnet
      transmit a ZLP instead in this case.
      
      Fixes: 4d619f62 ("net: cdc_ncm: no point in filling up the NTBs if we send ZLPs")
      Reported by: Yu-an Shih <yshih@nvidia.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9becd707
  7. 28 4月, 2014 7 次提交
  8. 12 4月, 2014 1 次提交
  9. 01 4月, 2014 1 次提交
  10. 28 3月, 2014 1 次提交
    • O
      usbnet: include wait queue head in device structure · 14a0d635
      Oliver Neukum 提交于
      This fixes a race which happens by freeing an object on the stack.
      Quoting Julius:
      > The issue is
      > that it calls usbnet_terminate_urbs() before that, which temporarily
      > installs a waitqueue in dev->wait in order to be able to wait on the
      > tasklet to run and finish up some queues. The waiting itself looks
      > okay, but the access to 'dev->wait' is totally unprotected and can
      > race arbitrarily. I think in this case usbnet_bh() managed to succeed
      > it's dev->wait check just before usbnet_terminate_urbs() sets it back
      > to NULL. The latter then finishes and the waitqueue_t structure on its
      > stack gets overwritten by other functions halfway through the
      > wake_up() call in usbnet_bh().
      
      The fix is to just not allocate the data structure on the stack.
      As dev->wait is abused as a flag it also takes a runtime PM change
      to fix this bug.
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Reported-by: NGrant Grundler <grundler@google.com>
      Tested-by: NGrant Grundler <grundler@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14a0d635
  11. 21 3月, 2014 1 次提交
    • B
      net: cdc_ncm: respect operator preferred MTU reported by MBIM · 259fef03
      Ben Chan 提交于
      According to "Universal Serial Bus Communications Class Subclass
      Specification for Mobile Broadband Interface Model, Revision 1.0,
      Errata-1" published by USB-IF, the wMTU field of the MBIM extended
      functional descriptor indicates the operator preferred MTU for IP data
      streams.
      
      This patch modifies cdc_ncm_setup to ensure that the MTU value set on
      the usbnet device does not exceed the operator preferred MTU indicated
      by wMTU if the MBIM device exposes a MBIM extended functional
      descriptor.
      Signed-off-by: NBen Chan <benchan@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      259fef03
  12. 19 3月, 2014 1 次提交
  13. 13 3月, 2014 1 次提交
  14. 12 3月, 2014 1 次提交
  15. 11 3月, 2014 1 次提交
  16. 08 3月, 2014 8 次提交
  17. 07 3月, 2014 3 次提交
  18. 06 3月, 2014 1 次提交
    • H
      r8152: disable the ECM mode · 10c32717
      hayeswang 提交于
      There are known issues for switching the drivers between ECM mode and
      vendor mode. The interrup transfer may become abnormal. The hardware
      may have the opportunity to die if you change the configuration without
      unloading the current driver first, because all the control transfers
      of the current driver would fail after the command of switching the
      configuration.
      
      Although to use the ecm driver and vendor driver independently is fine,
      it may have problems to change the driver from one to the other by
      switching the configuration. Additionally, now the vendor mode driver
      is more powerful than the ECM driver. Thus, disable the ECM mode driver,
      and let r8152 to set the configuration to vendor mode and reset the
      device automatically.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10c32717
  19. 03 3月, 2014 1 次提交