- 16 Aug, 2013 2 commits
-
-
Sarah Sharp authored
xhci: Step 1 to fix usb-linus and usb-next. Hi Greg, This is the first of three steps to fix your usb-linus and usb-next trees. As I mentioned, commit 4fae6f0f "USB: handle LPM errors during device suspend correctly" was incorrectly added to usb-next when it should have been added to usb-linus and marked for stable. Two port power off bug fixes touch the same code that patch touches, but it's not easy to simply move commit 4fae6f0f patch to usb-linus because commit 28e86165 "USB: refactor code for enabling/disabling remote wakeup" also touched those code sections. I propose a two step process to fix this: 1. Pull these four patches into usb-linus. 2. Revert commit 28e86165 from usb-next. Merge usb-linus into usb-next, and resolve the conflicts. I will be sending pull requests for these steps. This pull request is step one, and contains the backported version of commit 4fae6f0f, the two port power off fixes, and an unrelated xhci-plat bug fix. Sarah Sharp Resolved conflicts: drivers/usb/core/hub.c
-
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
-
- 15 Aug, 2013 4 commits
-
-
Sarah Sharp authored
The xHCI platform driver calls into usb_add_hcd to register the irq for its platform device. It does not want the xHCI generic driver to register an interrupt for it at all. The original code did that by setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not enable MSI or MSI-X for a PCI host. Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled, the xHCI generic driver will attempt to register a legacy PCI interrupt for the xHCI platform device in xhci_try_enable_msi(). This will result in a bogus irq being registered, since the underlying device is a platform_device, not a pci_device, and thus the pci_device->irq pointer will be bogus. Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can distinguish between a PCI device that can't handle MSI or MSI-X, and a platform device that should not have its interrupts touched at all. This quirk may be useful in the future, in case other corner cases like this arise. This patch should be backported to kernels as old as 3.9, that contain the commit 00eed9c8 "USB: xhci: correctly enable interrupts". Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by:
Yu Y Wang <yu.y.wang@intel.com> Tested-by:
Felipe Balbi <balbi@ti.com> Cc: stable@vger.kernel.org
-
Sarah Sharp authored
Userspace can tell the kernel to power off any USB port, including ones that are visible and connectible to users. When an attached USB device goes into suspend, the port will be powered off if the pm_qos_no_port_poweroff file for its port is set to 0, the device does not have remote wakeup enabled, and the device is marked as persistent. If the user disconnects the USB device while the port is powered off, the current code does not handle that properly. If you disconnect a device, and then run `lsusb -v -s` for the device, the device disconnect does not get handled by the USB core. The runtime resume of the port fails, because hub_port_debounce_be_connected() returns -ETIMEDOUT. This means the port resume fails and khubd doesn't handle the USB device disconnect. This leaves the device listed in lsusb, and the port's runtime_status will be permanently marked as "error". Fix this by ignoring the return value of hub_port_debounce_be_connected. Users can disconnect USB devices while the ports are powered off, and we must be able to handle that. This patch should be backported to kernels as old as 3.9, that contain the commit ad493e5e "usb: add usb port auto power off mechanism" Signed-off-by:
-
Lan Tianyu authored
The pm qos NO_POWER_OFF flag is checked twice during usb device suspend to see if the usb port power off condition is met. This is redundant and also will prevent the port from being powered off if the NO_POWER_OFF flag is changed to 1 from 0 after the device was already suspended. More detail in the following link. http://marc.info/?l=linux-usb&m=136543949130865&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit f7ac7787 "usb/acpi: Use ACPI methods to power off ports." Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> Signed-off-by:
-
Alan Stern authored
The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Note: Sarah fixed this patch to apply against 3.11, since the original commit (4fae6f0f "USB: handle LPM errors during device suspend correctly") called usb_disable_remote_wakeup, which won't be added until 3.12. This patch should be backported to kernels as old as 3.5, that contain the commit 8306095f "USB: Disable USB 3.0 LPM in critical sections.". There will be merge conflicts, since LTM wasn't added until 3.6. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
- 14 Aug, 2013 34 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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
Johan Hovold authored
Make sure to fail properly if the device is not accepted during attach in order to avoid null-pointer derefs (of missing interface private data) at disconnect or release. Cc: stable@vger.kernel.org Signed-off-by:
-
Johan Hovold authored
The parallel-port code of the drivers used a stack allocated control-request buffer for asynchronous (and possibly deferred) control requests. This not only violates the no-DMA-from-stack requirement but could also lead to corrupt control requests being submitted. Cc: stable@vger.kernel.org Signed-off-by:
-
Oliver Neukum authored
These devices tend to become unresponsive after S3 Signed-off-by:
Oliver Neukum <oneukum@suse.de> CC: stable@vger.kernel.org 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:
-
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:
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:
-
