aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* USB: usbip: remove CONFIG_USB_DEBUG referenceGreg Kroah-Hartman2014-05-28
| | | | | | | As the config option is gone, it's a bit hard to enable it so remove the reference to it. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: remove CONFIG_USB_DEBUG from defconfig filesGreg Kroah-Hartman2014-05-28
| | | | | | | Now that CONFIG_USB_DEBUG is gone, remove it from a number of defconfig files that were enabling it. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: resume child device when port is powered onDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unconditionally wake up the child device when the power session is recovered. This addresses the following scenarios: 1/ The device may need a reset on power-session loss, without this change port power-on recovery exposes khubd to scenarios that usb_port_resume() is set to handle. Prior to port power control the only time a power session would be lost is during dpm_suspend of the hub. In that scenario usb_port_resume() is guaranteed to be called prior to khubd running for that port. With this change we wakeup the child device as soon as possible (prior to khubd running again for this port). Although khubd has facilities to wake a child device it will only do so if the portstatus / portchange indicates a suspend state. In the case of port power control we are not coming from a hub-port-suspend state. This implementation simply uses pm_request_resume() to wake the device and relies on the port_dev->status_lock to prevent any collisions between khubd and usb_port_resume(). 2/ This mechanism rate limits port power toggling. The minimum port power on/off period is now gated by the child device suspend/resume latency. Empirically this mitigates devices downgrading their connection on perceived instability of the host connection. This ratelimiting is really only relevant to port power control testing, but it is a nice side effect of closing the above race. Namely, the race of khubd for the given port running while a usb_port_resume() event is pending. 3/ Going forward we are finding that power-session recovery requires warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This mechanism allows for warm-resets to be requested at the same point in the resume path for hub dpm_suspend power session losses, or port rpm_suspend power session losses. 4/ If the device *was* disconnected the only time we'll know for sure is after a failed resume, so it's necessary for usb_port_runtime_resume() to expedite a usb_port_resume() to clean up the removed device. The reasoning for this is "least surprise" for the user. Turning on a port means that hotplug detection is again enabled for the port, it is surprising that devices that were removed while the port was off are not disconnected until they are attempted to be used. As a user "why would I try to use a device I removed from the system?" 1, 2, and 4 are not a problem in the system dpm_resume() case because, although the power-session is lost, khubd is frozen until after device resume. For the rpm_resume() case pm_request_resume() is used to request re-validation of the device, and if it happens to collide with a khubd run we rely on the port_dev->status_lock to synchronize those operations. Besides testing, the primary scenario where this mechanism is expected to be triggered is when the user changes the port power policy (control/pm_qos_no_poweroff, or power/control). Each time power is enabled want to revalidate the child device, where the revalidation is handled by usb_port_resume(). Given that this arranges for port_dev->child to be de-referenced in usb_port_runtime_resume() we need to make sure not to collide with usb_disconnect() that frees the usb_device. To this end we hold the port active with the "child_usage" reference across the disconnect event. Subsequently, the need to access hub->child_usage_bits lead to the creation of hub_disconnect_children() to remove any ambiguity of which "hub" is being acted on in usb_disconnect() (prompted-by sharp eyes from Alan). Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: hub_handle_remote_wakeup() depends on CONFIG_PM_RUNTIME=yDan Williams2014-05-27
| | | | | | | | | | | | | | | Per Alan: "You mean from within hub_handle_remote_wakeup()? That routine will never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd never sees wakeup requests if they arise during system suspend. In fact, that routine ought to go inside the "#ifdef CONFIG_PM_RUNTIME" portion of hub.c, along with the other suspend/resume code." Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: introduce port status lockDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: synchronize port poweroff and khubdDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | If a port is powered-off, or in the process of being powered-off, prevent khubd from operating on it. Otherwise, the following sequence of events leading to an unintended disconnect may occur: Events: (0) <set pm_qos_no_poweroff to '0' for port1> (1) hub 2-2:1.0: hub_resume (2) hub 2-2:1.0: port 1: status 0301 change 0000 (3) hub 2-2:1.0: state 7 ports 4 chg 0002 evt 0000 (4) hub 2-2:1.0: port 1, power off status 0000, change 0000, 12 Mb/s (5) usb 2-2.1: USB disconnect, device number 5 Description: (1) hub is resumed before sending a ClearPortFeature request (2) hub_activate() notices the port is connected and sets hub->change_bits for the port (3) hub_events() starts, but at the same time the port suspends (4) hub_connect_change() sees the disabled port and triggers disconnect Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: refactor port handling in hub_events()Dan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: usb3 ports do not support FEAT_C_ENABLEDan Williams2014-05-27
| | | | | | | | | | | The port pm_runtime implementation unconditionally clears FEAT_C_ENABLE after clearing PORT_POWER, but the bit is reserved on usb3 hub ports. We expect khubd to be prevented from running because the port state is not RPM_ACTIVE, so we need to clear any errors for usb2 ports. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: don't clear FEAT_C_ENABLE on usb_port_runtime_resume failureDan Williams2014-05-27
| | | | | | | | | | | | | Three reasons: 1/ It's an invalid operation on usb3 ports 2/ There's no guarantee of when / if a usb2 port has entered an error state relative to PORT_POWER request 3/ The port is active / powered at this point, so khubd will clear it as a matter of course Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: block suspension of superspeed port while hispeed peer is activeDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the DSPORT.Powered-off state. There is no way to ensure that RX terminations will persist in this state, so it is possible a device will degrade to its usb2 connection. Prevent this by blocking power-off of a usb3 port while its usb2 peer is active, and powering on a usb3 port before its usb2 peer. By default the latency between peer power-on events is 0. In order for the device to not see usb2 active while usb3 is still powering up inject the hub recommended power_on_good delay. In support of satisfying the power_on_good delay outside of hub_power_on() refactor the places where the delay is consumed to call a new hub_power_on_good_delay() helper. Finally, because this introduces several new checks for whether a port is_superspeed, cache that disctinction at port creation so that we don't need to keep looking up the parent hub device. Acked-by: Alan Stern <stern@rowland.harvard.edu> [alan]: add a 'superspeed' flag to the port Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: make usb_port flags atomic, rename did_runtime_put to child_usageDan Williams2014-05-27
| | | | | | | | | | | | | We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), but we don't want that to collide with other updates. Move usb_port flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed "child_usage_bits" to reflect that it is strictly standing in for the fact that usb_devices are not the device_model children of their parent port. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: sysfs link peer portsDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The usb topology after this change will have symlinks between usb3 ports and their usb2 peers, for example: usb2/2-1/2-1:1.0/2-1-port1/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port1 usb2/2-1/2-1:1.0/2-1-port2/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port2 usb2/2-1/2-1:1.0/2-1-port3/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port3 usb2/2-1/2-1:1.0/2-1-port4/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port4 usb2/2-0:1.0/usb2-port1/peer => ../../../usb3/3-0:1.0/usb3-port1 usb2/2-0:1.0/usb2-port2/peer => ../../../usb3/3-0:1.0/usb3-port2 usb2/2-0:1.0/usb2-port3/peer => ../../../usb3/3-0:1.0/usb3-port3 usb2/2-0:1.0/usb2-port4/peer => ../../../usb3/3-0:1.0/usb3-port4 usb3/3-1/3-1:1.0/usb3-1-port1/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port1 usb3/3-1/3-1:1.0/usb3-1-port2/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port2 usb3/3-1/3-1:1.0/usb3-1-port3/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port3 usb3/3-1/3-1:1.0/usb3-1-port4/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port4 usb3/3-0:1.0/usb3-port1/peer => ../../../usb2/2-0:1.0/usb2-port1 usb3/3-0:1.0/usb3-port2/peer => ../../../usb2/2-0:1.0/usb2-port2 usb3/3-0:1.0/usb3-port3/peer => ../../../usb2/2-0:1.0/usb2-port3 usb3/3-0:1.0/usb3-port4/peer => ../../../usb2/2-0:1.0/usb2-port4 Introduce link_peers_report() to notify on all link_peers() failure cases. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: find internal hub tier mismatch via acpiDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI identifies peer ports by setting their 'group_token' and 'group_position' _PLD data to the same value. If a platform has tier mismatch [1] , ACPI can override the default (USB3 defined) peer port association for internal hubs. External hubs follow the default peer association scheme. Location data is cached as an opaque cookie in usb_port_location data. Note that we only consider the group_token and group_position attributes from the _PLD data as ACPI specifies that group_token is a unique identifier. When we find port location data for a port then we assume that the firmware will also describe its peer port. This allows the implementation to only ever set the peer once. This leads to a question about what happens when a pm runtime event occurs while the peer associations are still resolving. Since we only ever set the peer information once, a USB3 port needs to be prevented from suspending while its ->peer pointer is NULL (implemented in a subsequent patch). There is always the possibility that firmware mis-identifies the ports, but there is not much the kernel can do in that case. [1]: xhci 1.1 appendix D figure 131 [2]: acpi 5 section 6.1.8 [alan]: don't do default peering when acpi data present Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: assign usb3 external hub port peersDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | Given that root hub port peers are already established, external hub peer ports can be determined by traversing the device topology: 1/ ascend to the parent hub and find the upstream port_dev 2/ walk ->peer to find the peer port 3/ descend to the peer hub via ->child 4/ find the port with the matching port id Note that this assumes the port labeling scheme required by the specification [1]. [1]: usb3 3.1 section 10.3.3 Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: assign default peer ports for root hubsDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: cleanup setting udev->removable from port_dev->connect_typeDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | Once usb-acpi has set the port's connect type the usb_device's ->removable attribute can be set in the standard location set_usb_port_removable(). This also changes behavior in the case where the firmware says that the port connect type is unknown. In that case just use the default setting determined from the hub descriptor. Note, we no longer pass udev->portnum to acpi_find_child_device() in the root hub case since: 1/ the usb-core sets this to zero 2/ acpi always expects zero ...just pass zero. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: rename usb_port device objectsDan Williams2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: disable port power control if not supported in wHubCharacteristicsDan Williams2014-05-27
| | | | | | | | | | | | | | | A hub indicates whether it supports per-port power control via the wHubCharacteristics field in its descriptor. If it is not supported a hub will still emulate ClearPortPower(PORT_POWER) requests by stopping the link state machine. However, since this does not save power do not bother suspending. This also consolidates support checks into a hub_is_port_power_switchable() helper. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: mutual exclusion for resetting a hub and power-managing a portAlan Stern2014-05-27
| | | | | | | | | | | | | | | | | | The USB core doesn't properly handle mutual exclusion between resetting a hub and changing the power states of the hub's ports. We need to avoid sending port-power requests to the hub while it is being reset, because such requests cannot succeed. This patch fixes the problem by keeping track of when a reset is in progress. At such times, attempts to suspend (power-off) a port will fail immediately with -EBUSY, and calls to usb_port_runtime_resume() will update the power_is_on flag and return immediately. When the reset is complete, hub_activate() will automatically restore each port to the proper power state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: pci_quirks: fix sparse 'symbol not declared' warningKonrad Zapalowicz2014-05-27
| | | | | | | | | | | | | | This commit fixes the following sparse warning: drivers/usb/host/pci-quirks.c: - 252: warning: symbol 'usb_hcd_amd_remote_wakeup_quirk' was not declared. Should it be static? This function is exported so the fix was to add it's declaration to the header file. Signed-off-by: Konrad Zapalowicz <bergo.torino@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: gadget: rename CONFIG_USB_GADGET_PXA25XPaul Bolle2014-05-27
| | | | | | | | | | | | Commit 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") basically renamed the Kconfig symbol USB_GADGET_PXA25X to USB_PXA25X. It did not rename the related macros in use at that time. Commit c0a39151a405 ("ARM: pxa: fix inconsistent CONFIG_USB_PXA27X") did so for all but one macro. Rename that last macro too now. Fixes: 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: storage: ene_ub6250: Use kmemdup instead of kmalloc + memcpyBenoit Taine2014-05-27
| | | | | | | | This issue was reported by coccicheck using the semantic patch at scripts/coccinelle/api/memdup.cocci Signed-off-by: Benoit Taine <benoit.taine@lip6.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: usbtest: add pattern check on pipe in phase of unlink readHuang Rui2014-05-27
| | | | | | | | | | | TEST 11 unlinks the URB read request for N times. When host and gadget both initialize pattern 1 (mod 63) data series to do IN transfer, the host side function should check the data buffer if it is as mod 63 series, because the data packet which host receivced will follow pattern 1. So this patch adds this checking action. Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: usbtest: fix unlink write error with pattern 1Huang Rui2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TEST 12 and TEST 24 unlinks the URB write request for N times. When host and gadget both initialize pattern 1 (mod 63) data series to transfer, the gadget side will complain the wrong data which is not expected. Because in host side, usbtest doesn't fill the data buffer as mod 63 and this patch fixed it. [20285.488974] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.489181] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.489423] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb50800 length 512 last [20285.489727] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.490055] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.490281] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.490492] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Active [20285.490713] dwc3 dwc3.0.auto: ep1out-bulk: endpoint busy [20285.490909] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Complete [20285.491117] dwc3 dwc3.0.auto: request ffff8800aa6cb480 from ep1out-bulk completed 512/512 ===> 0 [20285.491431] zero gadget: bad OUT byte, buf[1] = 0 [20285.491605] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Set Stall' params 00000000 00000000 00000000 [20285.491915] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.492099] dwc3 dwc3.0.auto: queing request ffff8800aa6cb480 to ep1out-bulk length 512 [20285.492387] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.492595] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.492830] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb51000 length 512 last [20285.493135] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.493465] dwc3 dwc3.0.auto: Command Complete --> 0 Cc: <stable@vger.kernel.org> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: usb5303: add support for reference clock specified in device treeMarek Szyprowski2014-05-27
| | | | | | | | | | | | | USB3503 chip supports 8 values of reference clock. The value is specified by REF_SEL[1:0] pins and INT_N line. This patch add support for getting 'refclk' clock, enabling it and setting INT_N line according to the value of the gathered clock. If no clock has been specified, driver defaults to the old behaviour (assuming that clock has been specified by REF_SEL pins from primary reference clock frequencies table). Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: separate usb_address0 mutexes for each busTodd E Brandt2014-05-27
| | | | | | | | | | | | | | | | | This patch creates a separate instance of the usb_address0 mutex for each USB bus, and attaches it to the usb_bus device struct. This allows devices on separate buses to be enumerated in parallel; saving time. In the current code, there is a single, global instance of the usb_address0 mutex which is used for all devices on all buses. This isn't completely necessary, as this mutex is only needed to prevent address0 collisions for devices on the *same* bus (usb 2.0 spec, sec 4.6.1). This superfluous coverage can cause additional delay in system resume on systems with multiple hosts (up to several seconds depending on what devices are attached). Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Switch only Intel Lynx Point-LP ports to EHCI on shutdown.Denis Turischev2014-05-27
| | | | | | | | | | | | | | | | | Patch "xhci: Switch Intel Lynx Point ports to EHCI on shutdown." commit c09ec25d3684cad74d851c0f028a495999591279 is not fully correct It switches both Lynx Point and Lynx Point-LP ports to EHCI on shutdown. On some Lynx Point machines it causes spurious interrupt, which wake the system: bugzilla.kernel.org/show_bug.cgi?id=76291 On Lynx Point-LP on the contrary switching ports to EHCI seems to be necessary to fix these spurious interrupts. Signed-off-by: Denis Turischev <denis@compulab.co.il> Reported-by: Wulf Richartz <wulf.richartz@gmail.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: delete CONFIG_USB_DEVICEFS from defconfigNaoki MATSUMOTO2014-05-27
| | | | | | | | It no longer occurs in Kconfig. USB: remove CONFIG_USB_DEVICEFS(fb28d58b) leaked remove defconfig. Signed-off-by: Naoki MATSUMOTO <nekomatu+linux@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: udl: proper error reportingOliver Neukum2014-05-27
| | | | | | | | | Parsing device descriptors can fail due to a failed memory allocation. The error needs to be properly propagated to the upper layers. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: yurex: fix race between probe() and read()Oliver Neukum2014-05-27
| | | | | | | | | There's a window during which read() would return 0 instead of a correct error for no data yet. Reorder initialization to fix the race. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: appledisplay: fix race between reading and writing from the deviceOliver Neukum2014-05-27
| | | | | | | | | The workqueue handler may call appledisplay_bl_get_brightness() while user space calls appledisplay_bl_update_status(). As they share a buffer that must not happen. Use a mutex for mutual exclusion. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: usbtmc: fix DMA on stackOliver Neukum2014-05-27
| | | | | | | | send_request_dev_dep_msg_in() use a buffer allocated on the stack. Fix by kmalloc()ing the buffer. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: cdc-acm: use BIT macroOliver Neukum2014-05-27
| | | | | | | | Converting the header to BIT for readability. No functional change. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: gadget: net2280: Add support for PLX USB338XRicardo Ribalda Delgado2014-05-27
| | | | | | | | | | | | | | | | | | | | This patch adds support for the PLX USB3380 and USB3382. This driver is based on the driver from the manufacturer. Since USB338X is register compatible with NET2280, I thought that it would be better to include this hardware into net2280 driver. Manufacturer's driver only supported the USB33X, did not follow the Kernel Style and contain some trivial errors. This patch has tried to address this issues. This patch has only been tested on USB338x hardware, but the merge has been done trying to not affect the behaviour of NET2280. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Tested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: gadget: make return of 0 explicitJulia Lawall2014-05-27
| | | | | | | | | | | | | | | | | | | | | | | | | | Delete unnecessary local variable whose value is always 0 and that hides the fact that the result is always 0. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression ret; expression e; position p; @@ -ret = 0; ... when != ret = e return - ret + 0 ; // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* phy: Enable USB PHY support for arm64Liviu Dudau2014-05-27
| | | | | | | Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: unified loggig of RESET_ON_RESUMEOliver Neukum2014-05-27
| | | | | | | | Either we log for all chips we set the quirk for or for none. This patch reports it for all chips. Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: ehci-platform: add optional reset controller retrievalBoris BREZILLON2014-05-27
| | | | | | | | | | | | | | On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to be deasserted for the EHCI block to be usable. Add support for an optional reset controller that will be deasserted on power off and asserted on power on. Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: ohci-platform: Enable optional use of reset controllerMaxime Ripard2014-05-27
| | | | | | | | | | | | The OHCI controllers used in the Allwinner A31 are asserted in reset using a global reset controller. Add optional support for such a controller in the OHCI platform driver. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: ohci: sort out dependencies for lpc32xx and omapArnd Bergmann2014-05-27
| | | | | | | | | | | | | | | | The dependency on the isp1301 driver is not something that should be in the main OHCI driver but rather the SoC specific part of it. This moves the dependency for LPC32xx into USB_OHCI_HCD_LPC32XX, and changes the 'select ISP1301_OMAP' to a similar 'depends on'. Since the same dependency exists for the client driver, do the same change there. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: linux-omap@vger.kernel.org Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: ohci-da8xx can only be built-inArnd Bergmann2014-05-27
| | | | | | | | | | | | | | | | | | The PHY setup code of the TI DaVinci DA8xx OHCI controller uses ad-hoc register access using a pointer that is meant to be used only by the DaVinci platform implementation and that is intentionally not exported to loadable modules. This results in a link error on configurations that use a modular OHCI code on this platform. While the proper solution for this problem would be to implement a real PHY driver shared by ohci-da8xx and musb-da8xx, this patch for now just works around the build error by only allowing the ohci-da8xx code to be built-in. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: avoid warning for !PM_SLEEPArnd Bergmann2014-05-27
| | | | | | | | | | | | | If we build a kernel with PM_SUSPEND set and no PM_SLEEP, we get a build warning in the xhci-plat driver about unused functions. To fix this, use "#ifdef CONFIG_PM_SLEEP", like we do in most other drivers nowadays. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Mathias Nyman <mathias.nyman@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: dwc2: Add function to calculate correct FIFO sizesDinh Nguyen2014-05-27
| | | | | | | | | | | | | | | | | The dwc2 IP on the SOCFPGA cannot use the default HW configured FIFO sizes. The total FIFO depth as read from GHWCFG3 reports 0x1f80 or 8064 32-bit words. But the GRXFSIZ, GNPTXFSIZ, and HPTXFSIZ register defaults to 0x2000 or 8192 32-bit words. So the driver cannot just use the fifo sizes as read from those registers. For platforms that face the same issue, this commits sets the RX, periodic TX, and non-periodic TX fifo size to those that are recommended v2.93a spec for the DWC2 IP. Implements Method #2 from the Synopsys v2.93a spec for the DWC2. Signed-off-by: Dinh Nguyen <dinguyen@altera.com> Acked-by: Paul Zimmerman <paulz@synopsys.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: dwc2: Disable descriptor dma mode by defaultDinh Nguyen2014-05-27
| | | | | | | | | | | | | Even though the IP supports Descriptor DMA mode, it does not support SPLIT transactions in this mode. So the driver, in its currently form, will not support LS/FS devices when connected to a HS Hub if Descriptor DMA mode is enabled. So we should just default to disable descriptor dma mode. Signed-off-by: Dinh Nguyen <dinguyen@altera.com> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: dt-bindings: update xhci-platform DT bindingGregory CLEMENT2014-05-27
| | | | | | | | | | | | | | This commit extends the compatible string list of the xhci-platform binding with the new "armada-375-xhci" and "armada-380-xhci" compatible strings. It is used to describe the XHCI controller which is available in the Armada 375 and 38x SoCs. It also indicates that an optional 'clocks' property is now supported. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllersGregory CLEMENT2014-05-27
| | | | | | | | | | | | | | | The Armada 375 and 38x SoCs come with an XHCI controller that requires some specific initialization related to the MBus windows configuration. This patch adds the support for this special configuration as an XHCI quirk executed during probe. Two new compatible strings are added to identify the Armada 375 and Armada 38x XHCI controllers, and therefore enable the relevant quirk. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: host: xhci-plat: add clock supportGregory CLEMENT2014-05-27
| | | | | | | | | | | | | | | | | | Some platforms (such as the Armada 38x ones) can gate the clock of their USB controller. This patch adds the support for one clock in xhci-plat, by enabling it during probe and disabling it on remove. To achieve this, it adds a 'struct clk *' member in xhci_hcd. While only used for now in xhci-plat, it might be used by other drivers in the future. Moreover, the xhci_hcd structure already holds other members such as msix_count and msix_entries, which are MSI-X specific, and therefore only used by xhci-pci. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Felipe Balbi <balbi@ti.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: host: xhci-plat: sort the headers in alphabetic orderGregory CLEMENT2014-05-27
| | | | | | | | | Sorting the headers in alphabetic order will help to reduce the conflict when adding new headers later. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Documentation: dt-bindings: update ehci-orion binding documentationThomas Petazzoni2014-05-27
| | | | | | | | | | This commit updates the Device Tree binding documentation of ehci-orion to take into account the fact that we can now optionally pass a clock and a PHY reference. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: ehci-orion: add optional PHY supportGregory CLEMENT2014-05-27
| | | | | | | | | | | | | | | | This commit extends the ehci-orion so that it can optionally be passed a reference to a PHY through the Device Tree. It will be useful for the Armada 375 SoCs. If no PHY is provided then the behavior of the driver is unchanged. [Thomas: use devm_phy_optional_get() so that we handle -EPROBE_DEFER properly. Also call phy_power_off() when needed, and rename goto labels.] Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>