1. 17 5月, 2017 3 次提交
  2. 18 4月, 2017 1 次提交
  3. 12 4月, 2017 2 次提交
  4. 08 4月, 2017 1 次提交
  5. 29 3月, 2017 1 次提交
  6. 27 3月, 2017 1 次提交
  7. 25 3月, 2017 1 次提交
  8. 23 3月, 2017 5 次提交
    • J
      USB: core: add helpers to retrieve endpoints in reverse order · 279daf4e
      Johan Hovold 提交于
      Several drivers have implemented their endpoint look-up loops in such a
      way that they have picked the last endpoint descriptor of the specified
      type should more than one such descriptor exist.
      
      To avoid any regressions, add corresponding helpers to lookup endpoints
      by searching the endpoint descriptors in reverse order.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      279daf4e
    • J
      USB: core: add helpers to retrieve endpoints · 66a35939
      Johan Hovold 提交于
      Many USB drivers iterate over the available endpoints to find required
      endpoints of a specific type and direction. Typically the endpoints are
      required for proper function and a missing endpoint should abort probe.
      
      To facilitate code reuse, add a helper to retrieve common endpoints
      (bulk or interrupt, in or out) and four wrappers to find a single
      endpoint.
      
      Note that the helpers are marked as __must_check to serve as a reminder
      to always verify that all expected endpoints are indeed present. This
      also means that any optional endpoints, typically need to be looked up
      through separate calls.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66a35939
    • A
      usb: separate out sysdev pointer from usb_bus · a8c06e40
      Arnd Bergmann 提交于
      For xhci-hcd platform device, all the DMA parameters are not
      configured properly, notably dma ops for dwc3 devices.
      
      The idea here is that you pass in the parent of_node along with
      the child device pointer, so it would behave exactly like the
      parent already does. The difference is that it also handles all
      the other attributes besides the mask.
      
      sysdev will represent the physical device, as seen from firmware
      or bus.Splitting the usb_bus->controller field into the
      Linux-internal device (used for the sysfs hierarchy, for printks
      and for power management) and a new pointer (used for DMA,
      DT enumeration and phy lookup) probably covers all that we really
      need.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NSriram Dash <sriram.dash@nxp.com>
      Tested-by: NBaolin Wang <baolin.wang@linaro.org>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Tested-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Tested-by: NVivek Gautam <vivek.gautam@codeaurora.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Sinjan Kumar <sinjank@codeaurora.org>
      Cc: David Fisher <david.fisher1@synopsys.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: "Thang Q. Nguyen" <tqnguyen@apm.com>
      Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Jon Masters <jcm@redhat.com>
      Cc: Dann Frazier <dann.frazier@canonical.com>
      Cc: Peter Chen <peter.chen@nxp.com>
      Cc: Leo Li <pku.leo@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8c06e40
    • G
      usb: hub: Do not attempt to autosuspend disconnected devices · f5cccf49
      Guenter Roeck 提交于
      While running a bind/unbind stress test with the dwc3 usb driver on rk3399,
      the following crash was observed.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000218
      pgd = ffffffc00165f000
      [00000218] *pgd=000000000174f003, *pud=000000000174f003,
      				*pmd=0000000001750003, *pte=00e8000001751713
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac
      ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm
      xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth
      ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev
      snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async
      ppp_generic slhc tun
      CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507
      Hardware name: Google Kevin (DT)
      Workqueue: pm pm_runtime_work
      task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000
      PC is at autosuspend_check+0x74/0x174
      LR is at autosuspend_check+0x70/0x174
      ...
      Call trace:
      [<ffffffc00080dcc0>] autosuspend_check+0x74/0x174
      [<ffffffc000810500>] usb_runtime_idle+0x20/0x40
      [<ffffffc000785ae0>] __rpm_callback+0x48/0x7c
      [<ffffffc000786af0>] rpm_idle+0x1e8/0x498
      [<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      Source:
      
      (gdb) l *0xffffffc00080dcc0
      0xffffffc00080dcc0 is in autosuspend_check
      (drivers/usb/core/driver.c:1778).
      1773		/* We don't need to check interfaces that are
      1774		 * disabled for runtime PM.  Either they are unbound
      1775		 * or else their drivers don't support autosuspend
      1776		 * and so they are permanently active.
      1777		 */
      1778		if (intf->dev.power.disable_depth)
      1779			continue;
      1780		if (atomic_read(&intf->dev.power.usage_count) > 0)
      1781			return -EBUSY;
      1782		w |= intf->needs_remote_wakeup;
      
      Code analysis shows that intf is set to NULL in usb_disable_device() prior
      to setting actconfig to NULL. At the same time, usb_runtime_idle() does not
      lock the usb device, and neither does any of the functions in the
      traceback. This means that there is no protection against a race condition
      where usb_disable_device() is removing dev->actconfig->interface[] pointers
      while those are being accessed from autosuspend_check().
      
      To solve the problem, synchronize and validate device state between
      autosuspend_check() and usb_disconnect().
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5cccf49
    • G
      usb: hub: Fix error loop seen after hub communication errors · 245b2eec
      Guenter Roeck 提交于
      While stress testing a usb controller using a bind/unbind looop, the
      following error loop was observed.
      
      usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
      usb 7-1.2: hub failed to enable device, error -108
      usb 7-1-port2: cannot disable (err = -22)
      usb 7-1-port2: couldn't allocate usb_device
      usb 7-1-port2: cannot disable (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      ** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
      ** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      
      This continues forever. After adding tracebacks into the code,
      the call sequence leading to this is found to be as follows.
      
      [<ffffffc0007fc8e0>] hub_activate+0x368/0x7b8
      [<ffffffc0007fceb4>] hub_resume+0x2c/0x3c
      [<ffffffc00080b3b8>] usb_resume_interface.isra.6+0x128/0x158
      [<ffffffc00080b5d0>] usb_suspend_both+0x1e8/0x288
      [<ffffffc00080c9c4>] usb_runtime_suspend+0x3c/0x98
      [<ffffffc0007820a0>] __rpm_callback+0x48/0x7c
      [<ffffffc00078217c>] rpm_callback+0xa8/0xd4
      [<ffffffc000786234>] rpm_suspend+0x84/0x758
      [<ffffffc000786ca4>] rpm_idle+0x2c8/0x498
      [<ffffffc000786ed4>] __pm_runtime_idle+0x60/0xac
      [<ffffffc00080eba8>] usb_autopm_put_interface+0x6c/0x7c
      [<ffffffc000803798>] hub_event+0x10ac/0x12ac
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      kick_hub_wq() is called from hub_activate() even after failures to
      communicate with the hub. This results in an endless sequence of
      hub event -> hub activate -> wq trigger -> hub event -> ...
      
      Provide two solutions for the problem.
      
      - Only trigger the hub event queue if communication with the hub
        is successful.
      - After a suspend failure, only resume already suspended interfaces
        if the communication with the device is still possible.
      
      Each of the changes fixes the observed problem. Use both to improve
      robustness.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      245b2eec
  9. 17 3月, 2017 3 次提交
    • G
      usb: hub: Fix crash after failure to read BOS descriptor · 7b2db29f
      Guenter Roeck 提交于
      If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
      Nevertheless, it is dereferenced unconditionally in
      hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
      This results in a crash.
      
      usb 5-1: unable to get BOS descriptor
      ...
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      pgd = ffffffc00165f000
      [00000008] *pgd=000000000174f003, *pud=000000000174f003,
      		*pmd=0000000001750003, *pte=00e8000001751713
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
      CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: G    B 4.4.52 #480
      Hardware name: Google Kevin (DT)
      Workqueue: events driver_set_config_work
      task: ffffffc0c3690000 ti: ffffffc0ae9a8000 task.ti: ffffffc0ae9a8000
      PC is at hub_port_init+0xc3c/0xd10
      LR is at hub_port_init+0xc3c/0xd10
      ...
      Call trace:
      [<ffffffc0007fbbfc>] hub_port_init+0xc3c/0xd10
      [<ffffffc0007fbe2c>] usb_reset_and_verify_device+0x15c/0x82c
      [<ffffffc0007fc5e0>] usb_reset_device+0xe4/0x298
      [<ffffffbffc0e3fcc>] rtl8152_probe+0x84/0x9b0 [r8152]
      [<ffffffc00080ca8c>] usb_probe_interface+0x244/0x2f8
      [<ffffffc000774a24>] driver_probe_device+0x180/0x3b4
      [<ffffffc000774e48>] __device_attach_driver+0xb4/0xe0
      [<ffffffc000772168>] bus_for_each_drv+0xb4/0xe4
      [<ffffffc0007747ec>] __device_attach+0xd0/0x158
      [<ffffffc000775080>] device_initial_probe+0x24/0x30
      [<ffffffc0007739d4>] bus_probe_device+0x50/0xe4
      [<ffffffc000770bd0>] device_add+0x414/0x738
      [<ffffffc000809fe8>] usb_set_configuration+0x89c/0x914
      [<ffffffc00080a120>] driver_set_config_work+0xc0/0xf0
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      Since we don't know anything about LPM capabilities without BOS descriptor,
      don't attempt to enable LPM if it is not available.
      
      Fixes: 890dae88 ("xhci: Enable LPM support only for hardwired ...")
      Cc: stable <stable@vger.kernel.org>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b2db29f
    • Y
      usb: of: add functions to bind a companion controller · 5095cb89
      Yoshihiro Shimoda 提交于
      EHCI controllers will have a companion controller. However, on platform
      bus, there was difficult to bind them in previous code. So, this
      patch adds helper functions to bind them using a "companion" property.
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5095cb89
    • Y
      usb: add CONFIG_USB_PCI for system have both PCI HW and non-PCI based USB HW · 2c93e790
      yuan linyu 提交于
      a lot of embeded system SOC (e.g. freescale T2080) have both
      PCI and USB modules. But USB module is controlled by registers directly,
      it have no relationship with PCI module.
      
      when say N here it will not build PCI related code in USB driver.
      Signed-off-by: Nyuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
      Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c93e790
  10. 14 3月, 2017 1 次提交
    • S
      usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk · 3243367b
      Samuel Thibault 提交于
      Some USB 2.0 devices erroneously report millisecond values in
      bInterval. The generic config code manages to catch most of them,
      but in some cases it's not completely enough.
      
      The case at stake here is a USB 2.0 braille device, which wants to
      announce 10ms and thus sets bInterval to 10, but with the USB 2.0
      computation that yields to 64ms.  It happens that one can type fast
      enough to reach this interval and get the device buffers overflown,
      leading to problematic latencies.  The generic config code does not
      catch this case because the 64ms is considered a sane enough value.
      
      This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
      to mark devices which actually report milliseconds in bInterval,
      and marks Vario Ultra devices as needing it.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3243367b
  11. 02 3月, 2017 2 次提交
  12. 28 2月, 2017 1 次提交
  13. 25 1月, 2017 1 次提交
    • L
      USB: Add quirk for WORLDE easykey.25 MIDI keyboard · d9b2997e
      Lukáš Lalinský 提交于
      Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218,
      idProduct=0401). The device reports that it has config string
      descriptor at index 3, but when the system selects the configuration
      and tries to get the description, it returns a -EPROTO error,
      the communication restarts and this keeps repeating over and over again.
      Not requesting the string descriptor makes the device work correctly.
      
      Relevant info from Wireshark:
      
      [...]
      
      CONFIGURATION DESCRIPTOR
          bLength: 9
          bDescriptorType: 0x02 (CONFIGURATION)
          wTotalLength: 101
          bNumInterfaces: 2
          bConfigurationValue: 1
          iConfiguration: 3
          Configuration bmAttributes: 0xc0  SELF-POWERED  NO REMOTE-WAKEUP
              1... .... = Must be 1: Must be 1 for USB 1.1 and higher
              .1.. .... = Self-Powered: This device is SELF-POWERED
              ..0. .... = Remote Wakeup: This device does NOT support remote wakeup
          bMaxPower: 50  (100mA)
      
      [...]
      
           45 0.369104       host                  2.38.0                USB      64     GET DESCRIPTOR Request STRING
      
      [...]
      
      URB setup
          bmRequestType: 0x80
              1... .... = Direction: Device-to-host
              .00. .... = Type: Standard (0x00)
              ...0 0000 = Recipient: Device (0x00)
          bRequest: GET DESCRIPTOR (6)
          Descriptor Index: 0x03
          bDescriptorType: 0x03
          Language Id: English (United States) (0x0409)
          wLength: 255
      
           46 0.369255       2.38.0                host                  USB      64     GET DESCRIPTOR Response STRING[Malformed Packet]
      
      [...]
      
      Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
      USB URB
          [Source: 2.38.0]
          [Destination: host]
          URB id: 0xffff88021f62d480
          URB type: URB_COMPLETE ('C')
          URB transfer type: URB_CONTROL (0x02)
          Endpoint: 0x80, Direction: IN
          Device: 38
          URB bus id: 2
          Device setup request: not relevant ('-')
          Data: present (0)
          URB sec: 1484896277
          URB usec: 455031
          URB status: Protocol error (-EPROTO) (-71)
          URB length [bytes]: 0
          Data length [bytes]: 0
          [Request in: 45]
          [Time from request: 0.000151000 seconds]
          Unused Setup Header
          Interval: 0
          Start frame: 0
          Copy of Transfer Flags: 0x00000200
          Number of ISO descriptors: 0
      [Malformed Packet: USB]
          [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
              [Malformed Packet (Exception occurred)]
              [Severity level: Error]
              [Group: Malformed]
      Signed-off-by: NLukáš Lalinský <lukas@oxygene.sk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9b2997e
  14. 19 1月, 2017 2 次提交
    • W
      usb: hcd: initialize hcd->flags to 0 when rm hcd · 76b8db0d
      William wu 提交于
      On some platforms(e.g. rk3399 board), we can call hcd_add/remove
      consecutively without calling usb_put_hcd/usb_create_hcd in between,
      so hcd->flags can be stale.
      
      If the HC dies due to whatever reason then without this patch we get
      the below error on next hcd_add.
      
      [173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
      [173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
      [173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6
      [173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
      [173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
      [173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
      [173.297222] usb usb6: Product: xHCI Host Controller
      [173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
      [173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
      [173.298680] hub 6-0:1.0: USB hub found
      [173.298749] hub 6-0:1.0: 1 port detected
      [173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected
      [173.395418] hub 5-0:1.0: activate --> -19
      [173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
      [173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
      [173.603513] Hardware name: Google Kevin (DT)
      [173.603531] Call trace:
      [173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160
      [173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28
      [173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0
      [173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8
      [173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c
      [173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c
      [173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c
      [173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124
      [173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44
      [173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc
      [173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
      ...
      [173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8
      [173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc
      [173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94
      [173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc
      [173.604607] [<0000000000b16000>] 0xb16000
      [173.604622] handlers:
      [173.604648] [<ffffffc000642084>] usb_hcd_irq
      [173.604673] Disabling IRQ #228
      Signed-off-by: NWilliam wu <wulf@rock-chips.com>
      Acked-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76b8db0d
    • J
      usb: core: update comments for send message functions · 123b7b30
      Jaejoong Kim 提交于
      The commonly use of bottom halves are tasklet and workqueue. The big
      difference between tasklet and workqueue is that the tasklet runs in
      an interrupt context and the workqueue runs in a process context,
      which means it can sleep if need be.
      
      The comment for usb_control/interrupt/bulk_msg() functions note that do
      not use this function within an interrupt context, like a 'bottom half'
      handler. With this comment, it makes confuse about usage of these
      functions.
      
      To more clarify, remove 'bottom half' comment.
      Signed-off-by: NJaejoong Kim <climbbb.kim@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      123b7b30
  15. 11 1月, 2017 1 次提交
  16. 06 1月, 2017 2 次提交
    • A
      USB: fix problems with duplicate endpoint addresses · 0a8fd134
      Alan Stern 提交于
      When checking a new device's descriptors, the USB core does not check
      for duplicate endpoint addresses.  This can cause a problem when the
      sysfs files for those endpoints are created; trying to create multiple
      files with the same name will provoke a WARNING:
      
      WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
      sysfs: cannot create duplicate filename
      '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05'
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
       ffff88006bee64c8 ffffffff81f96b8a ffffffff00000001 1ffff1000d7dcc2c
       ffffed000d7dcc24 0000000000000001 0000000041b58ab3 ffffffff8598b510
       ffffffff81f968f8 ffffffff850fee20 ffffffff85cff020 dffffc0000000000
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff8168c88e>] panic+0x1cb/0x3a9 kernel/panic.c:179
       [<ffffffff812b80b4>] __warn+0x1c4/0x1e0 kernel/panic.c:542
       [<ffffffff812b8195>] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
       [<ffffffff819e70ca>] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30
       [<ffffffff819e7308>] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59
       [<     inline     >] create_dir lib/kobject.c:71
       [<ffffffff81fa1b07>] kobject_add_internal+0x227/0xa60 lib/kobject.c:229
       [<     inline     >] kobject_add_varg lib/kobject.c:366
       [<ffffffff81fa2479>] kobject_add+0x139/0x220 lib/kobject.c:411
       [<ffffffff82737a63>] device_add+0x353/0x1660 drivers/base/core.c:1088
       [<ffffffff82738d8d>] device_register+0x1d/0x20 drivers/base/core.c:1206
       [<ffffffff82cb77d3>] usb_create_ep_devs+0x163/0x260 drivers/usb/core/endpoint.c:195
       [<ffffffff82c9f27b>] create_intf_ep_devs+0x13b/0x200 drivers/usb/core/message.c:1030
       [<ffffffff82ca39d3>] usb_set_configuration+0x1083/0x18d0 drivers/usb/core/message.c:1937
       [<ffffffff82cc9e2e>] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172
       [<ffffffff82caa7fa>] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263
      
      This patch prevents the problem by checking for duplicate endpoint
      addresses during enumeration and skipping any duplicates.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a8fd134
    • G
      usb: hub: Move hub_port_disable() to fix warning if PM is disabled · 3bc02bce
      Geert Uytterhoeven 提交于
      If CONFIG_PM=n:
      
          drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called
          drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here
      
      To fix this, move hub_port_disable() after
      hub_usb3_port_prepare_disable(), and adjust forward declarations.
      
      Fixes: 37be6676 ("usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices")
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3bc02bce
  17. 25 12月, 2016 1 次提交
  18. 06 12月, 2016 1 次提交
    • R
      usb: core: usbport: Use proper LED API to fix potential crash · 89778ba3
      Rafał Miłecki 提交于
      Calling brightness_set manually isn't safe as some LED drivers don't
      implement this callback. The best idea is to just use a proper helper
      which will fallback to the brightness_set_blocking callback if needed.
      
      This fixes:
      [ 1461.761528] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      (...)
      [ 1462.117049] Backtrace:
      [ 1462.119521] [<bf228164>] (usbport_trig_port_store [ledtrig_usbport]) from [<c023f758>] (dev_attr_store+0x20/0x2c)
      [ 1462.129826]  r7:dcabc7c0 r6:dee0ff80 r5:00000002 r4:bf228164
      [ 1462.135511] [<c023f738>] (dev_attr_store) from [<c0169310>] (sysfs_kf_write+0x48/0x4c)
      [ 1462.143459]  r5:00000002 r4:c023f738
      [ 1462.147049] [<c01692c8>] (sysfs_kf_write) from [<c0168ab8>] (kernfs_fop_write+0xf8/0x1f8)
      [ 1462.155258]  r5:00000002 r4:df4a1000
      [ 1462.158850] [<c01689c0>] (kernfs_fop_write) from [<c0100c78>] (__vfs_write+0x34/0x120)
      [ 1462.166800]  r10:00000000 r9:dee0e000 r8:c000fc24 r7:00000002 r6:dee0ff80 r5:c01689c0
      [ 1462.174660]  r4:df727a80
      [ 1462.177204] [<c0100c44>] (__vfs_write) from [<c0101ae4>] (vfs_write+0xac/0x170)
      [ 1462.184543]  r9:dee0e000 r8:c000fc24 r7:dee0ff80 r6:b6f092d0 r5:df727a80 r4:00000002
      [ 1462.192319] [<c0101a38>] (vfs_write) from [<c01028dc>] (SyS_write+0x4c/0xa8)
      [ 1462.199396]  r9:dee0e000 r8:c000fc24 r7:00000002 r6:b6f092d0 r5:df727a80 r4:df727a80
      [ 1462.207174] [<c0102890>] (SyS_write) from [<c000fa60>] (ret_fast_syscall+0x0/0x3c)
      [ 1462.214774]  r7:00000004 r6:ffffffff r5:00000000 r4:00000000
      [ 1462.220456] Code: bad PC value
      [ 1462.223560] ---[ end trace 676638a3a12c7a56 ]---
      Reported-by: NRalph Sennhauser <ralph.sennhauser@gmail.com>
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Fixes: 0f247626 ("usb: core: Introduce a USB port LED trigger")
      Cc: stable@vger.kernel.org # 4.9+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89778ba3
  19. 05 12月, 2016 1 次提交
    • G
      usb: hub: Wait for connection to be reestablished after port reset · 22547c4c
      Guenter Roeck 提交于
      On a system with a defective USB device connected to an USB hub,
      an endless sequence of port connect events was observed. The sequence
      of events as observed is as follows:
      
      - Port reports connected event (port status=USB_PORT_STAT_CONNECTION).
      - Event handler debounces port and resets it by calling hub_port_reset().
      - hub_port_reset() calls hub_port_wait_reset() to wait for the reset
        to complete.
      - The reset completes, but USB_PORT_STAT_CONNECTION is not immediately
        set in the port status register.
      - hub_port_wait_reset() returns -ENOTCONN.
      - Port initialization sequence is aborted.
      - A few milliseconds later, the port again reports a connected event,
        and the sequence repeats.
      
      This continues either forever or, randomly, stops if the connection
      is already re-established when the port status is read. It results in
      a high rate of udev events. This in turn destabilizes userspace since
      the above sequence holds the device mutex pretty much continuously
      and prevents userspace from actually reading the device status.
      
      To prevent the problem from happening, let's wait for the connection
      to be re-established after a port reset. If the device was actually
      disconnected, the code will still return an error, but it will do so
      only after the long reset timeout.
      
      Cc: Douglas Anderson <dianders@chromium.org>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22547c4c
  20. 18 11月, 2016 1 次提交
  21. 17 11月, 2016 1 次提交
  22. 03 11月, 2016 3 次提交
  23. 30 10月, 2016 1 次提交
  24. 27 10月, 2016 1 次提交
  25. 28 9月, 2016 1 次提交
  26. 27 9月, 2016 1 次提交
    • 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