linux.git/drivers/usb/core/usb.c, branch v4.12

USB: core: fix up kerneldoc comment

2017-03-24T16:22:22+00:00

Make the kerneldoc comment for usb_find_common_endpoints_reverse()
self-contained by adding a full description and removing the reference
to usb_find_common_endpoints().

Reported-by: kbuild test robot 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: core: add helpers to retrieve endpoints in reverse order

2017-03-23T12:53:16+00:00

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: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: core: add helpers to retrieve endpoints

2017-03-23T12:53:16+00:00

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: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

usb: separate out sysdev pointer from usb_bus

2017-03-23T07:20:21+00:00

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: Arnd Bergmann 
Signed-off-by: Sriram Dash 
Tested-by: Baolin Wang 
Tested-by: Brian Norris 
Tested-by: Alexander Sverdlin 
Tested-by: Vivek Gautam 
Signed-off-by: Mathias Nyman 
Signed-off-by: Peter Chen 
Cc: Felipe Balbi 
Cc: Grygorii Strashko 
Cc: Sinjan Kumar 
Cc: David Fisher 
Cc: Catalin Marinas 
Cc: "Thang Q. Nguyen" 
Cc: Yoshihiro Shimoda 
Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Cc: Ming Lei 
Cc: Jon Masters 
Cc: Dann Frazier 
Cc: Peter Chen 
Cc: Leo Li 
Signed-off-by: Greg Kroah-Hartman

USB: core: add missing license information to some files

2016-10-29T16:51:56+00:00

Some of the USB core files were missing explicit license information.
As all files in the kernel tree are implicitly licensed under the
GPLv2-only, be explicit in case someone get confused looking at
individual files by using the SPDX nomenclature.

Signed-off-by: Greg Kroah-Hartman

usb: core: setup dma_pfn_offset for USB devices and, interfaces

2016-09-13T15:25:35+00:00

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: Roger Quadros 
Acked-by: Arnd Bergmann 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

Merge 4.6-rc7 into usb-next

2016-05-09T07:29:13+00:00

We want the USB fixes in here to resolve merge issues and make it easier
for testing.

Signed-off-by: Greg Kroah-Hartman

Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02T15:44:31+00:00

This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
broke system resume for a large class of devices.

Devices that after having been reset during resume need to be rebound
due to a missing reset_resume callback, are now left in a suspended
state. This specifically broke resume of common USB-serial devices,
which are now unusable after system suspend (until disconnected and
reconnected) when USB persist is enabled.

During resume, usb_resume_interface will set the needs_binding flag for
such interfaces, but unlike system resume, run-time resume does not
honour it.

Cc: stable 	# 4.5
Signed-off-by: Johan Hovold 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: core: move root hub's device node assignment after it is added to bus

2016-04-28T19:57:49+00:00

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: Peter Chen 
Reported-by: Lars Steubesand 
Signed-off-by: Greg Kroah-Hartman

usb/core: usb_alloc_dev(): fix setting of ->portnum

2016-03-18T16:19:02+00:00

With commit 69bec7259853 ("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:
   [] dump_stack+0xdc/0x15e
   [] ? _atomic_dec_and_lock+0xa2/0xa2
   [] ? print_section+0x61/0xb0
   [] print_trailer+0x179/0x2c0
   [] object_err+0x34/0x40
   [] kasan_report_error+0x2f8/0x8b0
   [] ? __slab_alloc+0x5e/0x90
   [] ? __lock_is_held+0x90/0x130
   [] kasan_report+0x71/0xa0
   [] ? kmem_cache_alloc_trace+0x212/0x560
   [] ? xhci_find_raw_port_number+0x98/0x170
   [] __asan_load8+0x64/0x70
   [] xhci_find_raw_port_number+0x98/0x170
   [] xhci_setup_addressable_virt_dev+0x235/0xa10
   [] xhci_setup_device+0x3c1/0x1430
   [] ? trace_hardirqs_on+0xd/0x10
   [] ? xhci_setup_device+0x1430/0x1430
   [] xhci_address_device+0x13/0x20
   [] hub_port_init+0x55a/0x1550
   [] hub_event+0xef5/0x24d0
   [] ? hub_port_debounce+0x2f0/0x2f0
   [] ? debug_object_deactivate+0x1be/0x270
   [] ? print_rt_rq+0x53/0x2d0
   [] ? trace_hardirqs_off+0xd/0x10
   [] ? _raw_spin_unlock_irqrestore+0x5b/0x60
   [] ? irq_domain_set_hwirq_and_chip+0x30/0xb0
   [] ? debug_lockdep_rcu_enabled+0x39/0x40
   [] ? __lock_is_held+0x90/0x130
   [] 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: 69bec7259853 ("USB: core: let USB device know device node")
Signed-off-by: Nicolai Stange 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman