Re: [PATCh V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On Sat, Jun 15, 2013 at 4:01 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 14 Jun 2013, Roger Quadros wrote: hi The following is my understanding. I think for PHY initialization and shutdown part, it is generic for other parts. PHY initialization need to be called before hc_driver-reset is called. I think it can be added at usb_add_hcd. For PHY shutdown, it can be added at usb_remove_hcd. Yes, that should work. I don't think this will work with OMAP USB host controller when used in Transceiver-less mode (e.g. HSIC). In this mode we need to release the HSIC reset (mapped to PHY init), after the EHCI controller is up and running. On the other hand, in the PHY mode, the PHY needs to be initialized (brought out of reset) before the EHCI controller starts. In other words, transceiver-less mode effectively works without using a software-controlled PHY? This behavior might be different on other controllers. Generalization is good as long as there is an override available for the controllers to handle the PHY init/shutdown themselves. To avoid PHY init/shutdown, the platform driver should simply leave the generic PHY pointer (which has not yet been added to struct hcd) set to NULL. So does it mean that i need add adtional usb_phy to struct hcd? I think we can still make use of struct hcd-phy without add addtional members. For OMAP transceiver-less mode, you can still use your own phy init/shutdown and leave the hcd-phy to be NULL, and for the PHY mode, hcd-phy can be set. It will do -init at usb_add_hcd and -shutdown at usb_remove_hcd. 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
Hi, I did another usbmon capture from the moment usb cable is plugged into the Ubuntu x100e laptop. This time the usbmon does not have -75 error. When the SCSI_READ_10 command request for 4096 bytes of data, and the data is returned by the gadget, usbmon simply shows -108 error. The gadget driver log and usbmon trace are attached. Again, the -108 indicates that the host controller disabled the port. The usbmon trace confirms this. I think the most common reason for disabling a port in this way is that the device tried to transmit a packet across a microframe boundary. The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break the 4096 bytes of data into 8 chunks of 512 bytes, before returning them to Ubuntu. I guess it would not be the root cause, won't it? It's hard to say without looking at the signals on the wire. Are you certain the hardware really is sending 512 bytes for each chunk? That's why you need to use a bus analyzer -- to see what's actually going on. I have an important finding. When the problem (SCSI_READ_10 command reads 4096 bytes of data, causing gadget to reset) happens, the PC shows that the gadget is detected as Full-speed device, but gadget reports that it is set to High-speed from: g_file_storage gadget: high-speed config #1 This is printed from do_set_config() in file_storage.c. In UDC driver, it is hardcorded to high speed in UDC driver start function. I changed it to be set depending on hardware value. Now it is: g_file_storage gadget: full-speed config #1 However, in usbmon, the SCSI_READ_10 command still requests for 4096 bytes of data, and this causes gadget to reset. Please see the gadget log, and usbmon trace, and host dmesg log. Thanks, Victor [ 3427.328908] usb 1-5.2: new full speed USB device using ehci_hcd and address 7 [ 3427.421804] usb 1-5.2: not running at top speed; connect to a high speed hub [ 3427.455274] usb-storage 1-5.2:1.0: Quirks match for vid 0525 pid a4a5: 1 [ 3427.457117] scsi3 : usb-storage 1-5.2:1.0 [ 3428.896784] usb 1-5.2: reset full speed USB device using ehci_hcd and address 7 f33fa400 1314593130 C Ci:1:007:0 0 9 = 09022000 010104c0 01 f33fa400 1314593147 S Ci:1:007:0 s 80 06 0200 0020 32 f33fa400 1314593752 C Ci:1:007:0 0 32 = 09022000 010104c0 01090400 00020806 50050705 81024000 00070501 0240 f33fa400 1314593791 S Ci:1:007:0 s 80 06 0300 00ff 255 f33fa400 1314594502 C Ci:1:007:0 0 4 = 04030904 f33fa400 1314594519 S Ci:1:007:0 s 80 06 0302 0409 00ff 255 f33fa400 1314595120 C Ci:1:007:0 0 54 = 36034600 69006c00 65002d00 62006100 63006b00 65006400 20005300 74006f00 f33fa400 1314595918 S Ci:1:007:0 s 80 06 0301 0409 00ff 255 f33fa400 1314596884 C Ci:1:007:0 0 58 = 3a034c00 69006e00 75007800 20003300 2e003400 2e003400 2b002000 77006900 f33fa400 1314597660 S Co:1:007:0 s 00 09 0001 0 f33fa400 1314598122 C Co:1:007:0 0 0 f33fa400 1314599768 S Ci:1:007:0 s 80 06 0304 0409 00ff 255 f33fa400 1314612251 C Ci:1:007:0 0 26 = 1a035300 65006c00 66002d00 70006f00 77006500 72006500 6400 f2e1ee00 1314612435 S Ci:1:007:0 s 80 06 0305 0409 00ff 255 f2e1ee00 1314613115 C Ci:1:007:0 0 26 = 1a034d00 61007300 73002000 53007400 6f007200 61006700 6500 f33a1380 1315254841 S Co:1:003:0 s 23 03 0016 0302 0 f33a1380 1315255168 C Co:1:003:0 0 0 f2e1e400 1315646807 S Ci:1:007:0 s a1 fe 0001 1 f2e1e400 1315647355 C Ci:1:007:0 0 1 = 00 f2e1e400 1315655086 S Bo:1:007:1 -115 31 = 55534243 0100 2400 8612 0024 00 f2e1e400 1315655351 C Bo:1:007:1 0 31 f2ed1a00 1315655414 S Bi:1:007:1 -115 36 f2ed1a00 1315657108 C Bi:1:007:1 0 36 = 0202 1f00 4c696e75 78202020 46696c65 2d53746f 72204761 64676574 f2e1e400 1315657185 S Bi:1:007:1 -115 13 f2e1e400 1315666355 C Bi:1:007:1 0 13 = 55534253 0100 00 f2e1e400 1315708514 S Bo:1:007:1 -115 31 = 55534243 0200 0600 00 f2e1e400 1315708845 C Bo:1:007:1 0 31 f2e1e400 1315708919 S Bi:1:007:1 -115 13 f2e1e400 1315718221 C Bi:1:007:1 0 13 = 55534253 0200 01 f2e1e400 1315718323 S Bo:1:007:1 -115 31 = 55534243 0300 1200 8603 0012 00 f2e1e400 1315718460 C Bo:1:007:1 0 31 f2ed1700 1315718501 S Bi:1:007:1 -115 18 f2ed1700 1315728467 C Bi:1:007:1 0 18 = 7600 000a 2900 f2e1e400 1315728630 S Bi:1:007:1 -115 13 f2e1e400 1315737728 C Bi:1:007:1 0 13 = 55534253 0300 00 f2e1e400 1315738087 S Bo:1:007:1 -115 31 = 55534243 0400 0600 00 f2e1e400 1315738959 C Bo:1:007:1 0 31 f2e1e400 1315739098 S Bi:1:007:1 -115 13 f2e1e400 1315748116 C Bi:1:007:1 0 13 = 55534253 0400 00 f2e1e400 1315748392 S Bo:1:007:1 -115 31 = 55534243 0500 0800 8a25 00 f2e1e400 1315748596 C Bo:1:007:1 0 31 f33faa00 1315748619 S Bi:1:007:1 -115 8 f33faa00 1315758231 C Bi:1:007:1 0 8 =
Re: [GIT PULL] USB patches for v3.11 merge window
On 06/14/2013 10:15 PM, Felipe Balbi wrote: Hi, On Fri, Jun 14, 2013 at 11:28:51AM +0300, Roger Quadros wrote: On 06/13/2013 05:55 PM, Felipe Balbi wrote: HI, On Thu, Jun 13, 2013 at 05:53:50PM +0300, Roger Quadros wrote: On 06/13/2013 05:17 PM, Felipe Balbi wrote: Hi, On Thu, Jun 13, 2013 at 12:05:36PM +0300, Roger Quadros wrote: On 06/13/2013 01:37 AM, Greg KH wrote: On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote: On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote: Hi, On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote: But, I get a build error with your tree pulled in, at the link point in time: ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-omap-usb3.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-omap-usb3.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-nop.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-nop.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-isp1301.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-isp1301.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! ERROR: usb_get_phy [drivers/usb/musb/ux500.ko] undefined! ERROR: usb_put_phy [drivers/usb/musb/ux500.ko] undefined! ERROR: usb_put_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined! ERROR: usb_get_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined! ERROR: devm_usb_get_phy [drivers/usb/gadget/mv_udc.ko] undefined! ERROR: devm_usb_get_phy [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: devm_usb_get_phy_by_phandle [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: usb_get_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined! ERROR: usb_put_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined! ERROR: usb_get_phy [drivers/power/isp1704_charger.ko] undefined! ERROR: usb_put_phy [drivers/power/isp1704_charger.ko] undefined! Any ideas? hmm... I think it was Roger's patches changing the way PHY layer is enabled, do you mind if I drop that for now ? I would have to rebase, but I guess it's a necessary evil at this point. I took the silence as a yes and pushed a new tag with Roger's patches removed. I have also removed one musb patch which wasn't necessary after all. Sorry for the silence, I went to lunch :) Here's an updated pull request, which I have compiled on ARM and x86 and didn't see the linking problem mentioned above: Ok, thanks, I'll try it out now... That worked, now pulled and pushed out, thanks. Hi Greg, I tried to reproduce the above problem but couldn't. Could you please share your .config that caused the issue and the command sequence you used to arrive at the problem? Thanks. By any chance is it possible that there were some stale modules lying around in your tree? The problem shouldn't happen because the symbols are defined in phy.c (USB_PHY) which is selected by the PHY drivers. Even if USB_PHY is not selected, the functions (except usb_add/remove_phy() are defined as inlines in /include/linux/usb/phy.h If CONFIG_USB is set to M you should see the problem since EHCI-OMAP would 'select' (meaning set Y) to the PHY driver. Kbuild won't statically link anything from a directory which was entered due to M. Not sure if that sounds as clear as I expected :-p OK thanks. Maybe setting USB_PHY as tristate should fix it. I'll try it out tomorrow. in your patchset you removed USB_PHY right ? That's what caused the issue. No I didn't remove USB_PHY. Just that it is not user selectable in menuconfig. The following patch fixed it for me. I'll repost the patchset. cheers, -roger --- diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 411c34c..b9bb845 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -43,7 +43,8 @@ obj-$(CONFIG_USB_MICROTEK) += image/ obj-$(CONFIG_USB_SERIAL)+= serial/ -obj-$(CONFIG_USB) += misc/ phy/ +obj-$(CONFIG_USB) += misc/ +obj-$(CONFIG_USB_SUPPORT) += phy/ makes sense, but don't send it now. I can't get this in v3.11 anymore. oops, I had already sent this before your message. This is a minor patch which can wait until v3.12 merge window and I'll make sure to queue it by then, no issues at all. OK. Thanks Felipe. 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
Re: [PATCh V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On 06/14/2013 11:01 PM, Alan Stern wrote: On Fri, 14 Jun 2013, Roger Quadros wrote: hi The following is my understanding. I think for PHY initialization and shutdown part, it is generic for other parts. PHY initialization need to be called before hc_driver-reset is called. I think it can be added at usb_add_hcd. For PHY shutdown, it can be added at usb_remove_hcd. Yes, that should work. I don't think this will work with OMAP USB host controller when used in Transceiver-less mode (e.g. HSIC). In this mode we need to release the HSIC reset (mapped to PHY init), after the EHCI controller is up and running. On the other hand, in the PHY mode, the PHY needs to be initialized (brought out of reset) before the EHCI controller starts. In other words, transceiver-less mode effectively works without using a software-controlled PHY? Right. This behavior might be different on other controllers. Generalization is good as long as there is an override available for the controllers to handle the PHY init/shutdown themselves. To avoid PHY init/shutdown, the platform driver should simply leave the generic PHY pointer (which has not yet been added to struct hcd) set to NULL. For suspend/resume, i do not know how to add it. For our EHCI driver, when system goes to deep idle states, we just directly shutdown the hcd and initialize it again when the system goes back. You shut down the host controller? Then how does it detect wakeup events? And how does it know if a device was disconnected while the power was off? On OMAP as well we are aiming to cut clocks to the host controller (state saved) during bus/system suspend. PHY is in low power mode capable of detecting wakeup events. The SoC is configured to wake up on any I/O activity on the PHY pins. Upon detection of PHY related I/O event, SoC wakes up, we restore the host controller state and proceed as normal. Maybe it's just me, but turning off USB Vbus power during suspend seems like a bad idea. Except for the case where all the root-hub ports are disabled (such as when no devices are plugged in) -- in that case it's fine. We don't turn off Vbus power at all. Just the USB controller IPs clocks (internal to our SoC) are cut off. 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
Re: [PATCH V2 01/10] USB: OHCI: Properly handle ohci-at91 suspend
On 17 June 2013 14:52, Manjunath Goudar manjunath.gou...@linaro.org wrote: when we are using tab characters before do_wakeup and ret variable,we will be getting error below. WARNING: please, no space before tabs #31: FILE: drivers/usb/host/ohci-at91.c:622: +^Ibool ^I^Ido_wakeup = device_may_wakeup(pdev-dev);$ WARNING: please, no space before tabs #32: FILE: drivers/usb/host/ohci-at91.c:623: +^Iint ^I^Iret;$ total: 0 errors, 2 warnings, 27 lines checked That's because you are using both tabs and spaces to align. Just use multiple tabs and remove all spaces. -- 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
staging mailing list dead ?
Hi All, First of all I am sorry to bother all of you, as this might not be the right place to ask this question. But since last few days, I am not able to reach staging mailing list (1), neither I am receiving emails from staging mailing list. As well linux driver project server is unreachable. (2) Can anyone shed some light on what is state of same ? (1) de...@driverdev.osuosl.org (2) www.linuxdriverproject.org/ -- Regards, Rupesh Gujare -- 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 v7 0/9] Generic PHY Framework
Hi, On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on linux mainline tree. Changes from v6 * corrected few typos in Documentation * Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when PHY Subsystem is kept as module and the dependent modules are built-in) * Added if pm_runtime_enabled check before runtime pm calls. Looks good, feel free to add: Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com for patches 1...3/9, 5...7/9 and Tested-by: Sylwester Nawrocki s.nawro...@samsung.com for patch 1/9 Hopefully we can gather more Acks and merge it for 3.11. I have already used this API for our MIPI CSI-2/DSIM DPHYs driver, the RFC patch series can be found at [1]. Thanks, Sylwester [1] http://www.spinics.net/lists/arm-kernel/msg251666.html -- 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 Mon, 17 Jun 2013, Chao Xie wrote: To avoid PHY init/shutdown, the platform driver should simply leave the generic PHY pointer (which has not yet been added to struct hcd) set to NULL. So does it mean that i need add adtional usb_phy to struct hcd? Ah, I was wrong. There already is a PHY pointer in struct usb_hcd. You don't need to add another one. I think we can still make use of struct hcd-phy without add addtional members. For OMAP transceiver-less mode, you can still use your own phy init/shutdown and leave the hcd-phy to be NULL, and for the PHY mode, hcd-phy can be set. It will do -init at usb_add_hcd and -shutdown at usb_remove_hcd. That's right. 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: MUSB multiplatform work?
On Wed, Jun 12, 2013 at 05:27:53PM +0530, Jassi Brar wrote: IIRC, TI's Sundaram Raju proposed a TI specific api to DMAEngine for this very purpose, which was generalized into device_prep_interleaved_dma(). Which I think should already be enough to serve the purpose. Is it not? The interleaved for having to get/set data from interleaved or an 2d array. Think of a raw image from camera where you need to get some region only and skip rest. In those case interleaved API helps Here this is just normal slave DMA with changing FIFO address and which just loops over the FIFO value -- ~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: Linux USB file storage gadget with new UDC
On Mon, 17 Jun 2013, victor yeo wrote: I have an important finding. When the problem (SCSI_READ_10 command reads 4096 bytes of data, causing gadget to reset) happens, the PC shows that the gadget is detected as Full-speed device, but gadget reports that it is set to High-speed from: g_file_storage gadget: high-speed config #1 This is printed from do_set_config() in file_storage.c. In UDC driver, it is hardcorded to high speed in UDC driver start function. I changed it to be set depending on hardware value. Now it is: g_file_storage gadget: full-speed config #1 Yes, I remember mentioning this to you some time ago. However, in usbmon, the SCSI_READ_10 command still requests for 4096 bytes of data, and this causes gadget to reset. Please see the gadget log, and usbmon trace, and host dmesg log. There is a mistake in the previous log file, because the fifo size is still set to 512 byte. Now i change it to 64 byte if it is Full speed. The FIFO size should always be set to the value in the endpoint descriptor, no matter what speed the connection is. The log file are attached. The log shows that your 64-byte transfers don't work very well. The first one didn't send any bytes. The second one sent only 4 bytes. And each of the ones after that sent 0 bytes. Alan Stern PS: Something was very wrong with the log file you posted. It is full of bad characters. You can it here: http://marc.info/?l=linux-usbm=137145486920691w=2 -- 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 0/1] Intel xhci: rework EHCI/xHCI port switching
On Fri, Jun 14, 2013 at 02:23:36PM -0700, Greg KH wrote: On Fri, Jun 14, 2013 at 02:16:50PM -0700, Sarah Sharp wrote: The main thing I'm concerned about is that the patch doesn't handle Intel xHCI host controller PCI hot-plug. We don't really expect any of the Intel PCI hosts to be hot-removed, since they are part of the chipset, but we could dereference a stale pointer if the host was hot-removed. So will there never be add-on PCI Express cards with the Intel host controller on them? What about Expressbus? I have a EHCI Expressbus device around here somewhere... I don't know the answer to that question, but I doubt it. I do have a PCI Express card, but it's a non-Intel host. I don't think it would make sense to have a port switchover with an add-in card anyway. The customer that buys the card would be expecting to install a separate Windows driver for it, so there's no reason to fall back to EHCI. If you think that I shouldn't be that defensive about the code, I'm fine with taking the patch as-is. We should be able to handle hotplug if at all possible. I know the quirk handling issues around PCI hotplug aren't all worked out (or at least they were not a year or so ago), so maybe there's really nothing you can/need to do here. Ok, I'll work with Mathias, and we'll figure out how to handle hot plug. If you have any good suggestions, let me know. 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 PATCH 0/1] Intel xhci: rework EHCI/xHCI port switching
On Mon, 17 Jun 2013, Sarah Sharp wrote: We should be able to handle hotplug if at all possible. I know the quirk handling issues around PCI hotplug aren't all worked out (or at least they were not a year or so ago), so maybe there's really nothing you can/need to do here. Ok, I'll work with Mathias, and we'll figure out how to handle hot plug. If you have any good suggestions, let me know. Sarah, can you go over the issues involved? I'm not entirely clear on all of this. For example, given an xHCI controller with switchable ports, you can't easily tell which EHCI controller those ports are connected to, right? And in fact, you don't even really care. Correct me if I'm wrong here. The original idea was to switch everything over to xHCI during some early stage (like when the xHCI controller is first passed to the pci-quirks.c code) and switch back to EHCI at shutdown. As a refinement, you want to switch over to xHCI again following system resume, in case the BIOS messed things up. Is there anything else? Why does the old code need to be changed? The only problem I see is that it may be a little too elaborate. For example, why bother trying to do the switch when the EHCI controller resumes? Won't everything work okay if you wait until the xHCI controller resumes? Why does the code check so hard to see whether or not there are any switchable ports? Why not just always try to set the switch on any Intel controller? Why is it necessary to search through all the PCI devices? Why is it necessary to store any sort of list of switchable controllers? Why should hot-unplug be an issue? Or multiple xHCI controllers? 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
[PATCH 2/2] musb: musb: dsps: determine the number of instances at runtime
There is no need to hardcode the number of instances here. It is better to
determine them at runtime. Even if the device provides two instances one
might only want to use one of them.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_dsps.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index d9ff390..0ac9934 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -110,8 +110,6 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
- /* number of musb instances */
- u8 instances;
};
/**
@@ -124,6 +122,7 @@ struct dsps_glue {
struct timer_list timer[2]; /* otg_workaround timer */
unsigned long last_timer[2];/* last timer data for each instance */
u32 __iomem *usb_ctrl[2];
+ u8 instances;
};
#defineDSPS_AM33XX_CONTROL_MODULE_PHYS_0 0x44e10620
@@ -646,6 +645,23 @@ static int dsps_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, glue);
+ i = 1;
+ do {
+ iomem = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!iomem) {
+ i--;
+ break;
+ }
+ i++;
+ } while (1);
+
+ glue-instances = i;
+ if (glue-instances 1) {
+ dev_err(pdev-dev, Need atleast iomem for one port.\n);
+ ret = -EINVAL;
+ goto err1_5;
+ }
+
/* enable the usbss clocks */
pm_runtime_enable(pdev-dev);
@@ -656,7 +672,7 @@ static int dsps_probe(struct platform_device *pdev)
}
/* create the child platform device for all instances of musb */
- for (i = 0; i wrp-instances ; i++) {
+ for (i = 0; i glue-instances; i++) {
ret = dsps_create_musb_pdev(glue, i);
if (ret != 0) {
dev_err(pdev-dev, failed to create child pdev\n);
@@ -673,6 +689,7 @@ static int dsps_probe(struct platform_device *pdev)
pm_runtime_put(pdev-dev);
err2:
pm_runtime_disable(pdev-dev);
+err1_5:
kfree(glue-wrp);
err1:
kfree(glue);
@@ -682,11 +699,10 @@ static int dsps_probe(struct platform_device *pdev)
static int dsps_remove(struct platform_device *pdev)
{
struct dsps_glue *glue = platform_get_drvdata(pdev);
- const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
/* delete the child platform device */
- for (i = 0; i wrp-instances ; i++)
+ for (i = 0; i glue-instances; i++)
platform_device_unregister(glue-musb[i]);
/* disable usbss clocks */
@@ -702,10 +718,9 @@ static int dsps_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
- for (i = 0; i wrp-instances; i++)
+ for (i = 0; i glue-instances; i++)
musb_dsps_phy_control(glue, i, 0);
return 0;
@@ -715,10 +730,9 @@ static int dsps_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
- for (i = 0; i wrp-instances; i++)
+ for (i = 0; i glue-instances; i++)
musb_dsps_phy_control(glue, i, 1);
return 0;
@@ -755,7 +769,6 @@ static const struct dsps_musb_wrapper ti81xx_driver_data = {
.rxep_bitmap= (0xfffe 16),
.musb_core_offset = 0x400,
.poll_seconds = 2,
- .instances = 1,
};
static const struct platform_device_id musb_dsps_id_table[] = {
--
1.8.3.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 1/2] musb: musb: dsps: support multiple instances
If we specify right now more than once instance then we attempt to add
the platform device twice. The nop driver does not mind the second add
because it checks for it and returns without a word. At removal time a
segfault is likely because the first intance clean ups the phy and
second, well, goes boom.
This patchs adds two dummy device node to the am33xx for the dummy phy
which we have now. During probe time, we grab the phy based on the
device node if we have one. If not, we use the same hack we used so far.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/am33xx.dtsi | 8
drivers/usb/musb/musb_dsps.c | 18 +-
include/linux/usb/musb.h | 1 +
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8e1248f..30d0d45 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -341,6 +341,14 @@
port1-mode = 3;
power = 250;
ti,hwmods = usb_otg_hs;
+ phys = nopphy0 nopphy1;
+ };
+
+ nopphy0: usbphy@0 {
+ compatible = usb-nop-xceiv;
+ };
+ nopphy1: usbphy@1 {
+ compatible = usb-nop-xceiv;
};
mac: ethernet@4a10 {
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e1b661d..d9ff390 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -415,9 +415,14 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb-mregs += wrp-musb_core_offset;
- /* NOP driver needs change if supporting dual instance */
- usb_nop_xceiv_register();
- musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+ if (!glue-dev-of_node) {
+ /* This hack works only for a single instance. */
+ usb_nop_xceiv_register();
+ musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+ } else {
+ musb-xceiv = devm_usb_get_phy_by_phandle(glue-dev, phys,
+ musb-config-instance);
+ }
if (IS_ERR_OR_NULL(musb-xceiv))
return -EPROBE_DEFER;
@@ -449,7 +454,8 @@ static int dsps_musb_init(struct musb *musb)
return 0;
err0:
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ if (!glue-dev-of_node)
+ usb_nop_xceiv_unregister();
return status;
}
@@ -466,7 +472,8 @@ static int dsps_musb_exit(struct musb *musb)
/* NOP driver needs change if supporting dual instance */
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ if (!glue-dev-of_node)
+ usb_nop_xceiv_unregister();
return 0;
}
@@ -570,6 +577,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue, u8
id)
of_property_read_u32(np, res_name, (u32 *)pdata-mode);
of_property_read_u32(np, power, (u32 *)pdata-power);
config-multipoint = of_property_read_bool(np, multipoint);
+ config-instance = id;
pdata-config = config;
}
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..e027705 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -83,6 +83,7 @@ struct musb_hdrc_config {
u8 vendor_stat __deprecated; /* vendor status reg witdh */
u8 dma_req_chan __deprecated; /* bitmask for required dma
channels */
u8 ram_bits; /* ram address size */
+ u8 instance;
struct musb_hdrc_eps_bits *eps_bits __deprecated;
#ifdef CONFIG_BLACKFIN
--
1.8.3.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
[RFC] Add support for am33xx which has two musb ports
Hi Felipe, so with these two I can use the second port on my am335x-evm in hostmode. After the second ports gets noticed by Linux I see over and over: |musb_bus_suspend 2457: trying to suspend as a_wait_bcon while active Which disappears once I plug in a device and does not come back after I unplug it. Port 0 in device seems to run as well. On the first time i see | CAUTION: musb: Babble Interrupt Occurred | g_ncm gadget: high-speed config #1: CDC Ethernet (NCM) and on the second time I plug it in there is no such babble error. Maybe there is some kind of init missing here. Any comments? Sebastian -- 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: Staging mailing list dead ?
On Mon, Jun 17, 2013 at 10:39:25AM +0100, Rupesh Gujare wrote: Hi All, First of all I am sorry to bother all of you, as this might not be the right place to ask this question. But since last few days, I am not able to reach staging mailing list (1), neither I am receiving emails from staging mailing list. As well linux driver project server is unreachable. (2) Can anyone shed some light on what is state of same ? (1) de...@driverdev.osuosl.org (2) www.linuxdriverproject.org/ The machine is down, along with the mailing list, and people are working on it this week to get the services restored. 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] USB: serial/ftdi_sio.c Fix kernel oops
Hi, On Thu, Jun 13, 2013 at 5:35 AM, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2013-06-07 at 15:14 +0200, Lotfi Manseur wrote: Handle null termios in ftdi_set_termios(), introduced in commit 552f6bf1bb0eda0011c0525dd587aa9e7ba5b846 This has been corrected in the mainline by commits c515598e0f5769916c31c00392cc2bfe6af74e55 and a816e3113b63753c330ca4751ea1d208e93e3015. This is to be fixed in longterm 2.6.32.60 and 3.4.47. This bug has been found with coccinelle. Signed-off-by: Lotfi Manseur lotfi.mans...@imag.fr Signed-off-by: Nicolas Palix nicolas.pa...@imag.fr I've queued up those changes for 3.2. This backported version seems nicer, but we generally prefer to use patches that are as close as possible to those in mainline. Thank you all for your comments. We will be more careful for upcoming reports and patches about the stable branches, and we will privilege mainline patches next time. Regards. Ben. --- drivers/usb/serial/ftdi_sio.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index c374beb..615bd9e 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -2364,7 +2364,8 @@ static void ftdi_set_termios(struct tty_struct *tty, cflag = termios-c_cflag; - if (old_termios-c_cflag == termios-c_cflag + if (old_termios + old_termios-c_cflag == termios-c_cflag old_termios-c_ispeed == termios-c_ispeed old_termios-c_ospeed == termios-c_ospeed) goto no_c_cflag_changes; @@ -2373,7 +2374,8 @@ static void ftdi_set_termios(struct tty_struct *tty, ftdi_sio_read_bulk_callback - need to examine what this means - don't see any problems yet */ - if ((old_termios-c_cflag (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) == + if (old_termios + (old_termios-c_cflag (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) == (termios-c_cflag (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB))) goto no_data_parity_stop_changes; -- Ben Hutchings friends: People who know you well, but like you anyway. -- Nicolas Palix Tel: +33 4 76 51 46 27 http://membres-liglab.imag.fr/palix/ -- 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 Mon, Jun 17, 2013 at 7:13 PM, Vinod Koul vinod.k...@intel.com wrote: On Wed, Jun 12, 2013 at 05:27:53PM +0530, Jassi Brar wrote: IIRC, TI's Sundaram Raju proposed a TI specific api to DMAEngine for this very purpose, which was generalized into device_prep_interleaved_dma(). Which I think should already be enough to serve the purpose. Is it not? The interleaved for having to get/set data from interleaved or an 2d array. Think of a raw image from camera where you need to get some region only and skip rest. In those case interleaved API helps IIRC I designed the interleaved api ;) and I am sure it was not designed solely for async, rather the first users of the api are slave. Here this is just normal slave DMA with changing FIFO address and which just loops over the FIFO value It is possible that I didn't understand the OMAP usecase and the interleave api won't work, but if it does work please let us not introduce yet another api for a 'normal' usecase. In fact my bigger plan was to call the api 'generic' and have it eventually consume most, if not all, dma_transaction_type's but then we couldn't see the same and I got busy with non-dma stuff ... anyways. cheers. -- 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 v2 0/4] Remove BUG() calls from xHCI driver
This is a revised version of the patchset that was originally sent to fix security issues identified by the Klockwork static analysis tool. As discussed, these weren't real security issues, mostly just Klockwork not understanding that BUG() would stop code execution. The older patchset did have some useful improvements, aside from the misguided patch to make the USB core be more robust about handling NULL pointers from usb_hub_to_struct_hub(). As discussed, that could only happen if khubd binds to a hub with no ports, and there's already a fix in Greg's tree to avoid that case. This new patchset focuses solely on removing instances of BUG() from the xHCI driver. It adds code to gracefully handle failures by returning standard error values, and changing the driver to handle those failure cases. These are against Greg's usb-next branch, and are not marked for stable. Please review and comment if this is the right approach. Sarah Sharp The following changes since commit 976f8bef9cfb5246bc0e8dc781562daa79cb7aaf: Merge tag 'usb-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next (2013-06-12 14:44:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git fun-klockwork for you to fetch changes up to 17d655543716791ebf8bb396b674fe95c07e55e4: xhci: remove BUG() in xhci_get_endpoint_type() (2013-06-14 13:53:23 -0700) Mathias Nyman (2): xhci: Remove BUG in xhci_setup_addressable_virt_dev xhci: remove BUG() in xhci_get_endpoint_type() Sarah Sharp (2): xhci: Remove BUG_ON() in xhci_alloc_container_ctx. xhci: Remove BUG_ON in xhci_get_input_control_ctx. drivers/usb/host/xhci-dbg.c |5 ++ drivers/usb/host/xhci-mem.c | 61 - drivers/usb/host/xhci-ring.c |4 + drivers/usb/host/xhci.c | 148 -- 4 files changed, 151 insertions(+), 67 deletions(-) -- 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 v2 4/4] xhci: remove BUG() in xhci_get_endpoint_type()
From: Mathias Nyman mathias.ny...@linux.intel.com
If the endpoint type is unknown, set it to 0 and fail gracefully
instead of causing a kernel panic.
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-mem.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6072f11..b0d789e 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1329,7 +1329,7 @@ static u32 xhci_get_endpoint_type(struct usb_device *udev,
else
type = EP_TYPE(INT_OUT_EP);
} else {
- BUG();
+ type = 0;
}
return type;
}
@@ -1375,10 +1375,16 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
unsigned int max_burst;
enum xhci_ring_type type;
u32 max_esit_payload;
+ u32 endpoint_type;
ep_index = xhci_get_endpoint_index(ep-desc);
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev-in_ctx, ep_index);
+ endpoint_type = xhci_get_endpoint_type(udev, ep);
+ if (!endpoint_type)
+ return -EINVAL;
+ ep_ctx-ep_info2 = cpu_to_le32(endpoint_type);
+
type = usb_endpoint_type(ep-desc);
/* Set up the endpoint ring */
virt_dev-eps[ep_index].new_ring =
@@ -1407,11 +1413,9 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
* CErr shall be set to 0 for Isoch endpoints.
*/
if (!usb_endpoint_xfer_isoc(ep-desc))
- ep_ctx-ep_info2 = cpu_to_le32(ERROR_COUNT(3));
+ ep_ctx-ep_info2 |= cpu_to_le32(ERROR_COUNT(3));
else
- ep_ctx-ep_info2 = cpu_to_le32(ERROR_COUNT(0));
-
- ep_ctx-ep_info2 |= cpu_to_le32(xhci_get_endpoint_type(udev, ep));
+ ep_ctx-ep_info2 |= cpu_to_le32(ERROR_COUNT(0));
/* Set the max packet size and max burst */
max_packet = GET_MAX_PACKET(usb_endpoint_maxp(ep-desc));
--
1.7.9
--
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 v2 3/4] xhci: Remove BUG in xhci_setup_addressable_virt_dev
From: Mathias Nyman mathias.ny...@linux.intel.com
We may have more speed types in the future, so fail gracefully, rather
than causing the kernel to panic.
BUG() was called if the device speed was unknown when setting max packet
size. Set the max packet size at the same time as the slot speed and
get rid of one switch statement with BUG() option completely.
[Note: Sarah merged a patch that she wrote that touched the
xhci_setup_addressable_virt_dev function with this patch from Mathias
for clarity.]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-mem.c | 35 ++-
1 files changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b7487a1..6072f11 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1055,6 +1055,7 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd
*xhci, struct usb_device *ud
struct xhci_ep_ctx *ep0_ctx;
struct xhci_slot_ctx*slot_ctx;
u32 port_num;
+ u32 max_packets;
struct usb_device *top_dev;
dev = xhci-devs[udev-slot_id];
@@ -1072,15 +1073,20 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd
*xhci, struct usb_device *ud
switch (udev-speed) {
case USB_SPEED_SUPER:
slot_ctx-dev_info |= cpu_to_le32(SLOT_SPEED_SS);
+ max_packets = MAX_PACKET(512);
break;
case USB_SPEED_HIGH:
slot_ctx-dev_info |= cpu_to_le32(SLOT_SPEED_HS);
+ max_packets = MAX_PACKET(64);
break;
+ /* USB core guesses at a 64-byte max packet first for FS devices */
case USB_SPEED_FULL:
slot_ctx-dev_info |= cpu_to_le32(SLOT_SPEED_FS);
+ max_packets = MAX_PACKET(64);
break;
case USB_SPEED_LOW:
slot_ctx-dev_info |= cpu_to_le32(SLOT_SPEED_LS);
+ max_packets = MAX_PACKET(8);
break;
case USB_SPEED_WIRELESS:
xhci_dbg(xhci, FIXME xHCI doesn't support wireless speeds\n);
@@ -1088,7 +1094,7 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd
*xhci, struct usb_device *ud
break;
default:
/* Speed was set earlier, this shouldn't happen. */
- BUG();
+ return -EINVAL;
}
/* Find the root hub port this device is under */
port_num = xhci_find_real_port_number(xhci, udev);
@@ -1147,31 +1153,10 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd
*xhci, struct usb_device *ud
/* Step 4 - ring already allocated */
/* Step 5 */
ep0_ctx-ep_info2 = cpu_to_le32(EP_TYPE(CTRL_EP));
- /*
-* XXX: Not sure about wireless USB devices.
-*/
- switch (udev-speed) {
- case USB_SPEED_SUPER:
- ep0_ctx-ep_info2 |= cpu_to_le32(MAX_PACKET(512));
- break;
- case USB_SPEED_HIGH:
- /* USB core guesses at a 64-byte max packet first for FS devices */
- case USB_SPEED_FULL:
- ep0_ctx-ep_info2 |= cpu_to_le32(MAX_PACKET(64));
- break;
- case USB_SPEED_LOW:
- ep0_ctx-ep_info2 |= cpu_to_le32(MAX_PACKET(8));
- break;
- case USB_SPEED_WIRELESS:
- xhci_dbg(xhci, FIXME xHCI doesn't support wireless speeds\n);
- return -EINVAL;
- break;
- default:
- /* New speed? */
- BUG();
- }
+
/* EP 0 can handle burst sizes of 1, so Max Burst Size field is 0 */
- ep0_ctx-ep_info2 |= cpu_to_le32(MAX_BURST(0) | ERROR_COUNT(3));
+ ep0_ctx-ep_info2 |= cpu_to_le32(MAX_BURST(0) | ERROR_COUNT(3) |
+max_packets);
ep0_ctx-deq = cpu_to_le64(dev-eps[0].ring-first_seg-dma |
dev-eps[0].ring-cycle_state);
--
1.7.9
--
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 v2 1/4] xhci: Remove BUG_ON() in xhci_alloc_container_ctx.
It's horrible coding style to panic the kernel when someone passes you
an argument value you didn't expect. In the future, we may want to add
additional context types, so it's better to gracefully handle additional
context types instead of panicking.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: John Youn johny...@synopsys.com
---
drivers/usb/host/xhci-mem.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8c0e119..cc1b3ef 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -358,11 +358,15 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct
xhci_ring *ring,
static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd
*xhci,
int type, gfp_t flags)
{
- struct xhci_container_ctx *ctx = kzalloc(sizeof(*ctx), flags);
+ struct xhci_container_ctx *ctx;
+
+ if ((type != XHCI_CTX_TYPE_DEVICE) (type != XHCI_CTX_TYPE_INPUT))
+ return NULL;
+
+ ctx = kzalloc(sizeof(*ctx), flags);
if (!ctx)
return NULL;
- BUG_ON((type != XHCI_CTX_TYPE_DEVICE) (type != XHCI_CTX_TYPE_INPUT));
ctx-type = type;
ctx-size = HCC_64BYTE_CONTEXT(xhci-hcc_params) ? 2048 : 1024;
if (type == XHCI_CTX_TYPE_INPUT)
--
1.7.9
--
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 v2 2/4] xhci: Remove BUG_ON in xhci_get_input_control_ctx.
Fail gracefully, instead of causing the kernel to panic, if the input
control context doesn't have the right type (XHCI_CTX_TYPE_INPUT). Push
finding the pointer to the input control context up into functions that
can fail.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: John Youn johny...@synopsys.com
---
drivers/usb/host/xhci-dbg.c |5 ++
drivers/usb/host/xhci-mem.c |4 +-
drivers/usb/host/xhci-ring.c |4 +
drivers/usb/host/xhci.c | 148 --
4 files changed, 126 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index f2e7689..5d5e58f 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -553,6 +553,11 @@ void xhci_dbg_ctx(struct xhci_hcd *xhci,
if (ctx-type == XHCI_CTX_TYPE_INPUT) {
struct xhci_input_control_ctx *ctrl_ctx =
xhci_get_input_control_ctx(xhci, ctx);
+ if (!ctrl_ctx) {
+ xhci_warn(xhci, Could not get input context, bad
type.\n);
+ return;
+ }
+
xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - drop flags\n,
ctrl_ctx-drop_flags, (unsigned long long)dma,
ctrl_ctx-drop_flags);
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index cc1b3ef..b7487a1 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -389,7 +389,9 @@ static void xhci_free_container_ctx(struct xhci_hcd *xhci,
struct xhci_input_control_ctx *xhci_get_input_control_ctx(struct xhci_hcd
*xhci,
struct xhci_container_ctx *ctx)
{
- BUG_ON(ctx-type != XHCI_CTX_TYPE_INPUT);
+ if (ctx-type != XHCI_CTX_TYPE_INPUT)
+ return NULL;
+
return (struct xhci_input_control_ctx *)ctx-bytes;
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e02b907..1e57eaf 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1424,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
*/
ctrl_ctx = xhci_get_input_control_ctx(xhci,
virt_dev-in_ctx);
+ if (!ctrl_ctx) {
+ xhci_warn(xhci, Could not get input context, bad
type.\n);
+ break;
+ }
/* Input ctx add_flags are the endpoint index plus one */
ep_index =
xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx-add_flags)) - 1;
/* A usb_set_interface() call directly after clearing a halted
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 77113c1..6779c92 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1235,19 +1235,25 @@ static int xhci_check_maxpacket(struct xhci_hcd *xhci,
unsigned int slot_id,
hw_max_packet_size);
xhci_dbg(xhci, Issuing evaluate context command.\n);
+ /* Set up the input context flags for the command */
+ /* FIXME: This won't work if a non-default control endpoint
+* changes max packet sizes.
+*/
+ in_ctx = xhci-devs[slot_id]-in_ctx;
+ ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
+ if (!ctrl_ctx) {
+ xhci_warn(xhci, %s: Could not get input context, bad
type.\n,
+ __func__);
+ return -ENOMEM;
+ }
/* Set up the modified control endpoint 0 */
xhci_endpoint_copy(xhci, xhci-devs[slot_id]-in_ctx,
xhci-devs[slot_id]-out_ctx, ep_index);
- in_ctx = xhci-devs[slot_id]-in_ctx;
+
ep_ctx = xhci_get_ep_ctx(xhci, in_ctx, ep_index);
ep_ctx-ep_info2 = cpu_to_le32(~MAX_PACKET_MASK);
ep_ctx-ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet_size));
- /* Set up the input context flags for the command */
- /* FIXME: This won't work if a non-default control endpoint
-* changes max packet sizes.
-*/
- ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
ctrl_ctx-add_flags = cpu_to_le32(EP0_FLAG);
ctrl_ctx-drop_flags = 0;
@@ -1607,6 +1613,12 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
in_ctx = xhci-devs[udev-slot_id]-in_ctx;
out_ctx = xhci-devs[udev-slot_id]-out_ctx;
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
+ if (!ctrl_ctx) {
+ xhci_warn(xhci, %s: Could not get input context, bad type.\n,
+ __func__);
+ return 0;
+ }
+
ep_index =
[RFC v2 1/1] xhci: check for failed dma pool allocation
From: Mathias Nyman mathias.ny...@linux.intel.com
Fail and free the container context in case dma_pool_alloc() can't allocate
the raw context data part of it
This patch should be backported to kernels as old as 2.6.31, that
contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 USB: xhci:
Support for 64-byte contexts.
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: John Youn johny...@synopsys.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-mem.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index fbf75e5..f2e57a1 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -369,6 +369,10 @@ static struct xhci_container_ctx
*xhci_alloc_container_ctx(struct xhci_hcd *xhci
ctx-size += CTX_SIZE(xhci-hcc_params);
ctx-bytes = dma_pool_alloc(xhci-device_pool, flags, ctx-dma);
+ if (!ctx-bytes) {
+ kfree(ctx);
+ return NULL;
+ }
memset(ctx-bytes, 0, ctx-size);
return ctx;
}
--
1.7.9
--
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 v2 0/1] Fix xHCI NULL pointer deref
This patchset breaks out the one real bug fix patch from the Klockwork security issues patchset. It should be applied to usb-linus and queued for stable, as it handles a real potential NULL pointer deference. Sarah Sharp The following changes since commit 0c3f3dc68bb6e6950e8cd7851e7778c550e8dfb4: usb: chipidea: fix id change handling (2013-06-11 16:18:05 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git ful-klockwork for you to fetch changes up to 48d3bc4f46b0fb6eb011b1be64c6a7c2c7a635b0: xhci: check for failed dma pool allocation (2013-06-14 13:59:25 -0700) Mathias Nyman (1): xhci: check for failed dma pool allocation drivers/usb/host/xhci-mem.c |4 1 files changed, 4 insertions(+), 0 deletions(-) -- 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 v2 0/4] Remove BUG() calls from xHCI driver
On Mon, 17 Jun 2013, Sarah Sharp wrote: The older patchset did have some useful improvements, aside from the misguided patch to make the USB core be more robust about handling NULL pointers from usb_hub_to_struct_hub(). As discussed, that could only happen if khubd binds to a hub with no ports, and there's already a fix in Greg's tree to avoid that case. In my email on May 26, I pointed out a couple of places where the proposed changes to the hub driver would make sense. Mathias, would you like to submit a patch doing what I outlined? 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 v2 0/4] Remove BUG() calls from xHCI driver
On Mon, Jun 17, 2013 at 09:55:17AM -0700, Sarah Sharp wrote: This is a revised version of the patchset that was originally sent to fix security issues identified by the Klockwork static analysis tool. As discussed, these weren't real security issues, mostly just Klockwork not understanding that BUG() would stop code execution. The older patchset did have some useful improvements, aside from the misguided patch to make the USB core be more robust about handling NULL pointers from usb_hub_to_struct_hub(). As discussed, that could only happen if khubd binds to a hub with no ports, and there's already a fix in Greg's tree to avoid that case. This new patchset focuses solely on removing instances of BUG() from the xHCI driver. It adds code to gracefully handle failures by returning standard error values, and changing the driver to handle those failure cases. These are against Greg's usb-next branch, and are not marked for stable. Please review and comment if this is the right approach. These all look great to me, thanks for redoing them. Do you want me to pull them into my usb-next branch for 3.11? 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: [RFC v2 0/1] Fix xHCI NULL pointer deref
On Mon, Jun 17, 2013 at 09:56:30AM -0700, Sarah Sharp wrote: This patchset breaks out the one real bug fix patch from the Klockwork security issues patchset. It should be applied to usb-linus and queued for stable, as it handles a real potential NULL pointer deference. But, given that if we are under this type of memory pressure, lots of things will be dying, it can wait for 3.11-rc1, and is not a regression fix that has to go into 3.10. Do you still want me to pull this, as you marked it RFC? 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
[PATCH/RESEND 03/12] usb: otg: msm: Convert to clk_prepare/unprepare
Add calls to clk_prepare and unprepare so that MSM can migrate to
the common clock framework.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/usb/phy/phy-msm-usb.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 749fbf4..d08f334 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
motg-pdata-otg_control == OTG_PMIC_CONTROL)
writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);
- clk_disable(motg-pclk);
- clk_disable(motg-clk);
+ clk_disable_unprepare(motg-pclk);
+ clk_disable_unprepare(motg-clk);
if (motg-core_clk)
- clk_disable(motg-core_clk);
+ clk_disable_unprepare(motg-core_clk);
if (!IS_ERR(motg-pclk_src))
- clk_disable(motg-pclk_src);
+ clk_disable_unprepare(motg-pclk_src);
if (motg-pdata-phy_type == SNPS_28NM_INTEGRATED_PHY
motg-pdata-otg_control == OTG_PMIC_CONTROL) {
@@ -552,12 +552,12 @@ static int msm_otg_resume(struct msm_otg *motg)
return 0;
if (!IS_ERR(motg-pclk_src))
- clk_enable(motg-pclk_src);
+ clk_prepare_enable(motg-pclk_src);
- clk_enable(motg-pclk);
- clk_enable(motg-clk);
+ clk_prepare_enable(motg-pclk);
+ clk_prepare_enable(motg-clk);
if (motg-core_clk)
- clk_enable(motg-core_clk);
+ clk_prepare_enable(motg-core_clk);
if (motg-pdata-phy_type == SNPS_28NM_INTEGRATED_PHY
motg-pdata-otg_control == OTG_PMIC_CONTROL) {
@@ -1468,7 +1468,7 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
if (IS_ERR(motg-pclk_src))
goto put_clk;
clk_set_rate(motg-pclk_src, INT_MAX);
- clk_enable(motg-pclk_src);
+ clk_prepare_enable(motg-pclk_src);
} else
motg-pclk_src = ERR_PTR(-ENOENT);
@@ -1511,8 +1511,8 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
goto free_regs;
}
- clk_enable(motg-clk);
- clk_enable(motg-pclk);
+ clk_prepare_enable(motg-clk);
+ clk_prepare_enable(motg-pclk);
ret = msm_hsusb_init_vddcx(motg, 1);
if (ret) {
@@ -1532,7 +1532,7 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
}
if (motg-core_clk)
- clk_enable(motg-core_clk);
+ clk_prepare_enable(motg-core_clk);
writel(0, USB_USBINTR);
writel(0, USB_OTGSC);
@@ -1579,8 +1579,8 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
free_irq:
free_irq(motg-irq, motg);
disable_clks:
- clk_disable(motg-pclk);
- clk_disable(motg-clk);
+ clk_disable_unprepare(motg-pclk);
+ clk_disable_unprepare(motg-clk);
ldo_exit:
msm_hsusb_ldo_init(motg, 0);
vddcx_exit:
@@ -1593,7 +1593,7 @@ put_core_clk:
clk_put(motg-pclk);
put_pclk_src:
if (!IS_ERR(motg-pclk_src)) {
- clk_disable(motg-pclk_src);
+ clk_disable_unprepare(motg-pclk_src);
clk_put(motg-pclk_src);
}
put_clk:
@@ -1643,12 +1643,12 @@ static int msm_otg_remove(struct platform_device *pdev)
if (cnt = PHY_SUSPEND_TIMEOUT_USEC)
dev_err(phy-dev, Unable to suspend PHY\n);
- clk_disable(motg-pclk);
- clk_disable(motg-clk);
+ clk_disable_unprepare(motg-pclk);
+ clk_disable_unprepare(motg-clk);
if (motg-core_clk)
- clk_disable(motg-core_clk);
+ clk_disable_unprepare(motg-core_clk);
if (!IS_ERR(motg-pclk_src)) {
- clk_disable(motg-pclk_src);
+ clk_disable_unprepare(motg-pclk_src);
clk_put(motg-pclk_src);
}
msm_hsusb_ldo_init(motg, 0);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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: [Application RFC PATCH] ptp-gadget: move from gadgetfs to functionfs
Hi Guennadi, On Thu, Jun 06, 2013 at 12:34:39AM +0200, Michael Grzeschik wrote: This patch moves the ptp-gadget to use functionfs for the endpoint handling. With functionfs, this patch is deleting a lot of control ep0 code, which is now handled by the framework. Ping! Do you know who is maintaining this code and/or could be interested in this work? Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] build some drivers only when compile-testing
On 05/23/2013 05:09 AM, Jeff Mahoney wrote: On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote: On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote: Some drivers can be built on more platforms than they run on. This causes users and distributors packaging burden when they have to manually deselect some drivers from their allmodconfigs. Or sometimes it is even impossible to disable the drivers without patching the kernel. Introduce a new config option COMPILE_TEST and make all those drivers to depend on the platform they run on, or on the COMPILE_TEST option. Now, when users/distributors choose COMPILE_TEST=n they will not have the drivers in their allmodconfig setups, but developers still can compile-test them with COMPILE_TEST=y. I understand the urge, and it's getting hard for distros to handle these drivers that just don't work on other architectures, but it's really valuable to ensure that they build properly, for those of us that don't have many/any cross compilers set up. But this is exactly what COMPILE_TEST will give us when set to y, or am I missing something? Now the drivers where we use this new option: * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom processors so it should depend on x86. * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc systems -- which do not actually support the hardware via that method. This seems ripe to start to get really messy, really quickly. Shouldn't default configs handle if this should be enabled for a platform or not, and let the rest of us just build them with no problems? If every time a new Kconfig option is added, corresponding default config updates come with it, sure. I just don't see that happening, especially when it can be done much more clearly in the Kconfig while the developer is writing the driver. What problems is this causing you? Are you running out of space in kernel packages with drivers that will never be actually used? Wasted build resources. Wasted disk space on /every/ system the kernel package is installed on. We're all trying to pare down the kernel packages to eliminate wasted space and doing it manually means a bunch of research, sometimes with incorrect assumptions about the results, needs to be done by someone not usually associated with that code. That research gets repeated by people maintaining kernel packages for pretty much every distro. I second all the above. +config COMPILE_TEST + bool Compile also drivers which will not load if EXPERT EXPERT is getting to be the let's hide it here option, isn't it... I don't know, if no one else strongly objects, I can be convinced that this is needed, but so far, I don't see why it really is, or what this is going to help with. I'm not convinced adding a || COMPILE_TEST option to every driver that may be arch specific is the best way to go either. Perhaps adding a new Kconfig verb called archdepends on or something that will evaluate as true if COMPILE_TEST is enabled but will evaluate the conditional if not. *waves hands* Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want to extend the kconfig language for this purpose (which I support). That a config option is fine and sufficient in this case [1]. Except he called the config option SHOW_ALL_DRIVERS. Adding the current maintainer to CCs ;). [1] http://comments.gmane.org/gmane.linux.kbuild.devel/9829 The last point I inclined to the Greg's argument to remove the EXPERT dependency. So currently I have what is attached... Comments? thanks, -- js suse labs From e818e90b4f901c8d949d08bd05735203c5e88530 Mon Sep 17 00:00:00 2001 From: Jiri Slaby jsl...@suse.cz Date: Wed, 22 May 2013 10:56:24 +0200 Subject: [PATCH v2] build some drivers only when compile-testing Some drivers can be built on more platforms than they run on. This is a burden for users and distributors who package a kernel. They have to manually deselect some (for them useless) drivers when updating their configs via oldconfig. And yet, sometimes it is even impossible to disable the drivers without patching the kernel. Introduce a new config option COMPILE_TEST and make all those drivers to depend on the platform they run on, or on the COMPILE_TEST option. Now, when users/distributors choose COMPILE_TEST=n they will not have the drivers in their allmodconfig setups, but developers still can compile-test them with COMPILE_TEST=y. Now the drivers where we use this new option: * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom processors so it should depend on x86. * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc systems -- which do not actually support the hardware via that method. * INTEL_MID_PTI: It is specific to the Penwell type of Intel Atom device. [v2] * remove
Re: [PATCH v3 2/3] USB: serial: make minor allocation dynamic
On Sat, Jun 08, 2013 at 12:03:47PM +0200, Johan Hovold wrote:
On Fri, Jun 07, 2013 at 11:04:28AM -0700, Greg KH wrote:
From: Greg Kroah-Hartman gre...@linuxfoundation.org
Changes v2 - v3:
- fixed up comments about usb_serial_get_by_minor()
- fixed error case in usb_serial_get_by_minor()
- folded get_free_port() into get_free_serial()
- renamed get_free_serial() to allocate_minors()
- fixed console.c build breakage
- properly pass in minor port number to usb_serial_console_init()
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -37,6 +37,7 @@
#include linux/usb.h
#include linux/usb/serial.h
#include linux/kfifo.h
+#include linux/idr.h
#include pl2303.h
#define DRIVER_AUTHOR Greg Kroah-Hartman gre...@linuxfoundation.org
@@ -49,72 +50,64 @@
drivers depend on it.
*/
-static struct usb_serial *serial_table[SERIAL_TTY_MINORS];
+static DEFINE_IDR(serial_minors);
static DEFINE_MUTEX(table_lock);
static LIST_HEAD(usb_serial_driver_list);
/*
- * Look up the serial structure. If it is found and it hasn't been
- * disconnected, return with its disc_mutex held and its refcount
- * incremented. Otherwise return NULL.
+ * Look up the serial port structure. If it is found and it hasn't been
+ * disconnected, return with the parent usb_serial structure's disc_mutex
held
+ * and its refcount incremented. Otherwise return NULL.
*/
-struct usb_serial *usb_serial_get_by_index(unsigned index)
+struct usb_serial_port *usb_serial_port_get_by_minor(unsigned minor)
{
- struct usb_serial *serial;
+ struct usb_serial *serial = NULL;
This isn't necessary anymore.
Now fixed, thanks.
static void return_serial(struct usb_serial *serial)
Perhaps rename this one release_minors to match allocate_minors (much
better name btw)?
Good idea, now done.
@@ -123,8 +116,9 @@ static void return_serial(struct usb_ser
mutex_lock(table_lock);
for (i = 0; i serial-num_ports; ++i)
- serial_table[serial-minor + i] = NULL;
+ idr_remove(serial_minors, serial-port[i]-minor);
mutex_unlock(table_lock);
+ serial-minors_reserved = 0;
This isn't strictly needed as the serial struct release_serial is only
called once when the struct is about to be freed.
Really? Why were we doing this type of thing before with the not
allocated flag? It seems that we were protecting some path that I
can't remember at the moment. So to be safe, I'll leave it for now...
All three patches look good otherwise. The port-number disambiguation
was indeed long overdue. Feel free to add
Reviewed-by: Johan Hovold jhov...@gmail.com
Thanks so much for the review, I'll go make these changes and apply them
now.
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] usb: host: Faraday fotg210-hcd driver
On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote: FOTG210 is an OTG controller which can be configured as an USB2.0 host. FOTG210 host is an ehci-like controller with some differences. First, register layout of FOTG210 is incompatible with EHCI. Furthermore, FOTG210 is lack of siTDs which means iTDs are used for both HS and FS ISO transfer. Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 12 + drivers/usb/host/Makefile |1 + drivers/usb/host/fotg210-hcd.c | 5967 drivers/usb/host/fotg210.h | 746 + 5 files changed, 6727 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/host/fotg210-hcd.c create mode 100644 drivers/usb/host/fotg210.h You obviously didn't even run this through checkpatch.pl, did you? $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1 total: 138 errors, 618 warnings, 6742 lines checked Please fix all of these if you wish us to at least start reviewing the patch. Your internal Q/A should have caught this first, please be more careful in the future. 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
patch usb: chipidea: ci13xxx_imx: let device core handle pinctrl added to usb tree
This is a note to let you know that I've just added the patch titled
usb: chipidea: ci13xxx_imx: let device core handle pinctrl
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
From a95fd1897378e9533f049f6a3c74ee80cedab947 Mon Sep 17 00:00:00 2001
From: Fabio Estevam fabio.este...@freescale.com
Date: Thu, 13 Jun 2013 17:59:45 +0300
Subject: usb: chipidea: ci13xxx_imx: let device core handle pinctrl
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for handling pinctrl.
So remove devm_pinctrl_get_select_default() from the driver.
Cc: linux-usb@vger.kernel.org
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Tested-by: Shawn Guo shawn@linaro.org
Signed-off-by: Alexander Shishkin alexander.shish...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/usb/chipidea/ci13xxx_imx.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 585099a..45bb9b5 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -20,7 +20,6 @@
#include linux/usb/chipidea.h
#include linux/clk.h
#include linux/regulator/consumer.h
-#include linux/pinctrl/consumer.h
#include ci.h
#include ci13xxx_imx.h
@@ -103,7 +102,6 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
struct device_node *phy_np;
struct resource *res;
struct regulator *reg_vbus;
- struct pinctrl *pinctrl;
int ret;
if (of_find_property(pdev-dev.of_node, fsl,usbmisc, NULL)
@@ -122,11 +120,6 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
return -ENOENT;
}
- pinctrl = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(pinctrl))
- dev_warn(pdev-dev, pinctrl get/select failed, err=%ld\n,
- PTR_ERR(pinctrl));
-
data-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(data-clk)) {
dev_err(pdev-dev,
--
1.8.3.rc0.20.gb99dd2e
--
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/20] usb: chipidea: drop 13xxx infix
On Thu, Jun 13, 2013 at 06:00:04PM +0300, Alexander Shishkin wrote: ci13xxx is bad for at least the following reasons: * people often mistype it * it doesn't add any informational value to the names it's used in * it needlessly attracts mail filters This patch replaces it with ci_hdrc, ci_udc or ci_hw, depending on the situation. Modules with ci13xxx prefix are also renamed accordingly and aliases are added for compatibility. Otherwise, no functional changes. Signed-off-by: Alexander Shishkin alexander.shish...@linux.intel.com This one didn't apply cleanly, and so I tried to do it by hand, and edited the file and totally messed it up :( So, can you regenerate it against my usb-next branch and resend it so that I can apply it? Sorry about that, it's my fault for loosing the patch. 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 00/20] usb: chipidea: updates for v3.11
On Thu, Jun 13, 2013 at 05:59:44PM +0300, Alexander Shishkin wrote: Hi, Here's a set of chipidea updates for v3.11. These are mostly fixes and cleanups, but also include isoch endpoint support and multi-td transfers by Michael. On top there are two mass rename patches that I've been meaning to push for a while, particularly the one that gets rid of ci13xxx. All but the last one applied cleanly, can you resend that one? 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
[no subject]
Loan Syndicacion Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie unsere Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen Mehrwert für unsere Kunden Unternehmen. eine Division der AFG Finance und Private Bank plc. Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können Sie brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen können zusammen das Syndikat, das die gesamte Kredit schnürt für Sie. Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu identifizieren Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben Hauptakteur in diesem Bereich. öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann die Sterne Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt. mit dem Folowing Informationen über Rechtsanwalt steven lee das Konto Offizier. FULL NAME; Wohnadresse; E-MAIL-ADRESSE; Telefonnummer; Nächsten KINS; MUTTER MAIDEN NAME; Familienstand; BÜROADRESSE; ALTERNATIVE Telefonnummer; TO @ yahoo.com bar.stevenlee NOTE; ALLE Darlehen sind für 10JAHRE RATE VALID ANGEBOT ENDET BALD SO JETZT HURRY -- 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: host: Faraday fotg210-hcd driver
Hi, On Tue, Jun 18, 2013 at 4:39 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote: FOTG210 is an OTG controller which can be configured as an USB2.0 host. FOTG210 host is an ehci-like controller with some differences. First, register layout of FOTG210 is incompatible with EHCI. Furthermore, FOTG210 is lack of siTDs which means iTDs are used for both HS and FS ISO transfer. Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 12 + drivers/usb/host/Makefile |1 + drivers/usb/host/fotg210-hcd.c | 5967 drivers/usb/host/fotg210.h | 746 + 5 files changed, 6727 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/host/fotg210-hcd.c create mode 100644 drivers/usb/host/fotg210.h You obviously didn't even run this through checkpatch.pl, did you? $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1 total: 138 errors, 618 warnings, 6742 lines checked Please fix all of these if you wish us to at least start reviewing the patch. Your internal Q/A should have caught this first, please be more careful in the future. Actually I did run checkpatch.pl and found that almost all errors and warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where my driver borrowed most of code. $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1 total: 18 errors, 69 warnings, 1138 lines checked $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1 total: 17 errors, 78 warnings, 1403 lines checked So you're saying that I should fix them, is that right? thanks, Yuan-Hsin 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: [RFC v2 0/4] Remove BUG() calls from xHCI driver
On Mon, Jun 17, 2013 at 10:40:24AM -0700, Greg Kroah-Hartman wrote: On Mon, Jun 17, 2013 at 09:55:17AM -0700, Sarah Sharp wrote: This is a revised version of the patchset that was originally sent to fix security issues identified by the Klockwork static analysis tool. As discussed, these weren't real security issues, mostly just Klockwork not understanding that BUG() would stop code execution. The older patchset did have some useful improvements, aside from the misguided patch to make the USB core be more robust about handling NULL pointers from usb_hub_to_struct_hub(). As discussed, that could only happen if khubd binds to a hub with no ports, and there's already a fix in Greg's tree to avoid that case. This new patchset focuses solely on removing instances of BUG() from the xHCI driver. It adds code to gracefully handle failures by returning standard error values, and changing the driver to handle those failure cases. These are against Greg's usb-next branch, and are not marked for stable. Please review and comment if this is the right approach. These all look great to me, thanks for redoing them. Do you want me to pull them into my usb-next branch for 3.11? Sure, I'll send you a tagged pull request. Sarah -- 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
[Pull Request] xhci: Remove BUG() calls from the driver
The following changes since commit 976f8bef9cfb5246bc0e8dc781562daa79cb7aaf: Merge tag 'usb-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next (2013-06-12 14:44:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next-2013-06-17 for you to fetch changes up to 17d655543716791ebf8bb396b674fe95c07e55e4: xhci: remove BUG() in xhci_get_endpoint_type() (2013-06-14 13:53:23 -0700) xhci: Remove BUG() calls from the driver. Hi Greg, This patchset removes instances of BUG() from the xHCI driver. It adds code to gracefully handle failures by returning standard error values, and changing the driver to handle those failure cases. These are against Greg's usb-next branch, and are not marked for stable. Please queue for 3.11. Sarah Sharp Mathias Nyman (2): xhci: Remove BUG in xhci_setup_addressable_virt_dev xhci: remove BUG() in xhci_get_endpoint_type() Sarah Sharp (2): xhci: Remove BUG_ON() in xhci_alloc_container_ctx. xhci: Remove BUG_ON in xhci_get_input_control_ctx. drivers/usb/host/xhci-dbg.c |5 ++ drivers/usb/host/xhci-mem.c | 61 - drivers/usb/host/xhci-ring.c |4 + drivers/usb/host/xhci.c | 148 -- 4 files changed, 151 insertions(+), 67 deletions(-) -- 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 v2 0/1] Fix xHCI NULL pointer deref
On Mon, Jun 17, 2013 at 10:41:56AM -0700, Greg Kroah-Hartman wrote: On Mon, Jun 17, 2013 at 09:56:30AM -0700, Sarah Sharp wrote: This patchset breaks out the one real bug fix patch from the Klockwork security issues patchset. It should be applied to usb-linus and queued for stable, as it handles a real potential NULL pointer deference. But, given that if we are under this type of memory pressure, lots of things will be dying, it can wait for 3.11-rc1, and is not a regression fix that has to go into 3.10. Do you still want me to pull this, as you marked it RFC? Sure, it can wait until 3.11. If you want to just pull it, go ahead. However, the patch is against usb-linus, so I'm not sure how it will merge. If it doesn't merge, let me know, and I'll send you an updated pull request. 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: [PATCH] usb: host: Faraday fotg210-hcd driver
On Tue, Jun 18, 2013 at 10:42:09AM +0800, Yuan-Hsin Chen wrote: Hi, On Tue, Jun 18, 2013 at 4:39 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote: FOTG210 is an OTG controller which can be configured as an USB2.0 host. FOTG210 host is an ehci-like controller with some differences. First, register layout of FOTG210 is incompatible with EHCI. Furthermore, FOTG210 is lack of siTDs which means iTDs are used for both HS and FS ISO transfer. Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 12 + drivers/usb/host/Makefile |1 + drivers/usb/host/fotg210-hcd.c | 5967 drivers/usb/host/fotg210.h | 746 + 5 files changed, 6727 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/host/fotg210-hcd.c create mode 100644 drivers/usb/host/fotg210.h You obviously didn't even run this through checkpatch.pl, did you? $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1 total: 138 errors, 618 warnings, 6742 lines checked Please fix all of these if you wish us to at least start reviewing the patch. Your internal Q/A should have caught this first, please be more careful in the future. Actually I did run checkpatch.pl and found that almost all errors and warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where my driver borrowed most of code. $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1 total: 18 errors, 69 warnings, 1138 lines checked $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1 total: 17 errors, 78 warnings, 1403 lines checked So you're saying that I should fix them, is that right? In that case, no, you should be figuring out how to refactor and reuse the EHCI code instead of copying it straight into your driver. 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 PATCH 0/1] Intel xhci: rework EHCI/xHCI port switching
On Mon, Jun 17, 2013 at 11:06:15AM -0400, Alan Stern wrote: On Mon, 17 Jun 2013, Sarah Sharp wrote: We should be able to handle hotplug if at all possible. I know the quirk handling issues around PCI hotplug aren't all worked out (or at least they were not a year or so ago), so maybe there's really nothing you can/need to do here. Ok, I'll work with Mathias, and we'll figure out how to handle hot plug. If you have any good suggestions, let me know. Sarah, can you go over the issues involved? I'm not entirely clear on all of this. For example, given an xHCI controller with switchable ports, you can't easily tell which EHCI controller those ports are connected to, right? And in fact, you don't even really care. Correct me if I'm wrong here. The original idea was to switch everything over to xHCI during some early stage (like when the xHCI controller is first passed to the pci-quirks.c code) and switch back to EHCI at shutdown. As a refinement, you want to switch over to xHCI again following system resume, in case the BIOS messed things up. Is there anything else? Yes, that was the idea. Why does the old code need to be changed? The only problem I see is that it may be a little too elaborate. For example, why bother trying to do the switch when the EHCI controller resumes? Won't everything work okay if you wait until the xHCI controller resumes? The code needs to be changed because we don't want to keep adding new PCI IDs for all the new Intel hosts. Mathias also didn't like that we inefficiently walked the PCI bus, looking for the xHCI host in the EHCI resume routine, so he stored the xHCI pointer. Perhaps this would be more clear if these two goals were broken up into two patches? Why does the code check so hard to see whether or not there are any switchable ports? Why not just always try to set the switch on any Intel controller? Not all ports may be exposed on the platform (because there are different skews). If we don't check which ports to switchover, some BIOSes freak out on either shutdown, or suspend. I don't remember which. So we need to pay attention to the port switchover masks. Why is it necessary to search through all the PCI devices? Why is it necessary to store any sort of list of switchable controllers? We don't know which host will resume from suspend first. Assume we have a broken BIOS that switches ports back to EHCI on resume. We don't want the USB core to notice EHCI connects and start servicing them before xHCI resumes. Therefore, we need to have both the xHCI and the EHCI resume functions attempt to switch the ports over to xHCI. That means for EHCI, we either need to search the PCI tree for the xHCI host on resume (because that's where the port switchover mechanism registers are), or we need to store the xHCI PCI host pointer somewhere. Mathias chose to store the pointer. Why should hot-unplug be an issue? Or multiple xHCI controllers? This is not a problem right now, I'm perhaps being paranoid. :) For all current Intel systems, AFAIK, there will only be one xHCI host controller, and it will be a part of the PCH, so you won't see any PCI hot unplug events unless someone removes the entire PCH (which I don't know if we support?). 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
[PATCH -next] usb: gadget: f_subset: fix missing unlock on error in geth_alloc()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function geth_alloc()
in the error handling case.
Introduced by commit 02832e56f88a981474ee4c7c141f46fc1b4454f4.
(usb: gadget: f_subset: add configfs support)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/usb/gadget/f_subset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/f_subset.c b/drivers/usb/gadget/f_subset.c
index fbc7a24..5601e1d 100644
--- a/drivers/usb/gadget/f_subset.c
+++ b/drivers/usb/gadget/f_subset.c
@@ -548,6 +548,7 @@ static struct usb_function *geth_alloc(struct
usb_function_instance *fi)
sizeof(geth-ethaddr));
if (status 12) {
kfree(geth);
+ mutex_unlock(opts-lock);
return ERR_PTR(-EINVAL);
}
geth_string_defs[1].s = geth-ethaddr;
--
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 -next] usb: gadget: f_ncm: fix missing unlock on error in ncm_alloc()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function ncm_alloc()
in the error handling case.
Introduced by commit e730660378be92b83288b59b824ccdace5cd2652.
(usb: gadget: f_ncm: add configfs support)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/usb/gadget/f_ncm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index 47a5724..952177f 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -1403,6 +1403,7 @@ struct usb_function *ncm_alloc(struct
usb_function_instance *fi)
sizeof(ncm-ethaddr));
if (status 12) { /* strlen(01234567890a) */
kfree(ncm);
+ mutex_unlock(opts-lock);
return ERR_PTR(-EINVAL);
}
ncm_string_defs[STRING_MAC_IDX].s = ncm-ethaddr;
--
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 -next] usb: gadget: f_ecm: fix missing unlock on error in ecm_alloc()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function ecm_alloc()
in the error handling case.
Introduced by commit da92801c647cdebfd45001fd6aaecb8f0be7f56b.
(usb: gadget: f_ecm: add configfs support)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/usb/gadget/f_ecm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/f_ecm.c b/drivers/usb/gadget/f_ecm.c
index fcafe1a..5d3561e 100644
--- a/drivers/usb/gadget/f_ecm.c
+++ b/drivers/usb/gadget/f_ecm.c
@@ -1012,6 +1012,7 @@ struct usb_function *ecm_alloc(struct
usb_function_instance *fi)
sizeof(ecm-ethaddr));
if (status 12) {
kfree(ecm);
+ mutex_unlock(opts-lock);
return ERR_PTR(-EINVAL);
}
ecm_string_defs[1].s = ecm-ethaddr;
--
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] build some drivers only when compile-testing
Dne 17.6.2013 22:05, Jiri Slaby napsal(a): On 05/23/2013 05:09 AM, Jeff Mahoney wrote: On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote: On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote: Some drivers can be built on more platforms than they run on. This causes users and distributors packaging burden when they have to manually deselect some drivers from their allmodconfigs. Or sometimes it is even impossible to disable the drivers without patching the kernel. Introduce a new config option COMPILE_TEST and make all those drivers to depend on the platform they run on, or on the COMPILE_TEST option. Now, when users/distributors choose COMPILE_TEST=n they will not have the drivers in their allmodconfig setups, but developers still can compile-test them with COMPILE_TEST=y. I understand the urge, and it's getting hard for distros to handle these drivers that just don't work on other architectures, but it's really valuable to ensure that they build properly, for those of us that don't have many/any cross compilers set up. But this is exactly what COMPILE_TEST will give us when set to y, or am I missing something? Now the drivers where we use this new option: * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom processors so it should depend on x86. * FB_GEODE: Geode is 32-bit only so only enable it for X86_32. * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc systems -- which do not actually support the hardware via that method. This seems ripe to start to get really messy, really quickly. Shouldn't default configs handle if this should be enabled for a platform or not, and let the rest of us just build them with no problems? If every time a new Kconfig option is added, corresponding default config updates come with it, sure. I just don't see that happening, especially when it can be done much more clearly in the Kconfig while the developer is writing the driver. What problems is this causing you? Are you running out of space in kernel packages with drivers that will never be actually used? Wasted build resources. Wasted disk space on /every/ system the kernel package is installed on. We're all trying to pare down the kernel packages to eliminate wasted space and doing it manually means a bunch of research, sometimes with incorrect assumptions about the results, needs to be done by someone not usually associated with that code. That research gets repeated by people maintaining kernel packages for pretty much every distro. I second all the above. +config COMPILE_TEST + bool Compile also drivers which will not load if EXPERT EXPERT is getting to be the let's hide it here option, isn't it... I don't know, if no one else strongly objects, I can be convinced that this is needed, but so far, I don't see why it really is, or what this is going to help with. I'm not convinced adding a || COMPILE_TEST option to every driver that may be arch specific is the best way to go either. Perhaps adding a new Kconfig verb called archdepends on or something that will evaluate as true if COMPILE_TEST is enabled but will evaluate the conditional if not. *waves hands* Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want to extend the kconfig language for this purpose (which I support). That a config option is fine and sufficient in this case [1]. Except he called the config option SHOW_ALL_DRIVERS. Adding the current maintainer to CCs ;). I agree with Sam. 'depends on XY || COMPILE_TEST' is quite self-explanatory. And even if it's not, you can look up the help text for COMPILE_TEST. With archdepends on or available on, you need to know what to look for to override the dependency. Michal -- 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
Detecting start/stop streaming for UVC webcam with bulk transfer mode
Hi, I am currently working with UVC camera device which send data using bulk transfer for preview and capture. I have modified UVC gadget driver to start bulk streaming on receiving first UVC_VS_COMMIT_CONTROL request from host side. But currently not able to detect when to stop the streaming. I am running Cheese Application on host side to test start/stop streaming. UVC gadget driver's 'uvc_function_set_alt' function is getting called when closing the cheese application, but this function is also (sometime) getting called when starting the cheese application on HOST side, also some time this function gets called after receiving first COMMIT_CONTROL. So, currently I am not able to find a proper way for starting / stopping streaming for UVC bulk transfer. Anyone has successfully implemented the start/stop streaming usecase for bulk mode? Any pointer would be very helpful. Thanks, Chetan Nanda -- 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: host: Faraday fotg210-hcd driver
Hi, On Tue, Jun 18, 2013 at 11:07 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Tue, Jun 18, 2013 at 10:42:09AM +0800, Yuan-Hsin Chen wrote: Hi, On Tue, Jun 18, 2013 at 4:39 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote: FOTG210 is an OTG controller which can be configured as an USB2.0 host. FOTG210 host is an ehci-like controller with some differences. First, register layout of FOTG210 is incompatible with EHCI. Furthermore, FOTG210 is lack of siTDs which means iTDs are used for both HS and FS ISO transfer. Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 12 + drivers/usb/host/Makefile |1 + drivers/usb/host/fotg210-hcd.c | 5967 drivers/usb/host/fotg210.h | 746 + 5 files changed, 6727 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/host/fotg210-hcd.c create mode 100644 drivers/usb/host/fotg210.h You obviously didn't even run this through checkpatch.pl, did you? $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1 total: 138 errors, 618 warnings, 6742 lines checked Please fix all of these if you wish us to at least start reviewing the patch. Your internal Q/A should have caught this first, please be more careful in the future. Actually I did run checkpatch.pl and found that almost all errors and warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where my driver borrowed most of code. $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1 total: 18 errors, 69 warnings, 1138 lines checked $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1 total: 17 errors, 78 warnings, 1403 lines checked So you're saying that I should fix them, is that right? In that case, no, you should be figuring out how to refactor and reuse the EHCI code instead of copying it straight into your driver. I was trying to use ehci-platform.c, anonymous union/struct, and quirk flags to avoid copying EHCI code. But there are too big incompatibilities between fotg210/fusbh200 controller and EHCI. That's why Alan agreed that I could create a stand-alone driver for fusbh200 host controller. Since fotg210 and fusbh200 have the same issue, fotg210 hcd is supposed to be stand-alone. More details please refer to mail sequence http://www.spinics.net/lists/linux-usb/msg83812.html Thanks, Yuan-Hsin 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
