Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied to my dma40 branch with Felipe's ACK. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi ba...@ti.com wrote: On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote: For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org for drivers/usb/musb Acked-by: Felipe Balbi ba...@ti.com Is that only for this patch 20/39 or also 21, 22 23? Poke us if we should re-send them... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Thu, 30 May 2013, Linus Walleij wrote: On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi ba...@ti.com wrote: On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote: For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org for drivers/usb/musb Acked-by: Felipe Balbi ba...@ti.com Is that only for this patch 20/39 or also 21, 22 23? Poke us if we should re-send them... I read this as all patches in the series for drivers/usb/musb. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, Ok. What other gadget driver can i test with UDC driver? Is it the mass storage driver (mass_storage.c)? That is essentially the same as g_file_storage. But there are lots of others. You should start with g_zero and run the testusb suite. See http://www.linux-usb.org/gadget/ and http://www.linux-usb.org/usbtest/ for more information. Those web pages are pretty old and somewhat out of date, but they still have useful stuff. I tested the g_zero with USB 2.0 Command Verifier. After the Command Verifier is run, the UDC gadget driver queue function is continuously being called, and the linux command prompt is frozen. Please see the attached UDC driver log. It looks like endpoint 1 in direction is called by USB 2.0 Command Verifier continuously. Is this weird? thanks, victor # insmod kagen2_udc.ko kagen2_init kagen2_plat_probe 1 kagen2_plat_probe 5 kagen2_plat_probe 6, 0xc2886000 0x1000 read pclk scu 7 irqmask ffbd 7fff val is 0x0 val is 0x8 check USB_OTGST 0x51000801 check USB_OTGIRQ 0x51000810 check USB_IRQINIT 0x70007 check USB_OTGFSM 0xa1d191f check USB_OTGCTRL 0x51300801 kagen2_plat_probe 8 register irq 32 kagen2_init 0 # insmod g_zero.ko bind epname ep1 epname ep1 epname ep1 epname ep1 gadget: Gadget Zero, version: Cinco de Mayo 2008 gadget: zero ready usb_gadget_udc_start 0xbf0386b8 0xbf0364c8 kagen2_start 0xbf0386b8 0xbf0364c8 0xc12d2cf0 0xbf030eb0 usb_gadget_connect # ept0 in queue len 0x12, buffer 0xc12d3000 USB_RECIP_DEVICE exit A ept0 in queue len 0x12, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x42, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0xa, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x3a, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x42, buffer 0xc12d3000 ept0 in queue len 0x2a, buffer 0xc12d3000 ept0 in queue len 0x2a, buffer 0xc12d3000 ept0 in queue len 0x12, buffer 0xc12d3000 USB_RECIP_DEVICE exit A ept0 in queue len 0x12, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 zero gadget: high-speed config #3: source/sink ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7
Re: time source unstable on usb/serial/pl2303 (globalsat br-353)
Hello, On Fri, May 24, 2013 at 09:46:32AM -0400, Alan Stern wrote: On Fri, 24 May 2013, Philippe De Muyter wrote: On Thu, May 23, 2013 at 08:31:18AM -0700, Greg Kroah-Hartman wrote: On Thu, May 23, 2013 at 03:07:09PM +0200, Philippe De Muyter wrote: Hi all, I have a lot of linux computers equipped with a GlobalSat Br-353 GPS receiver, Sorry for the typo, it is actually a BU-353 which is connected via USB (an integrated PL2303). The GPS receiver emits one multi-line message every second, giving position and time. I listen to this messages in a user program running in the highest priority, and I have noticed that under load, the messages are not delivered to my process every second, but often delayed, which is not great for a time source. I looked at the sources of pl2303 and added a diagnostic message if the beginning of a message came more than one second later than the beginning of the previous one, and I noticed that the delay was already present in the kernel: often even more than one second delay after the expected beginning time. Then that implies that the device itself is holding on to the message, right? I hoped it was the configuration on the host-side. I have read internet pages that implied that for USB mice it was possible to increase the polling rate. I hoped that it would be the same for serial lines. Have you tried usbmon? The detailed information about the timing of the URBs might give you some clues. USB is not something that you can rely on for very high-frequency, low latency, timing things. Although to be fair, second delays are quite rare, which implies that your hardware is to blame here. Yes, I think that there must be something wrong but more on a software side, because I do not get such big delays on an unloaded computer. It's possible that the delays are at the user level and not in the kernel. I analyzed the problem as deeply as I could, and the problem was threefold : (remember it is on a cpu-intensive environment) - the user had inadvertently dropped the setuid/setgid of the application program, thus it did not run in the highest priority, but at a normal priority - usb serial lines do not have the low_latency mode set, and setserial cannot set it either : linux-1syr:~ # setserial /dev/ttyUSB0 low_latency Cannot set serial info: Inappropriate ioctl for device linux-1syr:~ # - the gps receiver hardware/firmware (Gloabalsat BU-353, with a SiRF III chip) sometimes takes 100-200ms more to begin sending its messages (I can see that because the bulk_read allways give only one byte of data). Additionaly, because I only got one character at a time, the debugging I had put in pl2303.c tried to detect the beginning of a new message by measuring the delay between the last byte received and the current one and comparing that to a threshold. My threshold was too high, and sometimes (rarely now), there is no gap between the end of the message of second s and the beginning of message of second s+1. That gave wrongly the impression of a '1 additional second' delay. Setting low_latency in the pl2303 driver helped a lot !!! Now I only see the intrinsic delay of the gps receiver itself, and some millisecs from usb. Thanks for your input.. Philippe -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/39] usb: musb: ux500: move the MUSB HDRC configuration into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: The MUSB HDRC configuration never changes between each of the ux500 supported platforms, so there's little point passing it though platform data. If we set it in the driver instead, we can make good use of it when booting with either ATAGs or Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/39] usb: musb: ux500: take the dma_mask from coherent_dma_mask
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: The dma_mask will always be the same as the coherent_dma_mask, so let's cut down on the platform_data burden and set it as such in the driver. This also saves us from supporting it separately when we come to enable this driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/39] usb: musb: ux500: attempt to find channels by name before using pdata
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: If we can ever get to a state where we can solely search for DMA channels by name, this will almost completely alleviate the requirement to pass copious amounts of information though platform data. Here we take the first step towards this. The next step will be to enable Device Tree complete with name-event_line mapping. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 25/39] usb: musb: ux500: add device tree probing support
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: This patch will allow ux500-musb to be probed and configured solely from configuration found in Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: Rob Herring rob.herr...@calxeda.com Cc: linux-usb@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 26/39] ARM: ux500: Add an auxdata entry for MUSB for clock-name look-up
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: The recently DT:ed MUSB driver will require clock-name by device-name look-up capability, until common clk has is properly supported by the ux500 platform. Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Applied to my ux500-devicetree branch. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 27/39] ARM: ux500: Remove ux500-musb platform registation when booting with DT
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: Now the ux500-musb driver has been enabled for Device Tree, there is no requirement to register it from platform code. Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied to my ux500-dma40 branch on top of the musb stuff. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 28/39] ARM: ux500: Remove empty function u8500_of_init_devices()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: As promised, now all devices which resided in u8500_of_init_devices() have been enabled for Device Tree, we can completely remove it. Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Applied on my ux500-dma40 branch. And this is looking real good now! Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/39] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 x)'s
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: The aim is to make the code that little more readable. Acked-by: Vinod Koul vnod.k...@intel.com Acked-by: Arnd Bergmann a...@arndb.de Reviewed-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied to my ux500-dma40 branch. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 30/39] ARM: ux500: Replace ST-E's home-brew DMA direction definition with the generic one
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: STEDMA40_*_TO_* direction definitions are identical in all but name to the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not duplicating such things. Signed-off-by: Lee Jones lee.jo...@linaro.org Vinod, I'm lacking your ACK on this patch, but have tentatively queued it anyway. Maybe you missed it? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: STEDMA40_*_TO_* direction definitions are identical in all but name to the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not duplicating such things. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied to my dma40 branch with Vinod's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 32/39] ARM: ux500: Remove recently unused stedma40_xfer_dir enums
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: We're now using the transfer direction definitions provided by the DMA sub-system, so the home-brew ones have become obsolete. Signed-off-by: Lee Jones lee.jo...@linaro.org Tentatively applied, also missing Vinod's ACK on this, but it seems it was implicitly ACKed in the discussion on patch 31. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 33/39] dmaengine: ste_dma40_ll: Use the BIT macro to replace ugly '(1 x)'s
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: The aim is to make the code that little more readable. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied with Vinod's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: When a DMA client requests and configures a DMA channel, it requests data_width in Bytes. The DMA40 driver then swiftly converts it over to the necessary register bit value. Unfortunately, for any subsequent calculations we have to shift '1' by the bit pattern (1 data_width) times to make any sense of it. This patch flips the semantics on its head and only converts the value to its respective register bit pattern when writing to registers. This way we can use the true data_width (in Bytes) value. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied with what I interpret as Vinod's ACK (okay... statement on last reply.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 35/39] dmaengine: ste_dma40_ll: Replace meaningless register set with comment
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: Unsure of the author's intentions, rather than just removing the nop, we're replacing it with a comment containing the possible intention of the statement OR:ing with 0. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Signed-off-by: Lee Jones lee.jo...@linaro.org Tentatively applied. Missing Vinod's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 36/39] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: At this moment in time the memcpy channels which can be used by the D40 are fixed, as each supported platform in Mainline uses the same ones. However, platforms do exist which don't follow this convention, so these will need to be tailored. Fortunately, these platforms will be DT only, so this change has very little impact on platform data. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied with Vinod's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 37/39] ARM: ux500: Stop passing DMA platform data though AUXDATA
On Wed, May 15, 2013 at 11:52 AM, Lee Jones lee.jo...@linaro.org wrote: The DMA platform data is now empty due to some recent refactoring, so there is no longer a requirement to pass it though. Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Lee Jones lee.jo...@linaro.org Applied to dma40 branch, hm now I may get a conflict with all the AUXDATA changes in the devicetree branch. Oh well, I'll figure it out... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 38/39] dmaengine: ste_dma40: Fetch the number of physical channels from DT
On Wed, May 15, 2013 at 11:52 AM, Lee Jones lee.jo...@linaro.org wrote: Some platforms insist on obscure physical channel availability. This information is currently passed though platform data in internal BSP kernels. Once those platforms land, they'll need to configure them appropriately, so we may as well add the infrastructure. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied with Vinod's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 39/39] dmaengine: ste_dma40: Fetch disabled channels from DT
On Wed, May 15, 2013 at 11:52 AM, Lee Jones lee.jo...@linaro.org wrote: Some platforms have channels which are not available for normal use. This information is currently passed though platform data in internal BSP kernels. Once those platforms land, they'll need to configure them appropriately, so we may as well add the infrastructure. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied with Vinod's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] USB: OHCI: Splitting ohci-platform into independent driver
This series patch begins the process of splitting ohci-platform up into independent driver modules and add a name for the platform-private field. Patch 1/2 separate ohci-platform into independent driver modules. Patch 2/2 adds an ohci-priv field for private use by OHCI platform drivers. Manjunath Goudar (2): USB: OHCI: make ohci-platform a separate driver USB: OHCI: add a name for the platform-private field drivers/usb/host/Kconfig |2 +- drivers/usb/host/Makefile|1 + drivers/usb/host/ohci-hcd.c |6 +-- drivers/usb/host/ohci-platform.c | 88 ++ drivers/usb/host/ohci.h |3 ++ 5 files changed, 47 insertions(+), 53 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/2] USB: OHCI: make ohci-platform a separate driver
This patch splits the ohci-platform code from ohci-hcd out
into its own separate driver module.This work is part of enabling
multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig |2 +-
drivers/usb/host/Makefile|1 +
drivers/usb/host/ohci-hcd.c |6 +--
drivers/usb/host/ohci-platform.c | 88 ++
4 files changed, 44 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0a2f3a..5391a38 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -501,7 +501,7 @@ config USB_CNS3XXX_OHCI
It is needed for low-speed USB 1.0 device support.
config USB_OHCI_HCD_PLATFORM
- bool Generic OHCI driver for a platform device
+ tristate Generic OHCI driver for a platform device
default n
---help---
Adds an OHCI host driver for a generic platform device, which
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 2214ded..8a89c3d 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
obj-$(CONFIG_USB_OHCI_HCD_PCI) += ohci-pci.o
+obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 237be7c..39c7624 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1258,12 +1258,8 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERohci_hcd_tilegx_driver
#endif
-#ifdef CONFIG_USB_OHCI_HCD_PLATFORM
-#include ohci-platform.c
-#define PLATFORM_DRIVERohci_platform_driver
-#endif
-
#if!IS_ENABLED(CONFIG_USB_OHCI_HCD_PCI) \
+ !IS_ENABLED(CONFIG_USB_OHCI_HCD_PLATFORM) \
!defined(PLATFORM_DRIVER) \
!defined(OMAP1_PLATFORM_DRIVER) \
!defined(OMAP3_PLATFORM_DRIVER) \
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 76a3531..8295375 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -13,16 +13,28 @@
*
* Licensed under the GNU/GPL. See COPYING for details.
*/
+
+#include linux/hrtimer.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/err.h
#include linux/platform_device.h
#include linux/usb/ohci_pdriver.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ohci.h
+
+#define DRIVER_DESC OHCI generic platform driver
+
+static const char hcd_name[] = ohci-platform;
static int ohci_platform_reset(struct usb_hcd *hcd)
{
struct platform_device *pdev = to_platform_device(hcd-self.controller);
struct usb_ohci_pdata *pdata = pdev-dev.platform_data;
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- int err;
if (pdata-big_endian_desc)
ohci-flags |= OHCI_QUIRK_BE_DESC;
@@ -30,58 +42,17 @@ static int ohci_platform_reset(struct usb_hcd *hcd)
ohci-flags |= OHCI_QUIRK_BE_MMIO;
if (pdata-no_big_frame_no)
ohci-flags |= OHCI_QUIRK_FRAME_NO;
-
- ohci_hcd_init(ohci);
-
if (pdata-num_ports)
ohci-num_ports = pdata-num_ports;
- err = ohci_init(ohci);
-
- return err;
-}
-
-static int ohci_platform_start(struct usb_hcd *hcd)
-{
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- int err;
-
- err = ohci_run(ohci);
- if (err 0) {
- ohci_err(ohci, can't start\n);
- ohci_stop(hcd);
- }
-
- return err;
+ return ohci_setup(ohci);
}
-static const struct hc_driver ohci_platform_hc_driver = {
- .description= hcd_name,
- .product_desc = Generic Platform OHCI Controller,
- .hcd_priv_size = sizeof(struct ohci_hcd),
+static struct hc_driver __read_mostly ohci_platform_hc_driver;
- .irq= ohci_irq,
- .flags = HCD_MEMORY | HCD_USB11,
-
- .reset = ohci_platform_reset,
- .start = ohci_platform_start,
- .stop = ohci_stop,
- .shutdown = ohci_shutdown,
-
- .urb_enqueue= ohci_urb_enqueue,
- .urb_dequeue= ohci_urb_dequeue,
- .endpoint_disable = ohci_endpoint_disable,
-
- .get_frame_number = ohci_get_frame,
-
- .hub_status_data= ohci_hub_status_data,
- .hub_control= ohci_hub_control,
-#ifdef CONFIG_PM
- .bus_suspend= ohci_bus_suspend,
- .bus_resume =
[RFC PATCH 2/2] USB: OHCI: add a name for the platform-private field
This patch adds an ohci-priv field for private use by OHCI
platform drivers.
Until now none of the platform drivers has used this private space,
but that's about to change in the next patch of this series.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index 3b58482..e2e5faa 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -421,6 +421,9 @@ struct ohci_hcd {
struct dentry *debug_periodic;
struct dentry *debug_registers;
#endif
+ /* platform-specific data -- must come last */
+ unsigned long priv[0] __aligned(sizeof(s64));
+
};
#ifdef CONFIG_PCI
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] usb, chipidea: remove redundant D0 power state set
Pci_enable_device() will set device power state to D0, so it's no need to do it again in ci13xxx_pci_probe(). Signed-off-by: Yijing Wang wangyij...@huawei.com --- drivers/usb/chipidea/ci13xxx_pci.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/chipidea/ci13xxx_pci.c b/drivers/usb/chipidea/ci13xxx_pci.c index 4e1fc61..a2a6ac8 100644 --- a/drivers/usb/chipidea/ci13xxx_pci.c +++ b/drivers/usb/chipidea/ci13xxx_pci.c @@ -71,7 +71,6 @@ static int ci13xxx_pci_probe(struct pci_dev *pdev, goto disable_device; } - pci_set_power_state(pdev, PCI_D0); pci_set_master(pdev); pci_try_set_mwi(pdev); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] usb, dwc3: remove redundant D0 power state set
Pci_enable_device() will set device power state to D0, so it's no need to do it again in dwc3_pci_probe(). Signed-off-by: Yijing Wang wangyij...@huawei.com --- drivers/usb/dwc3/dwc3-pci.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 227d4a7..c068608 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -133,7 +133,6 @@ static int dwc3_pci_probe(struct pci_dev *pci, return -ENODEV; } - pci_set_power_state(pci, PCI_D0); pci_set_master(pci); ret = dwc3_pci_register_phys(glue); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] dwc2: remove redundant D0 power state set
Pci_enable_device() will set device power state to D0, so it's no need to do it again in dwc2_driver_probe(). Signed-off-by: Yijing Wang wangyij...@huawei.com --- drivers/staging/dwc2/pci.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/staging/dwc2/pci.c b/drivers/staging/dwc2/pci.c index 69c65eb..6a196c2 100644 --- a/drivers/staging/dwc2/pci.c +++ b/drivers/staging/dwc2/pci.c @@ -131,8 +131,6 @@ static int dwc2_driver_probe(struct pci_dev *dev, if (!hsotg) return -ENOMEM; - pci_set_power_state(dev, PCI_D0); - hsotg-dev = dev-dev; hsotg-regs = devm_request_and_ioremap(dev-dev, dev-resource[0]); if (!hsotg-regs) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCh V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On 05/29/2013 08:37 PM, Felipe Balbi wrote: Hi, On Wed, May 29, 2013 at 11:58:01AM +0800, Chao Xie wrote: On Wed, May 29, 2013 at 12:24 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, May 13, 2013 at 10:13:44AM -0400, Alan Stern wrote: On Mon, 13 May 2013, Chao Xie wrote: Originaly, ehci driver will call the callbacks in platform data for PHY initialization and shut down. With PHY driver, it will call the APIs provided by PHY driver for PHY initialization and shutdown. It removes the callbacks in platform data, and at same time it removes one block in the way of enabling device tree for ehci driver. I wonder if this is the sort of thing that should be handled in ehci-hcd.c rather than in all the different platform glue drivers. Felipe, what do you think? Are the required actions now sufficiently generic that a single source file can take care of them? Sorry for the delay, was on business trip and now on vacations. Anyway, I agree with you. Our PHY layer should be generic enough that it should be usable by ehci-hcd itself. If we have any missing method, let's add it generically. So what are your idea about making the PHY layer more generic? How ehci-hcd will make use of PHY layer? on probe grab the phy and initialize it. On suspend/resume, suspend/resume the PHY and so on. Whatever you were going to do on your ehci glue, do it on generic ehci-hcd. These operations sound generic enough to be done at HCD layer, no? So no need to replicate the same stuff in ohci, ehci, xhci, etc. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: config-desc.bLength may not exceed amount of data returned by the device
While reading the config parsing code I noticed this check is missing, without
this check config-desc.wTotalLength can end up with a value larger then the
dev-rawdescriptors length for the config, and when userspace then tries to
get the rawdescriptors bad things may happen.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 7199adc..a6b2cab 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -424,7 +424,8 @@ static int usb_parse_configuration(struct usb_device *dev,
int cfgidx,
memcpy(config-desc, buffer, USB_DT_CONFIG_SIZE);
if (config-desc.bDescriptorType != USB_DT_CONFIG ||
- config-desc.bLength USB_DT_CONFIG_SIZE) {
+ config-desc.bLength USB_DT_CONFIG_SIZE ||
+ config-desc.bLength size) {
dev_err(ddev, invalid descriptor for config index %d:
type = 0x%X, length = %d\n, cfgidx,
config-desc.bDescriptorType, config-desc.bLength);
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] proc_usb_info.txt: Correct documentation about endianness of config descriptors
The config descriptors as read from /proc/bus/usb/BBB/DDD are in *bus* endian format. Correct proc_usb_info.txt to correctly reflect that. Signed-off-by: Hans de Goede hdego...@redhat.com --- Documentation/usb/proc_usb_info.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/usb/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt index c9c3f0f..70bdcef 100644 --- a/Documentation/usb/proc_usb_info.txt +++ b/Documentation/usb/proc_usb_info.txt @@ -54,9 +54,12 @@ it and 002/048 sometime later. These files can be read as binary data. The binary data consists of first the device descriptor, then the descriptors for each -configuration of the device. Multi-byte fields in the device and -configuration descriptors, but not other descriptors, are converted -to host endianness by the kernel. This information is also shown +configuration of the device. Multi-byte fields in the device descriptor +are converted to host endianness by the kernel. The configuration +descriptors are in bus endian format! The configuration descriptor +are wTotalLength bytes apart. If a device returns less configuration +descriptor data then indicated by wTotalLength there will be a hole in +the file for the missing bytes. This information is also shown in text form by the /proc/bus/usb/devices file, described later. These files may also be used to write user-level drivers for the USB -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] Documentation sysfs-bus-usb: Correct use of devnum
Correct use of devnum in supports_autosuspend documentation, the sysfs path contains busnum-port.port.port not busnum-devnum (which is the usb bus device address). Signed-off-by: Hans de Goede hdego...@redhat.com --- Documentation/ABI/testing/sysfs-bus-usb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index c8baaf5..bbccdbf 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -60,7 +60,7 @@ Users: PowerTOP po...@bughost.org http://www.lesswatts.org/projects/powertop/ -What: /sys/bus/usb/device/busnum-devnum...:config num-interface num/supports_autosuspend +What: /sys/bus/usb/devices/busnum-port[.port]...:config num-interface num/supports_autosuspend Date: January 2008 KernelVersion: 2.6.27 Contact: Sarah Sharp sarah.a.sh...@intel.com -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] Documentation sysfs-bus-usb: Document all files used by libusb
Signed-off-by: Hans de Goede hdego...@redhat.com --- Documentation/ABI/testing/sysfs-bus-usb | 29 + 1 file changed, 29 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index bbccdbf..0778140 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -236,3 +236,32 @@ Description: This attribute is to expose these information to user space. The file will read hotplug, wired and not used if the information is available, and unknown otherwise. + +What: /sys/bus/usb/devices/.../devnum +KernelVersion: since atleast 2.6.18 +Description: + Device address on the USB bus. + +What: /sys/bus/usb/devices/.../bConfigurationValue +KernelVersion: since atleast 2.6.18 +Description: + bConfigurationValue of the *active* configuration for the + device. + +What: /sys/bus/usb/devices/.../busnum +KernelVersion: 2.6.22 +Description: + Bus-number of the USB-bus the device is connected to. + +What: /sys/bus/usb/devices/.../descriptors +KernelVersion: 2.6.26 +Description: + Binary file containing cached descriptors of the device. The + binary data consists of first the device descriptor, and then + the descriptors for each configuration of the device. + Note that the wTotalLength of the config descriptors can not + be trusted, as the device may have a smaller config descriptor + then it advertises. The bLength field of each (sub) descriptor + can be trusted, and can be used to seek forward one (sub) + descriptor at a time until the next config descriptor is found. + All descriptors read from this file are in bus-endian format -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Connection to a 3G USB Module using USB-Serial
I'm struggling with this issue since a while and as the author of the USB-Serial module I thought experts here might provide some help... As it's a USB-serail issue, I've posted on both USB and Serial lists. thanks in advance! The problem is about connecting with a 3G USB modem, a ZTE MF-210 mini-pci board; plugged as a daughter board inside an Android tablet. I have posted already on a couple forums, but got no useful feedback yet. As soon as I power up the module I get the expected /dev/ttyUSB0-3 and that's fine, so far: 6usb 1-1.1: new high speed USB device using emxx-ehci-driver and address 3 6option 1-1.1:1.0: GSM modem (1-port) converter detected 6usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB0 6option 1-1.1:1.1: GSM modem (1-port) converter detected 6usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB1 6option 1-1.1:1.2: GSM modem (1-port) converter detected 6usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB2 6option 1-1.1:1.3: GSM modem (1-port) converter detected 6usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB3 Issue is when I try to communicate with any of these ports. I can connect using picocom to all but can't receive any feedback from AT commands sent over to them. I made some partial progress only after using the -i option (i.e. no port init), but below you can find what I get if I simply type A + T + Z + enter, for example. As you can see, characters and commands are repeated several times. That's what I can't understand. Without the -i option, I don't even get any feedback from the modem and the same happens using other connection programs, e.g. busybox microcom. I'm using picocom as it's very small and I succesfully used it already in a similar case, though on a different Android platform and kernel. This Kernel is built including standard usb-serial options below: CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_WWAN=y CONFIG_USB_SERIAL_OPTION=y Is the kernel missing anything, or requiring some special ZTE-specific customizations in your opinion? What are the best connection options I could try? thanks -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: gadget: f_uac2: Fix broken prm to uac2 mapping
From: Jassi Brar jaswinder.si...@linaro.org
prm_to_uac2() is broken because it tests against pointer it itself
mapped onto, which will never be different.
Fix the mapping by adding pointer to parent chip in each rtd param
and removing the prm_to_uac2().
Reported-by: Julien Rouviere jrouvi...@qualistream.com
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/usb/gadget/f_uac2.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/f_uac2.c b/drivers/usb/gadget/f_uac2.c
index c7468b6..2c858a8 100644
--- a/drivers/usb/gadget/f_uac2.c
+++ b/drivers/usb/gadget/f_uac2.c
@@ -90,6 +90,7 @@ struct uac2_req {
};
struct uac2_rtd_params {
+ struct snd_uac2_chip *uac2; /* parent chip */
bool ep_enabled; /* if the ep is enabled */
/* Size of the ring buffer */
size_t dma_bytes;
@@ -169,18 +170,6 @@ struct snd_uac2_chip *pdev_to_uac2(struct platform_device
*p)
}
static inline
-struct snd_uac2_chip *prm_to_uac2(struct uac2_rtd_params *r)
-{
- struct snd_uac2_chip *uac2 = container_of(r,
- struct snd_uac2_chip, c_prm);
-
- if (uac2-c_prm != r)
- uac2 = container_of(r, struct snd_uac2_chip, p_prm);
-
- return uac2;
-}
-
-static inline
uint num_channels(uint chanmask)
{
uint num = 0;
@@ -204,7 +193,7 @@ agdev_iso_complete(struct usb_ep *ep, struct usb_request
*req)
struct uac2_req *ur = req-context;
struct snd_pcm_substream *substream;
struct uac2_rtd_params *prm = ur-pp;
- struct snd_uac2_chip *uac2 = prm_to_uac2(prm);
+ struct snd_uac2_chip *uac2 = prm-uac2;
/* i/f shutting down */
if (!prm-ep_enabled)
@@ -896,7 +885,7 @@ struct cntrl_range_lay3 {
static inline void
free_ep(struct uac2_rtd_params *prm, struct usb_ep *ep)
{
- struct snd_uac2_chip *uac2 = prm_to_uac2(prm);
+ struct snd_uac2_chip *uac2 = prm-uac2;
int i;
prm-ep_enabled = false;
@@ -972,6 +961,9 @@ afunc_bind(struct usb_configuration *cfg, struct
usb_function *fn)
}
agdev-in_ep-driver_data = agdev;
+ uac2-p_prm.uac2 = uac2;
+ uac2-c_prm.uac2 = uac2;
+
hs_epout_desc.bEndpointAddress = fs_epout_desc.bEndpointAddress;
hs_epout_desc.wMaxPacketSize = fs_epout_desc.wMaxPacketSize;
hs_epin_desc.bEndpointAddress = fs_epin_desc.bEndpointAddress;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chipidea usb otg support for IMX/MXS (device functionality)
Hi Michael, On Wed, May 29, 2013 at 02:41:08PM +0200, Michael Grzeschik wrote: Peters patches need some more care, as they are not cleanly sperated. One patch e.g. adds an delayed worker to handle the otg events. Another one above that patch is removing the worker afterwards. I see, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Serial ports for Septentrio USB GNSS receiver
Hello list! I'm using a http://www.septentrio.com/products/receivers/asterx2i-oem INS/GNSS receiver. When connected via USB to a windows-host, there's two (or even three, don't remember exactly) virtual serial ports to talk to it. When connected to a 3.8.0-19-generic #30-Ubuntu SMP i686 GNU/Linux system, I only see /dev/ttyACM0. I'd really like to get access to the second virtual com port, so I tried setting options usbserial vendor=0x152a product=0x8230 in /etc/modprobe.d/septentrio.conf. Doing this, I get /dev/ttyUSB0 - dmesg says: usbcore: registered new interface driver usbserial usbcore: registered new interface driver usbserial_generic usbserial: USB Serial support registered for generic usbserial_generic 3-2:1.0: Generic device with no bulk out, not allowed. usbserial_generic: probe of 3-2:1.0 failed with error -5 usbserial_generic 3-2:1.1: The generic usb-serial driver is only for testing and one-off prototypes. usbserial_generic 3-2:1.1: Tell linux-usb@vger.kernel.org to add your device to a proper driver. usbserial_generic 3-2:1.1: generic converter detected usb 3-2: generic converter now attached to ttyUSB0 ttyUSB0 does work for communicating with the device, but there's no second port (this trick did work with some NovAtel receivers). Is there a way to make the other virtual COM port appear? # lsusb -d 152a:8230 -v Bus 003 Device 002: ID 152a:8230 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x152a idProduct 0x8230 bcdDevice1.10 iManufacturer 1 Septentrio iProduct2 Septentrio USB Device iSerial 0 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 91 bNumInterfaces 4 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol255 Vendor Specific (MSFT RNDIS?) iInterface 0 CDC Header: bcdCDC 1.01 CDC ACM: bmCapabilities 0x0e connection notifications sends break line coding and serial state Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol255 Vendor specific iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol255 Vendor Specific (MSFT RNDIS?) iInterface 0 CDC Header: bcdCDC 1.01 CDC ACM: bmCapabilities 0x0e connection notifications sends break line coding and serial state Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol255 Vendor specific iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type
Re: [PATCh V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On Thu, 30 May 2013, Roger Quadros wrote: So what are your idea about making the PHY layer more generic? How ehci-hcd will make use of PHY layer? on probe grab the phy and initialize it. On suspend/resume, suspend/resume the PHY and so on. Whatever you were going to do on your ehci glue, do it on generic ehci-hcd. These operations sound generic enough to be done at HCD layer, no? So no need to replicate the same stuff in ohci, ehci, xhci, etc. The HCD layer handles suspend and resume only for PCI host controllers. Not for other types. I don't know if the acquire/start and stop/release parts can be moved into the USB core. Maybe they can. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
On Thu, 30 May 2013, victor yeo wrote: I tested the g_zero with USB 2.0 Command Verifier. After the Command Verifier is run, the UDC gadget driver queue function is continuously being called, and the linux command prompt is frozen. Please see the attached UDC driver log. It looks like endpoint 1 in direction is called by USB 2.0 Command Verifier continuously. Is this weird? I don't know. You can't tell what's going on just by looking at the gadget. You have to know what the host is doing as well. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: config-desc.bLength may not exceed amount of data returned by the device
On Thu, 30 May 2013, Hans de Goede wrote:
While reading the config parsing code I noticed this check is missing, without
this check config-desc.wTotalLength can end up with a value larger then the
dev-rawdescriptors length for the config, and when userspace then tries to
get the rawdescriptors bad things may happen.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 7199adc..a6b2cab 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -424,7 +424,8 @@ static int usb_parse_configuration(struct usb_device
*dev, int cfgidx,
memcpy(config-desc, buffer, USB_DT_CONFIG_SIZE);
if (config-desc.bDescriptorType != USB_DT_CONFIG ||
- config-desc.bLength USB_DT_CONFIG_SIZE) {
+ config-desc.bLength USB_DT_CONFIG_SIZE ||
+ config-desc.bLength size) {
dev_err(ddev, invalid descriptor for config index %d:
type = 0x%X, length = %d\n, cfgidx,
config-desc.bDescriptorType, config-desc.bLength);
Another thing that should be changed along with this is in line 710:
} else if (result 4) {
really should be
} else if (result != USB_DT_CONFIG_SIZE) {
Otherwise we may read a garbage value for desc-wTotalLength.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Documentation sysfs-bus-usb: Document all files used by libusb
On Thu, 30 May 2013, Hans de Goede wrote: +What:/sys/bus/usb/devices/.../bConfigurationValue +KernelVersion: since atleast 2.6.18 s/atleast/at least/ and ditto for the preceding entry. +Description: + bConfigurationValue of the *active* configuration for the + device. Here we need to mention that writing to bConfigurationValue will change or reset the active configuration. Note that some devices, in violation of the USB spec, have a configuration with value equal to 0. Writing 0 to bConfigurationValue for these devices will install that configuration; to unconfigure the device, write -1 to bConfigurationValue. (This also works with compliant devices.) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: config-desc.bLength may not exceed amount of data returned by the device
Hi,
On 05/30/2013 04:51 PM, Alan Stern wrote:
On Thu, 30 May 2013, Hans de Goede wrote:
While reading the config parsing code I noticed this check is missing, without
this check config-desc.wTotalLength can end up with a value larger then the
dev-rawdescriptors length for the config, and when userspace then tries to
get the rawdescriptors bad things may happen.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 7199adc..a6b2cab 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -424,7 +424,8 @@ static int usb_parse_configuration(struct usb_device *dev,
int cfgidx,
memcpy(config-desc, buffer, USB_DT_CONFIG_SIZE);
if (config-desc.bDescriptorType != USB_DT_CONFIG ||
- config-desc.bLength USB_DT_CONFIG_SIZE) {
+ config-desc.bLength USB_DT_CONFIG_SIZE ||
+ config-desc.bLength size) {
dev_err(ddev, invalid descriptor for config index %d:
type = 0x%X, length = %d\n, cfgidx,
config-desc.bDescriptorType, config-desc.bLength);
Another thing that should be changed along with this is in line 710:
} else if (result 4) {
really should be
} else if (result != USB_DT_CONFIG_SIZE) {
Otherwise we may read a garbage value for desc-wTotalLength.
Erm, no wTotalLength is byte 3 and 4, so the original check covers it.
I actually had a patch such as you suggested, but then thought it would
be better to leave things as is, so as to avoid regressions, in case
some crazy device has result = 4 result USB_DT_CONFIG_SIZE on
the first (header only) usb_get_descriptor call.
For the second (full) usb_get_descriptor call, my patch already ensures
that result = USB_DT_CONFIG_SIZE.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chipidea usb otg support for IMX/MXS (device functionality)
Dear Maxime, On 05/29/2013 09:50 AM, maxime.rip...@free-electrons.com wrote: Hi, On Wed, May 29, 2013 at 07:11:30AM +, Chen Peter-B29397 wrote: Hello, Am I right in assuming that the MXS USB on-the-go port does not currently support the device (gadget) functionality? Anybody out there working on that? As far as I know, Maxime Ripard may already let the chipidea durl-role function work ok at mx28. It may need my chipidea otg patch https://github.com/hzpeterchen/linux-usb.git Indeed, I've been using the patchset Add tested id switch and vbus connect detect support for Chipidea from Peter for quite some time on top of 3.9 and it works like a charm for the gadget mode on an MX28 platform. BTW, Peter, I've seen that these patches are still not merged in 3.10, is there a reason for that? do you plan on sending a version rebased on top of 3.10 some time in the future? I tried to do the rebasing myself, but the chipidea driver seems to have changed quite heavily, which makes the process quite difficult when you don't know what you're doing :) I guess you didn't get rid of the 'possible circular locking dependency' you talked about at [1], right? I experimented the same and also a BUG [2] after cable reconnection. Despite those, I ran a simple test of serial, ethernet, and mass_storage gadgets and they worked fine. I didn't use the new properties (phy_type, dr_mode...) in the DT of my mx28 platform, did you? [1] https://lkml.org/lkml/2013/3/6/200 [2] [ 1949.074726] BUG: spinlock lockup suspected on CPU#0, swapper/0 [ 1949.080623] lock: 0xcf41f014, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [ 1949.088184] [c001510c] (unwind_backtrace+0x0/0xf4) from [c0273754] (do_raw_spin_lock+0x104/0x14c) [ 1949.097463] [c0273754] (do_raw_spin_lock+0x104/0x14c) from [c045893c] (_raw_spin_lock_irqsave+0x50/0x5c) [ 1949.107340] [c045893c] (_raw_spin_lock_irqsave+0x50/0x5c) from [c03467f8] (ep_disable+0x30/0xfc) [ 1949.116541] [c03467f8] (ep_disable+0x30/0xfc) from [bf00a19c] (gserial_disconnect+0x9c/0x174 [g_serial]) [ 1949.126447] [bf00a19c] (gserial_disconnect+0x9c/0x174 [g_serial]) from [bf00a288] (acm_disable+0xc/0x2c [g_serial]) [ 1949.137325] [bf00a288] (acm_disable+0xc/0x2c [g_serial]) from [bf000930] (reset_config+0x34/0x5c [libcomposite]) [ 1949.147931] [bf000930] (reset_config+0x34/0x5c [libcomposite]) from [bf000fd0] (composite_disconnect+0x34/0x5c [libcomposite]) [ 1949.159737] [bf000fd0] (composite_disconnect+0x34/0x5c [libcomposite]) from [c0347b14] (udc_irq+0x1d8/0xbe4) [ 1949.169951] [c0347b14] (udc_irq+0x1d8/0xbe4) from [c0345830] (ci_irq+0x9c/0x104) [ 1949.177751] [c0345830] (ci_irq+0x9c/0x104) from [c006cb50] (handle_irq_event_percpu+0x5c/0x26c) [ 1949.186847] [c006cb50] (handle_irq_event_percpu+0x5c/0x26c) from [c006cd9c] (handle_irq_event+0x3c/0x5c) [ 1949.196716] [c006cd9c] (handle_irq_event+0x3c/0x5c) from [c006f3c8] (handle_level_irq+0x8c/0x118) [ 1949.205976] [c006f3c8] (handle_level_irq+0x8c/0x118) from [c006cae4] (generic_handle_irq+0x28/0x30) [ 1949.215421] [c006cae4] (generic_handle_irq+0x28/0x30) from [c001009c] (handle_IRQ+0x30/0x84) [ 1949.224246] [c001009c] (handle_IRQ+0x30/0x84) from [c00086ec] (icoll_handle_irq+0x30/0x44) [ 1949.232897] [c00086ec] (icoll_handle_irq+0x30/0x44) from [c000ee24] (__irq_svc+0x44/0x54) [ 1949.241438] Exception stack(0xc0627f68 to 0xc0627fb0) [ 1949.246520] 7f60: c0010278 0005317f 0005217f 6013 c0626000 c0667c88 [ 1949.254729] 7f80: c0631980 7fff 40004000 41069265 4061c574 60d3 c0627fb0 [ 1949.262926] 7fa0: c0010278 c0010284 6013 [ 1949.268023] [c000ee24] (__irq_svc+0x44/0x54) from [c0010284] (default_idle+0x40/0x48) [ 1949.276244] [c0010284] (default_idle+0x40/0x48) from [c00105b8] (cpu_idle+0x68/0xd0) [ 1949.284380] [c00105b8] (cpu_idle+0x68/0xd0) from [c0600810] (start_kernel+0x258/0x298) [ 1953.034550] gadget: high-speed config #2: CDC ACM config Regards, -- Héctor Palacios -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] proc_usb_info.txt: Correct documentation about endianness of config descriptors
2013/5/30 Hans de Goede: +are wTotalLength bytes apart. If a device returns less configuration +descriptor data then indicated by wTotalLength there will be a hole in s/then/than/ -- Daniele Forsi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: config-desc.bLength may not exceed amount of data returned by the device
On Thu, 30 May 2013, Hans de Goede wrote:
Hi,
On 05/30/2013 04:51 PM, Alan Stern wrote:
On Thu, 30 May 2013, Hans de Goede wrote:
While reading the config parsing code I noticed this check is missing,
without
this check config-desc.wTotalLength can end up with a value larger then
the
dev-rawdescriptors length for the config, and when userspace then tries to
get the rawdescriptors bad things may happen.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 7199adc..a6b2cab 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -424,7 +424,8 @@ static int usb_parse_configuration(struct usb_device
*dev, int cfgidx,
memcpy(config-desc, buffer, USB_DT_CONFIG_SIZE);
if (config-desc.bDescriptorType != USB_DT_CONFIG ||
- config-desc.bLength USB_DT_CONFIG_SIZE) {
+ config-desc.bLength USB_DT_CONFIG_SIZE ||
+ config-desc.bLength size) {
dev_err(ddev, invalid descriptor for config index %d:
type = 0x%X, length = %d\n, cfgidx,
config-desc.bDescriptorType, config-desc.bLength);
Another thing that should be changed along with this is in line 710:
} else if (result 4) {
really should be
} else if (result != USB_DT_CONFIG_SIZE) {
Otherwise we may read a garbage value for desc-wTotalLength.
Erm, no wTotalLength is byte 3 and 4, so the original check covers it.
Oh, you're right. I must have had that in mind when going through this
code years ago, and then forgot about it. :-)
I actually had a patch such as you suggested, but then thought it would
be better to leave things as is, so as to avoid regressions, in case
some crazy device has result = 4 result USB_DT_CONFIG_SIZE on
the first (header only) usb_get_descriptor call.
For the second (full) usb_get_descriptor call, my patch already ensures
that result = USB_DT_CONFIG_SIZE.
Yes, okay. This is fine then.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Documentation sysfs-bus-usb: Document all files used by libusb
2013/5/30 Hans de Goede: + be trusted, as the device may have a smaller config descriptor + then it advertises. The bLength field of each (sub) descriptor as in the other text: s/then/than/ -- Daniele Forsi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] USB: OHCI: make ohci-platform a separate driver
On Thu, 30 May 2013, Manjunath Goudar wrote:
This patch splits the ohci-platform code from ohci-hcd out
into its own separate driver module.This work is part of enabling
multi-platform kernels on ARM.
Okay, except...
+static const struct ohci_driver_overrides platform_overrides = {
+ .product_desc = Generic Platform EHCI controller,
+ .reset =ohci_platform_reset,
};
Don't forget the __initconst annotation. After that is fixed, you can
add my Acked-by.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] USB: OHCI: add a name for the platform-private field
On Thu, 30 May 2013, Manjunath Goudar wrote: This patch adds an ohci-priv field for private use by OHCI platform drivers. Until now none of the platform drivers has used this private space, but that's about to change in the next patch of this series. As far as I'm concerned, this doesn't need to be in a patch of its own. It can be merged into the 1/3 patch of the previous series. After all, that patch adds the extra_priv_size field in ohci_driver_overrides, which doesn't make much sense unless there's a way to refer to the private part of the ohci_hcd structure. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] USB: OHCI: make ohci-platform a separate driver
Hello.
On 05/30/2013 09:23 PM, Alan Stern wrote:
This patch splits the ohci-platform code from ohci-hcd out
into its own separate driver module.This work is part of enabling
multi-platform kernels on ARM.
Okay, except...
+static const struct ohci_driver_overrides platform_overrides = {
+ .product_desc = Generic Platform EHCI controller,
Maybe OHCI? :-)
Alan Stern
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: xhci: rename ambiguous named XHCI_NEC_HOST to XHCI_NEC_SHOW_FW
On Thu, May 30, 2013 at 06:16:34AM +0200, Alexander Holler wrote: Am 30.05.2013 00:25, schrieb Sarah Sharp: On Wed, May 29, 2013 at 11:14:32PM +0200, Alexander Holler wrote: Current Renesas Electronics XHCI hosts (which were formerly NEC) do support the same vendor command to show the firmware. Rename the ambigious named define XHCI_NEC_HOST to XHCI_NEC_SHOW_FW because it's only used to display the firmware version. Besides that, change the output ... NEC firmware version x.y to ... firmware version x.y to not confuse owners of Renesas USB hosts. (so only cosmetic, no functional changes) I'm actually inclined to say you should just rip out the firmware version code entirely. I haven't needed to use it for years, and if Renesas changed their vendor command set, I would rather not submit random commands to the host. So, can you redo this patch to just rip out XHCI_NEC_HOST and everything that uses it? Hmm, I find the firmware version rather informational and would even display it unconditionally (instead of with xhci_debug). It prevents the need to boot Windows to checkout if the latest version is installed, especially if someone is hunting a bug. Below is the patch I'm using locally on top of the two previous patches. Feel free to use/submit/merge it too. Regards, Alexander Holler From 9bf9e555600626b87371a8825c2557bdf5621e76 Mon Sep 17 00:00:00 2001 From: Alexander Holler hol...@ahsoftware.de Date: Thu, 30 May 2013 18:04:14 +0200 Subject: [PATCH] USB: xhci: always show the firmware version for NEC/Renesas hosts Signed-off-by: Alexander Holler hol...@ahsoftware.de --- drivers/usb/host/xhci-ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 761d566..8873b3e 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1493,7 +1493,7 @@ bandwidth_change: xhci-error_bitmask |= 1 6; break; } - xhci_dbg(xhci, firmware version %2x.%02x\n, + dev_info(xhci_to_hcd(xhci)-self.controller, firmware version %2x.%02x\n, NEC_FW_MAJOR(le32_to_cpu(event-status)), NEC_FW_MINOR(le32_to_cpu(event-status))); break; -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: Addition of dr_mode dt property.
This patch adds the possibility of the mode being specified in a device
tree. This allows the scenario when there maybe multiple USB subsystems
operating in different modes.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 22 ++
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..5c4db93 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. This could be gadget, host,
+ drd.
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..cf211be 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,7 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
-
+ char*dr_mode;
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
dev_err(dev, not enough memory\n);
@@ -520,9 +520,23 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
- else
- mode = DWC3_MODE_DRD;
-
+ else {
+ if (of_property_read_string(node, dr_mode, dr_mode)) {
+ dev_warn(dev, Missing dr_mode so assuming
DWC3_MODE_DRD\n);
+ mode = DWC3_MODE_DRD;
+ } else {
+ if (strcmp(dr_mode, host) == 0)
+ mode = DWC3_MODE_HOST;
+ else if (strcmp(dr_mode, gadget) == 0)
+ mode = DWC3_MODE_DEVICE;
+ else if (strcmp(dr_mode, drd) == 0)
+ mode = DWC3_MODE_DRD;
+ else {
+ dev_err(dev, invalid dr_mode property
value\n);
+ goto err0;
+ }
+ }
+ }
switch (mode) {
case DWC3_MODE_DEVICE:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB3 SSD/HD device file disappears after eject
On Thu, 30 May 2013, Grant wrote: There are two things you can do to help diagnose this. One is to build a kernel with CONFIG_USB_DEBUG enabled and then post the portion of the dmesg log showing what happens when you eject, unplug, and replug the device. I've enabled CONFIG_USB_DEBUG. Here is the output after mounting in Thunar and then the sequence you specified: [ 2536.683944] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) [ 2539.556586] sd 16:0:0:0: [sdb] Synchronizing SCSI cache [ 2543.885054] xhci_hcd :02:00.0: Port Status Change Event for port 3 [ 2543.885070] xhci_hcd :02:00.0: handle_port_status: starting port polling. [ 2543.885156] hub 4-0:1.0: state 7 ports 2 chg evt 0002 [ 2543.885255] xhci_hcd :02:00.0: get port status, actual port 0 status = 0x202c0 [ 2543.885261] xhci_hcd :02:00.0: Get port status returned 0x102c0 [ 2543.885300] xhci_hcd :02:00.0: clear port connect change, actual port 0 status = 0x2c0 [ 2543.885307] hub 4-0:1.0: warm reset port 1 [ 2544.050074] xhci_hcd :02:00.0: xhci_hub_status_data: stopping port polling. [ 2548.139118] xhci_hcd :02:00.0: Port Status Change Event for port 3 [ 2548.139132] xhci_hcd :02:00.0: handle_port_status: starting port polling. I've attached dmesg.txt which contains the output after mounting in Thunar, ejecting in Thunar, and waiting a minute or two. I can't make much out of that, except that the warm reset seems suspicious. Maybe it will mean more to Sarah. I should also mention that unmounting in Thunar or using umount seems to work fine and causes no problems. Ejecting seems to trigger the problem. What about the second part of my suggestion, capturing a usbmon trace? That will probably be more informative. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/7] dwc2: remove redundant D0 power state set
From: Yijing Wang [mailto:wangyij...@huawei.com] Sent: Thursday, May 30, 2013 3:24 AM Pci_enable_device() will set device power state to D0, so it's no need to do it again in dwc2_driver_probe(). Signed-off-by: Yijing Wang wangyij...@huawei.com --- drivers/staging/dwc2/pci.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/staging/dwc2/pci.c b/drivers/staging/dwc2/pci.c index 69c65eb..6a196c2 100644 --- a/drivers/staging/dwc2/pci.c +++ b/drivers/staging/dwc2/pci.c @@ -131,8 +131,6 @@ static int dwc2_driver_probe(struct pci_dev *dev, if (!hsotg) return -ENOMEM; - pci_set_power_state(dev, PCI_D0); - hsotg-dev = dev-dev; hsotg-regs = devm_request_and_ioremap(dev-dev, dev-resource[0]); if (!hsotg-regs) -- 1.7.1 Acked-by: Paul Zimmerman pa...@synopsys.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: xhci: rename ambiguous named XHCI_NEC_HOST to XHCI_NEC_SHOW_FW
On Thu, May 30, 2013 at 06:16:34AM +0200, Alexander Holler wrote: Am 30.05.2013 00:25, schrieb Sarah Sharp: On Wed, May 29, 2013 at 11:14:32PM +0200, Alexander Holler wrote: Current Renesas Electronics XHCI hosts (which were formerly NEC) do support the same vendor command to show the firmware. Rename the ambigious named define XHCI_NEC_HOST to XHCI_NEC_SHOW_FW because it's only used to display the firmware version. Besides that, change the output ... NEC firmware version x.y to ... firmware version x.y to not confuse owners of Renesas USB hosts. (so only cosmetic, no functional changes) I'm actually inclined to say you should just rip out the firmware version code entirely. I haven't needed to use it for years, and if Renesas changed their vendor command set, I would rather not submit random commands to the host. So, can you redo this patch to just rip out XHCI_NEC_HOST and everything that uses it? Hmm, I find the firmware version rather informational and would even display it unconditionally (instead of with xhci_debug). It prevents the need to boot Windows to checkout if the latest version is installed, especially if someone is hunting a bug. Right, but we need to stop sending commands to Renesas hosts that don't support this command. We don't know what that command does in the hosts that don't support the firmware version command. For all we know, we could be setting the host into a debugging mode, or asking it to only report USB 2.0 device connects, or other things that I can't imagine. The point is that unless Renesas tells us how to know if a host supports the firmware fetch vendor command, we should stop issuing that command to the host. I think my contacts at Renesas have moved onto other jobs, but maybe you know someone there? I just dont't like the name, because e.g. in my case, it made me to have a deeper look at what that quirk does, because I had the hope it might solve a problem. Therefor I think it's useful to rename it. I understand. If the command worked fine on all Renesas hosts, I would be fine with renaming it and printing it with dev_info instead of xhci_dbg. However, since some Renesas hosts don't support the command, I'm concerned we may be forced to rip out the code. If you don't do it, I will have to. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] xHCI and USB security bug fixes
On Wed, May 29, 2013 at 10:45:04AM -0700, Sarah Sharp wrote: On Wed, May 29, 2013 at 10:27:50AM +0900, Greg Kroah-Hartman wrote: On Fri, May 24, 2013 at 05:42:52PM -0700, Sarah Sharp wrote: This patchset address some (but not all) of the security issues found with the Klockwork static analysis tool. I have not reviewed these in detail to see if these could be used by attackers, so someone with more security experience may want to look these over. A lot of these changes are just to add checks to functions that you are calling yourself. How can those pointers be not valid when you control what you pass to them? It's purely paranoia. It's entirely possible we'll add new code later that would accidentally trigger these checks. That's especially true of, say, the device speeds, since USB 3.1 (10Gbps) is in the works. Then let's worry about it at that point in time :) Those seems over-eager, and not really needed. Or am I missing somewhere that could change the pointer without the driver knowing it? In all honesty, these patches are the result of a bureaucratic push for code quality. We switched static analysis tools from Coverity to Klockwork, and the QA folks pushed us to fix the issues that Klockwork discovered. If you don't think they're appropriate, let me know, and I'll push back. It is great to get rid of the BUG_ON() calls. But to be over-eager in checking parameters that we have full control of is not needed at all. So if you rework the patches to just clean up the BUG_ON() calls, I'll be glad to accept them, but they aren't security issues at all. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 35/39] dmaengine: ste_dma40_ll: Replace meaningless register set with comment
On Thu, May 30, 2013 at 11:04:23AM +0200, Linus Walleij wrote: On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: Unsure of the author's intentions, rather than just removing the nop, we're replacing it with a comment containing the possible intention of the statement OR:ing with 0. Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Cc: Per Forlin per.for...@stericsson.com Cc: Rabin Vincent ra...@rab.in Signed-off-by: Lee Jones lee.jo...@linaro.org Tentatively applied. Missing Vinod's ACK. Acked-by: Vinod Koul vinod.k...@intel.com -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Misbehaving device
On Wed, 29 May 2013, Joe Julian wrote: On 05/22/2013 12:27 PM, Alan Stern wrote: On Wed, 22 May 2013, Joe Julian wrote: On 05/21/2013 03:20 PM, Joe Julian wrote: I have about 100 of these creditcard/check scanners that are dropping events. I was able to find some overflows that I assume are probably related to the problem, usb 4-1: ctrl urb status -75 received. Short of asking the vendor to fix their product or compiling a custom kernel, are there any other options? Can the MaxPacketSize or the buffer size be overridden somehow (/sys/bus/usb/devices... maybe)? I have started a dialog with UIC (Uniform Industrial Corp) about a fix, but I'm not very hopeful. Is there anything I can do to work around the overflow? Without knowing more (like where the overflows occur and what data was expected), it is impossible to answer this question. A usbmon trace would help. I spent the day at one of our stores capturing data from a small handful of customer loyalty cards I picked up for this purpose. I was able to capture 2 bad scans. If I'm reading this correctly, there's nothing wrong that could be corrected from the linux side, could you confirm? I agree. In fact, the usbmon trace doesn't show any errors at all. I think that overflow was a red herring as none occurred during the bad scans. Could be. All the transfers to endpoint 0 in the trace are to turn some output indicator on or off. Maybe an LED or something of the sort. The best example is the last scan of the Qdoba card that ends in I (7th from the bottom). What is that an example of? The usbmon capture is at http://joejulian.name/media/uploads/usbcapture.usbmon.gz The expected scan data was successive scans of the following cards: %B6277200522629830^^391200077861?[ %B6277200522629848^^391200017860?S %B6277200522629855^^391200027724?S %B6277200522629863^^391200055339?[ %B6277200522629871^^391200079146?\ %B6010565032591577^QDOBA/VALUELINK^2501000460072408 ?@ %B6010565032591494^QDOBA/VALUELINK^2501000460073301 ?C %B6010565032591700^QDOBA/VALUELINK^2501000460076767 ?L %B6010565032591551^QDOBA/VALUELINK^2501000460073264 ?I %B6010565032591536^QDOBA/VALUELINK^2501000460075630 ?K %B6010565032591528^QDOBA/VALUELINK^2501000460072347 ?F %B6010565032591569^QDOBA/VALUELINK^2501000460075724 ?E %B6010565032591544^QDOBA/VALUELINK^2501000460075630 ?N %B6010565032591502^QDOBA/VALUELINK^2501000460074630 ?M %B6010565032591510^QDOBA/VALUELINK^2501000460074982 ?H I don't have any way to match up these strings against the data in the trace. For example, it looks like the scan of the first card got something like 69 keystrokes. They don't seem to bear any relation to the expected scan data above; for example, the fifth and sixth keystrokes aren't the same. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb-audio regression 3.8.5-3.9.2
On Thu, 30 May 2013, Tobias Diedrich wrote: Alan Stern wrote: On Sat, 25 May 2013, Tobias Diedrich wrote: I've recently upgraded my kernel from 3.8.5 to 3.9.2 and ran into an issue with usb-audio: With two different usb-headsets, pulseaudio is now regularily losing the microphone audio stream (which just gets 'stuck', i.e. the level indicator bar in pavucontrol doesn't move anymore, but is not at 0). Every time this happens I get kernel messages like these: May 25 11:05:01 nukunuku kernel: [43611.510661] delay: estimated 221, actual 0 May 25 11:06:02 nukunuku kernel: [43672.086015] delay: estimated 222, actual 1 May 25 11:06:02 nukunuku kernel: [43672.102018] delay: estimated 133, actual 0 May 25 11:07:03 nukunuku kernel: [43733.814401] delay: estimated 133, actual 0 May 25 11:08:02 nukunuku kernel: [43792.636147] delay: estimated 89, actual 0 May 25 11:10:03 nukunuku kernel: [43913.539550] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539610] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539622] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539630] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539637] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539643] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539658] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539664] cannot submit urb (err = -18) Now, replugging the headset fixes the issue temporarily until it happens again, but that's a bit annoying if you're in a video call... 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) usb-audio devices in question: Bus 003 Device 004: ID 041e:0401 Creative Technology, Ltd Bus 004 Device 002: ID 041e:30df Creative Technology, Ltd Bus 004 Device 003: ID 047f:c009 Plantronics, Inc. Please post the contents of /sys/kernel/debug/usb/devices. Still happens on 3.9.4 (although it only happened once there so far, and not (yet?) on the XHCI port, which I previously hadn't compiled in the drivers for (new board)). It's odd that the devices listing shows only one Creative headset: bus 8 (which uses xHCI) device 2. The other headset, Plantronics, is bus 4 (OHCI) device 2. So this problem occurs only when a headset is attached to an OHCI controller, right? Can you collect a usbmon trace that shows the error? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
HI On Thu, May 30, 2013 at 09:12:11AM +0100, Lee Jones wrote: On Thu, 30 May 2013, Linus Walleij wrote: On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi ba...@ti.com wrote: On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote: For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org for drivers/usb/musb Acked-by: Felipe Balbi ba...@ti.com Is that only for this patch 20/39 or also 21, 22 23? Poke us if we should re-send them... I read this as all patches in the series for drivers/usb/musb. right :-) Should've sent on patch 0/39, my bad. cheers -- balbi signature.asc Description: Digital signature
Re: usb-audio regression 3.8.5-3.9.2
On Thu, 30 May 2013, Alan Stern wrote: On Thu, 30 May 2013, Tobias Diedrich wrote: Alan Stern wrote: On Sat, 25 May 2013, Tobias Diedrich wrote: I've recently upgraded my kernel from 3.8.5 to 3.9.2 and ran into an issue with usb-audio: With two different usb-headsets, pulseaudio is now regularily losing the microphone audio stream (which just gets 'stuck', i.e. the level indicator bar in pavucontrol doesn't move anymore, but is not at 0). By the way, this may be fixed by commit e1944017839d7dfbf7329fac4bdec8b4050edf5e (USB: fix latency in uhci-hcd and ohci-hcd), which is in the current 3.10-rc kernel and is scheduled to go into 3.9.stable but isn't there yet. Try it and see. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: Addition of dr_mode dt property.
On 05/30/2013 12:56 PM, Ruchika Kharwar wrote:
This patch adds the possibility of the mode being specified in a device
tree. This allows the scenario when there maybe multiple USB subsystems
operating in different modes.
Nitpick. Maybes and possibilities can we get more concrete statements?
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 22 ++
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..5c4db93 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. This could be gadget, host,
+ drd.
change to a more concrete statement.
dr_mode: determines the mode of the DWC core. Modes supported are gadget,
host, drd
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..cf211be 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,7 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
-
+ char*dr_mode;
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
dev_err(dev, not enough memory\n);
@@ -520,9 +520,23 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
- else
- mode = DWC3_MODE_DRD;
-
+ else {
+ if (of_property_read_string(node, dr_mode, dr_mode)) {
This will not execute if the either CONFIG options are set and then the DT
property is not even honored
Did you test this with multiple CONFIG options?
There seems to be a conflict between CONFIGs and runtime operation.
+ dev_warn(dev, Missing dr_mode so assuming
DWC3_MODE_DRD\n);
If dr_mode is an optional parameter why would the dev_warn say it is missing?
Do we even want to warn here?
+ mode = DWC3_MODE_DRD;
+ } else {
+ if (strcmp(dr_mode, host) == 0)
+ mode = DWC3_MODE_HOST;
What if CONFIG_USB_DWC3_HOST is not enabled?
+ else if (strcmp(dr_mode, gadget) == 0)
+ mode = DWC3_MODE_DEVICE;
What if CONFIG_USB_DWC3_GADGET is not enabled?
+ else if (strcmp(dr_mode, drd) == 0)
+ mode = DWC3_MODE_DRD;
+ else {
+ dev_err(dev, invalid dr_mode property
value\n);
+ goto err0;
This should be err1 since core init is called prior to this
+ }
+ }
+ }
switch (mode) {
case DWC3_MODE_DEVICE:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
--
--
Dan Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] jacinto6 : usb3_phy: Updated dpll M,N values.
Addition of the M and N recommended values for the USB3 PHY DPLL.
Sysclk for DRA7xx is 20MHz.
This yields:
Clk = 20MHz * M/(N+1) = 20MHz * 1000 /(7+1) = 2.5 Ghz
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/phy/phy-omap-usb3.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index a6e60b1..efe6e14 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -27,7 +27,7 @@
#include linux/delay.h
#include linux/usb/omap_control_usb.h
-#defineNUM_SYS_CLKS5
+#defineNUM_SYS_CLKS6
#definePLL_STATUS 0x0004
#definePLL_GO 0x0008
#definePLL_CONFIGURATION1 0x000C
@@ -62,6 +62,7 @@ enum sys_clk_rate {
CLK_RATE_12MHZ,
CLK_RATE_16MHZ,
CLK_RATE_19MHZ,
+ CLK_RATE_20MHZ,
CLK_RATE_26MHZ,
CLK_RATE_38MHZ
};
@@ -72,6 +73,8 @@ static struct usb_dpll_params
omap_usb3_dpll_params[NUM_SYS_CLKS] = {
{1172, 8, 4, 20, 65537},/* 19.2 MHz */
{1250, 12, 4, 20, 0}, /* 26 MHz */
{3125, 47, 4, 20, 92843}, /* 38.4 MHz */
+ {1000, 7, 4, 10, 0},/* 20 MHz */
+
};
static int omap_usb3_suspend(struct usb_phy *x, int suspend)
@@ -122,6 +125,8 @@ static inline enum sys_clk_rate
__get_sys_clk_index(unsigned long rate)
return CLK_RATE_16MHZ;
case 1920:
return CLK_RATE_19MHZ;
+ case 2000:
+ return CLK_RATE_20MHZ;
case 2600:
return CLK_RATE_26MHZ;
case 3840:
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: Addition of dr_mode dt property.
This patch adds an optional parameter dr_mode to the dwc3 core device node.
In the case the compile flag for the DWC3 controller is set to
USB_DWC3_DUAL_ROLE a device tree could restrain to either functionality of
host or gadget. In the case the device tree does not use this optional flag or
specifies it superfluously to drd the functionality will be that
of a dual role device.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 21 +
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..2f5d584 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. Supported modes are gadget, host
+ and drd.
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..e11660a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,7 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
-
+ char*dr_mode;
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
dev_err(dev, not enough memory\n);
@@ -520,9 +520,22 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
- else
- mode = DWC3_MODE_DRD;
-
+ else {
+ if (of_property_read_string(node, dr_mode, dr_mode))
+ mode = DWC3_MODE_DRD;
+ else {
+ if (strcmp(dr_mode, host) == 0)
+ mode = DWC3_MODE_HOST;
+ else if (strcmp(dr_mode, gadget) == 0)
+ mode = DWC3_MODE_DEVICE;
+ else if (strcmp(dr_mode, drd) == 0)
+ mode = DWC3_MODE_DRD;
+ else {
+ dev_err(dev, invalid dr_mode property
value\n);
+ goto err2;
+ }
+ }
+ }
switch (mode) {
case DWC3_MODE_DEVICE:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB multiplatform work?
* Felipe Balbi ba...@ti.com [130528 09:42]: Hi, On Mon, May 27, 2013 at 05:02:09PM +0200, Arnd Bergmann wrote: Hi Felipe, We've gone through remaining work items for getting the ARM kernel to full multiplatform support again, and MUSB came up. I'm sure you have your own thoughts on this, but I'd like to know if there is already a plan in place. From what I can see, the driver in PIO mode should almost work on multiple platforms, but there are a couple of compile-time dependencies in it that need to be turned into run-time conditionals. In particular the TUSB version seem sufficiently different that it needs some extra work to be a true run-time option. yeah, TUSB layer is quite messy, all the others should be doable though. TUSB we can make depend on ARMv7, the only implementation we have is for omap2420, which is ARMv6. This should solve the issue for ARMv7 multiplatform builds for now. The DMA support as far as I can tell has never been intended to be usable in a multiplatform setup, but that also seems doable. we're looking into dmaengine for that but will take a lot of work to have something usable. TUSB would work with dmaengine, but AFAIK we're still missing the dmaengine configuration options to support increasing device end FIFO address. Looking just at the #ifdef statements in the driver, I found that the following things need to be addressed: * abstract musb_write_fifo and musb_read_fifo into callbacks * move fifo_mode setting into glue driver for runtime selection for the fifo mode, I'd rather detect the size of the internal fifo and configure it dynamically based on that plus number of endpoints configured in the IP. * turn TUSB compile-time switches into run-time conditionals * turn musb_ep_select into run-time switch * make is_dma_capable/is_cppi_enabled/tusb_dma_omap run-time conditionals those can be remove, actually. Back at Nokia we did a huge cleanup on the DMA programming part, it can be very simple with no ifdefs at all, just needs someone to put the work and test on all platforms. * abtract dma_controller_create/destroy interface Aside from this, a recent discussion with Maxime has brought up that the Allwinner A1x platform (mach-sunxi) contains an MUSB variant that is currently used with an independently implemented device driver, see https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/drivers/usb/sun5i_usb I wonder if you have any insight on how that can be integrated into musb, or whether it is likely to be a compatible version to start with. just write a glue layer, should be as easy as that :-) Yes the MUSB code should be able to support it considering the number of implementations we already have there. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: Addition of dr_mode dt property.
Hello.
On 05/31/2013 12:14 AM, Ruchika Kharwar wrote:
This patch adds an optional parameter dr_mode to the dwc3 core device node.
In the case the compile flag for the DWC3 controller is set to
USB_DWC3_DUAL_ROLE a device tree could restrain to either functionality of
host or gadget. In the case the device tree does not use this optional flag or
specifies it superfluously to drd the functionality will be that
of a dual role device.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 21 +
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..2f5d584 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. Supported modes are gadget, host
+ and drd.
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..e11660a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,7 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
-
+ char*dr_mode;
Please leave empty line here, after the declarations.
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
dev_err(dev, not enough memory\n);
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB multiplatform work?
On Thu, May 30, 2013 at 10:18 PM, Tony Lindgren t...@atomide.com wrote: TUSB would work with dmaengine, but AFAIK we're still missing the dmaengine configuration options to support increasing device end FIFO address. Can you elaborate on this? What is the usecase here? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: Addition of dr_mode dt property.
This patch adds an optional parameter dr_mode to the dwc3 core device node.
In the case the compile flag for the DWC3 controller is set to
USB_DWC3_DUAL_ROLE a device tree could restrain to either functionality of
host or gadget. In the case the device tree does not use this optional flag or
specifies it superfluously to drd the functionality will be that
of a dual role device.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 20 +---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..2f5d584 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. Supported modes are gadget, host
+ and drd.
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..05c0c8b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,6 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
+ char*dr_mode;
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
@@ -520,9 +521,22 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
- else
- mode = DWC3_MODE_DRD;
-
+ else {
+ if (of_property_read_string(node, dr_mode, dr_mode))
+ mode = DWC3_MODE_DRD;
+ else {
+ if (strcmp(dr_mode, host) == 0)
+ mode = DWC3_MODE_HOST;
+ else if (strcmp(dr_mode, gadget) == 0)
+ mode = DWC3_MODE_DEVICE;
+ else if (strcmp(dr_mode, drd) == 0)
+ mode = DWC3_MODE_DRD;
+ else {
+ dev_err(dev, invalid dr_mode property
value\n);
+ goto err2;
+ }
+ }
+ }
switch (mode) {
case DWC3_MODE_DEVICE:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB multiplatform work?
* Linus Walleij linus.wall...@linaro.org [130530 13:27]: On Thu, May 30, 2013 at 10:18 PM, Tony Lindgren t...@atomide.com wrote: TUSB would work with dmaengine, but AFAIK we're still missing the dmaengine configuration options to support increasing device end FIFO address. Can you elaborate on this? What is the usecase here? There are many devices where the device FIFO is memory mapped to the GPMC bus on omaps, like TUSB, OneNAND, smc911x etc. I believe the only reason why these have not been converted to the dmaengine is the fact that dmaengine cannot configure the DMA hardware to do autoincrement and loop over the device FIFO. You can see an example of this in tusb_omap_dma_program() if you look at the various dma_params entries and omap_set_dma_* functions. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: Addition of dr_mode dt property.
Fix spelling in my own comments
On 05/30/2013 03:31 PM, Dan Murphy wrote:
On 05/30/2013 03:14 PM, Ruchika Kharwar wrote:
This patch adds an optional parameter dr_mode to the dwc3 core device node.
In the case the compile flag for the DWC3 controller is set to
USB_DWC3_DUAL_ROLE a device tree could restrain to either functionality of
host or gadget. In the case the device tree does not use this optional flag
or
specifies it superfluously to drd the functionality will be that
of a dual role device.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Can you add patch history if this is truly a new patch to a previous
submission
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 21 +
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..2f5d584 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. Supported modes are gadget,
host
+ and drd.
My previous comments still stand for this section. Nothing was addressed or
commented back
https://patchwork.kernel.org/patch/2638511/
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..e11660a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,7 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
-
+char*dr_mode;
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
dev_err(dev, not enough memory\n);
@@ -520,9 +520,22 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
-else
-mode = DWC3_MODE_DRD;
-
+else {
+if (of_property_read_string(node, dr_mode, dr_mode))
+mode = DWC3_MODE_DRD;
+else {
+if (strcmp(dr_mode, host) == 0)
+mode = DWC3_MODE_HOST;
+else if (strcmp(dr_mode, gadget) == 0)
+mode = DWC3_MODE_DEVICE;
+else if (strcmp(dr_mode, drd) == 0)
+mode = DWC3_MODE_DRD;
My previous comments still stand for this section. Nothing was addressed or
commented back
https://patchwork.kernel.org/patch/2638511/
+else {
+dev_err(dev, invalid dr_mode property
value\n);
+goto err2;
This is still wrong. You have not initialized and of the device's
s/and/any
+}
+}
+}
switch (mode) {
case DWC3_MODE_DEVICE:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
Is this a new patch?
Subject should say v2.
--
--
Dan Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB multiplatform work?
* Tony Lindgren t...@atomide.com [130530 13:25]: TUSB we can make depend on ARMv7, the only implementation we have is for omap2420, which is ARMv6. This should solve the issue for ARMv7 multiplatform builds for now. Sorry mean depend on !ARMv7. But thinking about it more, that does not make much sense as it would break things for omap2plus_defconfig at least which is multiplatform v6 and v7. For now TUSB can be made to depend on MACH_NOKIA_N8X0. I doubt that anybody is using the add on cards for H4 boards any longer.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB multiplatform work?
On Thu, May 30, 2013 at 10:31 PM, Tony Lindgren t...@atomide.com wrote: There are many devices where the device FIFO is memory mapped to the GPMC bus on omaps, like TUSB, OneNAND, smc911x etc. I believe the only reason why these have not been converted to the dmaengine is the fact that dmaengine cannot configure the DMA hardware to do autoincrement and loop over the device FIFO. OK that seems like something pretty generic that we could just add to the struct dma_slave_config actually, something like: u32 src_fifoloop; u32 dst_fifoloop; Given in # of words on the src/dst address simply, left as zero for hitting a constant address over and over again. We'd need both to make space for device-device transfers. If this is all that is needed to convert them do DMAengine I'd surely ACK it (FWIW). Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb-audio regression 3.8.5-3.9.2
Alan Stern wrote: On Thu, 30 May 2013, Tobias Diedrich wrote: Alan Stern wrote: On Sat, 25 May 2013, Tobias Diedrich wrote: I've recently upgraded my kernel from 3.8.5 to 3.9.2 and ran into an issue with usb-audio: With two different usb-headsets, pulseaudio is now regularily losing the microphone audio stream (which just gets 'stuck', i.e. the level indicator bar in pavucontrol doesn't move anymore, but is not at 0). Every time this happens I get kernel messages like these: May 25 11:05:01 nukunuku kernel: [43611.510661] delay: estimated 221, actual 0 May 25 11:06:02 nukunuku kernel: [43672.086015] delay: estimated 222, actual 1 May 25 11:06:02 nukunuku kernel: [43672.102018] delay: estimated 133, actual 0 May 25 11:07:03 nukunuku kernel: [43733.814401] delay: estimated 133, actual 0 May 25 11:08:02 nukunuku kernel: [43792.636147] delay: estimated 89, actual 0 May 25 11:10:03 nukunuku kernel: [43913.539550] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539610] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539622] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539630] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539637] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539643] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539658] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539664] cannot submit urb (err = -18) Now, replugging the headset fixes the issue temporarily until it happens again, but that's a bit annoying if you're in a video call... 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) usb-audio devices in question: Bus 003 Device 004: ID 041e:0401 Creative Technology, Ltd Bus 004 Device 002: ID 041e:30df Creative Technology, Ltd Bus 004 Device 003: ID 047f:c009 Plantronics, Inc. Please post the contents of /sys/kernel/debug/usb/devices. Still happens on 3.9.4 (although it only happened once there so far, and not (yet?) on the XHCI port, which I previously hadn't compiled in the drivers for (new board)). It's odd that the devices listing shows only one Creative headset: bus The second creative device is just a soundcard, didn't have it plugged in in this dump. 8 (which uses xHCI) device 2. The other headset, Plantronics, is bus 4 (OHCI) device 2. So this problem occurs only when a headset is attached to an OHCI controller, right? Probably. I specifically went and compiled in the XHCI driver and attached the headset there to see if it is controller-specific. It hasn't happened while plugged into that port so far, but I almost never use it during the week, only on weekends. Can you collect a usbmon trace that shows the error? I can try it this weekend. Thanks, -- Tobias PGP: http://8ef7ddba.uguu.de -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb-audio regression 3.8.5-3.9.2
Alan Stern wrote: On Thu, 30 May 2013, Alan Stern wrote: On Thu, 30 May 2013, Tobias Diedrich wrote: Alan Stern wrote: On Sat, 25 May 2013, Tobias Diedrich wrote: I've recently upgraded my kernel from 3.8.5 to 3.9.2 and ran into an issue with usb-audio: With two different usb-headsets, pulseaudio is now regularily losing the microphone audio stream (which just gets 'stuck', i.e. the level indicator bar in pavucontrol doesn't move anymore, but is not at 0). By the way, this may be fixed by commit e1944017839d7dfbf7329fac4bdec8b4050edf5e (USB: fix latency in uhci-hcd and ohci-hcd), which is in the current 3.10-rc kernel and is scheduled to go into 3.9.stable but isn't there yet. Try it and see. Sure, will try, thanks. -- Tobias PGP: http://8ef7ddba.uguu.de -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: Addition of dr_mode dt property.
On 05/30/2013 03:35 PM, Dan Murphy wrote:
Fix spelling in my own comments
On 05/30/2013 03:31 PM, Dan Murphy wrote:
On 05/30/2013 03:14 PM, Ruchika Kharwar wrote:
This patch adds an optional parameter dr_mode to the dwc3 core device node.
In the case the compile flag for the DWC3 controller is set to
USB_DWC3_DUAL_ROLE a device tree could restrain to either functionality of
host or gadget. In the case the device tree does not use this optional flag or
specifies it superfluously to drd the functionality will be that
of a dual role device.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Can you add patch history if this is truly a new patch to a previous submission
Will do in the next pach submitted.
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 21 +
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..2f5d584 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. Supported modes are gadget, host
+ and drd.
My previous comments still stand for this section. Nothing was addressed or
commented back
https://patchwork.kernel.org/patch/2638511/
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..e11660a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,7 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
-
+ char*dr_mode;
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
dev_err(dev, not enough memory\n);
@@ -520,9 +520,22 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
- else
- mode = DWC3_MODE_DRD;
-
+ else {
+ if (of_property_read_string(node, dr_mode, dr_mode))
+ mode = DWC3_MODE_DRD;
+ else {
+ if (strcmp(dr_mode, host) == 0)
+ mode = DWC3_MODE_HOST;
+ else if (strcmp(dr_mode, gadget) == 0)
+ mode = DWC3_MODE_DEVICE;
+ else if (strcmp(dr_mode, drd) == 0)
+ mode = DWC3_MODE_DRD;
My previous comments still stand for this section. Nothing was addressed or
commented back
https://patchwork.kernel.org/patch/2638511/
DRD mode is the super set mode for Host and Gadget. The compile
time flag is primary. If DRD is set, the host and gadget code is
compiled in.
The dr_mode property can be used *if* specified in the device
tree. A specific example may be a board could have constraints where the
port could only be a host
or gadget. In that case, the dr_mode property is specified
overrides the compile flag.
+ else {
+ dev_err(dev, invalid dr_mode property
value\n);
+ goto err2;
This is still wrong. You have not initialized and of the device's
s/and/any
This is correct as per 3.10-rc3. If you're looking at an older
tree you'd be right.
+ }
+ }
+ }
switch (mode) {
case DWC3_MODE_DEVICE:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
Is this a new patch?
Subject should say v2.
Yes, my bad.. learning.. next patch will have it.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] usb: dwc3: use extcon fwrk to receive connect/disconnect notification
On 05/24/2013 11:31 PM, Kishon Vijay Abraham I wrote:
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 80
+--
include/linux/usb/dwc3-omap.h | 30
2 files changed, 62 insertions(+), 48 deletions(-)
delete mode 100644 include/linux/usb/dwc3-omap.h
Hi Kishon,
Thi patch is suspended until fix following build error.
(If kernel builds extcon fwr as module, dwc3-omap.c happen error message)
---
tree: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon extcon-next
head: 30f5d6ea2561c2a54e40b1e8e8f9bb30e064e01b
commit: 30f5d6ea2561c2a54e40b1e8e8f9bb30e064e01b [3/3] usb: dwc3: use extcon
fwrk to receive connect/disconnect notification
config: i386-randconfig-x14-0530 (attached as .config)
All error/warnings:
drivers/built-in.o: In function `dwc3_omap_remove':
dwc3-omap.c:(.text+0x8c0fa): undefined reference to
`extcon_unregister_interest'
dwc3-omap.c:(.text+0x8c102): undefined reference to
`extcon_unregister_interest'
drivers/built-in.o: In function `dwc3_omap_probe':
dwc3-omap.c:(.text+0x8c5e6): undefined reference to `extcon_get_extcon_dev'
dwc3-omap.c:(.text+0x8c6a4): undefined reference to
`extcon_register_interest'
dwc3-omap.c:(.text+0x8c6c9): undefined reference to
`extcon_register_interest'
dwc3-omap.c:(.text+0x8c831): undefined reference to `extcon_get_cable_state'
dwc3-omap.c:(.text+0x8c851): undefined reference to `extcon_get_cable_state'
---
Also, I missed a issue of this patch. If h/w target use other USB device
instead of palmas-usb, dwc-omap.c driver won't be operating.
So, I propose two method about this issue.
First, we can get extcon device name through platform data or dt.
Two, When use extcon_register_interest() to register notifier block,
NULL pointer pass to extcon_register_interest() instead of specific extcon
device name(palmas-usb). If extcon_register_interest() check NULL
pointer of extcon device name parameter, extcon fwr will find previous
registered extcon device and then register notifier block of consumer
device driver(dwc3-omap.c) to previous registered extcon device.
+ edev = extcon_get_extcon_dev(palmas-usb);
+ if (!edev) {
+ dev_dbg(dev, couldn't get extcon device\n);
+ return -EPROBE_DEFER;
+ }
+
spin_lock_init(omap-lock);
omap-dev = dev;
omap-irq = irq;
omap-base = base;
+ omap-vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
+ extcon_register_interest(omap-extcon_vbus_dev, palmas-usb, USB,
+ omap-vbus_nb);
+ omap-id_nb.notifier_call = dwc3_omap_id_notifier;
+ extcon_register_interest(omap-extcon_id_dev, palmas-usb, USB-HOST,
+ omap-id_nb);
dev-dma_mask = dwc3_omap_dma_mask;
+
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: xhci: rename ambiguous named XHCI_NEC_HOST to XHCI_NEC_SHOW_FW
Am 30.05.2013 20:20, schrieb Sarah Sharp: On Thu, May 30, 2013 at 06:16:34AM +0200, Alexander Holler wrote: The point is that unless Renesas tells us how to know if a host supports the firmware fetch vendor command, we should stop issuing that command to the host. I think my contacts at Renesas have moved onto other jobs, but maybe you know someone there? No, sorry. I just dont't like the name, because e.g. in my case, it made me to have a deeper look at what that quirk does, because I had the hope it might solve a problem. Therefor I think it's useful to rename it. I understand. If the command worked fine on all Renesas hosts, I would be fine with renaming it and printing it with dev_info instead of xhci_dbg. However, since some Renesas hosts don't support the command, I'm concerned we may be forced to rip out the code. If you don't do it, I will have to. I don't want to do it as it works fine on my Renesas upd720202. Instead of removing this feature completely, you could just use the first patch and forget the second one. So only NEC hosts will still have it and I assume there will not any new appear, as they are now Renesas. Another possibility would be to use the device ID too (for Renesas devices), mine has 0x0015. The reason why I really like this feature is that there were already 2-3 firmware updates and since USB 3.0 still isn't that widely used, I assume more will appear if more people actually start using such devices. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH -next] usb: fusbh200-hcd: fix error handling in fusbh200_hcd_fusbh200_probe()
-Original Message- From: Wei Yongjun [mailto:weiyj...@gmail.com] Sent: Tuesday, May 21, 2013 10:41 AM To: gre...@linuxfoundation.org; Wendy Yuan-Hsin Chen(陳元馨) Cc: yongjun_...@trendmicro.com.cn; linux-usb@vger.kernel.org Subject: [PATCH -next] usb: fusbh200-hcd: fix error handling in fusbh200_hcd_fusbh200_probe() From: Wei Yongjun yongjun_...@trendmicro.com.cn Fix to release all resources when fusbh200_setup() fail instead of only return error. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Yuan-Hsin Chen yhc...@faraday-tech.com --- drivers/usb/host/fusbh200-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/fusbh200-hcd.c b/drivers/usb/host/fusbh200-hcd.c index 79ce799..7f3293b 100644 --- a/drivers/usb/host/fusbh200-hcd.c +++ b/drivers/usb/host/fusbh200-hcd.c @@ -5864,7 +5864,7 @@ static int fusbh200_hcd_fusbh200_probe(struct platform_device *pdev) retval = fusbh200_setup(hcd); if (retval) - return retval; + goto fail_add_hcd; fusbh200_init(fusbh200); * Confidentiality Notice This electronic message and any attachments may contain confidential and legally privileged information or information which is otherwise protected from disclosure. If you are not the intended recipient,please do not disclose the contents, either in whole or in part, to anyone,and immediately delete the message and any attachments from your computer system and destroy all hard copies. Thank you for your cooperation. ***
Re: MUSB multiplatform work?
On Thu, May 30, 2013 at 01:54:49PM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130530 13:25]: TUSB we can make depend on ARMv7, the only implementation we have is for omap2420, which is ARMv6. This should solve the issue for ARMv7 multiplatform builds for now. Sorry mean depend on !ARMv7. But thinking about it more, that does not make much sense as it would break things for omap2plus_defconfig at least which is multiplatform v6 and v7. For now TUSB can be made to depend on MACH_NOKIA_N8X0. I doubt that anybody is using the add on cards for H4 boards any longer.. could also be made to depend on BROKEN. I don't think anyone *really* cares about that glue layer other than the very few in the world who still like the nostalgic feeling of booting current linux releases on n8x0 devices. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: Addition of dr_mode dt property.
Hi,
On Thu, May 30, 2013 at 02:53:10PM -0500, Dan Murphy wrote:
@@ -520,9 +520,23 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
- else
- mode = DWC3_MODE_DRD;
-
+ else {
+ if (of_property_read_string(node, dr_mode, dr_mode)) {
This will not execute if the either CONFIG options are set and then
the DT property is not even honored
Did you test this with multiple CONFIG options?
There seems to be a conflict between CONFIGs and runtime operation.
this is alright. We still want to honor the users who chose to compile
the driver for gadget-only. In that case, there is no choice to be made.
Now, if you build the driver in its entirety (meaning, DRD), you can
still choose in runtime if you want the driver to behave as host-only or
gadget-only.
Picture a situation where you have a single SoC with multiple instances
of this IP and you want to make sure that e.g. ports 1-3 are host-only,
port 4 is peripheral-only and port 5 is DRD.
+ dev_warn(dev, Missing dr_mode so assuming
DWC3_MODE_DRD\n);
If dr_mode is an optional parameter why would the dev_warn say it is missing?
Do we even want to warn here?
Yes. Definitely yes. That would mean a less than optimal DTS file.
Still, for the sake of sensible defaults, we can still choose to work on
DRD mode, assuming full capabilities in case user didn't write proper
DTS, still user should be notified about it.
+ mode = DWC3_MODE_DRD;
+ } else {
+ if (strcmp(dr_mode, host) == 0)
+ mode = DWC3_MODE_HOST;
What if CONFIG_USB_DWC3_HOST is not enabled?
No issues, this will only execute if DRD is enabled, which means both
Host and Device are built in the final binary.
+ else if (strcmp(dr_mode, gadget) == 0)
+ mode = DWC3_MODE_DEVICE;
What if CONFIG_USB_DWC3_GADGET is not enabled?
see above.
--
balbi
signature.asc
Description: Digital signature
