Fixed typos in comments of various drivers/usb files
Signed-off-by: NMickael Maison <mickael.maison@gmail.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of dereference each byte let's use %*ph specifier in the printk()
calls.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Need include it for irq_of_parse_and_map(), the related error with
allmodconfig under microblaze:

  drivers/usb/host/ehci-xilinx-of.c: In function ‘ehci_hcd_xilinx_of_probe’:
  drivers/usb/host/ehci-xilinx-of.c:156:2: error: implicit declaration of function ‘irq_of_parse_and_map’ [-Werror=implicit-function-declaration]
    irq = irq_of_parse_and_map(dn, 0);
    ^
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Acked-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If three or more wireless devices are connected and two of them
disconnect between 1-3 seconds apart, it can cause the HWA to disconnect
the remaining devices due to failing to see a DN_Alive message from
them.  This happens because when the HWA detects that the first device
is gone, it will attempt to rekey the remaining devices.  If one of the
devices is not responding because it has also been disconnected but not
yet timed out, the synchronous rekey operation running on the wusbd
workqueue can block for up to 5 seconds.  This will prevent the
KEEPALIVE timer from running and DN_Alive messages from being processed
because they are processed by the same workqueue.  This patch moves the
rekey operation to a separate workqueue since it is the only wusb work
item that needs to communicate directly with wireless devices.  The rest
of the WUSB work items either perform no device IO or communicate
directly with the host controller and should not be blocked out by a
non-responding wireless device.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When completing an aborted transfer, skip done segs before calling
wa_complete_remaining_xfer_segs to avoid a runtime warning.  The warning
is harmless in this case but avoiding it prevents false error reports.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add USB build dependency for USB_WUSB_CBAF.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Wireless USB does not require PCI so remove USB_WUSB build dependency on
PCI.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An HWA is a USB device so it depends on USB.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Document the /sys/class/uwb_rc/uwbN/ASIE sysfs attribute
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allow user mode to add and remove application specific information
elements (ASIEs) to the beacon of a uwb_rc device.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The existing UWB documentation states that UWB devices show up in
/sys/class/uwb and /sys/bus/uwb/devices.  Up until the most recent
changes to add uwb devices to their own bus, neither of these statements
were actually true.  Now, UWB devices do show up in /sys/bus/uwb/devices
so the documentation has been updated to reflect that and removed
references to /sys/class/uwb.

The existing documentation also states that local UWB radio controller
(RC) devices also show up as UWB devices along with their wireless peer
UWB devices under /sys/class/uwb.  This is not true so that statement
has been removed.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation/usb/WUSB-Design-overview.txt states that UWB devices seen
by a UWB radio controller are added to /sys/bus/uwb/devices, but this
was not actually being done.  This functionality is needed in order for
UWB peer devices to be enumerated by user mode tools.  This patch
creates a uwb bus type and adds UWB peer devices to it as they are
discovered by the radio controller.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

UWB does not require PCI to be enabled so remove build dependency.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Print info about the radio controller device instead of the its parent
when UWB devices connect and disconnect.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix line length in uwb-internal.h
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Delete successive assignments to the same location.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression i;
@@

*i = ...;
 i = ...;
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Renesas USBHS controller support should be available only on
Renesas ARM SoCs and SuperH architecture.
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.
Signed-off-by: NVivek Gautam <gautam.vivek@samsung.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NArjun Sreedharan <arjun024@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Lately (with the use of uas / bulk-streams) we have been seeing several
cases where this error triggers (which should never happen).

Add some extra logging to make debugging these errors easier.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Even though a Set TR deq ptr command operates on a ring, and an endpoint
can have multiple rings, we can have only one Set TR deq ptr command pending.

When an endpoint with streams halts or is stopped to unlink urbs, there
will only be at most one ring active / one td being executed (the td
stopped_td points to).

So when we reset the endpoint (for a halt), or the stop command completes, we
will queue one Set TR deq ptr command at most, cancelled urbs on other stream
rings then the one being executed will have there trbs turned to nops, and
once the hcd gets around to execute that stream ring they will be simply
skipped.

So the SET_DEQ_PENDING flag in the endpoint is sufficient protection against
starting the endpoing before all stream rings are cleaned up.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Even if the stream for which the command was intended has been freed in the
mean time. This ensures that things start rolling again after an unlink / halt.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci_queue_new_dequeue_state is the only caller of queue_set_tr_deq
and queue_set_tr_deq checks for SET_DEQ_PENDING, where as
xhci_queue_new_dequeue_state sets it which is inconsistent.

Simply fold the 2 into one is a nice cleanup and fixes the inconsistency.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

V2 - Restart polling (which will restart the timer) for the shared
HCD in xhci_resume().

xhci_suspend() will stop the primary HCD's root hub timer, but leaves
the shared HCD's timer running. This change adds stopping of the
shared HCD timer.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are multiple reasons for this:

1) This fixes a missing check for xhci_alloc_command failing in
   xhci_handle_cmd_stop_ep()
2) This adds a warning when we cannot set the new dequeue state because of
   xhci_alloc_command failing
3) It puts the allocation of the command after the sanity checks in
   queue_set_tr_deq(), avoiding leaking the command if those fail
4) Since queue_set_tr_deq now owns the command it can free it if queue_command
   fails
5) It reduces code duplication
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If something goes wrong in our communication with an uas device we may get
a response iu in reaction to a cmnd, rather then a status iu. In this case
propagate an error upwards, rather then logging a bogus iu message.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of doing:

uas_log_cmd_state(cmnd, __func__)
scmd_printk(KERN_ERR, cmnd, "error doing foo %d\n", err)

On error, resulting in 2 log calls for a single error, make uas_log_cmd_state
take a status code, and change calls like the above to:

uas_log_cmd_state(cmnd, "error doing foo", err)

Also change various sanity checks (which should never trigger) from:
"scmd_printk(KERN_ERR, cmnd, "sanity foo failed\n")" to calling the new
uas_log_cmd_state(), so that when they do trigger we get more info.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We've removed all hack from the driver for pre-production hardware.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I've access to a number of different uas devices now, and none of them use
old style sense urbs. The only case where these code-paths trigger is with
the asm1051 and there they do the wrong thing, as the asm1051 sends 8 bytes
status iu-s when it does not have any sense data, but uses new style
sense iu-s regardless, as can be seen for scsi cmnds where there is sense
data.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It was only used to sanity check against completing the same cmnd twice,
but that is the case we're likely operating on free-ed memory, and doing
sanity checks on free-ed memory is not really helpful.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use scsi_print_command to print commands during errors, rather then printing
the rather meaningless pointer to the command.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Check for both type of cancellation codes for sense and data urbs.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Limit the no-streams case to speeds less then USB_SPEED_SUPER.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The purpose of uas_pre_reset is to:

1) Stop any new commands from being submitted while an externally triggered
   usb-device-reset is running
2) Wait for any pending commands to finish before allowing the usb-device-reset
   to continue

The purpose of uas_suspend is to:
2) Wait for any pending commands to finish before suspending

This commit fixes races in both paths:

1) For 1) we use scsi_block_requests, but the scsi midlayer calls queuecommand
   without holding any locks, so a queuecommand may already past the midlayer
   scsi_block_requests checks when we call it, add a check to uas_queuecommand
   to fix this

2) For 2) we were waiting for all sense-urbs to complete, there are 2 problems
   with this approach:
a) data-urbs may complete after the sense urb, so we need to check for those
   too
b) if a sense-urb completes with a iu id of READ/WRITE_READY a command is not
   yet done. We submit a new sense-urb immediately in this case, but that
   submit may fail (in which case it will get retried by uas_do_work), if this
   happens the sense_urbs anchor may become empty while the cmnd is not yet
   done

Also unblock requests on timeout, to avoid things getting stuck in that case.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Not all urbs we've allocated are necessarily also submitted, non-submitted
urbs will not be free-ed by their completion handler. So we need to free
them manually.

There are 2 scenarios where this can happen:

1) We have failed to submit some urbs at abort / disconnect
2) When running over usb-2 we may have never tried to submit the data urbs
   when completing the scsi cmnd, because we never got a READ/WRITE_READY iu
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Do not keep references around to a cmnd which is under error handling.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is not strictly necessary for the cmd urb to have a reference to the
cmnd, and without this reference it becomes easier to drop all references to
a cmnd on an abort.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We've the same info doubled in both the inflight list and the cmnd array,
drop the list.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>