1. 10 1月, 2016 1 次提交
  2. 17 11月, 2015 1 次提交
  3. 16 9月, 2015 1 次提交
  4. 09 7月, 2015 1 次提交
  5. 01 4月, 2015 1 次提交
  6. 08 11月, 2014 1 次提交
  7. 29 10月, 2014 2 次提交
  8. 30 7月, 2014 1 次提交
  9. 01 4月, 2014 1 次提交
  10. 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
  11. 17 1月, 2014 1 次提交
  12. 15 1月, 2014 1 次提交
  13. 02 1月, 2014 1 次提交
  14. 07 12月, 2013 1 次提交
  15. 17 9月, 2013 3 次提交
  16. 12 7月, 2013 1 次提交
  17. 02 7月, 2013 1 次提交
  18. 11 6月, 2013 1 次提交
    • B
      qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820 · c2020be3
      Bjørn Mork 提交于
      Another QMI speaking Qualcomm based device, which should be
      driven by qmi_wwan, while cdc_ether should ignore it.
      
      Like on other Huawei devices, the wwan function can appear
      either as a single vendor specific interface or as a CDC ECM
      class function using separate control and data interfaces.
      The ECM control interface protocol is 0xff, likely in an
      attempt to indicate that vendor specific management is
      required.
      
      In addition to the near standard CDC class, Huawei also add
      vendor specific AT management commands to their firmwares.
      This is probably an attempt to support non-Windows systems
      using standard class drivers.  Unfortunately, this part of
      the firmware is often buggy.  Linux is much better off using
      whatever native vendor specific management protocol the
      device offers, and Windows uses, whenever possible. This
      means QMI in the case of Qualcomm based devices.
      
      The E1820 has been verified to work fine with QMI.
      
      Matching on interface number is necessary to distiguish the
      wwan function from serial functions in the single interface
      mode, as both function types will have class/subclass/function
      set to ff/ff/ff.
      
      The control interface number does not change in CDC ECM mode,
      so the interface number matching rule is sufficient to handle
      both modes.  The cdc_ether blacklist entry is only relevant in
      CDC ECM mode, but using a similar interface number based rule
      helps document this as a transfer from one driver to another.
      
      Other Huawei 02/06/ff devices are left with the cdc_ether driver
      because we do not know whether they are based on Qualcomm chips.
      The Huawei specific AT command management is known to be somewhat
      hardware independent, and their usage of these class codes may
      also be independent of the modem hardware.
      Reported-by: NGraham Inggs <graham.inggs@uct.ac.za>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2020be3
  19. 09 5月, 2013 1 次提交
  20. 07 5月, 2013 1 次提交
  21. 18 4月, 2013 1 次提交
  22. 12 4月, 2013 1 次提交
  23. 19 2月, 2013 1 次提交
  24. 20 12月, 2012 1 次提交
  25. 18 12月, 2012 2 次提交
  26. 26 10月, 2012 1 次提交
  27. 20 5月, 2012 1 次提交
  28. 19 5月, 2012 1 次提交
    • S
      USB: Disable hub-initiated LPM for comms devices. · e1f12eb6
      Sarah Sharp 提交于
      Hub-initiated LPM is not good for USB communications devices.  Comms
      devices should be able to tell when their link can go into a lower power
      state, because they know when an incoming transmission is finished.
      Ideally, these devices would slam their links into a lower power state,
      using the device-initiated LPM, after finishing the last packet of their
      data transfer.
      
      If we enable the idle timeouts for the parent hubs to enable
      hub-initiated LPM, we will get a lot of useless LPM packets on the bus
      as the devices reject LPM transitions when they're in the middle of
      receiving data.  Worse, some devices might blindly accept the
      hub-initiated LPM and power down their radios while they're in the
      middle of receiving a transmission.
      
      The Intel Windows folks are disabling hub-initiated LPM for all USB
      communications devices under a xHCI USB 3.0 host.  In order to keep
      the Linux behavior as close as possible to Windows, we need to do the
      same in Linux.
      
      Set the disable_hub_initiated_lpm flag for for all USB communications
      drivers.  I know there aren't currently any USB 3.0 devices that
      implement these class specifications, but we should be ready if they do.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: Hansjoerg Lipp <hjlipp@web.de>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Cc: Jan Dumon <j.dumon@option.com>
      Cc: Petko Manolov <petkan@users.sourceforge.net>
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Roland Vossen <rvossen@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
      Cc: Kan Yan <kanyan@broadcom.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Gertjan van Wingerde <gwingerde@gmail.com>
      Cc: Helmut Schaa <helmut.schaa@googlemail.com>
      Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Chaoming Li <chaoming_li@realsil.com.cn>
      Cc: Daniel Drake <dsd@gentoo.org>
      Cc: Ulrich Kunitz <kune@deine-taler.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e1f12eb6
  29. 16 5月, 2012 1 次提交
  30. 07 5月, 2012 1 次提交
    • B
      cdc_ether: Ignore bogus union descriptor for RNDIS devices · 6eddcb4c
      Bjørn Mork 提交于
      Some RNDIS devices include a bogus CDC Union descriptor pointing
      to non-existing interfaces.  The RNDIS code is already prepared
      to handle devices without a CDC Union descriptor by hardwiring
      the driver to use interfaces 0 and 1, which is correct for the
      devices with the bogus descriptor as well. So we can reuse the
      existing workaround.
      
      Cc: Markus Kolb <linux-201011@tower-net.de>
      Cc: Iker Salmón San Millán <shaola@esdebian.org>
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Cc: Oliver Neukum <oliver@neukum.org>
      Cc: 655387@bugs.debian.org
      Cc: stable@vger.kernel.org
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6eddcb4c
  31. 23 2月, 2012 1 次提交
  32. 19 11月, 2011 1 次提交
    • G
      USB: convert drivers/net/* to use module_usb_driver() · d632eb1b
      Greg Kroah-Hartman 提交于
      This converts the drivers in drivers/net/* to use the
      module_usb_driver() macro which makes the code smaller and a bit
      simpler.
      
      Added bonus is that it removes some unneeded kernel log messages about
      drivers loading and/or unloading.
      
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Cc: Samuel Ortiz <samuel@sortiz.org>
      Cc: Oliver Neukum <oliver@neukum.name>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Cc: Petko Manolov <petkan@users.sourceforge.net>
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Gertjan van Wingerde <gwingerde@gmail.com>
      Cc: Helmut Schaa <helmut.schaa@googlemail.com>
      Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Chaoming Li <chaoming_li@realsil.com.cn>
      Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Roel Kluin <roel.kluin@gmail.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Jiri Pirko <jpirko@redhat.com>
      Cc: Pavel Roskin <proski@gnu.org>
      Cc: Yoann DI-RUZZA <y.diruzza@lim.eu>
      Cc: George <george0505@realtek.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d632eb1b
  33. 14 11月, 2011 1 次提交
  34. 11 5月, 2011 1 次提交
  35. 30 4月, 2011 1 次提交
  36. 02 4月, 2011 1 次提交
    • A
      usbnet: use eth%d name for known ethernet devices · c261344d
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd.bergmann@linaro.org>
      Tested-by: NAndy Green <andy.green@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c261344d