- 10 Mar, 2015 38 commits
-
-
Andrzej Pietrasiewicz authored
Function-specific setup requests should be handled in such a way, that apart from filling in the data buffer, the requests are also actually enqueued: if function-specific setup is called from composte_setup(), the "usb_ep_queue()" block of code in composite_setup() is skipped. The printer function lacks this part and it results in e.g. get device id requests failing: the host expects some response, the device prepares it but does not equeue it for sending to the host, so the host finally asserts timeout. This patch adds enqueueing the prepared responses. Cc: <stable@vger.kernel.org> # v3.4+ Fixes: 2e87edf4: "usb: gadget: make g_printer use composite" Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Andrzej Pietrasiewicz authored
If a non-standard request is processed and its parameters just happen to match those of some standard request, the logic of composite_setup() can be fooled, so don't even try any switch cases, just go to the proper place where unknown requests are handled. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
This patch removes "Enable USB3 LPM Capability" option from Kconfig and adds snps,usb3_lpm_capable devicetree property instead of it. USB3 LPM (Link Power Management) capability is hardware property, and it's platform dependent, so if our hardware supports this feature, we want rather to configure it in devicetree than having it as Kconfig option. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
there's no need to fake an IRQ, just check if VBUS is valid already. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
no functional changes, clean up only. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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>
-
Mian Yousaf Kaukab authored
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>
-
Mian Yousaf Kaukab authored
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>
-
Mian Yousaf Kaukab authored
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>
-
Mian Yousaf Kaukab authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
no functional changes, cleanup only. Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
no functional changes, clean up only. Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
no functional changes, clean up only. Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
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>
-
Sudeep Holla authored
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>
-
Joseph Kogut authored
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>
-
Joe Perches authored
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>
-
- 09 Mar, 2015 2 commits
-
-
Felipe Balbi authored
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>
-
Felipe Balbi authored
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>
-