Fix driver new_id sysfs-attribute removal deadlock by making sure to
not hold any locks that the attribute operations grab when removing the
attribute.

Specifically, usb_serial_deregister holds the table mutex when
deregistering the driver, which includes removing the new_id attribute.
This can lead to a deadlock as writing to new_id increments the
attribute's active count before trying to grab the same mutex in
usb_serial_probe.

The deadlock can easily be triggered by inserting a sleep in
usb_serial_deregister and writing the id of an unbound device to new_id
during module unload.

As the table mutex (in this case) is used to prevent subdriver unload
during probe, it should be sufficient to only hold the lock while
manipulating the usb-serial driver list during deregister. A racing
probe will then either fail to find a matching subdriver or fail to get
the corresponding module reference.

Since v3.15-rc1 this also triggers the following lockdep warning:

======================================================
[ INFO: possible circular locking dependency detected ]
3.15.0-rc2 #123 Tainted: G        W
-------------------------------------------------------
modprobe/190 is trying to acquire lock:
 (s_active#4){++++.+}, at: [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94

but task is already holding lock:
 (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (table_lock){+.+.+.}:
       [<c0075f84>] __lock_acquire+0x1694/0x1ce4
       [<c0076de8>] lock_acquire+0xb4/0x154
       [<c03af3cc>] _raw_spin_lock+0x4c/0x5c
       [<c02bbc24>] usb_store_new_id+0x14c/0x1ac
       [<bf007eb4>] new_id_store+0x68/0x70 [usbserial]
       [<c025f568>] drv_attr_store+0x30/0x3c
       [<c01690e0>] sysfs_kf_write+0x5c/0x60
       [<c01682c0>] kernfs_fop_write+0xd4/0x194
       [<c010881c>] vfs_write+0xbc/0x198
       [<c0108e4c>] SyS_write+0x4c/0xa0
       [<c000f880>] ret_fast_syscall+0x0/0x48

-> #0 (s_active#4){++++.+}:
       [<c03a7a28>] print_circular_bug+0x68/0x2f8
       [<c0076218>] __lock_acquire+0x1928/0x1ce4
       [<c0076de8>] lock_acquire+0xb4/0x154
       [<c0166b70>] __kernfs_remove+0x254/0x310
       [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
       [<c0169fb8>] remove_files.isra.1+0x48/0x84
       [<c016a2fc>] sysfs_remove_group+0x58/0xac
       [<c016a414>] sysfs_remove_groups+0x34/0x44
       [<c02623b8>] driver_remove_groups+0x1c/0x20
       [<c0260e9c>] bus_remove_driver+0x3c/0xe4
       [<c026235c>] driver_unregister+0x38/0x58
       [<bf007fb4>] usb_serial_bus_deregister+0x84/0x88 [usbserial]
       [<bf004db4>] usb_serial_deregister+0x6c/0x78 [usbserial]
       [<bf005330>] usb_serial_deregister_drivers+0x2c/0x4c [usbserial]
       [<bf016618>] usb_serial_module_exit+0x14/0x1c [sierra]
       [<c009d6cc>] SyS_delete_module+0x184/0x210
       [<c000f880>] ret_fast_syscall+0x0/0x48

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(table_lock);
                               lock(s_active#4);
                               lock(table_lock);
  lock(s_active#4);

 *** DEADLOCK ***

1 lock held by modprobe/190:
 #0:  (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]

stack backtrace:
CPU: 0 PID: 190 Comm: modprobe Tainted: G        W     3.15.0-rc2 #123
[<c0015e10>] (unwind_backtrace) from [<c0013728>] (show_stack+0x20/0x24)
[<c0013728>] (show_stack) from [<c03a9a54>] (dump_stack+0x24/0x28)
[<c03a9a54>] (dump_stack) from [<c03a7cac>] (print_circular_bug+0x2ec/0x2f8)
[<c03a7cac>] (print_circular_bug) from [<c0076218>] (__lock_acquire+0x1928/0x1ce4)
[<c0076218>] (__lock_acquire) from [<c0076de8>] (lock_acquire+0xb4/0x154)
[<c0076de8>] (lock_acquire) from [<c0166b70>] (__kernfs_remove+0x254/0x310)
[<c0166b70>] (__kernfs_remove) from [<c0167aa0>] (kernfs_remove_by_name_ns+0x4c/0x94)
[<c0167aa0>] (kernfs_remove_by_name_ns) from [<c0169fb8>] (remove_files.isra.1+0x48/0x84)
[<c0169fb8>] (remove_files.isra.1) from [<c016a2fc>] (sysfs_remove_group+0x58/0xac)
[<c016a2fc>] (sysfs_remove_group) from [<c016a414>] (sysfs_remove_groups+0x34/0x44)
[<c016a414>] (sysfs_remove_groups) from [<c02623b8>] (driver_remove_groups+0x1c/0x20)
[<c02623b8>] (driver_remove_groups) from [<c0260e9c>] (bus_remove_driver+0x3c/0xe4)
[<c0260e9c>] (bus_remove_driver) from [<c026235c>] (driver_unregister+0x38/0x58)
[<c026235c>] (driver_unregister) from [<bf007fb4>] (usb_serial_bus_deregister+0x84/0x88 [usbserial])
[<bf007fb4>] (usb_serial_bus_deregister [usbserial]) from [<bf004db4>] (usb_serial_deregister+0x6c/0x78 [usbserial])
[<bf004db4>] (usb_serial_deregister [usbserial]) from [<bf005330>] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial])
[<bf005330>] (usb_serial_deregister_drivers [usbserial]) from [<bf016618>] (usb_serial_module_exit+0x14/0x1c [sierra])
[<bf016618>] (usb_serial_module_exit [sierra]) from [<c009d6cc>] (SyS_delete_module+0x184/0x210)
[<c009d6cc>] (SyS_delete_module) from [<c000f880>] (ret_fast_syscall+0x0/0x48)
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If no valid CHID value has previously been set on an HWA, writing a
value of all zeros will cause a kernel panic in uwb_radio_stop because
wusbhc->uwb_rc has not been set.  This patch skips the call to
uwb_radio_stop if wusbhc->uwb_rc has not been initialized.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Nesting a spin_lock_irq/unlock_irq inside a lock that has already
disabled interrupts will enable interrupts before we are ready when
spin_unlock_irq is called.  This patch converts the inner lock to use
spin_lock and spin_unlock instead.
Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w=2

For external PHY (like ulpi), it needs to configure portsc.pts before
visit viewport, or the viewport can't be visited. so phy_phymode_configure
needs to be called before usb_phy_init.
See: cd0b42c2

It may not the best solution, but it can work for all situations.

Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Cc: shc_work@mail.ru
Cc: denis@eukrea.com
Cc: festevam@gmail.com
Cc: stable <stable@vger.kernel.org> # 3.14
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Tests have shown that when a power-up transition is followed by other
PHY operations too quickly, the USB port appears dead. Waiting 1ms fixes
this problem.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Cc: stable@vger.kernel.org [3.14]
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch reduce unecessary NETTX softirq call caused by
free skb header. You will see this softirq comes twice while
there is only one TX packet to be transmitted.

So using dev_kfree_skb() instead of dev_kfree_skb_any() to
avoid this problem.

Cc: David S. Miller <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NMacpaul Lin <macpaul@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This reverts commit 716fb91d.

That commit caused a regression which would end up in a kernel
BUG() as below:

[  101.554300] g_ether gadget: full-speed config #1: CDC Subset/SAFE
[  101.585186] ------------[ cut here ]------------
[  101.600587] kernel BUG at include/linux/netdevice.h:495!
[  101.615850] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
[  101.645539] Modules linked in:
[  101.660483] CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1+ #104
[  101.690175] task: c05dc5c8 ti: c05d2000 task.ti: c05d2000
[  101.705579] PC is at eth_start+0x64/0x8c
[  101.720981] LR is at __netif_schedule+0x7c/0x90
[  101.736455] pc : [<c0299174>]    lr : [<c036a134>]    psr: 60000093
[  101.736455] sp : c05d3d18  ip : c05d3cf8  fp : c05d3d2c
[  101.782340] r10: 00000000  r9 : c196c1f0  r8 : c196c1a0
[  101.797823] r7 : 00000000  r6 : 00000002  r5 : c1976400  r4 : c1976400
[  101.828058] r3 : 00000000  r2 : c05d3ce8  r1 : 00000001  r0 : 00000002
[  101.858722] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel
Reported-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-of-by: NFelipe Balbi <balbi@ti.com>

This fix the fsl usb gadget driver in a way that the usb device
will be only "pulled up" on requests only when vbus is powered
Signed-off-by: NSuresh Gupta <suresh.gupta@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There are also two allocations with GFP_KERNEL in the pre-/post_reset
code paths. That is no good because that is a part of the SCSI error handler.
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

intfdata is set only after scsi_scan(). uas_pre_reset() however
needs intfdata to be valid and will follow the NULL pointer
killing khubd. intfdata must be preemptively set before the
host is registered and undone in the error case.
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Quote Dan:

The patch e36e6493: "uas: Use GFP_NOIO rather then GFP_ATOMIC
where possible" from Nov 7, 2013, leads to the following static
checker warning:

        drivers/usb/storage/uas.c:806 uas_eh_task_mgmt()
        error: scheduling with locks held: 'spin_lock:lock'

Some other allocations under spinlock are not caught.
The fix essentially reverts e36e6493Signed-off-by: NOliver Neukum <oliver@neukum.org>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

By specifying NO_UNION_NORMAL the ACM driver does only use the first two
USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA
interfaces are left to the USB serial driver.
Signed-off-by: NMichael Ulbricht <michael.ulbricht@systec-electronic.com>
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Power control of hub ports target the CLEAR_FEATURE and SET_FEATURE
requests to ports, not to the hub. Fix the hub control function to
detect the request correctly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ret variable is not initialized in all code paths of the
ohci_jz4740_hub_control function. Fix it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To avoid memory fetch underflows with larger USB transfers, Tegra SoCs
need txfill_tuning's txfifothresh register field set to a non-default
value. Add a custom reset override in order to set this up.

These values are recommended practice for all Tegra chips. However,
I've only noticed practical problems when not setting them this way on
systems using Tegra124. Hence, CC: stable only for recent kernels which
actually support Tegra124.

Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Patch 'b8efdafb USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather should return immediately to avoid
powering down the essential things, like phy.
Signed-off-by: NVivek Gautam <gautam.vivek@samsung.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Patch 'b8efdafb USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather should return immediately to avoid
powering down the essential things, like phy.
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>

The code in hcd-pci.c that matches up EHCI controllers with their
companion UHCI or OHCI controllers assumes that the private drvdata
fields don't get set too early.  However, it turns out that this field
gets set by usb_create_hcd(), before hcd-pci expects it, and this can
result in a crash when two controllers are probed in parallel (as can
happen when a new controller card is hotplugged).

The companions_rwsem lock was supposed to prevent this sort of thing,
but usb_create_hcd() is called outside the scope of the rwsem.

A simple solution is to check that the root-hub pointer has been
initialized as well as the drvdata field.  This doesn't happen until
usb_add_hcd() is called; that call and the check are both protected by
the rwsem.

This patch should be applied to stable kernels from 3.10 onward.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NStefani Seibold <stefani@seibold.net>
Tested-by: NStefani Seibold <stefani@seibold.net>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If acm_submit_read_urbs() fails in acm_port_activate(), error handling
code calls usb_autopm_put_interface() while it is already called
before acm_submit_read_urbs(). The patch reorganizes error handling code
to avoid double decrement of USB interface's PM-usage counter.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

%s/addresssed/addressed
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix regression introduced by commit 8e493ca1 ("USB: usb_wwan: fix
bulk-urb allocation") by making sure to require both bulk-in and out
endpoints during port probe.

The original option driver (which usb_wwan is based on) was written
under the assumption that either endpoint could be missing, but
evidently this cannot have been tested properly. Specifically, it would
handle opening a device without bulk-in (but would blow up during resume
which was implemented later), but not a missing bulk-out in write()
(although it is handled in some places such as write_room()).

Fortunately (?), the driver also got the test for missing endpoints
wrong so the urbs were in fact always allocated, although they would be
initialised using the wrong endpoint address (0) and any submission of
such an urb would fail.

The commit mentioned above fixed the test for missing endpoints but
thereby exposed the other bugs which would now generate null-pointer
exceptions rather than failed urb submissions.

The regression was introduced in v3.7, but the offending commit was also
marked for stable.
Reported-by: NRafał Miłecki <zajec5@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Tested-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays:

LD960: 03f0:0B39
LCM220: 03f0:3139
LCM960: 03f0:3239

[ Johan: fix indentation and sort PIDs numerically ]
Signed-off-by: NAaron Sanders <aaron.sanders@hp.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NTristan Bruns <tristan@tristanbruns.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

option driver, added VID/PID for Telit UE910v2 modem
Signed-off-by: NDaniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 1ebca9da.

This device was erroneously added to the sierra driver even though it's
not a Sierra device and was already handled by the option driver.

Cc: Richard Farina <sidhayn@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Custom VID/PIDs for Brainboxes cards as reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1071914Signed-off-by: NMichele Baldessari <michele@acksyn.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

ffs_epfile_io() is called from userspace, while ffs_func_eps_disable() might be
called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile->ep would be removed by
ffs_func_eps_disable() during ffs_epfile_io() is referring this pointer, then
it leads to kernel PANIC.

The scenario is as below:

Thread 1                                 Thread 2
   |                                        |
SyS_read                             dwc3_gadget_disconnect_interrupt
   |                                        |
ffs_epfile_read                         reset_config
   |                                        |
ffs_epfile_io                       ffs_func_eps_disable
   |                                        |
 -----                      usb_ep_disable():  epfile->ep->ep->desc = NULL
   |                                        |
usb_ep_align_maybe():                     -----
it refers ep->desc->wMaxPacketSize        -----
Signed-off-by: NChao Bi <chao.bi@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case we found a matching USB PHY in usb_get_phy() but the call to
try_module_get() fails, we shouldn't return a (probably soon dangling)
pointer but an ERR_PTR instead.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Include "u_rndis.h" in order to fix the following sparse warning:

drivers/usb/gadget/rndis.c:1144:5: warning: symbol 'rndis_init' was not declared. Should it be static?
drivers/usb/gadget/rndis.c:1177:6: warning: symbol 'rndis_exit' was not declared. Should it be static?
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

completion in udc_controller->done should be assign with proper
value before complete called. The complete called in fsl_udc_release
which intern called from usb_del_gadget_udc, so moving assignment
before calling usb_del_gadget_udc
Signed-off-by: NSuresh Gupta <suresh.gupta@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When the platform initialization fails due to missing resources, it will
return -EPROBE_DEFER after dsps_musb_init() has been called.

dsps_musb_init() calls dsps_musb_dbg_init() to allocate the debugfs
nodes. At a later point in time, the probe will be retried, and
dsps_musb_dbg_init() will be called again. debugfs_create_dir() will
fail this time, as the node already exists, and so the entire device
probe will fail with -ENOMEM.

Fix this by moving debugfs_remove_recursive() from dsps_remove() to the
plaform's exit function, so it will be cleanly torn down when the probe
fails. It also feels more natural this way, as .exit is the counterpart
to .init.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Otherwise the value from the last probe would be retained that possibly is
freed since (the UDC is removed) and therefore no longer relevant. Reproducible
with the dummy UDC:

  modprobe dummy_hcd
  mount -t gadgetfs gadgetfs /dev/gadget
  umount /dev/gadget
  rmmod dummy_hcd
  mount -t gadgetfs gadgetfs /dev/gadget

BUG: unable to handle kernel paging request at ffffffffa066fd9d
Call Trace:
 [<ffffffff811d0cd2>] ? d_alloc_name+0x22/0x50
 [<ffffffff812b74dc>] ? selinux_d_instantiate+0x1c/0x20
 [<ffffffffa067d687>] gadgetfs_create_file+0x27/0xa0 [gadgetfs]
 [<ffffffffa067da70>] ? setup_req.isra.4+0x80/0x80 [gadgetfs]
 [<ffffffffa067dbac>] gadgetfs_fill_super+0x13c/0x180 [gadgetfs]
 [<ffffffff811bc832>] mount_single+0x92/0xc0
 [<ffffffffa067d0f8>] gadgetfs_mount+0x18/0x20 [gadgetfs]
 [<ffffffff811bc8f9>] mount_fs+0x39/0x1b0
 [<ffffffff8116b220>] ? __alloc_percpu+0x10/0x20
 [<ffffffff811d6da3>] vfs_kern_mount+0x63/0xf0
 [<ffffffff811d93be>] do_mount+0x23e/0xac0
 [<ffffffff811660eb>] ? strndup_user+0x4b/0xf0
 [<ffffffff811d9f63>] SyS_mount+0x83/0xc0
 [<ffffffff81695b69>] system_call_fastpath+0x16/0x1b
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

During system resume, if the event buffers are not setup before
the gadget controller starts then we start with invalid context
and this can lead to bus access errors. This is especially true for
platforms that loose the controller context during system suspend.
e.g. AM437x.

The following backtrace was found when the system is suspended
and resumed with g_zero loaded on AM437x-evm (USB cable connected
to host all the while).

[  120.981506] WARNING: CPU: 0 PID: 1656 at drivers/bus/omap_l3_noc.c:137 l3_interrupt_handler+0x198/0x28c()
[  120.981514] L3 custom error: MASTER:USB0 WR TARGET:GPMC
[  120.981638] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite configfs bufferclass_ti(O) omaplfb(O) cryptodev(O) dwc3 snd_soc_evm snd_soc_omap snd_pe
[  120.981659] CPU: 0 PID: 1656 Comm: sh Tainted: G           O 3.12.10-gc559824 #1
[  120.981669] Backtrace:
[  120.981705] [<c0017880>] (dump_backtrace+0x0/0x10c) from [<c0017a1c>] (show_stack+0x18/0x1c)
[  120.981730]  r6:c02819ac r5:00000009 r4:ec137cb8 r3:00000000
[  120.981767] [<c0017a04>] (show_stack+0x0/0x1c) from [<c056c0b0>] (dump_stack+0x20/0x28)
[  120.981802] [<c056c090>] (dump_stack+0x0/0x28) from [<c0046d08>] (warn_slowpath_common+0x70/0x90)
[  120.981830] [<c0046c98>] (warn_slowpath_common+0x0/0x90) from [<c0046dcc>] (warn_slowpath_fmt+0x38/0x40)
[  120.981856]  r8:c0855eb0 r7:00000002 r6:f1000700 r5:00000007 r4:80080003
[  120.981886] [<c0046d94>] (warn_slowpath_fmt+0x0/0x40) from [<c02819ac>] (l3_interrupt_handler+0x198/0x28c)
[  120.981900]  r3:c0801ab8 r2:c06cb354
[  120.981936] [<c0281814>] (l3_interrupt_handler+0x0/0x28c) from [<c007162c>] (handle_irq_event_percpu+0x54/0x1b8)
[  120.981962] [<c00715d8>] (handle_irq_event_percpu+0x0/0x1b8) from [<c00717c0>] (handle_irq_event+0x30/0x40)
[  120.981993] [<c0071790>] (handle_irq_event+0x0/0x40) from [<c0074058>] (handle_fasteoi_irq+0x74/0x128)
[  120.982006]  r4:ed0056c0 r3:00000000
[  120.982033] [<c0073fe4>] (handle_fasteoi_irq+0x0/0x128) from [<c0070f34>] (generic_handle_irq+0x28/0x38)
[  120.982046]  r4:0000002a r3:c0073fe4
[  120.982085] [<c0070f0c>] (generic_handle_irq+0x0/0x38) from [<c0015560>] (handle_IRQ+0x38/0x8c)
[  120.982098]  r4:c080137c r3:00000182
[  120.982124] [<c0015528>] (handle_IRQ+0x0/0x8c) from [<c00087e0>] (gic_handle_irq+0x30/0x5c)
[  120.982145]  r6:ec137dd0 r5:c07ac480 r4:fa24010c r3:00000100
[  120.982169] [<c00087b0>] (gic_handle_irq+0x0/0x5c) from [<c056fcc0>] (__irq_svc+0x40/0x54)
[  120.982179] Exception stack(0xec137dd0 to 0xec137e18)
[  120.982195] 7dc0:                                     00000000 a00001d3 00000000 00000004
[  120.982216] 7de0: a0000153 ec1d9010 c080de90 ec137e30 c080debc 00000000 ed756e44 ec137e2c
[  120.982232] 7e00: ec137de0 ec137e18 bf1150e4 bf115474 60000153 ffffffff
[  120.982253]  r7:ec137e04 r6:ffffffff r5:60000153 r4:bf115474
[  120.982327] [<bf115438>] (dwc3_complete+0x0/0x40 [dwc3]) from [<c0338f50>] (dpm_complete+0xd4/0x19c)
[  120.982341]  r5:ed756e10 r4:ed756e64
[  120.982370] [<c0338e7c>] (dpm_complete+0x0/0x19c) from [<c0339034>] (dpm_resume_end+0x1c/0x20)
[  120.982400] [<c0339018>] (dpm_resume_end+0x0/0x20) from [<c006d4ec>] (suspend_devices_and_enter+0x118/0x33c)
[  120.982412]  r4:c0833da4 r3:00000000
[  120.982436] [<c006d3d4>] (suspend_devices_and_enter+0x0/0x33c) from [<c006d928>] (pm_suspend+0x218/0x254)
[  120.982458] [<c006d710>] (pm_suspend+0x0/0x254) from [<c006c594>] (state_store+0x70/0xc0)
[  120.982478]  r6:c057a6cc r5:c06a8320 r4:00000003 r3:0000006d
[  120.982515] [<c006c524>] (state_store+0x0/0xc0) from [<c0264cc0>] (kobj_attr_store+0x1c/0x28)
[  120.982546] [<c0264ca4>] (kobj_attr_store+0x0/0x28) from [<c012ccb8>] (sysfs_write_file+0x170/0x1a4)
[  120.982583] [<c012cb48>] (sysfs_write_file+0x0/0x1a4) from [<c00d17e4>] (vfs_write+0xb8/0x190)
[  120.982611] [<c00d172c>] (vfs_write+0x0/0x190) from [<c00d1bf8>] (SyS_write+0x44/0x78)
[  120.982641] [<c00d1bb4>] (SyS_write+0x0/0x78) from [<c0014660>] (ret_fast_syscall+0x0/0x30)
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It was impossible to enumerate on a SuperSpeed (XHCI) host
with alternate setting = 1 due to the wrongly set 'bMaxBurst'
field in the SuperSpeed Endpoint Companion descriptor.

Testcase:
<host> modprobe -r usbtest; modprobe usbtest alt=1
<device> modprobe g_zero
plug device to SuperSpeed port on the host.

Without this patch the host always complains like so
"usb 12-2: Not enough bandwidth for new device state.
 usb 12-2: Not enough bandwidth for altsetting 1"

Bug was introduced by commit cf9a08ae in v3.9

Fixes: cf9a08ae (usb: gadget: convert source sink and loopback to
new function interface)

Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Make dwc3_gadget_resize_tx_fifos() iterate only over IN
endpoints that are actually present, based on the
num_in_eps parameter. This terminates the loop so as to
prevent dereferencing a potential NULL dwc->eps[i] where
i >= (num_in_eps + num_out_eps).
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

on early initialization we could fall into
a situation where the mailbox is called before
MUSB's clocks are running, in order to avoid
that, make sure mailbox is always wrapped with
pm_runtime calls.
Reported-by: NStefan Roese <sr@denx.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

commi 30a70b02 (usb: musb: fix obex in g_nokia.ko
causing kernel panic) removed phy_power_on()
and phy_power_off() calls from runtime PM callbacks
but it failed to note that the driver depended
on pm_runtime_get_sync() calls to power up the PHY,
thus leaving some platforms without any means to
have a working PHY.

Fix that by enabling the phy during omap2430_musb_init()
and killing it in omap2430_musb_exit().

Fixes: 30a70b02 (usb: musb: fix obex in g_nokia.ko causing kernel panic)
Cc: <stable@vger.kernel.org> # v3.14
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Reported-by: NMichael Scott <hashcode0f@gmail.com>
Tested-by: NMichael Scott <hashcode0f@gmail.com>
Tested-by: NStefan Roese <sr@denx.de>
Reported-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In order to support local WRITE_INSERT + READ_STRIP operations for
non PI enabled fabrics, the fabric driver needs to be able signal
what protection offload operations are supported.

This is done at session initialization time so the modes can be
signaled by individual se_wwn + se_portal_group endpoints, as well
as optionally across different transports on the same endpoint.

For iser-target, set TARGET_PROT_ALL if the underlying ib_device
has already signaled PI offload support, and allow this to be
exposed via a new iscsit_transport->iscsit_get_sup_prot_ops()
callback.

For loopback, set TARGET_PROT_ALL to signal SCSI initiator mode
operation.

For all other drivers, set TARGET_PROT_NORMAL to disable fabric
level PI.

Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Now that TASK_ABORTED status is not generated for all cases by
TMR ABORT_TASK + LUN_RESET, a new TFO->abort_task() caller is
necessary in order to give fabric drivers a chance to unmap
hardware / software resources before the se_cmd descriptor is
released via the normal TFO->release_cmd() codepath.

This patch adds TFO->aborted_task() in core_tmr_abort_task()
in place of the original transport_send_task_abort(), and
also updates all fabric drivers to implement this caller.

The fabric drivers that include changes to perform cleanup
via ->aborted_task() are:

  - iscsi-target
  - iser-target
  - srpt
  - tcm_qla2xxx

The fabric drivers that currently set ->aborted_task() to
NOPs are:

  - loopback
  - tcm_fc
  - usb-gadget
  - sbp-target
  - vhost-scsi

For the latter five, there appears to be no additional cleanup
required before invoking TFO->release_cmd() to release the
se_cmd descriptor.

v2 changes:
  - Move ->aborted_task() call into transport_cmd_finish_abort (Alex)

Cc: Alex Leung <amleung21@yahoo.com>
Cc: Mark Rustad <mark.d.rustad@intel.com>
Cc: Roland Dreier <roland@kernel.org>
Cc: Vu Pham <vu@mellanox.com>
Cc: Chris Boot <bootc@bootc.net>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Cc: Saurav Kashyap <saurav.kashyap@qlogic.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

The USB_QUIRK_RESET flag indicates that a USB device changes its
identity in some way when it is reset.  It may lose its firmware, its
descriptors may change, or it may switch back to a default mode of
operation.

If a device does this, the kernel needs to avoid resetting it.  Resets
are likely to fail, or worse, succeed while changing the device's
state in a way the system can't detect.

This means we should disable the reset-resume mechanism whenever this
quirk flag is present.  An attempted reset-resume will fail, the
device will be logically disconnected, and later on the hub driver
will rediscover and re-enumerate the device.  This will cause the
appropriate udev events to be generated, so that userspace will have a
chance to switch the device into its normal operating mode, if
necessary.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>