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: Felipe Balbi <balbi@ti.com>

no functional changes, clean up only.
Signed-off-by: Felipe 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: Felipe 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: Mian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: Felipe 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: Mian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: Felipe 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: Mian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: Felipe 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: Mian Yousaf Kaukab <yousaf.kaukab@intel.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

There's no point is splitting those anymore.

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

no functional changes, cleanup only.
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

this makes it easier to filter function traces.
No functional changes.
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

MUSB does not generate a connect IRQ when working
in peripheral mode.
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

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

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

if reset fails, we should return a *negative*
error code, not a positive value.
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

no functional changes, clean up only.
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe 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: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Felipe 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: Joseph Kogut <joseph.kogut@gmail.com>
Signed-off-by: Felipe 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: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Felipe 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: Felipe 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: Felipe 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: Felipe 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: Felipe 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: Felipe Balbi <balbi@ti.com>

that function is pretty close to a no-op by now,
all we need is a call to musb_stop().
Signed-off-by: Felipe Balbi <balbi@ti.com>

POLL_OUT isn't what callers of ->poll() are expecting to see; it's
actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
bit...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
Cc: Bruce Fields <bfields@fieldses.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>