1. 07 11月, 2016 4 次提交
  2. 01 11月, 2016 1 次提交
  3. 31 10月, 2016 2 次提交
  4. 25 10月, 2016 1 次提交
  5. 24 10月, 2016 6 次提交
  6. 21 10月, 2016 1 次提交
    • J
      USB: serial: fix potential NULL-dereference at probe · 126d26f6
      Johan Hovold 提交于
      Make sure we have at least one port before attempting to register a
      console.
      
      Currently, at least one driver binds to a "dummy" interface and requests
      zero ports for it. Should such an interface also lack endpoints, we get
      a NULL-deref during probe.
      
      Fixes: e5b1e206 ("USB: serial: make minor allocation dynamic")
      Cc: stable <stable@vger.kernel.org>	# 3.11
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      126d26f6
  7. 20 10月, 2016 4 次提交
  8. 19 10月, 2016 1 次提交
  9. 18 10月, 2016 2 次提交
  10. 17 10月, 2016 10 次提交
  11. 12 10月, 2016 1 次提交
  12. 05 10月, 2016 1 次提交
  13. 28 9月, 2016 2 次提交
  14. 27 9月, 2016 4 次提交
    • K
      USB: serial: cp210x: Add ID for a Juniper console · decc5360
      Kyle Jones 提交于
      Signed-off-by: NKyle Jones <kyle@kf5jwc.us>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      decc5360
    • P
      usb: Kconfig: using select for USB_COMMON dependency · cb9c1cfc
      Peter Chen 提交于
      According to (badf6d47 "usb: common: rework CONFIG_USB_COMMON logic")
      we should select USB_COMMON at Kconfig when usb common stuffs are needed,
      but some of Kconfig enties have not followed it, update them.
      
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb9c1cfc
    • Y
      usb: hub: change CLEAR_FEATURE to SET_FEATURE · 4e248000
      Yonglong Wu 提交于
      In USB20 specification, describes in chapter 9.4.5: The Remote Wakeup
      field can be modified by the SetFeature() and ClearFeature() requests
      using the DEVICE_REMOTE_WAKEUP feature selector.
      
      In USB30 specification, also describes in chapter 9.4.5: The Function
      Remote Wakeup field can be modified by the SetFeature() requests
      using the FUNCTION_SUSPEND feature selector. In chapter 9.4.9 Set
      Feature reference, it describes Function Remote Wake Enabled/Disabled
      at suspend options by SET_FEATURE.
      
      In USB30 specification only mentioned SetFeature(), so we need use
      SET_FEATURE replace CLEAR_FEATURE to disable USB30 function remote
      wakeup in suspend options.
      Signed-off-by: NYonglong Wu <yonglong.wu@mediatek.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e248000
    • R
      usb: core: Introduce a USB port LED trigger · 0f247626
      Rafał Miłecki 提交于
      This commit adds a new trigger responsible for turning on LED when USB
      device gets connected to the selected USB port. This can can useful for
      various home routers that have USB port(s) and a proper LED telling user
      a device is connected.
      
      The trigger gets its documentation file but basically it just requires
      enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).
      
      There was a long discussion on design of this driver. Its current state
      is a result of picking them most adjustable solution as others couldn't
      handle all cases.
      
      1) It wasn't possible for the driver to register separated trigger for
         each USB port. Some physical USB ports are handled by more than one
         controller and so by more than one USB port. E.g. USB 2.0 physical
         port may be handled by OHCI's port and EHCI's port.
         It's also not possible to assign more than 1 trigger to a single LED
         and implementing such feature would be tricky due to syncing triggers
         and sysfs conflicts with old triggers.
      
      2) Another idea was to register trigger per USB hub. This wouldn't allow
         handling devices with multiple USB LEDs and controllers (hubs)
         controlling more than 1 physical port. It's common for hubs to have
         few ports and each may have its own LED.
      
      This final trigger is highly flexible. It allows selecting any USB ports
      for any LED. It was also modified (comparing to the initial version) to
      allow choosing ports rather than having user /guess/ proper names. It
      was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
      2 physical ports and 3 controllers.
      
      It was noted USB subsystem already has usb-gadget and usb-host triggers
      but they are pretty trivial ones. They indicate activity only and can't
      have ports specified.
      
      In future it may be good idea to consider adding activity support to
      usbport as well. This should allow switching to this more generic driver
      and maybe marking old ones as obsolete.
      This can be implemented with another sysfs file for setting mode. The
      default mode wouldn't change so there won't be ABI breakage and so such
      feature can be safely implemented later.
      
      There was also an idea of supporting other devices (PCI, SDIO, etc.) but
      as this driver already contains some USB specific code (and will get
      more) these should be probably separated drivers (triggers).
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f247626