- 04 3月, 2016 37 次提交
-
-
由 Michal Nazarewicz 提交于
In general case, all of midi->in_port pointers may be non-NULL which implies that the ‘if (\!port)’ condition will never execute thus never zeroing midi->in_last_port. Fix by rewriting the loop such that the field is set to zero if \!port or end of loop has been reached. Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Michal Nazarewicz 提交于
Move some of the f_midi_transmit to a separate f_midi_do_transmit function so the massive indention levels are not so jarring. This introduces no changes in behaviour. Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Felipe F. Tonello 提交于
remove a field which is unnecessary. No functional changes. Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com> Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Du, Changbin 提交于
ffs_epfile_io and ffs_epfile_io_complete runs in different context, but there is no synchronization between them. consider the following scenario: 1) ffs_epfile_io interrupted by sigal while wait_for_completion_interruptible 2) then ffs_epfile_io set ret to -EINTR 3) just before or during usb_ep_dequeue, the request completed 4) ffs_epfile_io return with -EINTR In this case, ffs_epfile_io tell caller no transfer success but actually it may has been done. This break the caller's pipe. Below script can help test it (adbd is the process which lies on f_fs). while true do pkill -19 adbd #SIGSTOP pkill -18 adbd #SIGCONT sleep 0.1 done To avoid this, just dequeue the request first. After usb_ep_dequeue, the request must be done or canceled. With this change, we can ensure no race condition in f_fs driver. But actually I found some of the udc driver has analogical issue in its dequeue implementation. For example, 1) the dequeue function hold the controller's lock. 2) before driver request controller to stop transfer, a request completed. 3) the controller trigger a interrupt, but its irq handler need wait dequeue function to release the lock. 4) dequeue function give back the request with negative status, and release lock. 5) irq handler get lock but the request has already been given back. So, the dequeue implementation should take care of this case. IMO, it can be done as below steps to dequeue a already started request, 1) request controller to stop transfer on the given ep. HW know the actual transfer status. 2) after hw stop transfer, driver scan if there are any completed one. 3) if found, process it with real status. if no, the request can canceled. Signed-off-by: N"Du, Changbin" <changbin.du@intel.com> [mina86@mina86.com: rebased on top of refactoring commits] Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Michal Nazarewicz 提交于
Eliminate one of the return paths by using a ‘goto error_mutex’ and rearrange some if-bodies which results in reduction of the indention level and thus hopefully makes the function easier to read and reason about. Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Michal Nazarewicz 提交于
In ffs_epfile_io error label points to a return path which includes a kfree(data) call. However, at the beginning of the function data is always NULL so some of the early ‘goto error’ can safely be replaced with a trivial return statement. Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Michal Nazarewicz 提交于
In the AIO path, if allocating of a request failse, the function simply goes to the error_lock path whose end result is returning value of ret. However, at this point ret’s value is zero (assigned as return value from ffs_mutex_lock). Fix by adding ‘ret = -ENOMEM’ statement. Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Michal Nazarewicz 提交于
In the ffs_epfile_io function, data buffer is allocated for non-halt requests. Later, after grabing a mutex, the function checks that epfile->ep is still ep and if it’s not, it set ret to -ESHUTDOWN and follow a path including spin_unlock_irq (just after ‘ret = -ESHUTDOWN’), mutex_unlock (after if-else-if-else chain) and returns ret. Noticeably, this does not include freeing of the data buffer. Fix by introducing a goto which moves control flow to the the end of the function where spin_unlock_irq, mutex_unlock and kfree are all called. Signed-off-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Bjorn Helgaas 提交于
phy-am335x.c doesn't use any interfaces from linux/regulator/consumer.h, so stop including it. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
When I wrote the cleanup patch series, it was not clear how exactly big-endian mode works on ixp4xx, and whether the driver was doing this correctly. After discussing with Krzysztof Hałasa, this has been clarified, so I can update the comment let pxa25x big-endian (which we don't support) work the same way as ixp4xx. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
When dma_addr_t is 64-bit, we get a warning about an invalid cast in the call to ux500_dma_is_compatible() from ux500_dma_channel_program(): drivers/usb/musb/ux500_dma.c: In function 'ux500_dma_channel_program': drivers/usb/musb/ux500_dma.c:210:51: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] if (!ux500_dma_is_compatible(channel, packet_sz, (void *)dma_addr, len)) The problem is that ux500_dma_is_compatible() is called from the main musb driver on the virtual address, but here we pass in a DMA address, so the types are fundamentally different but it works because the function only checks the alignment of the buffer and that is the same. We could work around this by adding another cast, but I have checked that the buffer we get passed here is already checked before it gets mapped, so the second check seems completely unnecessary and removing it must be the cleanest solution. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
The musb driver prints DMA addresses in a few places, using the 0x%x format string. This is wrong on 64-bit architectures (which need %lx) and 32-bit ARM with CONFIG_LPAE set (which needs %llx), otherwise we print the wrong data, as gcc warns: musb/musbhsdma.c: In function 'configure_channel': musb/musbhsdma.c:120:53: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=] dev_dbg(musb->controller, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n", musb/musbhsdma.c: In function 'dma_channel_program': musb/musbhsdma.c:155:53: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=] dev_dbg(musb->controller, "ep%d-%s pkt_sz %d, dma_addr 0x%x length %d, mode %d\n", musb/tusb6010_omap.c: In function 'tusb_omap_dma_program': musb/tusb6010_omap.c:313:53: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=] dev_dbg(musb->controller, "ep%i %s dma ch%i dma: %08x len: %u(%u) packet_sz: %i(%i)\n", This uses the %pad format string, which prints a dma_addr_t that gets passed by reference, which works for all combinations. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
The power_up function is used for otg or udc mode, but nost when the driver is only configured for host mode: drivers/usb/phy/phy-isp1301-omap.c:261:13: error: 'power_up' defined but not used [-Werror=unused-function] This marks the function __maybe_unused to avoid the warning and silently drop the definition when it is unused. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
The USB_FSL_MPH_DR_OF symbol is used to ensure the code that interprets the DR device node is built whenever one of the two drivers (EHCI or UDC) for the platform is enabled. However, if CONFIG_USB is disabled and we only support gadget mode, this causes a Kconfig warning: warning: (USB_FSL_USB2) selects USB_FSL_MPH_DR_OF which has unmet direct dependencies (USB_SUPPORT && USB) We can avoid this warning by simply no longer using the symbol, and making sure we enter the drivers/usb/host/ directory when the UDC driver is enabled that needs the file, and then we use Makefile syntax to ensure the file is built-in if needed. There is currently a dependency on CONFIG_OF, but this is redundant, as we already know that this is set unconditionally for the platforms that use this driver. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
This converts the pxa25x udc driver to use readl/writel as normal driver should do, rather than dereferencing __iomem pointers themselves. Based on the earlier preparation work, we can now also pass the register start in the device pointer so we no longer need the global variable. The unclear part here is for IXP4xx, which supports both big-endian and little-endian configurations. So far, the driver has done no byteswap in either case. I suspect that is wrong and it would actually need to swap in one or the other case, but I don't know which. It's also possible that there is some magic setting in the chip that makes the endianess of the MMIO register match the CPU, and in that case, the code actually does the right thing for all configurations, both before and after this patch. Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
This removes the dependency on the mach/hardware.h header file from the pxa25x_udc driver after the register definitions were already unified in the previous patch. Following the model of pxa27x_udc (and basically all other drivers in the kernel), we define the register numbers as offsets from the register base address and use accessor functions to read/write them. For the moment, this still leaves the direct pointer dereference in place, instead of using readl/writel, so this patch should not be changing the behavior of the driver, other than using ioremap() on the platform resource to replace the hardcoded virtual address pointers. Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Arnd Bergmann 提交于
ixp4xx and pxa25x both use this driver and provide a slightly different set of register definitions for it. Aside from that, the definition in the ixp4xx-regs.h header conflicts with the on in the pxa27x device driver when compile-testing that: In file included from ../drivers/usb/gadget/udc/pxa27x_udc.c:37:0: ../drivers/usb/gadget/udc/pxa27x_udc.h:26:0: warning: "UDCCR" redefined #define UDCCR 0x0000 /* UDC Control Register */ ^ In file included from ../arch/arm/mach-ixp4xx/include/mach/hardware.h:27:0, from ../arch/arm/mach-ixp4xx/include/mach/io.h:18, from ../arch/arm/include/asm/io.h:194, from ../include/linux/io.h:25, from ../include/linux/irq.h:24, from ../drivers/usb/gadget/udc/pxa27x_udc.c:23: ../arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:415:0: note: this is the location of the previous definition #define UDCCR IXP4XX_USB_REG(IXP4XX_USB_BASE_VIRT+0x0000) This addresses both issues by moving all the definitions into the pxa25x_udc driver itself. It turns out the only difference between them was 'UDCCS_IO_ROF', and that could well be a mistake when it was incorrectly copied from pxa25x to ixp4xx. Acked-by: NKrzysztof Halasa <khalasa@piap.pl> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Yoshihiro Shimoda 提交于
Since Some SoCs (e.g. R-Car Gen2) don't have the CSSTS bit in the pipectrl registers ({DCP,PIPEn}CTR) because such SoCs have peripheral mode only. So, this driver should not check the CSSTS bit if peripheral mode is running. Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Yoshihiro Shimoda 提交于
Since the usb2 phy driver for gen3 (phy-rcar-gen3-usb2) cannot access LPSTS and UGCTRL2 registers in the HSUSB module, this driver have to initialize the registers. So, this patch adds such handling code into rcar3.c. Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Enable SuperSpeedPlus by programming the DCFG.speed and after enumerating, set gadget->speed appropriately. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
If the maximum_speed is not set, set it to a known value, either SuperSpeed or SuperSpeedPlus based on the type of controller we are using. If we are on DWC_usb31 controller, check the PHY interface to see if it is capable of SuperSpeedPlus. Also this check is moved after dwc3_core_init() so that we can check dwc->revision. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Update various places where the speed is checked so that it takes into account SuperSpeedPlus properly. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Update various registers fields definitions for the DWC_usb31 controller for SuperSpeedPlus support. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Add a convenience function to check if the controller is DWC_usb31. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Enable superspeed plus configuration for the mass storage gadget. The mass storage function doesn't do anything special for SuperSpeedPlus. Just pass in the same SuperSpeed descriptors for SuperSpeedPlus. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Update the debug message reporting the speeds that a configuration supports for SuperSpeedPlus. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Configure the usb_ep using the SuperSpeedPlus descriptors if connected in SuperSpeedPlus. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Enable writing of SuperSpeedPlus descriptors for any SuperSpeedPlus capable configuration when connected in SuperSpeedPlus. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
There are a couple places in the code that get the function descriptors based on the speed. Move this lookup into a function call and add support to handle the SuperSpeedPlus descriptors as well. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
If enumerated in SuperSpeedPlus, count the configurations that support it. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
When a function is added to a configuration with usb_add_function(), the configuration speed flags are updated. These flags indicate for which speeds the configuration is valid for. This patch adds a flag in the configuration for SuperSpeedPlus and also updates this based on the existence of ssp_descriptors. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Add a ssp_descriptors member to struct usb_function and handle the initialization and cleanup of it. This holds the SuperSpeedPlus descriptors for a function that supports SuperSpeedPlus. This is added by usb_assign_descriptors(). Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Add the 'ssp_descriptors' parameter to the usb_assign_descriptors() function. This allows a function driver to add descriptors for SuperSpeedPlus speeds if it supports it. Also update all uses of this function in the gadget subsystem so that they pass NULL for the ssp_descriptors parameters. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
If a gadget supports SuperSpeedPlus or higher speeds, return a SuperSpeedPlus USB Device Capability descriptor. Currently this implementation returns a fixed descriptor with typical values set. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
The USB 3.1 specification replaces the USB 3.0 specification and all new devices that are running at SuperSpeed or higher speeds must report a bcdUSB of 0x0310. Refer to USB 3.1 Specification, Revision 1.0, Section 9.6. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
Add a function to check for SuperSpeedPlus capable gadgets. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 John Youn 提交于
The SuperspeedPlus Device Capability Descriptor has a variable size depending on the number of sublink speed attributes. This patch adds a macro to calculate that size. The macro takes one argument, the Sublink Speed Attribute Count (SSAC) as reported by the descriptor in bmAttributes[4:0]. See USB 3.1 9.6.2.5, Table 9-19. Signed-off-by: NJohn Youn <johnyoun@synopsys.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
- 02 3月, 2016 2 次提交
-
-
由 Greg Kroah-Hartman 提交于
Merge tag 'usb-ci-v4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next Peter writes: - Add platform interface to choose ttctrl.ttha - Some tiny improvements
-
由 Greg Kroah-Hartman 提交于
We want the USB fixes in here as well. Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 2月, 2016 1 次提交
-
-
由 Stefan Agner 提交于
Avoid printing an error if adding the device failes with return value EPROBE_DEFFER. This may happen e.g. due to missing GPIO for the vbus-supply regulator. Signed-off-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NPeter Chen <peter.chen@nxp.com>
-