- 16 Aug, 2013 5 commits
-
-
Thomas Pugliese authored
In wa_seg_init, use usb_init_urb to init the URB object contained in the transfer segment instead of initializing it manually. Use kmalloc to allocate the memory for segment instead of kzalloc and then use memset to set the non-URB portion of the transfer segment struct to 0 since that was already done by usb_init_urb. Signed-off-by:
Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Pugliese authored
The check to free the URB was the opposite of the correct case. This patch removes the check altogether since the ptr will be NULL if the URB was not allocated. Also use usb_free_urb instead of usb_put_urb. Signed-off-by:
-
Thomas Pugliese authored
Use usb_free_urb instead of kfree in error path and point to the correct URB. Also remember to clean up the sg list for the URB if it was allocated. Signed-off-by:
-
Thomas Pugliese authored
When the HWA encounters a STALL on a control endpoint, it should clear the RPIPE_STALL feature on the RPIPE before processing the next transfer request. Otherwise, all transfer requests on that endpoint after the first STALL will fail because the RPIPE is still in the halted state. This also removes the unneccessary call to spin_lock_irqsave for a nested lock that was present in the first patch. Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'for-usb-next-2013-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next Sarah writes: xhci: Platform updates, 64-bit DMA, and trace events for 3.12. Hi Greg, This pull request includes one new feature for the xhci-plat driver (device tree support). Felipe was fine with the patch last I checked, but hadn't provided an official Acked-by line. This pull request also includes 13 patches from my FOSS Outreach Program for Women (OPW) intern, Xenia. She fixed a bug in the xHCI driver so that the driver can allocate 64-bit consistent DMA, converted the driver to use dynamic debugging, and added a bunch of new trace events for the xHCI driver. The python plugin for trace-cmd should be up on git hub shortly, although the trace events are usable without it. I'm very happy with the progress that Xenia has made, and I look forward to her future contributions to the Linux kernel. Sarah Sharp
-
- 14 Aug, 2013 35 commits
-
-
Johan Hovold authored
Make sure the USB control request is allocated separately from containing structure to prevent potential memory corruption on non-cache-coherent systems. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Johan Hovold authored
Make sure serial DMA-buffers are allocated separately from containing structure to prevent potential memory corruption on non-cache-coherent systems. Signed-off-by:
-
Johan Hovold authored
Make sure serial DMA-buffers are allocated separately from containing structure to prevent potential memory corruption on non-cache-coherent systems. Signed-off-by:
-
Johan Hovold authored
Make sure port DMA-buffers are allocated separately from containing structure to prevent potential memory corruption on non-cache-coherent systems. Signed-off-by:
-
Johan Hovold authored
Make sure serial DMA-buffers are allocated separately from containing structure to prevent potential memory corruption on non-cache-coherent systems. Signed-off-by:
-
Sascha Hauer authored
The chipidea i.MX driver is split into two drivers. The ci_hdrc_imx driver handles the chipidea cores and the usbmisc_imx driver handles the noncore registers common to all chipidea cores (but SoC specific). Current flow is: - usbmisc sets an ops pointer in the ci_hdrc_imx driver during probe - ci_hdrc_imx checks if the pointer is valid during probe, if yes calls the functions in the ops pointer. - usbmisc_imx calls back into the ci_hdrc_imx driver to get additional data This is overly complicated and has problems if the drivers are compiled as modules. In this case the usbmisc_imx driver can be unloaded even if the ci_hdrc_imx driver still needs usbmisc functionality. This patch changes this by letting the ci_hdrc_imx driver calling functions from the usbmisc_imx driver. This way the symbol resolving during module load makes sure the ci_hdrc_imx driver depends on the usbmisc_imx driver. Also instead of letting the usbmisc_imx driver call back into the ci_hdrc_imx driver, pass the needed data in the first place. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
-
Peter Chen authored
For chipidea, the IP must know vbus before the controller begins to run. So the .pullup should only be called when the vbus is there. Tested-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Peter Chen authored
Currently, the controller only runs when the ci->vbus_active is true. So the flag CI_HDRC_PULLUP_ON_VBUS is useless no longer. If the user doesn't have otgsc, he/she needs to change ci_handle_vbus_change to update ci->vbus_active. Signed-off-by:
-
Peter Chen authored
CI_HDRC_REGS_SHARED stands for the controller registers is shared with other USB drivers, if all USB drivers are at chipidea/, it doesn't needed to be set. CI_HDRC_PULLUP_ON_VBUS stands for pullup dp when the vbus is on. This flag doesn't need to be set if the vbus is always on for gadget since dp has always pulled up after the gadget has initialized. So, the current code seems to misuse this two flags. - When the gadget initializes, the controller doesn't need to run if it depends on vbus (CI_HDRC_PULLUP_ON_VBUS), it does not relate to shared register. - When the gadget starts (load one gadget module), the controller can run if vbus is on (CI_HDRC_PULLUP_ON_VBUS), it also does not relate to shared register. Tested-by:
-
Peter Chen authored
When the gadget role starts, we need to make sure the vbus is lower than OTGSC_BSV, or there will be an vbus interrupt since we use B_SESSION_VALID as vbus interrupt to indicate connect and disconnect. When the host role starts, it may not be useful to wait vbus to lower than OTGSC_BSV, but it can indicate some hardware problems like the vbus is still higher than OTGSC_BSV after we disconnect to host some time later (5000 milliseconds currently), which is obvious not correct. Tested-by:
-
Peter Chen authored
We add vbus interrupt handler at ci_otg_work, it uses OTGSC_BSV(at otgsc) to know it is connect or disconnet event. Meanwhile, we introduce two flags id_event and b_sess_valid_event to indicate it is an id interrupt or a vbus interrupt. Tested-by:
-
Peter Chen authored
Move otg related things to otg file. Tested-by:
-
Peter Chen authored
During the initialization, it needs to disable all interrupts enable bit as well as clear all interrupts status bits to avoid exceptional interrupt. Tested-by:
-
Peter Chen authored
Since we need otgsc to know vbus's status at some chipidea controllers even it is peripheral-only mode. Besides, some SoCs (eg, AR9331 SoC) don't have otgsc register even the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS. We inroduce flag CI_HDRC_DUAL_ROLE_NOT_OTG to indicate if the controller is dual role, but not supports OTG. If this flag is not set, we follow the rule that if DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS, then this controller is otg capable. Signed-off-by:
-
Peter Chen authored
- The role's init will be called at probe procedure. - The role's destroy will be called at fail patch at probe and driver's removal. - The role's start/stop will be called when specific role has started. Tested-by:
-
Peter Chen authored
This file is mainly used to access otgsc currently, it may add otg related things in the future. Tested-by:
-
Peter Chen authored
It is useless at below cases: - If we implement both usb host and device at chipidea driver. - If we don't need phy->otg. Tested-by:
-
Peter Chen authored
For boards which have board level vbus control (eg, through gpio), we need to vbus operation according to below rules: - For host, we need open vbus before start hcd, and close it after remove hcd. - For otg, the vbus needs to be on/off when usb role switches. When the host roles begins, it opens vbus; when the host role finishes, it closes vbus. We put vbus operation to host as host is the only vbus user, When we are at host mode, the vbus is on, when we are not at host mode, vbus should be off. Tested-by:
-
Peter Chen authored
The vbus regulator is a common element for USB vbus operation, So, move it from glue layer to core. Tested-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
-
Fabio Estevam authored
After the rename to ci_hdrc we ended up with two MODULE_ALIAS entries, so remove the old one. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Reviewed-by:
-
Lothar Waßmann authored
Commit 40dcd0e8 ("usb: chipidea: add PTW, PTS and STS handling") introduced the following code to the ci_hdrc_probe() function: + if (!dev->of_node && dev->parent) + dev->of_node = dev->parent->of_node; This inadvertently associates the ci_hdrc device with the ci_hdrc_imx driver (which created the ci_hdrc device in the first place). This results in ci_hdrc_imx_probe() being run for the ci_hdrc device if ci_hdrc_probe() fails for some reason. ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device whose probing will likewise fail and trigger a new invocation of ci_hdrc_imx_probe() ... ad nauseam. Signed-off-by:
Lothar Waßmann <LW@KARO-electronics.de> Reviewed-and-tested-by:
-
Lothar Waßmann authored
If a role fails to start, propagate the error code up the call stack from probe. Signed-off-by:
-
Lothar Waßmann authored
This prevents the USB PHY refcount to be decremented below zero upon unloading the ci-hdrc-imx module. Signed-off-by:
-
Lothar Waßmann authored
This patch provides a cleaner solution to the problem described in commit 20a677fd ("usb: chipidea: improve kconfig"). The goal to be achieved is to force USB_CHIPIDEA=m if either USB_EHCI_HCD=m or USB_GADGET=m. If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'. The old patch had the drawback, that USB_CHIPIDEA could be chosen as 'y' though USB_EHCI_HCD or USB_GADGET (or both) were 'm' leading to a situation where USB_CHIPIDEA_HOST or USB_CHIPIDEA_UDC vanished from the config options producing a compilable but dysfunctional driver. Signed-off-by:
-
Peter Chen authored
Remove an unused macro leftover from the old initialization code. Signed-off-by:
-
Fabio Estevam authored
Currently hw_phymode_configure() is located inside hw_device_reset(), which is only called by chipidea udc driver. When operating in host mode, we also need to call hw_phymode_configure() in order to properly configure the PHY mode, so move this function into probe. After this change, USB Host1 port on mx53qsb board is functional. Signed-off-by:
Arnaud Patard <arnaud.patard@rtp-net.org> Reviewed-by:
-
Fabio Estevam authored
'res' is not used anywhere, so let's get rid of it. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Felipe Balbi authored
if pdata is a NULL pointer we could cause a kernel oops when probing the driver. Make sure to cope with systems which won't pass pdata to the driver. Tested-by:
Paul Zimmerman <paulz@synopsys.com> Reported-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sean O. Stalley authored
rh_call_control() contains a buffer, tbuf, which it uses to hold USB descriptors. These discriptors are eventually copied into the transfer_buffer in the URB. The buffer in the URB is dynamically defined and is always large enough to hold the amount of data it requests. tbuf is currently statically allocated on the stack with a size of 15 bytes, regardless of the size specified in the URB. This patch dynamically allocates tbuf, and ensures that tbuf is at least as big as the buffer in the URB. If an hcd attempts to write a descriptor containing more than 15 bytes ( such as the Standard BOS Descriptor for hubs, defined in the USB3.0 Spec, section 10.13.1 ) the write would overflow the buffer and corrupt the stack. This patch addresses this behavior. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Sean O. Stalley <sean.stalley@intel.com> Signed-off-by:
-
Jack Pham authored
commit 9841f37a ("usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET") added additional code to the EHCI hub driver but it is anticipated to only have a limited audience (e.g. embedded silicon vendors and integrators). Avoid subjecting all EHCI (and in the future maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally compiling the EHSET-specific additions with a new Kconfig option, CONFIG_USB_HCD_TEST_MODE. Signed-off-by:
Jack Pham <jackp@codeaurora.org> Acked-by:
-
Frank Schäfer authored
The driver currently knows about 3 different PL2303 chip types: The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX type. The device distinction is currently completely based on the examination of the USB descriptors. During the last years, Prolific has introduced further PL2303 chips, such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA, RA, EA and TB variants. Unfortunately, all these new chips are currently detected as HX chips, because they are all using the same bMaxPacketSize0 = 0x40 value in the USB device descriptor. At this point it is not clear if these chips are really working with the driver, there are just some positive indicators (like device manufacturers claiming Linux support for these devices or commit 8d48fdf6 "correctly handle baudrates above 115200" which should only be necessary for newer devices, ...) For a complete support of all devices, we need to distinguish between them, because they differ in several functional aspects, such as the maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps, RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and GPIO ports support (currently not supported by the driver). And there might be further differences that we don't know yet. This patch improves the chip type detection by evaluating the bcdDevice value of the device descriptor. The values are taken from the datasheets and are safe to use because manufacturers can't change them: 3.00: X/HX, TA 4.00: HXD, EA, RA, SA 5.00: TB The rest of the device descriptors is completely identical, so no further distinction is possible this way. Anyway, Prolifics "checkChipVersion.exe"-tool is definitely able to distinguish for example between the X/HX and the TA chips, so there must be a possibility to improve the distinction further... Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Frank Schäfer authored
The chip type distinction is getting more and more relevant and complicating, so always print the chip type. Printing a name string is also much better than just printing an internal index number. Signed-off-by:
-
Frank Schäfer authored
There is no need for two else-if constructs for the type_1 chip detection in pl2303_startup(), so merge them. Signed-off-by:
-
Xenia Ragiadakou authored
The function dma_set_mask() tests internally whether the dma_mask pointer for the device is initialized and fails if the dma_mask pointer is NULL. On pci platforms, the device dma_mask pointer is initialized, when pci devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff. However, for non-pci platforms, the dma_mask pointer may not be initialized and in that case dma_set_mask() will fail. This patch initializes the dma_mask and the coherent_dma_mask to 32bits in xhci_plat_probe(), before the call to usb_create_hcd() that sets the "uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates coherent dma pools for the usb hcd. Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask. Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc() to allocate consistent DMA memory blocks, the coherent DMA address mask has to be set explicitly. This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when the xHC is capable for 64-bit DMA addressing. If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that the given bitmask is also supported for consistent DMA mappings. Other changes introduced in this patch are: - The return value of dma_set_mask() is checked to ensure that the required dma bitmask conforms with the host system's addressing capabilities. - The dma_mask setup code for the non-primary hcd was removed since both primary and non-primary hcd refer to the same generic device whose dma_mask and coherent_dma_mask are already set during the setup of the primary hcd. - The code for reading the HCCPARAMS register to find out the addressing capabilities of xHC was removed since its value is already cached in xhci->hccparams. - hcd->self.controller was replaced with the dev variable since it is already available. Signed-off-by:
Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com>
-
