usb: hsic: suspend hsic until really activated by the gadget driver

Hsic can enter to low power mode only after bus suspend when
connected to host. Since there is no disconnect state in hsic,
hsic remaines resumed even not activated by the gadget driver.
Therefore hsic still votes for some resources, such as clocks,
that prevent from power save modes to occur, as Vdd minimization.

This fix suspends the hsic by default, right after hsic udc driver
Initializations take place, and only on activation by the gadget
driver,aka pullup, resume the hsic device.

Change-Id: I22ecbbd66e76e28161428287e6a8b44cf42a1325
CRs-Fixed: 400263
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
USB: ci13xxx_udc: Fix ENDPOINT PRIME failure issue

while queueing requests to USB HW, waiting till EP PRIME bit
get cleared after setting it leads to wathdog timeout. Fix
this by implementing timer based solution instead of infinite
PRIME check loop.

CRs-Fixed: 397907
Change-Id: I74e9acbfdfcd2030896d1fa813e66803ece7d5bd
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
USB: ci13xxx_udc: Add timeout of 100ms for endpoint flush loop

Currently completion of endpoint flush operation is checked after
setting that endpoint bit with ENDPTFLUSH register and polling the
same to get it clear. It has been observed that sometime this flush
operation takes huge amount of time which results into watchdog
timeout issue due to this busy loop without any time-out. Hence add
time-out of 100ms for endpoint flush operation completion and also
add 100us delay before checking ENDPTFLUSH register for endpoint bit
clear or not.

Also print important usb status register and flushed endpoint dtds
at the time of issue.

CRs-Fixed: 409382
Change-Id: I7ae57cc436077f8a03051b92750bdca9a571da2b
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
usb: gadget: ci13xxx_msm: Allow BAM enable and disable

There are scenarios where the USB BAM has to be reset.
For example, when the peer BAM is being reset, the USB BAM
must be reset as well, otherwise the BAM-BAM connection will
go out of sync.

In order to reset the USB BAM, the USB controller has to disable
the BAM first. After the USB BAM reset is completed, the USB
controller has to re-enable the USB BAM.

So this change adds the support for USB BAM enable/disable.
This is done by adding an API to ci13xxx_msm. A function driver can
ask for BAM enable/disable by calling this API.

This change doesn't add the support for the USB BAM reset sequence.

CRs-Fixed: 424867
Change-Id: Ib5518fafe3765f86bb09d1ce10723ec733543b35
Signed-off-by: Amit Blay <ablay@codeaurora.org>

Conflicts:
	include/linux/usb/msm_hsusb.h
net: usb: Prevent suspend if response available notification received

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>
net: usb: Abort suspend if get_encap response is not sent

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
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Change-Id: Ib2a079a7107d994f760c0a876736ede3add07ea2
net: usb: Handle interface suspend properly

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.

Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Change-Id: I405b4797740e1b2aa67c6c28a2f3dcee0c196391
net: usb: Define waitqueue head as static global variable

usbnet_terminate_urbs() defines waitqueue head as local variable.
There is a possibility that wake_up is called on this queue head
in workqueue context and usbnet_terminate_urbs() already returned
or dev->wait pointer becomes NULL while calling wake_up() from
workqueue context. Hence call wake_up() using waitqueue head
defined as static global variable.

CRs-Fixed: 388724
Change-Id: Ib7e6c3023b9d780af0466496b25e68113b2d3fd3
Signed-off-by: Hemant Kumar <hemantk@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.

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>
Change-Id: I5e1cbd39e4469150de7cc98af9517a4dbdc80780
CRs-Fixed: 404339
Signed-off-by: Hemant Kumar <hemantk@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.

Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change-Id: I708632185ca0b310c4082cab3571a2d6552bf135
CRs-Fixed: 430579
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>