summaryrefslogtreecommitdiff
path: root/drivers/usb/core/hub.h
AgeCommit message (Collapse)AuthorFilesLines
2016-01-25usb: Support USB 3.1 extended port status requestMathias Nyman1-0/+7
usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02usb: core: lpm: add sysfs node for usb3 lpm permitLu Baolu1-1/+4
USB3 LPM is default on in Linux kernel if both xHCI host controller and the USB devices declare to be LPM-capable. Unfortunately, some devices are known to work well with LPM disabled, but to be broken if LPM is enabled, although it declares the LPM capability. Users won't be able to use this kind of devices, until someone puts them in the kernel blacklist and gets the kernel upgraded. This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2 entry for a port. The settings apply to both before and after device enumeration. Supported values are "0" - neither u1 nor u2 permitted, "u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" - both u1 and u2 are permitted. With this interface, users can use an LPM-unfriendly USB device on a released Linux kernel. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-24usb: hub: convert khubd into workqueuePetr Mladek1-1/+1
There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-10usb: force warm reset to break link re-connect livelockDan Williams1-0/+2
Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> 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>
2014-06-18usb: fix hub-port pm_runtime_enable() vs runtime pm transitionsDan Williams1-0/+2
Commit 9262c19d14c4 "usb: disable port power control if not supported in wHubCharacteristics" gated enabling runtime pm for usb_port devices on whether the parent hub supports power control, which causes a regression. The port must still be allowed to carry out runtime pm callbacks and receive a -EAGAIN or -EBUSY result. Otherwise the usb_port device will transition to the pm error state and trigger the same for the child usb_device. Prior to the offending commit usb_hub_create_port_device() arranged for runtime pm to be disabled is dev_pm_qos_expose_flags() failed. Instead, force the default state of PM_QOS_FLAG_NO_POWER_OFF flag to be set prior to enabling runtime pm. If that policy can not be set then fail registration. Report: http://marc.info/?l=linux-usb&m=140290586301336&w=2 Fixes: 9262c19d14c4 ("usb: disable port power control if not supported in wHubCharacteristics") Reported-by: Bjørn Mork <bjorn@mork.no> Reported-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>
2014-05-28usb: introduce port status lockDan Williams1-2/+2
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>
2014-05-28usb: block suspension of superspeed port while hispeed peer is activeDan Williams1-0/+15
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>
2014-05-28usb: make usb_port flags atomic, rename did_runtime_put to child_usageDan Williams1-4/+3
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>
2014-05-28usb: find internal hub tier mismatch via acpiDan Williams1-0/+2
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>
2014-05-28usb: assign default peer ports for root hubsDan Williams1-0/+2
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>
2014-05-28usb: disable port power control if not supported in wHubCharacteristicsDan Williams1-0/+10
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>
2014-05-28USB: mutual exclusion for resetting a hub and power-managing a portAlan Stern1-0/+1
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>
2014-03-10usbcore: rename struct dev_state to struct usb_dev_stateValentina Manea1-1/+1
Since it is needed outside usbcore and exposed in include/linux/usb.h, it conflicts with enum dev_state in rt2x00 wireless driver. Mark it as usb specific to avoid conflicts in the future. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-08USB: core: correct spelling mistakes in comments and warningRahul Bedarkar1-1/+1
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-17USB: global suspend and remote wakeup don't mixAlan Stern1-0/+3
The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18usb: check usb_hub_to_struct_hub() return valueMathias Nyman1-1/+1
usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-25usb: add usb port auto power off mechanismLan Tianyu1-0/+21
This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-25usb: add runtime pm support for usb port deviceLan Tianyu1-0/+4
This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-25USB: fix sign-extension bug in the hub driverAlan Stern1-1/+1
This patch (as1646) fixes a long-standing bug in the USB hub driver. Upon conversion from char to unsigned long, the bytes in the status buffer are subject to unwanted sign extension. The bytes should be declared as u8 rather than char, to prevent this. This effects of this bug are minimal. The hub driver may end up doing a little unnecessary extra work because it thinks events have occurred on some ports when they really haven't. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-19usb: Add driver/usb/core/(port.c,hub.h) filesLan Tianyu1-0/+97
This patch is to create driver/usb/core/(port.c,hub.h) files and move usb port related code into port.c. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2010-05-21USB: make hub.h public (drivers dependency)Eric Lescouet1-205/+0
The usbcore headers: hcd.h and hub.h are shared between usbcore, HCDs and a couple of other drivers (e.g. USBIP modules). So, it makes sense to move them into a more public location and to cleanup dependency of those modules on kernel internal headers. This patch moves hub.h from drivers/usb/core into include/linux/usb/ Signed-of-by: Eric Lescouet <eric@lescouet.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-13USB: fix the clear_tt_buffer interfaceAlan Stern1-2/+4
This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-16USB: Add USB 3.0 roothub support to USB core.Sarah Sharp1-0/+3
Add USB 3.0 root hub descriptors. This is a kludge because I reused the old USB 2.0 descriptors, instead of using the new USB 3.0 hub descriptors with endpoint companion descriptors and other descriptors. I did this because I wasn't ready to add USB 3.0 hub changes to khubd. For now, a USB 3.0 roothub looks like a USB 2.0 roothub, with a higher speed. USB 3.0 hubs have no transaction translator (TT). Make USB core debugging handle super speed ports. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-25wusb: make ep0_reinit available for modulesInaky Perez-Gonzalez1-0/+1
We need to be able to call ep0_reinit() [renamed to usb_ep0_reinit()] from the WUSB security code. The reason is that when we authenticate the device, it's address changes (from having bit 7 set to having it cleared). Thus, we need to signal the USB stack to reinitialize EP0, so the status with the previous address kept at the HCD layer is cleared and properly reinitialized. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-25USB: defines for USB "Link Power Management" (LPM) ECNDavid Brownell1-2/+6
There's a new PM-related change notice for the USB 2.0 specification called "Link Power Management" (LPM). It defines a new "L1 Suspend" state which resembles the current (L2) suspend state, except that it can be entered and exited much more quickly. It should thus be more useful for runtime PM, even though it doesn't mandate reduced power draw from VBUS. This patch provides the relevant #defines for usbcore. Actually implementing these mechanisms requires host silicon that can generate new USB packets, plus hubs handling some new requests and peripherals which understand the new packets. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-02-02USB: fix codingstyle issues in drivers/usb/core/*.hGreg Kroah-Hartman1-9/+9
Fixes a number of coding style issues in the USB internal header files. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-02USB: Move private hub declarations out of public header fileAlan Stern1-41/+0
This patch (as809b) moves the declaration of the hub driver's private data structure from hub.h into the hub.c source file. Lots of other files import hub.h; they have no need to know about the details of the hub driver's private data. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-02usb/hub: allow hubs up to 31 childreninaky@linux.intel.com1-1/+1
Current Wireless USB host hardware (Intel i1480 for example) allows up to 22 devices to connect, thus bringing up the max number of children in the WUSB Host Controller to 22 'fake' ports. Upcoming hardware might raise that limit. Makes almost no difference to go to 31, as the bit arrays are byte-aligned (plus an extra bit in general), so 22 bits fit in 4 bytes as 31 do. As well, the only other array that depends on USB_MAXCHILDREN is 'struct usb_hub->indicator'. By declaring it 'u8' instead of 'enum hub_led_mode', we reduce the size of each entry from 4 bytes (in i386) to 1, which will add as we when are doubling USB_MAXCHILDREN (with 16 the size of that array is 64 bytes, with 31 would be 128; by using u8 that goes down to 31 bytes). Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-27usbcore: khubd and busy-port handlingAlan Stern1-1/+2
We don't want khubd to start interfering in the device-resume process merely because the PORT_STATUS_C_SUSPEND feature happens to be set. Ports need to be marked as busy while a resume is taking place. In addition, so long as ports are marked as busy, khubd won't be able to clear their various status-change features. On an interrupt-driven root hub this could lead to an interrupt storm. Root hub IRQs should not be re-enabled until the busy_bits value is equal to 0. This patch (as765) fixes these two potential problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-05[PATCH] USB: Consider power budget when choosing configurationAlan Stern1-1/+2
This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-29[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor ↵Greg Kroah-Hartman1-1/+1
fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-09-09[PATCH] ehci: add think_timedavid-b@pacbell.net1-0/+7
This adds think_time to the usb_tt struct and sets it appropriately (measured in ns); this can help us implement better split transaction scheduling. Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-28[PATCH] usbcore: Remove hub_set_power_budgetAlan Stern1-11/+0
This patch removes the hub_set_power_budget routine, which was used by a couple of HCDs to indicate that the root hub was running on battery power. In its place is a new field added to struct usb_hcd, which HCDs can set before the root hub is registered. Special-case code in the hub driver knows to look at this field when configuring a root hub. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+238
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!