1. 30 10月, 2016 1 次提交
  2. 13 9月, 2016 1 次提交
    • R
      usb: core: setup dma_pfn_offset for USB devices and, interfaces · b44bbc46
      Roger Quadros 提交于
      If dma_pfn_offset is not inherited correctly from the host controller,
      it might result in sub-optimal configuration as bounce
      buffer limit might be set to less than optimal level.
      
      Consider the mass storage device case.
      USB storage driver creates a scsi host for the mass storage interface in
      drivers/usb/storage/usb.c
      The scsi host parent device is nothing but the the USB interface device.
      Now, __scsi_init_queue() calls scsi_calculate_bounce_limit() to find out
      and set the block layer bounce limit.
      scsi_calculate_bounce_limit() uses dma_max_pfn(host_dev) to get the
      bounce_limit. host_dev is nothing but the device representing the
      mass storage interface.
      If that device doesn't have the right dma_pfn_offset, then dma_max_pfn()
      is messed up and the bounce buffer limit is wrong.
      
      e.g. On Keystone 2 systems, dma_max_pfn() is 0x87FFFF and dma_mask_pfn
      is 0xFFFFF. Consider a mass storage use case: Without this patch,
      usb scsi host device (usb-storage) will get a dma_pfn_offset of 0 resulting
      in a dma_max_pfn() of 0xFFFFF within the scsi layer
      (scsi_calculate_bounce_limit()).
      This will result in bounce buffers being unnecessarily used.
      
      Hint: On 32-bit ARM platforms dma_max_pfn() = dma_mask_pfn + dma_pfn_offset
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b44bbc46
  3. 02 5月, 2016 1 次提交
  4. 29 4月, 2016 1 次提交
    • P
      usb: core: move root hub's device node assignment after it is added to bus · dc5878ab
      Peter Chen 提交于
      When the root hub device is added to the bus, it tries to get pins
      information from pinctrl (see pinctrl_bind_pins, at really_probe), if
      the pin information is described at DT, it will show below error since
      the root hub's device node is the same with controller's, but controller's
      pin has already been requested when it is added to platform bus.
      
      	imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
             	requested by 2184000.usb; cannot claim for usb1
      	imx6q-pinctrl 20e0000.iomuxc: pin-137 (usb1) status -22
      	imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
             	(MX6Q_PAD_GPIO_1) from group usbotggrp-3 on device 20e0000.iomuxc
      	usb usb1: Error applying setting, reverse things back
      
      To fix this issue, we move the root hub's device node assignment (equals
      to contrller's) after device is added to bus, we only need to know root
      hub's device node information after the device under root hub is created,
      so this movement will not affect current function.
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Reported-by: NLars Steubesand <lars.steubesand@philips.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc5878ab
  5. 19 3月, 2016 1 次提交
    • N
      usb/core: usb_alloc_dev(): fix setting of ->portnum · 7222c832
      Nicolai Stange 提交于
      With commit 69bec725 ("USB: core: let USB device know device node"),
      the port1 argument of usb_alloc_dev() gets overwritten as follows:
      
        ... usb_alloc_dev(..., unsigned port1)
        {
          ...
          if (!parent->parent) {
            port1 = usb_hcd_find_raw_port_number(..., port1);
          }
          ...
        }
      
      Later on, this now overwritten port1 gets assigned to ->portnum:
      
        dev->portnum = port1;
      
      However, since xhci_find_raw_port_number() isn't idempotent, the
      aforementioned commit causes a number of KASAN splats like the following:
      
        BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170
                                             at addr ffff8801d9311670
        Read of size 8 by task kworker/2:1/87
        [...]
        Workqueue: usb_hub_wq hub_event
         0000000000000188 000000005814b877 ffff8800cba17588 ffffffff8191447e
         0000000041b58ab3 ffffffff82a03209 ffffffff819143a2 ffffffff82a252f4
         ffff8801d93115e0 0000000000000188 ffff8801d9311628 ffff8800cba17588
        Call Trace:
         [<ffffffff8191447e>] dump_stack+0xdc/0x15e
         [<ffffffff819143a2>] ? _atomic_dec_and_lock+0xa2/0xa2
         [<ffffffff814e2cd1>] ? print_section+0x61/0xb0
         [<ffffffff814e4939>] print_trailer+0x179/0x2c0
         [<ffffffff814f0d84>] object_err+0x34/0x40
         [<ffffffff814f4388>] kasan_report_error+0x2f8/0x8b0
         [<ffffffff814eb91e>] ? __slab_alloc+0x5e/0x90
         [<ffffffff812178c0>] ? __lock_is_held+0x90/0x130
         [<ffffffff814f5091>] kasan_report+0x71/0xa0
         [<ffffffff814ec082>] ? kmem_cache_alloc_trace+0x212/0x560
         [<ffffffff81d99468>] ? xhci_find_raw_port_number+0x98/0x170
         [<ffffffff814f33d4>] __asan_load8+0x64/0x70
         [<ffffffff81d99468>] xhci_find_raw_port_number+0x98/0x170
         [<ffffffff81db0105>] xhci_setup_addressable_virt_dev+0x235/0xa10
         [<ffffffff81d9ea51>] xhci_setup_device+0x3c1/0x1430
         [<ffffffff8121cddd>] ? trace_hardirqs_on+0xd/0x10
         [<ffffffff81d9fac0>] ? xhci_setup_device+0x1430/0x1430
         [<ffffffff81d9fad3>] xhci_address_device+0x13/0x20
         [<ffffffff81d2081a>] hub_port_init+0x55a/0x1550
         [<ffffffff81d28705>] hub_event+0xef5/0x24d0
         [<ffffffff81d27810>] ? hub_port_debounce+0x2f0/0x2f0
         [<ffffffff8195e1ee>] ? debug_object_deactivate+0x1be/0x270
         [<ffffffff81210203>] ? print_rt_rq+0x53/0x2d0
         [<ffffffff8121657d>] ? trace_hardirqs_off+0xd/0x10
         [<ffffffff8226acfb>] ? _raw_spin_unlock_irqrestore+0x5b/0x60
         [<ffffffff81250000>] ? irq_domain_set_hwirq_and_chip+0x30/0xb0
         [<ffffffff81256339>] ? debug_lockdep_rcu_enabled+0x39/0x40
         [<ffffffff812178c0>] ? __lock_is_held+0x90/0x130
         [<ffffffff81196877>] process_one_work+0x567/0xec0
        [...]
      
      Afterwards, xhci reports some functional errors:
      
        xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
                                      code 0x11.
        xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion
                                      code 0x11.
        usb 4-3: device not accepting address 2, error -22
      
      Fix this by not overwriting the port1 argument in usb_alloc_dev(), but
      storing the raw port number as required by OF in an additional variable,
      raw_port.
      
      Fixes: 69bec725 ("USB: core: let USB device know device node")
      Signed-off-by: NNicolai Stange <nicstange@gmail.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7222c832
  6. 06 3月, 2016 1 次提交
  7. 04 2月, 2016 1 次提交
  8. 25 1月, 2016 2 次提交
  9. 08 1月, 2016 1 次提交
  10. 05 12月, 2015 1 次提交
  11. 23 9月, 2015 1 次提交
  12. 19 8月, 2015 1 次提交
  13. 15 8月, 2015 1 次提交
  14. 26 3月, 2015 2 次提交
  15. 10 1月, 2015 1 次提交
    • S
      usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN · 5efd2ea8
      Sebastian Andrzej Siewior 提交于
      the following error pops up during "testusb -a -t 10"
      | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
      hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
      size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
      hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
      might by identified by buffer_offset() as another buffer. This means the
      buffer which is on a 32 byte boundary will not get freed, instead it
      tries to free another buffer with the error message.
      
      This patch fixes the issue by creating the smallest DMA buffer with the
      size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
      smaller). This might be 32, 64 or even 128 bytes. The next three pools
      will have the size 128, 512 and 2048.
      In case the smallest pool is 128 bytes then we have only three pools
      instead of four (and zero the first entry in the array).
      The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
      2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
      we would end up with 8KiB buffer in case we have 16KiB pages.
      Instead I think it makes sense to have a common size(s) and extend them
      if there is need to.
      There is a BUILD_BUG_ON() now in case someone has a minalign of more than
      128 bytes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5efd2ea8
  16. 04 12月, 2014 1 次提交
  17. 18 7月, 2014 1 次提交
  18. 12 10月, 2013 1 次提交
  19. 03 8月, 2013 1 次提交
  20. 21 5月, 2013 1 次提交
    • J
      usb: ehci: Only sleep for post-resume handover if devices use persist · 9b790915
      Julius Werner 提交于
      The current EHCI code sleeps a flat 110ms in the resume path if there
      was a USB 1.1 device connected to its companion controller during
      suspend, waiting for the device to reappear and reset so that it can be
      handed back to the companion. This is necessary if the device uses
      persist, so that the companion controller can actually see it during its
      own resume path.
      
      However, if the device doesn't use persist, this is entirely
      unnecessary. We might just as well ignore it and have the normal device
      detection/reset/handoff code handle it asynchronously when it eventually
      shows up. As USB 1.1 devices are almost exclusively HIDs these days (for
      which persist has no value), this can allow distros to shave another
      tenth of a second off their resume time.
      
      In order to enable this optimization, the patch also adds a new
      usb_for_each_dev() iterator that is exported by the USB core and wraps
      bus_for_each_dev() with the logic to differentiate between struct
      usb_device and struct usb_interface on the usb_bus_type bus.
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b790915
  21. 12 4月, 2013 1 次提交
  22. 08 4月, 2013 1 次提交
    • K
      driver core: add uid and gid to devtmpfs · 3c2670e6
      Kay Sievers 提交于
      Some drivers want to tell userspace what uid and gid should be used for
      their device nodes, so allow that information to percolate through the
      driver core to userspace in order to make this happen.  This means that
      some systems (i.e.  Android and friends) will not need to even run a
      udev-like daemon for their device node manager and can just rely in
      devtmpfs fully, reducing their footprint even more.
      Signed-off-by: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c2670e6
  23. 29 3月, 2013 1 次提交
    • A
      USB: remove CONFIG_USB_SUSPEND option · 84ebc102
      Alan Stern 提交于
      This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
      replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
      in hub.c, where it is replaced with CONFIG_PM because the code needs
      to be used in both runtime and system PM).  The net result is code
      shrinkage and simplification.
      
      There's very little point in keeping CONFIG_USB_SUSPEND because almost
      everybody enables it.  The few that don't will find that the usbcore
      module has gotten somewhat bigger and they will have to take active
      measures if they want to prevent hubs from being runtime suspended.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Peter Chen <peter.chen@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84ebc102
  24. 22 11月, 2012 1 次提交
  25. 25 10月, 2012 1 次提交
  26. 11 7月, 2012 1 次提交
    • S
      USB: Disable LPM while the device is unconfigured. · 9cf65991
      Sarah Sharp 提交于
      The USB 3.0 Set/Clear Feature U1/U2 Enable cannot be sent to a device in
      the Default or Addressed state.  It can only be sent to a configured
      device.  Change the USB core to initialize the LPM disable count to 1
      (disabled), which reflects this limitation.
      
      Change usb_set_configuration() to ensure that if the device is
      unconfigured on entry, usb_lpm_disable() is not called.  This avoids
      sending the Clear Feature U1/U2 when the device is in the Addressed
      state.  When usb_set_configuration() exits with a successfully installed
      configuration, usb_lpm_enable() will be called.
      
      Once the new configuration is installed, make sure
      usb_set_configuration() only calls usb_enable_lpm() if the device moved
      to the Configured state.  If we have unconfigured the device by sending
      it a Set Configuration for config 0, don't enable LPM.
      
      This commit should be backported to kernels as old as 3.5, that contain
      the commit 8306095f "USB: Disable USB
      3.0 LPM in critical sections."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      9cf65991
  27. 16 5月, 2012 1 次提交
    • S
      usb: fix breakage on systems without ACPI · ea79c2ed
      Sasha Levin 提交于
      Commit da0af6e7 ("usb: Bind devices to ACPI devices when possible") really
      tries to force-bind devices even when impossible, unlike what it says in
      the subject.
      
      CONFIG_ACPI is not an indication that ACPI tables are actually present, nor
      is an indication that any USB relevant information is present in them. There
      is no reason to fail the creation of a USB bus if it can't bind it to
      ACPI device during initialization.
      
      On systems with CONFIG_ACPI set but without ACPI tables it would cause a
      boot panic.
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea79c2ed
  28. 12 5月, 2012 1 次提交
  29. 30 4月, 2012 1 次提交
  30. 25 1月, 2012 1 次提交
  31. 13 1月, 2012 1 次提交
  32. 04 1月, 2012 1 次提交
  33. 27 9月, 2011 1 次提交
  34. 30 4月, 2011 1 次提交
  35. 19 3月, 2011 1 次提交
  36. 17 11月, 2010 1 次提交
    • A
      USB: use the runtime-PM autosuspend implementation · fcc4a01e
      Alan Stern 提交于
      This patch (as1428) converts USB over to the new runtime-PM core
      autosuspend framework.  One slightly awkward aspect of the conversion
      is that USB devices will now have two suspend-delay attributes: the
      old power/autosuspend file and the new power/autosuspend_delay_ms
      file.  One expresses the delay time in seconds and the other in
      milliseconds, but otherwise they do the same thing.  The old attribute
      can be deprecated and then removed eventually.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fcc4a01e
  37. 11 8月, 2010 1 次提交
  38. 22 5月, 2010 1 次提交