usb: ks_bridge: Synchronize disconnect with ongoing IO

Following scenarios possible for interface disconnect racing
with ongoing IO:-

1) Interface disconnect setting interface pointer to NULL and
rx work is executing on other core dereferencing interface
pointer, causing kernel panic. Cancel a work and wait for it
to finish during disconnect.

2) Interface disconnect setting interface pointer to NULL and
tx completion running on other core dereferencing interface
pointer while calling usb_autopm_put_interface_async() API.
Check for USB_DEV_CONNECTED flag(cleared at the time of
disconnect) before dereferencing the interface pointer.

3) Interface unbound and driver is accessing already freed
interface pointer in tx completion or usb device pointer to
re-submit rx urb in rx completion. Add rx and tx urb pending
counters and wait for them to become zero (or timeout) during
disconnect.

CRs-Fixed: 448142
Change-Id: I50341173b94200bcfa60715b4b26b2117fc37c2c
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
usb: ks_bridge: Free up stale buffers in probe

Driver can add data buffer to the link list of rx/tx
buffers after emptying the list during disconnect.
These stale buffers can confuse efs sync server when
mdm device connects back. Hence free up the rx/tx
buffers again during probe. Avoid further addition of
tx buffers after disconnect by checking device
connection status in write API. Also, move
misc_deregister() after cancelling the work in order
to remove device node early during disconnect to avoid
any write call further.

CRs-Fixed: 448142
Change-Id: Ifff58d2adc113257809eb80b7f91c1a0f4a0adeb
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
USB: ks_bridge: Prevent freeing buffers while copy is in progress

The completed read buffers are added to to_ks_list in Rx URB
completion handler.  The buffer is deleted from this list by
reader process after copying to user space buffer.  If disconnect
happens during this copy, the buffer is freed from disconnect
context.  Hence detach the buffer from to_ks_list before copying
to user space buffer.

CRs-Fixed: 448142
Change-Id: Ia4484b2709065162b0d32782a30e2b2fd36f5fda
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
USB: ks_bridge: Abort suspend when data is received during unlink

All the submitted URBs are unlinked during suspend.  Abort suspend
if data is received during unlink.  This avoids unnecessary suspend
and resume of remaining interfaces.

CRs-Fixed: 449097
Change-Id: Ia4009775ec29df0222b475581649c3a9f4f1899f
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
USB: ks_bridge: Enable autosuspend only for remote wakeup capable devices

USB core marks a device wakeup capable if it supports remote wakeup.
Check this wakeup capable flag before enabling autosuspend.

CRs-Fixed: 449100
Change-Id: I055bf5801859e4d83782916c71e0245c455becbf
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
usb: mdm_bridge: Fix race between disconnect and I/O completion handler

There is a possibility of race between device disconnect and I/O
completion handler. In this case disconnect frees bridge device
memory in thread context and I/O completion handler uses already
freed bridge device memory in interrupt context. Hence allocate
bridge device memory at the time of driver load and free it
during unload. Also, do not anchor interrupt and read urb and
unlink them synchronously to avoid accessing transfer buffers
associated to these urbs when driver disconnect frees them.

Guard the race condition by:-
1) Adding check for usb device disconnect state in the I/O
completion handler to avoid further processing I/O completion.

2) Unlinking tx urbs synchronously since asynchronous unlinking
results in the same race condition.

CRs-Fixed: 447591
Change-Id: Iae4c2a1920c16fcf3e1728144a7cfe6ca66c7705
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
USB: mdm_bridge: Simplify data bridge suspend/resume path

Synchronous runtime PM API is used to increment the PM usage counter
in Tx path.  It means Tx data path will not race with interface suspend.
Remove "delayed" anchor which is meant for Tx requests, that are arrived
during suspend.  There is no point in distinguishing auto suspend and
system wide suspend.  Abort suspend when we have pending Tx URBs.

CRs-Fixed: 451414
Change-Id: I302b120ccecfe30db1ebd2b1fcd9945a3675cf83
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
USB: mdm_bridge: Fix control bridge suspend

The current code does not abort suspend when there are pending URBs.
They are simply killed during suspend. This may lead to QMI stall.
Add proper checks to ensure that there is no pending Tx/Rx data
during suspend.  Clear the "SUSPENDED" flag in resume only after
taking out all the URBs from "tx_deferred" anchor.

CRs-Fixed: 451414
Change-Id: Icc48afc5eeedcc126d0ab1bec951bde4a53ac165
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
net: usb: Prevent suspend if response available notification received

cherry picked from 148c5323330bf41890392fe23e8983612ecb3580

There is a possibility of interface suspend after receiving response
available notification from mdm device. In this case driver unlinks
the rx urb and do not send GET_ENCAPSULATED_RESPONSE setup packet to
mdm. Response to mdm gets delayed up until interface resumes and mdm
sends response available notification again. Hence resume interface
after receiving response available notification if it is suspended.
Allow interface suspend only after completing
GET_ENCAPSULATED_RESPONSE.

Change-Id: Ib52e64b1cc7b6d5edfe3ada9651ec56526cf4852
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
usbnet: decrease suspend count if returning -EBUSY for runtime suspend

From commit 5eeb3132eb4c5e9ca92e5247fe4575fe9f8c3efe upstream.

This patch decreases dev->suspend_count in the -EBUSY failure path
of usbnet_suspend. Without the change, the later runtime suspend
will do nothing except for increasing dev->suspend_count.

CRs-Fixed: 404339
Change-Id: I5e1cbd39e4469150de7cc98af9517a4dbdc80780
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
net: usb: Fix memory leak on Tx data path

Cherry picked from 673e1f276a71065638da2dd7f431b630e9d414f4

Driver anchors the tx urbs and defers the urb submission if
a transmit request comes when the interface is suspended.
Anchoring urb increments the urb reference count. These
deferred urbs are later accessed by calling usb_get_from_anchor()
for submission during interface resume. usb_get_from_anchor()
unanchors the urb but urb reference count remains same.
This causes the urb reference count to remain non-zero
after usb_free_urb() gets called and urb never gets freed.
Hence call usb_put_urb() after anchoring the urb to properly
balance the reference count for these deferred urbs. Also,
unanchor these deferred urbs during disconnect, to free them
up.

CRs-Fixed: 408145
Change-Id: If37b2f63da4ed20796cc8f3be6e64d15149c6cea
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
net: usb: Abort suspend if get_encap response is not sent

Cherry picked from 9a8280fab6030abef96ca835ef88f92926ca88bb

After receiving response available notification driver queues
a work to send get_encap response. pm state is set to
RPM_SUSPENDING before interface suspend is initiated. If
interface suspend happens after queuing the work then work
will be executed and blocked until it is done. Work tries to
resume the interface synchronously by calling rpm_resume().
This causes rpm_resume() to wait indefinitely for the pm state
to change from RPM_SUSPENDED to RPM_RESUME which will not
happen until interface suspend returns EBUSY. Hence avoid this
situation by aborting interface suspend if work is pending
or running.

CRs-Fixed: 415208
Change-Id: Ib2a079a7107d994f760c0a876736ede3add07ea2
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
net: rmnet_ctrl_usb: Block file close until tx URBs are transmitted

Cherry picked from 16599ec35c3bc8965eb26d33cac044518df88c73

Rmnet control driver is directly killing tx URBs submitted to HSIC
HW if userspace closes the file. When a file is close, all pending
data needs to get flushed. Hence wait for the pending tx URBs to
finish transfer with a timeout before file close. This will complete
all the pending transfers gracefully on tx path so that mdm device
does not miss any control channel information upon file close.

Change-Id: I70942391056e57b0f6dd2cd5c16be2654759eabd
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
net: usb: Handle interface suspend properly

Cherry picked from c4659d9c5264b569e06c7d5f5a807ce6c3ad47c9

Upon interface suspend driver performs suspend on data channel
first and then on control channel. In case if suspend aborts
due to pending transfer on control channel, driver is not
undoing data channel suspend. This causes stall on data channel.
Fix the problem by performing suspend check on control channel
first. In this case if suspend aborts on control channel, driver
does not have to undo anything to abort interface suspend. Once
data channel suspend succeeds driver performs suspend on control
channel.

Change-Id: I405b4797740e1b2aa67c6c28a2f3dcee0c196391
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
usbnet: ratelimit kevent may have been dropped warnings

From commit 9532021da6da48351ce48a079c673df8e3930b4a upstream.

when something goes wrong, a flood of these messages can be
generated by usbnet (thousands per second).  This doesn't
generally *help* the condition so this patch ratelimits the
rate of their generation.

There's an underlying problem in usbnet's kevent deferral
mechanism which needs fixing, specifically that events *can*
get dropped and not handled.  This patch doesn't address this,
but just mitigates fallout caused by the current implemention.

CRs-Fixed: 430579
Change-Id: I708632185ca0b310c4082cab3571a2d6552bf135
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
EHCI: HSIC: Handle asynchronous interrupt properly

Runtime PM resume and asynchronous interrupt can run in parallel. When
this happens, there is a possibility of PM usage counter mismatch.
Fix this by checking the return value of pm_runtime_get() and by
disabling the USB interrupt while resuming the HSIC.

Consider asynchronous interrupt case when resuming HSIC during system
resume.

CRs-Fixed: 444883
Change-Id: I63db49d8b45a7413f9456a93c9648511ad622b4b
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
EHCI: HSIC: Disable asynchronous interrupt when wakeup gpio is present

Controller can generate interrupt asynchronously in low power mode (LPM).
Enable this interrupt in USBCMD register only when wakeup gpio IRQ is
not available.

CRs-Fixed: 444883
Change-Id: I05258feb9476d1373d30645f6c750923589aa1cb
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
EHCI: HSIC: Implement new reset sequence to workaround PHY lockup issue

commit 8e6edcb (usb: ehci: Avoid phy lockup due to SOFs during port
reset) implements a workaround for PHY lockup issue during port reset.
The workaround relies on a hardware debug feature which allows driving
strobe and data lines to reset using ULPI interface.  This is not
working some times for unknown reason.

This patch implements a new reset sequence to workaround the PHY lockup
issue.  The controller drive reset signaling for ~50 msec when reset bit
is set in PORTSC register.  The controller automatically clears this bit
after finishing the reset signaling.  The software can also finish the
reset signaling any time by clearing the reset bit.

According to USB2 spec, Host controller should drive reset signaling for
50 msec for root hub ports.  But HSIC spec allows shorter reset signaling
time (20 msec).  Clear the reset bit in PORTSC register after 20 msec and
start controller immediately to send SOF.  Use controller internal timers
to achieve this.  If reset bit is not cleared in time, perform the sequence
in a loop with interrupts disabled.

CRs-Fixed: 445659
Change-Id: I6b251ced8d47b9ece4a06e58baf15c69a8bb340f
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
EHCI: HSIC: Fix GPT timer count values used for resume sequence

The counter value to be loaded into GPT timer represents the time
in micro seconds minus 1 for the timer duration.  The current code
incorrectly programs the timer.  Fix it.

CRs-Fixed: 449090
Change-Id: I53eddb6b4323bbfaf0e3a1d3aaa0fb9120c70647
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
EHCI: HSIC: Fix a race between root hub resume and controller removal

The pm_qos request is removed before unregistering the HCD in remove
function. If root hub resume runs in parallel, there is a possibility
of adding the pm_qos request back to the active list. The pm_qos request
memory is freed after unregistering the HCD and this would lead to
pm_qos list corruption. A crash is observed when another driver is
submitting a pm_qos request after HSIC controller is removed during
shutdown.  Remove HCD prior to releasing controller resources.

CRs-Fixed: 444928
Change-Id: Iaed6964e7d4245b8ae6c295ed6c76f5a9d32e20f
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>