After commit b09b5224 ("usb: chipidea: implement platform shutdown
callback") and commit 43a40457 ("usb: chipidea: host: set host to
be null after hcd is freed") a NULL pointer dereference is caused
on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and
we finish interrupt handling before the hcd is deallocated. This avoids
the NULL pointer dereference.
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Fixes: b09b5224 ("usb: chipidea: implement platform shutdown callback")
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Since the controller on R-Car Gen3 doesn't have any status registers
to detect initialization (LPSTS.SUSPM = 1) and the initialization needs
up to 45 usec, this patch adds wait after the initialization. Otherwise,
writing other registers (e.g. INTENB0) will fail.

Fixes: de18757e ("usb: renesas_usbhs: add R-Car Gen3 power control")
Cc: <stable@vger.kernel.org> # v4.6+
Cc: <balbi@kernel.org>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"
Signed-off-by: NBryan Paluch <bryanpaluch@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we're booting pandaboard using NFSroot over built-in g_ether, we
can get the following after booting once and doing a warm reset:

g_ether gadget: ecm_open
g_ether gadget: notify connect true
...
WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x220/0x34c
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read):
Data Access in User mode du ring Functional access
...

Fix the issue by calling pm_runtime functions from
musb_gadget_queue.

Note that in the long run we should be able to queue the pending
transfers if pm_runtime is not active, and flush the queue from
pm_runtime_resume.
Reported-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we configure musb with 2430 glue as a peripheral, and then rmmod
omap2430 module, we'll get the following error:

[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
...
rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
 (&phy->mutex){+.+.+.}, at: [<c04b9fd0>] phy_power_off+0x1c/0xb8
[  204.678710]
               and this task is already holding:
 (&(&musb->lock)->rlock){-.-...}, at: [<bf3a482c>]
 musb_gadget_stop+0x24/0xec [musb_hdrc]
which would create a new lock dependency:
 (&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.}
...

This is because some glue layers expect musb_platform_enable/disable
to be called with spinlock held, and 2430 glue layer has USB PHY on
the I2C bus using a mutex.

We could fix the glue layers to take the spinlock, but we still have
a problem of musb_plaform_enable/disable being called in an unbalanced
manner. So that would still lead into USB PHY enable/disable related
problems for omap2430 glue layer.

While it makes sense to only enable USB PHY when needed from PM point
of view, in this case we just can't do it yet without breaking things.
So let's just revert phy_enable/disable related changes instead and
reconsider this after we have fixed musb_platform_enable/disable to
be balanced.

Fixes: a83e17d0 ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer")
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
needs to handle 4 reset lines for EHCI.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The reset value of RWC is 0, set RemoteWakeupConnected bit explicitly
before calling ohci_run, it also fixes the issue that the mass
storage stick connected wasn't suspended when the system suspend.
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure we have at least one port before attempting to register a
console.

Currently, at least one driver binds to a "dummy" interface and requests
zero ports for it. Should such an interface also lack endpoints, we get
a NULL-deref during probe.

Fixes: e5b1e206 ("USB: serial: make minor allocation dynamic")
Cc: stable <stable@vger.kernel.org>	# 3.11
Signed-off-by: NJohan Hovold <johan@kernel.org>

USB2 host inititated resume, and system suspend bus resume
need to use the same USB_RESUME_TIMEOUT as elsewhere.

This resolves a device disconnect issue at system resume seen
on Intel Braswell and Apollolake, but is in no way limited to
those platforms.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If a device is unplugged and replugged during Sx system suspend
some  Intel xHC hosts will overwrite the CAS (Cold attach status) flag
and no device connection is noticed in resume.

A device in this state can be identified in resume if its link state
is in polling or compliance mode, and the current connect status is 0.
A device in this state needs to be warm reset.

Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8

Observed on Cherryview and Apollolake as they go into compliance mode
if LFPS times out during polling, and re-plugged devices are not
discovered at resume.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the
same quirks to prevent machines from spurious restart while
shutting them down.
Reported-by: NHasan Mahmood <hasan.mahm@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current tiocmget implementation would fail to report errors up the
stack and instead leaked a few bits from the stack as a mask of
modem-status flags.

Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Fix to return error code -ENOMEM from the kmalloc() error handling
case instead of 0, as done elsewhere in this function.

Fixes: a19b882c ("wusb: Stop using the stack for sg crypto scratch space")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit aa381a72 ("usb: dwc2: gadget: fix TX FIFO size
and address initialization").

The original commit removed the FIFO size programming per endpoint. The
DPTXFSIZn register is also used for DIEPTXFn and the SIZE field is r/w
in dedicated fifo mode. So it isn't appropriate to simply remove this
initialization as it might break existing behavior.

Also, some cores might not have enough fifo space to handle the
programming method used in the reverted patch, resulting in fifo
initialization failure.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Cc: Robert Baldyga <r.baldyga@samsung.com>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This reverts commit ba48eab8 ("usb: dwc2: gadget: change variable
name to more meaningful").

This is needed to cleanly revert commit aa381a72 ("usb: dwc2:
gadget: fix TX FIFO size and address initialization") which may cause
regressions on some platforms.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Cc: Robert Baldyga <r.baldyga@samsung.com>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This adds support to ftdi_sio for the Infineon TriBoard TC2X7
engineering board for first-generation Aurix SoCs with Tricore CPUs.
Mere addition of the device IDs does the job.
Signed-off-by: NStefan Tauner <stefan.tauner@technikum-wien.at>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Pointing an sg list at the stack is verboten and, with
CONFIG_VMAP_STACK=y, will malfunction.  Use kmalloc for the wusb
crypto stack space instead.

Untested -- I'm not entirely convinced that this hardware exists in
the wild.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In commit 2abd9d5f ("usb: dwc3: ep0: Add chained TRB support"), the
size of the memory allocated with 'dma_alloc_coherent()' has been modified
but the corresponding calls to 'dma_free_coherent()' have not been updated
accordingly.

This has been spotted with coccinelle, using the following script:
////////////////////
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@

*   ret = dma_alloc_coherent(x0, y0, z0, t0);
    ...
*   dma_free_coherent(x1, y1, ret, t1);

@script:python@
y0 << r.y0;
y1 << r.y1;

@@
if y1.find(y0) == -1:
 print "WARNING: sizes look different:  '%s'   vs   '%s'" % (y0, y1)
////////////////////

Fixes: 2abd9d5f ("usb: dwc3: ep0: Add chained TRB support")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

ffs_func_eps_disable is called from atomic context so it cannot sleep
thus cannot grab a mutex.  Change the handling of epfile->read_buffer
to use non-sleeping synchronisation method.
Reported-by: NChen Yu <chenyu56@huawei.com>
Signed-off-by: NMichał Nazarewicz <mina86@mina86.com>
Fixes: 9353afbb ("buffer data from ‘oversized’ OUT requests")
Tested-by: NJohn Stultz <john.stultz@linaro.org>
Tested-by: NChen Yu <chenyu56@huawei.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

epfile->ep is protected by ffs->eps_lock (not epfile->mutex) so clear it
while holding the spin lock.
Tested-by: NJohn Stultz <john.stultz@linaro.org>
Tested-by: NChen Yu <chenyu56@huawei.com>
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Although a host-only controller should not have any associated delay,
some rockchip SOC platforms will not show the correct host-values of
registers until after a delay.

So add a 50 ms sleep when in host-only mode.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We cannot pre-start isochronous endpoints because we
rely on the micro-frame number passed via
XferNotReady command for proper Isochronous
scheduling.

Fixes: 08a36b54 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()")
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Some requests could be accounted for multiple
times. Let's fix that so each and every requests is
accounted for only once.

Cc: <stable@vger.kernel.org> # v4.8
Fixes: 55a0237f ("usb: dwc3: gadget: use allocated/queued reqs for LST bit")
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If we don't guarantee that we will always get an
interrupt at least when we're queueing our very last
request, we could fall into situation where we queue
every request with 'no_interrupt' set. This will
cause the link to get stuck.

The behavior above has been triggered with g_ether
and dwc3.

Cc: <stable@vger.kernel.org>
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Since commit c32b5bcf ("ARM: dts: at91: Fix USB endpoint nodes"),
atmel_usba_udc fails with:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
ecm_do_notify+0x188/0x1a0
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
Hardware name: Atmel SAMA5
[<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
[<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
[<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
[<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
[<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
[<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
[<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
[<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
[<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
[<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
[<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
[<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
[<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
[<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
[<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
[<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
[<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
---[ end trace e7cf9dcebf4815a6 ]---

Fixes: c32b5bcf ("ARM: dts: at91: Fix USB endpoint nodes")
Cc: <stable@vger.kernel.org>
Reported-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Kernel source files need not include <linux/kconfig.h> explicitly
because the top Makefile forces to include it with:

  -include $(srctree)/include/linux/kconfig.h

This commit removes explicit includes except the following:

  * arch/s390/include/asm/facilities_src.h
  * tools/testing/radix-tree/linux/kernel.h

These two are used for host programs.

Link: http://lkml.kernel.org/r/1473656164-11929-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The SEAD-3 board is now probing its EHCI controller using the generic
EHCI driver & its generic-ehci device tree binding. Remove the unused
SEAD-3 specific EHCI code.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14052/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This reverts commit e6c7efdc.

Turns out it was totally wrong.  The memory is supposed to be bound to
the kref, as the original code was doing correctly, not the
device/driver binding as the devm_kzalloc() would cause.

This fixes an oops when read would be called after the device was
unbound from the driver.
Reported-by: NLadislav Michl <ladis@linux-mips.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable <stable@vger.kernel.org>  # 3.12+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_time() instead.

CURRENT_TIME is also not y2038 safe.

This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe. As part of the effort current_time() will be
extended to do range checks. Hence, it is necessary for all
file system timestamps to use current_time(). Also,
current_time() will be transitioned along with vfs to be
y2038 safe.

Note that whenever a single call to current_time() is used
to change timestamps in different inodes, it is because they
share the same time granularity.
Signed-off-by: NDeepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NFelipe Balbi <balbi@kernel.org>
Acked-by: NSteven Whitehouse <swhiteho@redhat.com>
Acked-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Acked-by: NDavid Sterba <dsterba@suse.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NKyle Jones <kyle@kf5jwc.us>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to (badf6d47 "usb: common: rework CONFIG_USB_COMMON logic")
we should select USB_COMMON at Kconfig when usb common stuffs are needed,
but some of Kconfig enties have not followed it, update them.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In USB20 specification, describes in chapter 9.4.5: The Remote Wakeup
field can be modified by the SetFeature() and ClearFeature() requests
using the DEVICE_REMOTE_WAKEUP feature selector.

In USB30 specification, also describes in chapter 9.4.5: The Function
Remote Wakeup field can be modified by the SetFeature() requests
using the FUNCTION_SUSPEND feature selector. In chapter 9.4.9 Set
Feature reference, it describes Function Remote Wake Enabled/Disabled
at suspend options by SET_FEATURE.

In USB30 specification only mentioned SetFeature(), so we need use
SET_FEATURE replace CLEAR_FEATURE to disable USB30 function remote
wakeup in suspend options.
Signed-off-by: NYonglong Wu <yonglong.wu@mediatek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the selected USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.

The trigger gets its documentation file but basically it just requires
enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).

There was a long discussion on design of this driver. Its current state
is a result of picking them most adjustable solution as others couldn't
handle all cases.

1) It wasn't possible for the driver to register separated trigger for
   each USB port. Some physical USB ports are handled by more than one
   controller and so by more than one USB port. E.g. USB 2.0 physical
   port may be handled by OHCI's port and EHCI's port.
   It's also not possible to assign more than 1 trigger to a single LED
   and implementing such feature would be tricky due to syncing triggers
   and sysfs conflicts with old triggers.

2) Another idea was to register trigger per USB hub. This wouldn't allow
   handling devices with multiple USB LEDs and controllers (hubs)
   controlling more than 1 physical port. It's common for hubs to have
   few ports and each may have its own LED.

This final trigger is highly flexible. It allows selecting any USB ports
for any LED. It was also modified (comparing to the initial version) to
allow choosing ports rather than having user /guess/ proper names. It
was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
2 physical ports and 3 controllers.

It was noted USB subsystem already has usb-gadget and usb-host triggers
but they are pretty trivial ones. They indicate activity only and can't
have ports specified.

In future it may be good idea to consider adding activity support to
usbport as well. This should allow switching to this more generic driver
and maybe marking old ones as obsolete.
This can be implemented with another sysfs file for setting mode. The
default mode wouldn't change so there won't be ABI breakage and so such
feature can be safely implemented later.

There was also an idea of supporting other devices (PCI, SDIO, etc.) but
as this driver already contains some USB specific code (and will get
more) these should be probably separated drivers (triggers).
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This driver should initialize controller only, PHY initialization should
be handled by separated PHY driver. We already have phy-bcm-ns-usb2 in
place so let it makes its duty.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We get 1 warning when building kernel with W=1:
drivers/usb/core/hcd.c:2390:5: warning: no previous prototype for 'usb_bus_start_enum' [-Wmissing-prototypes]

In fact, these functions are declared in linux/usb/otg.h, so this patch
adds the missing header dependencies.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We print an error message when platform_device_register_full()
fails, but the initialization of the argument has been removed,
as shown in this warning:

drivers/usb/musb/da8xx.c: In function 'da8xx_probe':
drivers/usb/musb/da8xx.c:521:3: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This modifies the function to assign the return code before
checking it, and does uses the same method in the check for
usb_phy_generic_register() as well.

Fixes: 947c49af ("usb: musb: da8xx: Remove mach code")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the session bit based PM runtime working on musb, we've
implemented few quirks to attempt to detect the current state of
the hardware. One of the quirks is for invalid VBUS as peripheral,
but it is not working in all cases.

If we start musb on dm3730 as a peripheral with no cable connected,
we will get the devctl 91 state once and will never idle as there
are not further interrupts from musb. So we need to ignore the first
devctl 91 state as there will be more interrupts if we're connected.

The invalid VBUS state also can happen always when connected to
certain USB hubs. Looks like musb on dm3730 can claim invalid VBUS
with some hubs while 3717-evm and BeagleBone don't. This causes
session as peripheral to fail for dm3730 with some hubs.

This too is fixed by ignoring only the first invalid VBUS. When
connected, we can just look at the session bit as that will clear
automatically when the session ends.

Fixes: 467d5c98 ("usb: musb: Implement session bit based runtime PM for musb-core")
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we unconfigure musb as a USB peripheral with cable connected,
and then remove the cable, no interrupts will happen. And musb
thinks we're still connected keeping the device active.

Now with the session bit based PM runtime working for musb, we
can fix this issue by calling musb irq_work. That rechecks the
devctl register and reconfigures PM runtime based on the devctl.

Fixes: 467d5c98 ("usb: musb: Implement session bit based runtime PM for musb-core")
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Export musb_root_disconnect for use in modules, so that musb glue
code build as module can use it.

This fixes the buildbot errors for -next in arm64-allmodconfig
and arm-allmodconfig.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Fixes: 7cba17ec ("musb: sunxi: Add support for platform_set_mode")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes a NULL pointer dereference caused by a race codition in
the probe function of the legousbtower driver. It re-structures the
probe function to only register the interface after successfully reading
the board's firmware ID.

The probe function does not deregister the usb interface after an error
receiving the devices firmware ID. The device file registered
(/dev/usb/legousbtower%d) may be read/written globally before the probe
function returns. When tower_delete is called in the probe function
(after an r/w has been initiated), core dev structures are deleted while
the file operation functions are still running. If the 0 address is
mappable on the machine, this vulnerability can be used to create a
Local Priviege Escalation exploit via a write-what-where condition by
remapping dev->interrupt_out_buffer in tower_write. A forged USB device
and local program execution would be required for LPE. The USB device
would have to delay the control message in tower_probe and accept
the control urb in tower_open whilst guest code initiated a write to the
device file as tower_delete is called from the error in tower_probe.

This bug has existed since 2003. Patch tested by emulated device.
Reported-by: NJames Patrick-Evans <james@jmp-e.com>
Tested-by: NJames Patrick-Evans <james@jmp-e.com>
Signed-off-by: NJames Patrick-Evans <james@jmp-e.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>