This patch is to enable the USB gadget device for Intel Quark X1000
Signed-off-by: NBryan O'Donoghue <bryan.odonoghue@intel.com>
Signed-off-by: NBing Niu <bing.niu@intel.com>
Signed-off-by: NAlvin (Weike) Chen <alvin.chen@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If the pending buffers in the queue could not be pushed to the udc
endpoint we have to cancel the uvc_queue. Otherwise the gadget will get
stuck on this error. This patch calls uvc_queue_cancel if usb_ep_queue
failed.
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This reverts commit a9232076.

It introduced a dead lock, and did not fix anything.

it made netif_tx_lock() be called in IRQ context, but in softirq context,
the same lock is locked without disabling IRQ. In fact, the commit a9232076
did not fix anything, since netif_stop_queue did not free the any resource

[   10.154920] =================================
[   10.156026] [ INFO: inconsistent lock state ]
[   10.156026] 3.16.0-rc5+ #13 Not tainted
[   10.156026] ---------------------------------
[   10.156026] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[   10.156026] swapper/1/0 [HC0[0]:SC1[5]:HE1:SE0] takes:
[   10.156026]  (_xmit_ETHER){?.-...}, at: [<80948b6a>] sch_direct_xmit+0x7a/0x250
[   10.156026] {IN-HARDIRQ-W} state was registered at:
[   10.156026]   [<804811f0>] __lock_acquire+0x800/0x17a0
[   10.156026]   [<804828ba>] lock_acquire+0x6a/0xf0
[   10.156026]   [<809ed477>] _raw_spin_lock+0x27/0x40
[   10.156026]   [<8088d508>] gether_disconnect+0x68/0x280
[   10.156026]   [<8088e777>] eem_set_alt+0x37/0xc0
[   10.156026]   [<808847ce>] composite_setup+0x30e/0x1240
[   10.156026]   [<8088b8ae>] pch_udc_isr+0xa6e/0xf50
[   10.156026]   [<8048abe8>] handle_irq_event_percpu+0x38/0x1e0
[   10.156026]   [<8048adc1>] handle_irq_event+0x31/0x50
[   10.156026]   [<8048d94b>] handle_fasteoi_irq+0x6b/0x140
[   10.156026]   [<804040a5>] handle_irq+0x65/0x80
[   10.156026]   [<80403cfc>] do_IRQ+0x3c/0xc0
[   10.156026]   [<809ee6ae>] common_interrupt+0x2e/0x34
[   10.156026]   [<804668c5>] finish_task_switch+0x65/0xd0
[   10.156026]   [<809e89df>] __schedule+0x20f/0x7d0
[   10.156026]   [<809e94aa>] schedule_preempt_disabled+0x2a/0x70
[   10.156026]   [<8047bf03>] cpu_startup_entry+0x143/0x410
[   10.156026]   [<809e2e61>] rest_init+0xa1/0xb0
[   10.156026]   [<80ce2a3b>] start_kernel+0x336/0x33b
[   10.156026]   [<80ce22ab>] i386_start_kernel+0x79/0x7d
[   10.156026] irq event stamp: 52070
[   10.156026] hardirqs last  enabled at (52070): [<809375de>] neigh_resolve_output+0xee/0x2a0
[   10.156026] hardirqs last disabled at (52069): [<809375a8>] neigh_resolve_output+0xb8/0x2a0
[   10.156026] softirqs last  enabled at (52020): [<8044401f>] _local_bh_enable+0x1f/0x50
[   10.156026] softirqs last disabled at (52021): [<80404036>] do_softirq_own_stack+0x26/0x30
[   10.156026]
[   10.156026] other info that might help us debug this:
[   10.156026]  Possible unsafe locking scenario:
[   10.156026]
[   10.156026]        CPU0
[   10.156026]        ----
[   10.156026]   lock(_xmit_ETHER);
[   10.156026]   <Interrupt>
[   10.156026]     lock(_xmit_ETHER);
[   10.156026]
[   10.156026]  *** DEADLOCK ***
[   10.156026]
[   10.156026] 4 locks held by swapper/1/0:
[   10.156026]  #0:  (((&idev->mc_ifc_timer))){+.-...}, at: [<8044b100>] call_timer_fn+0x0/0x190
[   10.156026]  #1:  (rcu_read_lock){......}, at: [<a0577c40>] mld_sendpack+0x0/0x590 [ipv6]
[   10.156026]  #2:  (rcu_read_lock_bh){......}, at: [<a055680c>] ip6_finish_output2+0x4c/0x7f0 [ipv6]
[   10.156026]  #3:  (rcu_read_lock_bh){......}, at: [<8092e510>] __dev_queue_xmit+0x0/0x5f0
[   10.156026]
[   10.156026] stack backtrace:
[   10.156026] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.16.0-rc5+ #13
[   10.156026]  811dbb10 00000000 9e919d10 809e6785 9e8b8000 9e919d3c 809e561e 80b95511
[   10.156026]  80b9545a 80b9543d 80b95450 80b95441 80b957e4 9e8b84e0 00000002 8047f7b0
[   10.156026]  9e919d5c 8048043b 00000002 00000000 9e8b8000 00000001 00000004 9e8b8000
[   10.156026] Call Trace:
[   10.156026]  [<809e6785>] dump_stack+0x48/0x69
[   10.156026]  [<809e561e>] print_usage_bug+0x18f/0x19c
[   10.156026]  [<8047f7b0>] ? print_shortest_lock_dependencies+0x170/0x170
[   10.156026]  [<8048043b>] mark_lock+0x53b/0x5f0
[   10.156026]  [<804810cf>] __lock_acquire+0x6df/0x17a0
[   10.156026]  [<804828ba>] lock_acquire+0x6a/0xf0
[   10.156026]  [<80948b6a>] ? sch_direct_xmit+0x7a/0x250
[   10.156026]  [<809ed477>] _raw_spin_lock+0x27/0x40
[   10.156026]  [<80948b6a>] ? sch_direct_xmit+0x7a/0x250
[   10.156026]  [<80948b6a>] sch_direct_xmit+0x7a/0x250
[   10.156026]  [<8092e6bf>] __dev_queue_xmit+0x1af/0x5f0
[   10.156026]  [<80947fc0>] ? ether_setup+0x80/0x80
[   10.156026]  [<8092eb0f>] dev_queue_xmit+0xf/0x20
[   10.156026]  [<8093764c>] neigh_resolve_output+0x15c/0x2a0
[   10.156026]  [<a0556927>] ip6_finish_output2+0x167/0x7f0 [ipv6]
[   10.156026]  [<a0559b05>] ip6_finish_output+0x85/0x1c0 [ipv6]
[   10.156026]  [<a0559cb7>] ip6_output+0x77/0x240 [ipv6]
[   10.156026]  [<a0578163>] mld_sendpack+0x523/0x590 [ipv6]
[   10.156026]  [<80480501>] ? mark_held_locks+0x11/0x90
[   10.156026]  [<a057947d>] mld_ifc_timer_expire+0x15d/0x280 [ipv6]
[   10.156026]  [<8044b168>] call_timer_fn+0x68/0x190
[   10.156026]  [<a0579320>] ? igmp6_group_added+0x150/0x150 [ipv6]
[   10.156026]  [<8044b3fa>] run_timer_softirq+0x16a/0x240
[   10.156026]  [<a0579320>] ? igmp6_group_added+0x150/0x150 [ipv6]
[   10.156026]  [<80444984>] __do_softirq+0xd4/0x2f0
[   10.156026]  [<804448b0>] ? tasklet_action+0x100/0x100
[   10.156026]  [<80404036>] do_softirq_own_stack+0x26/0x30
[   10.156026]  <IRQ>  [<80444d05>] irq_exit+0x65/0x70
[   10.156026]  [<8042d758>] smp_apic_timer_interrupt+0x38/0x50
[   10.156026]  [<809ee91f>] apic_timer_interrupt+0x2f/0x34
[   10.156026]  [<8048007b>] ? mark_lock+0x17b/0x5f0
[   10.156026]  [<8040a912>] ? default_idle+0x22/0xf0
[   10.156026]  [<8040b13e>] arch_cpu_idle+0xe/0x10
[   10.156026]  [<8047bfc6>] cpu_startup_entry+0x206/0x410
[   10.156026]  [<8042bfbd>] start_secondary+0x19d/0x1e0
Acked-by: NTony Lindgren <tony@atomide.com>
Reported-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Jeff Westfahl <jeff.westfahl@ni.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Acked-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case of error, the function memdup_user() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

"ret" should be signed.  It's only used for zero and negative error
codes.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The prefix suggests the number should be printed in hex, so use
the %x specifier to do that.

Found by using regex suggested by Joe Perches.
Signed-off-by: NHans Wennborg <hans@hanshq.net>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As, the interrupt for DMA is counted from 1, so need to checked
the USBA_NR_DMAS, in old way, it only check (USBA_NR_DMAS - 1),
so fix it.
Reported-by: NMax Liao <liaops@embest-tech.com>
Signed-off-by: NBo Shen <voice.shen@atmel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Convert a zero return value on error to a negative one, as returned
elsewhere in the function.

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

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>
Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

According to the datasheet, PHYPARAM1_PCS_TXDEEMPH is set as
6 bits [5:0]. Thus, the bit mask should be set as 0x3f, instead
of 0x1f.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

After dbgp_bind()-dbgp_unbind() cycle happens, static variable dbgp
contains pointers to already deallocated memory (dbgp.serial and dbgp.req).
If the next dbgp_bind() fails, for example in usb_ep_alloc_request(),
dbgp_bind() calls dbgp_unbind() on failure path,
and dbgp_unbind() frees dbgp.serial that still stores a pointer
to already deallocated memory.

The patch sets pointers to NULL in dbgp_unbind().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Using kfree to free data allocated with devm_kzalloc causes double frees.

The Coccinelle semantic patch that fixes this problem is as follows:

// <smpl>
@@
expression x;
@@

x = devm_kzalloc(...)
...
?-kfree(x);
// </smpl>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NHimangi Saraogi <himangi774@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When __usb_find_phy_dev() does not return error and
try_module_get() fails, return -ENODEV.
Signed-off-by: NArjun Sreedharan <arjun024@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK
for output URBs. That causes usbcore to log messages without limit
for a nonsensical disallowed combination. The fix is to silently drop
the attribute in usbfs.
The problem is reported to exist since 3.14
https://www.virtualbox.org/ticket/13085Signed-off-by: NOliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

So that an user who wants to use uas can see why he is not getting uas.

Also move the check down so that we don't warn if there are other reasons
why uas cannot work.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't complain about controllers without sg support if there are other
reasons why uas cannot be used anyways.
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>

The 7023 product id is the generic product id for the Etron EJ168, it is
not specific to the version found on the Asrock P67 motherboard. The same id
is e.g. also used on Gigabyte motherboards and on no-name pci-e usb-3 addon
cards.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Streams on the EJ168 do not work as they should. I've spend 2 days trying
to get them to work, but without success.

The first problem is that when ever you ring the stream-ring doorbell, the
controller starts executing trbs at the beginning of the first ring segment,
event if it ended somewhere else previously. This can be worked around by
allowing enqueing only one td (not a problem with how streams are typically
used) and then resetting our copies of the enqueueing en dequeueing pointers
on a td completion to match what the controller seems to be doing.

This way things seem to start working with uas and instead of being able
to complete only the very first scsi command, the scsi core can probe the disk.

But then things break later on when td-s get enqueued with more then one
trb. The controller does seem to increase its dequeue pointer while executing
a stream-ring (data transfer events I inserted for debugging do trigger).
However execution seems to stop at the final normal trb of a multi trb td,
even if there is a data transfer event inserted after the final trb.

The first problem alone is a serious deviation from the spec, and esp.
dealing with cancellation would have been very tricky if not outright
impossible, but the second problem simply is a deal breaker altogether,
so this patch simply disables streams.

Note this will cause the usb-storage + uas driver pair to automatically switch
to using usb-storage instead of uas on these devices, essentially reverting
to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN.

https://bugzilla.redhat.com/show_bug.cgi?id=1121288
https://bugzilla.kernel.org/show_bug.cgi?id=80101

Cc: stable@vger.kernel.org # 3.15
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some jmicron uas chipsets act up (they disconnect from the bus) when sending
more then 32 commands to them at once.

Rather then building an ever growing list with usb-id based quirks for
devices using this chipset, simply reduce the qdepth to 32 when connected
over usb-2. 32 should be plenty to keep things close to maximum
possible throughput on usb-2.

Cc: stable@vger.kernel.org
Tested-and-reported-by: NLaszlo T. <tlacix@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds a usb quirk to support devices with interupt endpoints
and bInterval values expressed as microframes. The quirk causes the
parse endpoint function to modify the reported bInterval to a standards
conforming value.

There is currently code in the endpoint parser that checks for
bIntervals that are outside of the valid range (1-16 for USB 2+ high
speed and super speed interupt endpoints). In this case, the code assumes
the bInterval is being reported in 1ms frames. As well, the correction
is only applied if the original bInterval value is out of the 1-16 range.

With this quirk applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.
Signed-off-by: NJames P Michels III <james.p.michels@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds support for new Xsens devices, using Xsens' own Vendor ID.
Signed-off-by: NPatrick Riphagen <patrick.riphagen@xsens.com>
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Cc: Johan Hovold <johan@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The converters are used in specific products. It can be useful to know
which they are exactly.
Signed-off-by: NPatrick Riphagen <patrick.riphagen@xsens.com>
Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
Cc: Johan Hovold <johan@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver hasn't been fully cleaned up and it doesn't look like anyone
is working on it anymore (including the original author). So remove the
driver and all references to it. If someone wants to finish cleaning
the driver up and moving it out of staging, this commit can be reverted.
Signed-off-by: NKristina Martšenko <kristina.martsenko@gmail.com>
Cc: Cho, Yu-Chen <acho@novell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes the following sparse warnings:

drivers/usb/chipidea/debug.c:211:5: warning:
 symbol 'ci_otg_show' was not declared. Should it be static?
drivers/usb/chipidea/debug.c:334:5: warning:
 symbol 'ci_registers_show' was not declared. Should it be static?
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

-ENODEV is interpreted by the generic driver probing function as a
non-matching driver. This leads to a missing probe failure message.

Also a missing USB PHY is more of an invalid configuration of the usb
driver because it is necessary.

This patch returns -EINVAL if devm_usb_get_phy_by_phandle() returned -ENODEV.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Section 4.4.7.2 "Interrupt Transfer Bandwidth Requirements" of the USB3.0 spec
says:
	A zero-length data payload is a valid transfer and may be useful for
	some implementations.

So, extend the logic of allowing URB_ZERO_PACKET to interrupt urbs too.
Otherwise, the kernel throws warning of BOGUS transfer flags.
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Following sparse warnings were reported by kbuild test bot

drivers/usb/misc/lvstest.c:314:28: sparse: incorrect type in assignment (different base types)
   drivers/usb/misc/lvstest.c:314:28:    expected unsigned short [unsigned] [usertype] portchange
   drivers/usb/misc/lvstest.c:314:28:    got restricted __le16 [usertype] wPortChange
drivers/usb/misc/lvstest.c:332:40: sparse: restricted __le16 degrades to integer

This patch fixes above warnings.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The assigned IRQ should be freed before calling pci_disable_device()
when shutting down system, otherwise it will cause following warning.
[  568.879482] ------------[ cut here ]------------
[  568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170()
[  568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4'
[  568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq
[  568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G        W     3.16.0-rc5upstream-01651-g03b9189 #1
[  568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015  04/01/2010
[  568.956008]  00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c
[  568.964068]  00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d
[  568.972128]  ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5
[  568.980194] Call Trace:
[  568.982715]  [<c1617946>] dump_stack+0x48/0x60
[  568.987294]  [<c1090c3f>] warn_slowpath_common+0x7f/0xa0
[  569.003887]  [<c1090cde>] warn_slowpath_fmt+0x2e/0x30
[  569.009092]  [<c11f22a5>] remove_proc_entry+0x165/0x170
[  569.014476]  [<c10da6ca>] unregister_irq_proc+0xaa/0xc0
[  569.019858]  [<c10d582f>] free_desc+0x1f/0x60
[  569.024346]  [<c10d58aa>] irq_free_descs+0x3a/0x80
[  569.029283]  [<c10d9e9d>] irq_dispose_mapping+0x2d/0x50
[  569.034666]  [<c1078fd3>] mp_unmap_irq+0x73/0xa0
[  569.039423]  [<c107196b>] acpi_unregister_gsi_ioapic+0x2b/0x40
[  569.045431]  [<c107180f>] acpi_unregister_gsi+0xf/0x20
[  569.050725]  [<c1339cad>] acpi_pci_irq_disable+0x4b/0x50
[  569.056196]  [<c14daa38>] pcibios_disable_device+0x18/0x20
[  569.061848]  [<c130123d>] do_pci_disable_device+0x4d/0x60
[  569.067410]  [<c13012b7>] pci_disable_device+0x47/0xb0
[  569.077814]  [<c14800b1>] usb_hcd_pci_shutdown+0x31/0x40
[  569.083285]  [<c1304b19>] pci_device_shutdown+0x19/0x50
[  569.088667]  [<c13fda64>] device_shutdown+0x14/0x120
[  569.093777]  [<c10ac29d>] kernel_restart_prepare+0x2d/0x30
[  569.099429]  [<c10ac41e>] kernel_restart+0xe/0x60
[  569.109028]  [<c10ac611>] SYSC_reboot+0x191/0x220
[  569.159269]  [<c10ac6ba>] SyS_reboot+0x1a/0x20
[  569.163843]  [<c161c718>] sysenter_do_call+0x12/0x16
[  569.168951] ---[ end trace ccc1ec4471c289c9 ]---
Tested-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds an extra check to ohci-hcd's I/O watchdog routine.  If
the controller stops updating the frame counter, we will assume it is
dead.  But there has to be an exception: Some controllers stop the
frame counter when no ports are connected.  Check to make sure there
is at least one active port before deciding the controller is dead.

(This test may appear racy, but it isn't.  Enabling a newly connected
port takes several milliseconds, during which time the frame counter
must advance.)
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NDennis New <dennisn@dennisn.linuxd.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some OHCI controllers have a bug: They fail to add completed TDs to
the done queue.  Examining this queue is the only method ohci-hcd has
for telling when a transfer is complete; failure to add a TD can
result in an URB that never completes and cannot be unlinked.

This patch adds a watchdog routine to ohci-hcd.  The routine
periodically scans the active ED and TD lists, looking for TDs which
are finished but not on the done queue.  When one is found, and it is
certain that the controller hardware will never add the TD to the done
queue, the watchdog routine manually puts the TD on the done list so
that it can be handled normally.

The watchdog routine also checks for a condition indicating the
controller has died.  If the done queue is non-empty but the
HccaDoneHead pointer hasn't been updated for a few hundred
milliseconds, we assume the controller will never update it and
therefore is dead.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

URBs for a particular endpoint should complete sequentially.  That is,
we shouldn't call the completion handler for one URB until the handler
for the previous URB has returned.

When the OHCI watchdog routine is added, there will be two paths for
completing URBs: interrupt handler and watchdog routine.  Their
activities have to be synchronized so that completions don't occur in
multiple threads concurrently.

For that purpose, this patch creates an ohci_work() routine which will
be responsible for calling process_done_list() and finish_unlinks(),
the two routines that detect when an URB is complete.  Everything will
funnel through ohci_work(), and it will be careful not to run in more
than one thread at a time.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch changes the way ohci-hcd handles the TD done list.  In
addition to relying on the TD pointers stored by the controller
hardware, we need to handle TDs that the hardware has forgotten about.

This means the list has to exist even while the dl_done_list() routine
isn't running.  That function essentially gets split in two:
update_done_list() reads the TD pointers stored by the hardware and
adds the TDs to the done list, and process_done_list() scans through
the list to handle URB completions.  When we detect a TD that the
hardware forgot about, we will be able to add it to the done list
manually and then process it normally.

Since the list is really a queue, and because there can be a lot of
TDs, keep the existing singly linked implementation.  To insure that
URBs are given back in order of submission, whenever a TD is added to
the done list, all the preceding TDs for the same endpoint must be
added as well (going back to the first one that isn't already on the
done list).

The done list manipulations must all be protected by the private
lock.  The scope of the lock is expanded in preparation for the
watchdog routine to be added in a later patch.

We have to be more careful about giving back unlinked URBs.  Since TDs
may be added to the done list by the watchdog routine and not in
response to a controller interrupt, we have to check explicitly to
make sure all the URB's TDs that were added to the done list have been
processed before giving back the URB.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When an URB is unlinked from a dead controller, ohci-hcd gives back
the URB with no regard for cleaning up the internal data structures.
This won't play nicely with the upcoming changes to the TD done
list.

Therefore make ohci_urb_dequeue() call finish_unlinks(), which uses
td_done() to do a proper cleanup, rather than calling finish_urb()
directly.  Also, remove the checks that urb_priv is non-NULL; the
driver guarantees that urb_priv will never be NULL for a valid URB.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch reverts the important parts of commit 89a0fd18 (USB:
OHCI handles more ZFMicro quirks), namely, the parts related to
handling orphan TDs for interrupt endpoints.  A later patch in this
series will introduce a more general mechanism that applies to all
endpoint types and all controllers.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others.  Such
devices fail to reconnect with same old address which was associated
with it before suspend.

When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.

Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port.  In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.

Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.

I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.

So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.

XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present.  USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.

This patch implements above delay, but only for SS device and when
persist is enabled.

So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.

Results:

Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.

Cc: <stable@vger.kernel.org>
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I am removing two fix mes in this file as after dicussing then it  seems
there is no reason to check against Null for usb_device as it can never
be NULL and this is check is therefore not needed.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some laptops have an internal port for a BT device which picks
up noise when the kill switch is used, but not enough to trigger
printk_rlimit(). So we shouldn't log consecutive faults of this kind.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing
hub_usb3_port_disable().

Fixes: 41e7e056 (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: NGavin Guo <gavin.guo@canonical.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>