there's no need to fake an IRQ, just check
if VBUS is valid already.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

when polling, we were using n * HZ (where n is
an integer in seconds), however HZ isn't always
correct if we're using cpufreq. A better way
is to use msecs_to_jiffies(n) (where n is now
an integer in miliseconds).

while at that, also rename poll_seconds to poll_timeout
and  change its type to unsigned int.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

according to comment in code, HS completion
will happen pretty fast, instead of using
udelay(), let's just busy loop and drop a
cpu_relax() where udelay() was.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

as soon as we find out tx fifo is empty, there's
no need to break out of the loop just to have another
branch to complete the transfer. We can just complete
transfer and exit early.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

no functional changes, clean up only.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Silence the following warning:

drivers/usb/gadget/udc/net2280.c:3176:33: warning: context imbalance in
'handle_stat1_irqs' - unexpected unlock
Signed-off-by: NFelipe Balbi <balbi@ti.com>

net2280_start can be called with pullup disabled. Don't set
softconnect flag in it. Let net2280_pullup handle the connection part.
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Hopefully, these prints will help localize the problems faster.

[ balbi@ti.com: removed 2 unnecessary OOM error messages ]
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Remove fiforegs from struct net2280 and net2280_ep as it is unused.
By the way, ep->fiforegs = &dev->fiforegs[i] assignment is incorrect.
It should be ep->fiforegs = &dev->fiforegs[ne[i]], but it doesn't
matter now.
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Each struct usb_ep added for net2280 can be used in either direction.
Whereas, each struct usb_ep for usb3380 has fixed direction. Use
ep_autoconf compatible names so that endpoint with correct direction
can be selected.

Name sequence is due to the logic in usb_reinit_338x() in ne[] and
ep_reg_addr[].
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

we can also have babble conditions with LS/FS
and we also want to recover in that case.

Because of that we will drop the check of HSMODE
and always try to run babble recovery.
Suggested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There's no point is splitting those anymore.

We're now also able to drop another forward
declaration.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

no functional changes, cleanup only.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that's not needed anymore. Everything that we
call is irq-safe, so we might as well not
have a delayed work for babble recovery.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

recover is a much better name than reset, considering
we don't really reset the IP, just run platform-specific
babble recovery algorithm.

while at that, also fix a typo in comment and add kdoc
for recover memeber of platform_ops.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

we're not resetting musb at all, just restarting
the session. This means we don't need to touch PHYs
or VBUS or anything like that. Just make sure session
bit is reenabled after MUSB dropped it.

while at that, make sure to tell usbcore that we're
dropping the session and, thus, disconnecting the
device.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

All we have to do is, really, drop session bit
and let the session restart.

Big thanks goes to Bin Liu <b-liu@ti.com> for
inspiring this work.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When babble IRQ happens, we need to wait only
5.3us (320 cycles of 60MHz clock), we will give
it some slack and schedule our work a 10 usecs into
the future.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We do *not* want to touch devctl at all when
trying to recover from babble. All we want to
do is mask IRQs until we're done without our
babble recovery, at which point we will unmask
IRQs.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

sometimes we want to just mask/unmask interrupts
without touching devctl register. For those
cases, let's introduce musb_enable_interrupts and
musb_disable_interrupts()
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

this makes it easier to filter function traces.
No functional changes.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Whenever babble happens, MUSB controller will
drop session automatically.

The only case where it won't drop the session,
is when we're running on AM335x and SW_SESSION_CTRL
bit has been set. In that case, controller will
not touch session bit so SW has a chance to recover
from babble condition.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We want to check if that particular bit is
set. It could very well be that bootloader
(or romcode) has fiddled with MUSB before
us which could leave other bits set in this
register.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

musb->int_usb already contains the correct
information for musb-core to handle babble.

In fact, this very check was just causing a
nonsensical babble interrupt storm.

With this I can get test.sh to run and, even though
all tests fail with timeout, that's still better
than locking up the system due to IRQ storm.

Also, if I remove g_zero and load g_mass_storage,
then everything works fine again.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

MUSB does not generate a connect IRQ when working
in peripheral mode.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

when musb is operating as host and a remote wakeup
fires up, a resume interrupt will be raised. At that
point SUSPENDM bit is automatically cleared and
RESUME bit is automatically set.

Remove those two from IRQ handler.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

no functional changes, clean up only.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There was already a proper place where we were
checking for babble interrupts, move babble
recovery there.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if reset fails, we should return a *negative*
error code, not a positive value.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

FSDEV is set for both HIGH and FULL speeds,
the correct HIGHSPEED check is done through
power register's HSMODE bit.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

no functional changes, clean up only.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

devctl & MUSB_DEVCTL_HM represents a single bit,
just check for the bit, there's really no need
to compare the result against 0.
Tested-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As per the SAF1761 data sheet[0], the DcChipID register represents
the hardware version number (0001h) and the chip ID (1582h) for the
Peripheral Controller.

However as per the ISP1761 data sheet[1], the DcChipID register
represents the hardware version number (0015h) and the chip ID (8210h)
for the Peripheral Controller.

This patch adds support for both the chip ID values.

[0] http://www.nxp.com/documents/data_sheet/SAF1761.pdf
[1] http://pdf.datasheetcatalog.com/datasheets2/74/742102_1.pdf

Cc: Felipe Balbi <balbi@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Removed FIXME from usb/dwc3/dwc3-pci.c by moving definition of
PCI_VENDOR_ID_SYNOPSYS shared with usb/dwc2 to linux/pci_ids.h.
Signed-off-by: NJoseph Kogut <joseph.kogut@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The seq_printf return value, because it's frequently misused,
will eventually be converted to void.

See: commit 1f33c41c ("seq_file: Rename seq_overflow() to
     seq_has_overflowed() and make public")

While there, simplify the error handler logic by returning
immediately and remove the unnecessary labels.
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Now that we're using XFERINPROGRESS for all endpoint
types (except Control), we will *always* be completing
one TRB at a time, so it's safe to remove the loop
from dwc3_cleanup_done_reqs.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch fixes a bug where removing dwc3-omap.ko
would not trigger removal of dwc3.ko.

of_platform_depopulate() already bakes an easy to
use API for removing all our children which were
populated during probe(); Let's use that one instead
of cooking our own solution.

Note that this is kind of a revert of commit c5a1fbca
(usb: dwc3: dwc3-omap: Fix the crash on module removal)
although we can't simply revert that because a direct
call to platform_device_unregister would also be flakey.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

That trick is only needed if we end up with an error, so
there's no point in messing that outside of an error path.

In fact doing so causes problems when removing dwc3.ko,
problems which commit c5a1fbca (usb: dwc3: dwc3-omap: Fix
the crash on module removal) mistakenly tried to fix.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

instead of using manually spelled out bit-shits
and iterate over each of the 16-bits (one for
each endpoint) on each direction, we can make use
of for_each_set_bit() which internally uses
find_first_bit().

This makes the code slightly more readable while
also making we only iterate over bits which are
actually set.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As per Mentor Graphics' documentation, we should
always handle TX endpoints before RX endpoints.

This patch fixes that error while also updating
some hard-to-read comments which were scattered
around musb_interrupt().

This patch should be backported as far back as
possible since this error has been in the driver
since it's conception.

Cc: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>