summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'for-usb-next-2012-05-21' of ↵Greg Kroah-Hartman2012-05-213-31/+51
|\ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next xhci/usb: Build error fixes for 3.5 Hi Greg, Here's four patches that fix the build errors introduced by the USB 3.0 Link PM patches. Please pull for inclusion in 3.5. Sarah Sharp
| * xhci: Fix DIV_ROUND_UP compile error.Sarah Sharp2012-05-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fengguang reports that the xHCI driver isn't linked properly on his machine: ERROR: "__udivdi3" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined! ERROR: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined! The driver compiles fine on my 64-bit box (gcc version 4.6.1). Fengguang thinks it's because the xHCI driver was using DIV_ROUND_UP() instead of DIV_ROUND_UP_ULL() with arguments that were unsigned long long variables. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Wu Fengguang <wfg@linux.intel.com>
| * xhci: Fix compile with CONFIG_USB_SUSPEND=nSarah Sharp2012-05-211-27/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB 2.0 Link PM code is conditionally compiled when CONFIG_USB_SUSPEND=y. I believe that's a mistake, since Link PM is not directly related to USB device suspend and Link PM is implemented without relying on any of the suspend code in the USB core. For now, keep the USB 2.0 Link PM code conditionally compiled if CONFIG_USB_SUSPEND=y. This patch does move the code to implement USB 3.0 Link PM out of the xHCI driver #ifdefs for CONFIG_USB_SUSPEND and moves it into a section dependent on CONFIG_PM. The USB core functions for USB 3.0 Link PM are already conditionally compiled when CONFIG_PM=y. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB: Fix core compile with CONFIG_USB_SUSPEND=nSarah Sharp2012-05-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CONFIG_PM=n, make sure that the usb_[unlocked_][en/dis]able_lpm declarations are visible in include/linux/usb.h, and exported from drivers/usb/core/hub.c. Before this patch, if CONFIG_USB_SUSPEND was turned off, it would cause build errors: drivers/usb/core/hub.c: In function 'usb_disable_lpm': drivers/usb/core/hub.c:3394:2: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/hub.c: At top level: drivers/usb/core/hub.c:3424:6: warning: conflicting types for 'usb_enable_lpm' [enabled by default] drivers/usb/core/hub.c:3394:2: note: previous implicit declaration of 'usb_enable_lpm' was here drivers/usb/core/driver.c: In function 'usb_probe_interface': drivers/usb/core/driver.c:339:2: error: implicit declaration of function 'usb_unlocked_disable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/driver.c:364:3: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/message.c: In function 'usb_set_interface': drivers/usb/core/message.c:1314:2: error: implicit declaration of function 'usb_disable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/message.c:1323:3: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/message.c:1368:2: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration] Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Chen Peter-B29397 <B29397@freescale.com>
| * brcm80211: Fix compile error for .disable_hub_initiated_lpm.Sarah Sharp2012-05-211-1/+1
| | | | | | | | | | | | | | Fix missing comma. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Wu Fengguang <wfg@linux.intel.com>
* | Revert "USB: EHCI: work around bug in the Philips ISP1562 controller"Greg Kroah-Hartman2012-05-213-9/+1
|/ | | | | | | | | | | This reverts commit 1996e6c572969a8cf6d7fa97eef621219acd94a9. It turned out to not be needed, now that the real fix has been committed. Reported-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: EHCI: fix command register configuration lost problemMing Lei2012-05-191-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 3d9545cc375d117554a9b35dfddadf9189c62775(EHCI: maintain the ehci->command value properly) introducs one command register configuration lost problem by the below line in ehci_reset: ehci->command = ehci_readl(ehci, &ehci->regs->command); After writting RESET into command register, it is restored to its default value per EHCI spec[1], so the previous configuration will be lost, and may introduce some problems reported recently: - imx51 Babbage board detect usb hub failed[2], reported by Richard Zhao. - mouse and keyboard hangs in linux-next found by Dan Carpenter and Greg-KH. So this patch just removes the line to fix these problems, and keep configurating command register consistent as before the commit 3d9545cc(EHCI: maintain the ehci->command value properly). [1], 4.1 Host Controller Initialization of EHCI Specification 1.0 [2], failed dmesg log: usb 1-1: new high-speed USB device number 2 using mxc-ehci hub 1-1:1.0: USB hub found hub 1-1:1.0: 7 ports detected mxc-ehci mxc-ehci.1: fatal error mxc-ehci mxc-ehci.1: HC died; cleaning up mxc-ehci mxc-ehci.1: force halt; handshake f5780344 00004000 00004000 -> -110 mxc-ehci mxc-ehci.1: HC died; cleaning up usb 1-1: USB disconnect, device number 2 Reported-by: Richard Zhao <richard.zhao@freescale.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Chen Peter-B29397 <B29397@freescale.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: Remove races in devio.cHuajun Li2012-05-181-8/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | There exist races in devio.c, below is one case, and there are similar races in destroy_async() and proc_unlinkurb(). Remove these races. cancel_bulk_urbs() async_completed() ------------------- ----------------------- spin_unlock(&ps->lock); list_move_tail(&as->asynclist, &ps->async_completed); wake_up(&ps->wait); Lead to free_async() be triggered, then urb and 'as' will be freed. usb_unlink_urb(as->urb); ===> refer to the freed 'as' Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oncaphillis <oncaphillis@snafu.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: ehci-platform: remove update_deviceHauke Mehrtens2012-05-181-2/+0
| | | | | | | | | | The update_device callback is not needed and the function used here is from the pci ehci driver. Without this patch we get a compile error if ehci-platform is compiled without ehci-pci. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Cc: stable <stable@vger.kernel.org> [3.4] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'for-usb-next-2012-05-18' of ↵Greg Kroah-Hartman2012-05-1866-13/+1385
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next xhci: Link PM and bug fixes for 3.5. Hi Greg, Here's the final Link Power Management patches, along with a couple of bug fixes that have been sitting in my queue. I've fixed all the comments that Alan and Andiry had on the Link PM patches, so I think they're ready to go. Sarah Sharp
| * USB: Disable hub-initiated LPM for comms devices.Sarah Sharp2012-05-1856-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hub-initiated LPM is not good for USB communications devices. Comms devices should be able to tell when their link can go into a lower power state, because they know when an incoming transmission is finished. Ideally, these devices would slam their links into a lower power state, using the device-initiated LPM, after finishing the last packet of their data transfer. If we enable the idle timeouts for the parent hubs to enable hub-initiated LPM, we will get a lot of useless LPM packets on the bus as the devices reject LPM transitions when they're in the middle of receiving data. Worse, some devices might blindly accept the hub-initiated LPM and power down their radios while they're in the middle of receiving a transmission. The Intel Windows folks are disabling hub-initiated LPM for all USB communications devices under a xHCI USB 3.0 host. In order to keep the Linux behavior as close as possible to Windows, we need to do the same in Linux. Set the disable_hub_initiated_lpm flag for for all USB communications drivers. I know there aren't currently any USB 3.0 devices that implement these class specifications, but we should be ready if they do. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Hansjoerg Lipp <hjlipp@web.de> Cc: Tilman Schmidt <tilman@imap.cc> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: Peter Korsgaard <jacmet@sunsite.dk> Cc: Jan Dumon <j.dumon@option.com> Cc: Petko Manolov <petkan@users.sourceforge.net> Cc: Steve Glendinning <steve.glendinning@smsc.com> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Kalle Valo <kvalo@qca.qualcomm.com> Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com> Cc: Jouni Malinen <jouni@qca.qualcomm.com> Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Brett Rudley <brudley@broadcom.com> Cc: Roland Vossen <rvossen@broadcom.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com> Cc: Kan Yan <kanyan@broadcom.com> Cc: Dan Williams <dcbw@redhat.com> Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: Herton Ronaldo Krzesinski <herton@canonical.com> Cc: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Chaoming Li <chaoming_li@realsil.com.cn> Cc: Daniel Drake <dsd@gentoo.org> Cc: Ulrich Kunitz <kune@deine-taler.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * xhci: Add Intel U1/U2 timeout policy.Sarah Sharp2012-05-183-0/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All Intel xHCI host controllers support USB 3.0 Link Power Management. The Panther Point xHCI host controller needs the xHCI driver to calculate the U1 and U2 timeout values, because it will blindly accept a MEL that would cause scheduling issues. The Lynx Point xHCI host controller will reject MEL values that are too high, but internally it implements the same algorithm that is needed for Panther Point xHCI. Simplify the code paths by just having the xHCI driver calculate what the U1/U2 timeouts should be. Comments on the policy are in the code. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * xhci: Add infrastructure for host-specific LPM policies.Sarah Sharp2012-05-183-0/+335
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM) is highly host controller specific. Here are a few examples of why it's host specific: 1. Setting the U1/U2 timeout too short may cause the link to go into U1/U2 in between service intervals, which some hosts may tolerate, and some may not. 2. The host controller has to modify its bus schedule in order to take into account the Maximum Exit Latency (MEL) to bring all the links from the host to the device into U0. If the MEL is too big, and it takes too long to bring the links into an active state, the host controller may not be able to service periodic endpoints in time. 3. Host controllers may also have scheduling limitations that force them to disable U1 or U2 if a USB device is behind too many tiers of hubs. We could take an educated guess at what U1/U2 timeouts may work for a particular host controller. However, that would result in a binary search on every new configuration or alt setting installation, with multiple failed Evaluate Context commands. Worse, the host may blindly accept the timeouts and just fail to update its schedule for U1/U2 exit latencies, which could result in randomly delayed periodic transfers. Since we don't want to cause jitter in periodic transfers, or delay config/alt setting changes too much, lay down a framework that xHCI vendors can extend in order to add their own U1/U2 timeout policies. To extend the framework, they will need to: - Modify the PCI init code to add a new xhci->quirk for their host, and set the XHCI_LPM_SUPPORT quirk flag. - Add their own vendor-specific hooks, like the ones that will be added in xhci_call_host_update_timeout_for_endpoint() and xhci_check_tier_policy() - Make the LPM enable/disable methods call those functions based on the xhci->quirk for their host. An example will be provided for the Intel xHCI host controller in the next patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * xhci: Reserve one command for USB3 LPM disable.Sarah Sharp2012-05-182-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do everything we can to ensure that USB 3.0 Link Power Management (LPM) can be disabled when it is enabled. If LPM can't be disabled, we can't suspend USB 3.0 devices, or reset them. To make sure we can submit the command to disable LPM, allocate a command in the xhci_hcd structure, and reserve one TRB on the command ring. We only need one command per xHCI driver instance, because LPM is only disabled or enabled while the USB core is holding the bandwidth_mutex that is shared between the xHCI USB 2.0 and USB 3.0 roothubs. The bandwidth_mutex will be held until the command completes, or times out. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * xhci: Some Evaluate Context commands must succeed.Sarah Sharp2012-05-183-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The upcoming USB 3.0 Link PM patches will introduce new API to enable and disable low-power link states. We must be able to disable LPM in order to reset a device, or place the device into U3 (device suspend). Therefore, we need to make sure the Evaluate Context command to disable the LPM timeouts can't fail due to there being no room on the command ring. Introduce a new flag to the function that queues the Evaluate Context command, command_must_succeed. This tells the ring handler that a TRB has already been reserved for the command (by incrementing xhci->cmd_ring_reserved_trbs), and basically ensures that prepare_ring() won't fail. A similar flag was already implemented for the Configure Endpoint command queuing function. All functions that currently call xhci_configure_endpoint() to issue an Evaluate Context command pass "false" for the "must_succeed" parameter, so this patch should have no effect on current xHCI driver behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB: Disable USB 3.0 LPM in critical sections.Sarah Sharp2012-05-183-1/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several places where the USB core needs to disable USB 3.0 Link PM: - usb_bind_interface - usb_unbind_interface - usb_driver_claim_interface - usb_port_suspend/usb_port_resume - usb_reset_and_verify_device - usb_set_interface - usb_reset_configuration - usb_set_configuration Use the new LPM disable/enable functions to temporarily disable LPM around these critical sections. We need to protect the critical section around binding and unbinding USB interface drivers. USB drivers may want to disable hub-initiated USB 3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI driver will install. We need to disable LPM completely until the driver is bound to the interface, and the driver has a chance to enable whatever alternate interface setting it needs in its probe routine. Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values. We also need to disable LPM in usb_driver_claim_interface, because drivers like usbfs can bind to an interface through that function. Note, there is no way currently for userspace drivers to disable hub-initiated USB 3.0 LPM. Revisit this later. When a driver is unbound, the U1/U2 timeouts may change because we are unbinding the last driver that needed hub-initiated USB 3.0 LPM to be disabled. USB LPM must be disabled when a USB device is going to be suspended. The USB 3.0 spec does not define a state transition from U1 or U2 into U3, so we need to bring the device into U0 by disabling LPM before we can place it into U3. Therefore, call usb_unlocked_disable_lpm() in usb_port_suspend(), and call usb_unlocked_enable_lpm() in usb_port_resume(). If the port suspend fails, make sure to re-enable LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will not be called on a failed port suspend. USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB device-initiated LPM is enabled) across device suspend. Therefore, disable LPM before the device will be reset in usb_reset_and_verify_device(), and re-enable LPM after the reset is complete and the configuration/alt settings are re-installed. The calculated U1/U2 timeout values are heavily dependent on what USB device endpoints are currently enabled. When any of the enabled endpoints on the device might change, due to a new configuration, or new alternate interface setting, we need to first disable USB 3.0 LPM, add or delete endpoints from the xHCI schedule, install the new interfaces and alt settings, and then re-enable LPM. Do this in usb_set_interface, usb_reset_configuration, and usb_set_configuration. Basically, there is a call to disable and then enable LPM in all functions that lock the bandwidth_mutex. One exception is usb_disable_device, because the device is disconnecting or otherwise going away, and we should not care about whether USB 3.0 LPM is enabled. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB: Add support to enable/disable USB3 link states.Sarah Sharp2012-05-181-0/+414
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are various functions within the USB core that will need to disable USB 3.0 link power states. For example, when a USB device driver is being bound to an interface, we need to disable USB 3.0 LPM until we know if the driver will allow hub-initiated LPM transitions. Another example is when the USB core is switching alternate interface settings. The USB 3.0 timeout values are dependent on what endpoints are enabled, so we want to ensure that LPM is disabled until the new alt setting is fully installed. Multiple functions need to disable LPM, and those functions can even be nested. For example, usb_bind_interface() could disable LPM, and then call into the driver probe function, which may attempt to switch to a different alt setting. Therefore, we need to keep a count of the number of functions that require LPM to be disabled at any point in time. Introduce two new USB core API calls, usb_disable_lpm() and usb_enable_lpm(). These functions increment and decrement a new variable in the usb_device, lpm_disable_count. If usb_disable_lpm() fails, it will call usb_enable_lpm() in order to balance the lpm_disable_count. These two new functions must be called with the bandwidth_mutex locked. If the bandwidth_mutex is not already held by the caller, it should instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take the bandwidth_mutex before calling usb_disable_lpm() and usb_enable_lpm(), respectively. Introduce a new variable (timeout) in the usb3_lpm_params structure to keep track of the currently enabled U1/U2 timeout values. When usb_disable_lpm() is called, and the USB device has the U1 or U2 timeouts set to a non-zero value (meaning either device-initiated or hub-initiated LPM is enabled), attempt to disable LPM, regardless of the state of the lpm_disable_count. We want to ensure that all callers can be guaranteed that LPM is disabled if usb_disable_lpm() returns zero. Otherwise the following scenario could occur: 1. Driver A is being bound to interface 1. usb_probe_interface() disables LPM. Driver A doesn't care if hub-initiated LPM is enabled, so even though usb_disable_lpm() fails, the probe of the driver continues, and the bandwidth mutex is dropped. 2. Meanwhile, Driver B is being bound to interface 2. usb_probe_interface() grabs the bandwidth mutex and calls usb_disable_lpm(). That call should attempt to disable LPM, even though the lpm_disable_count is set to 1 by Driver A. For usb_enable_lpm(), we attempt to enable LPM only when the lpm_disable_count is zero. If some step in enabling LPM fails, it will only have a minimal impact on power consumption, and all USB device drivers should still work properly. Therefore don't bother to return any error codes. Don't enable device-initiated LPM if the device is unconfigured. The USB device will only accept the U1/U2_ENABLE control transfers in the configured state. Do enable hub-initiated LPM in that case, since devices are allowed to accept the LGO_Ux link commands in any state. Don't enable or disable LPM if the device is marked as not being LPM capable. This can happen if: - the USB device doesn't have a SS BOS descriptor, - the device's parent hub has a zeroed bHeaderDecodeLatency value, or - the xHCI host doesn't support LPM. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB: Calculate USB 3.0 exit latencies for LPM.Sarah Sharp2012-05-181-1/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several different exit latencies associated with coming out of the U1 or U2 lower power link state. Device Exit Latency (DEL) is the maximum time it takes for the USB device to bring its upstream link into U0. That can be found in the SuperSpeed Extended Capabilities BOS descriptor for the device. The time it takes for a particular link in the tree to exit to U0 is the maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL. Hubs introduce a further delay that effects how long it takes a child device to transition to U0. When a USB 3.0 hub receives a header packet, it takes some time to decode that header and figure out which downstream port the packet was destined for. If the port is not in U0, this hub header decode latency will cause an additional delay for bringing the child device to U0. This Hub Header Decode Latency is found in the USB 3.0 hub descriptor. We can use DEL and the header decode latency, along with additional latencies imposed by each additional hub tier, to figure out the exit latencies for both host-initiated and device-initiated exit to U0. The Max Exit Latency (MEL) is the worst-case time it will take for a host-initiated exit to U0, based on whether U1 or U2 link states are enabled. The ping or packet must traverse the path to the device, and each hub along the way incurs the hub header decode latency in order to figure out which device the transfer was bound for. We say worst-case, because some hubs may not be in the lowest link state that is enabled. See the examples in section C.2.2.1. Note that "HSD" is a "host specific delay" that the power appendix architect has not been able to tell me how to calculate. There's no way to get HSD from the xHCI registers either, so I'm simply ignoring it. The Path Exit Latency (PEL) is the worst-case time it will take for a device-initiate exit to U0 to place all the links from the device to the host into U0. The System Exit Latency (SEL) is another device-initiated exit latency. SEL is useful for USB 3.0 devices that need to send data to the host at specific intervals. The device may send an NRDY to indicate it isn't ready to send data, then put its link into a lower power state. If it needs to have that data transmitted at a specific time, it can use SEL to back calculate when it will need to bring the link back into U0 to meet its deadlines. SEL is the worst-case time from the device-initiated exit to U0, to when the device will receive a packet from the host controller. It includes PEL, the time it takes for an ERDY to get to the host, a host-specific delay for the host to process that ERDY, and the time it takes for the packet to traverse the path to the device. See Figure C-2 in the USB 3.0 bus specification. Note: I have not been able to get good answers about what the host-specific delay to process the ERDY should be. The Intel HW developers say it will be specific to the platform the xHCI host is integrated into, and they say it's negligible. Ignore this too. Separate from these four exit latencies are the U1/U2 timeout values we program into the parent hubs. These timeouts tell the hub to attempt to place the device into a lower power link state after the link has been idle for that amount of time. Create two arrays (one for U1 and one for U2) to store mel, pel, sel, and the timeout values. Store the exit latency values in nanosecond units, since that's the smallest units used (DEL is in us, but the Hub Header Decode Latency is in ns). If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS descriptor, it's highly unlikely it will be able to handle LPM requests properly. So it's best to disable LPM for devices that don't have this descriptor, and any children beneath it, if it's a USB 3.0 hub. Warn users when that happens, since it means they have a non-compliant USB 3.0 device or hub. This patch assumes a simplified design where links deep in the tree will not have U1 or U2 enabled unless all their parent links have the corresponding LPM state enabled. Eventually, we might want to allow a different policy, and we can revisit this patch when that happens. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
| * USB: Refactor code to set LPM support flag.Sarah Sharp2012-05-181-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | Refactor the code that sets the usb_device flag to indicate the device support link power management (lpm_capable). The current code sets lpm_capable unconditionally if the USB devices have a USB 2.0 Extended Capabilities Descriptor. USB 3.0 devices can also have that descriptor, but the xHCI driver code that uses lpm_capable will not run the USB 2.0 LPM test for devices under the USB 3.0 roothub. Therefore, it's fine only set lpm_capable for high speed devices in this refactoring. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB: Make sure to fetch the BOS desc for roothubs.Sarah Sharp2012-05-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | The BOS descriptor is normally fetched and stored in the usb_device->bos during enumeration. USB 3.0 roothubs don't undergo enumeration, but we need them to have a BOS descriptor, since each xHCI host has a different U1 and U2 exit latency. Make sure to fetch the BOS descriptor for USB 3.0 roothubs. It will be freed when the roothub usb_device is released. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com>
| * xhci: Add roothub code to set U1/U2 timeouts.Sarah Sharp2012-05-182-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | USB 3.0 hubs can be put into a mode where the hub can automatically request that the link go into a deeper link power state after the link has been idle for a specified amount of time. Each of the new USB 3.0 link states (U1 and U2) have their own timeout that can be programmed per port. Change the xHCI roothub emulation code to handle the request to set the U1 and U2 timeouts. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * xhci: Reset reserved command ring TRBs on cleanup.Sarah Sharp2012-05-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the xHCI driver needs to clean up memory (perhaps due to a failed register restore on resume from S3 or resume from S4), it needs to reset the number of reserved TRBs on the command ring to zero. Otherwise, several resume cycles (about 30) with a UAS device attached will continually increment the number of reserved TRBs, until all command submissions fail because there isn't enough room on the command ring. This patch should be backported to kernels as old as 2.6.32, that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d "USB: xhci: Change how xHCI commands are handled." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
| * USB: fix resource leak in xhci power loss pathOliver Neukum2012-05-181-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some more data structures must be freed and counters reset if an XHCI controller has lost power. The failure to do so renders some chips inoperative after a certain number of S4 cycles. This patch should be backported to kernels as old as 3.2, that contain the commits c29eea621900f18287d50519f72cb9113746d75a "xhci: Implement HS/FS/LS bandwidth checking." and commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Implement HS/FS/LS bandwidth checking." Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
| * usbcore: enable USB2 LPM if port suspend failsAndiry Xu2012-05-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB2 LPM is disabled when device begin to suspend and enabled after device is resumed. That's because USB spec does not define the transition from U1/U2 state to U3 state. If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM is disabled in this situation. Enable USB2 LPM if port suspend fails. This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM". Signed-off-by: Andiry Xu <andiry.xu@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
| * xhci: Add new short TX quirk for Fresco Logic host.Sarah Sharp2012-05-173-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sergio reported that when he recorded audio from a USB headset mic plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded "robotic". When plugged into the USB 2.0 port under EHCI on the same laptop, the audio sounded fine. The device is: Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset The problem was tracked down to the Fresco Logic xHCI host controller not correctly reporting short transfers on isochronous IN endpoints. The driver would submit a 96 byte transfer, the device would only send 88 or 90 bytes, and the xHCI host would report the transfer had a "successful" completion code, with an untransferred buffer length of 8 or 6 bytes. The successful completion code and non-zero untransferred length is a contradiction. The xHCI host is supposed to only mark a transfer as successful if all the bytes are transferred. Otherwise, the transfer should be marked with a short packet completion code. Without the EHCI bus trace, we wouldn't know whether the xHCI driver should trust the completion code or the untransferred length. With it, we know to trust the untransferred length. Add a new xHCI quirk for the Fresco Logic host controller. If a transfer is reported as successful, but the untransferred length is non-zero, print a warning. For the Fresco Logic host, change the completion code to COMP_SHORT_TX and process the transfer like a short transfer. This should be backported to stable kernels that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts." That commit was marked for stable kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Sergio Correia <lists@uece.net> Tested-by: Sergio Correia <lists@uece.net> Cc: stable@vger.kernel.org Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | USB: gpio_vbus: wakeup support on GPIO VBUS interruptsShinya Kuribayashi2012-05-171-0/+33
| | | | | | | | | | | | | | | | | | | | We'd like to see the system waking up from the system-wide suspend when it gets plugged-in, or the USB cable is pulled out. Also makes it configurable via platform data 'wakeup'. Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: gpio_vbus: a missing cancellation of workqueue in remove() functionShinya Kuribayashi2012-05-171-0/+1
| | | | | | | | | | Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: gpio_vbus: handle IRQ flags properlyShinya Kuribayashi2012-05-171-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, 'res->flags' handlings are wrong in three respects: * the driver _modifies_ the contents of platform data * res->flags is set up, but not used anywhere in the driver * request_irq() always takes VBUS_IRQ_FLAGS, regardless of refs->flags This patch tries to fix this with a policy: If a platform IRQ resource is available, give preference to its IRQ flag(s) over a default one (VBUS_IRQ_FLAGS). Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: gpio_vbus: remove IRQF_SAMPLE_RANDOM useShinya Kuribayashi2012-05-171-3/+2
| | | | | | | | | | | | | | | | | | | | | | IRQF_SAMPLE_RANDOM has been scheduled for removal for years (it was scheduled by July 2009, but not yet remvoed). I'm not sure when it's going to take place, but would be better to remove it now. Thanks for scripts/checkpatch secretary. Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: gpio_vbus: use cached IRQ number for consistency with the probed oneShinya Kuribayashi2012-05-171-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gpio_vbus is designed to be able to get an IRQ number for VBUS change interrupt either (1) through platform_get_resource(IORESOURCE_IRQ) or (2) by processing gpio_to_irq(pdata->gpio_vbus), in probe() function. On the other hand, gpio_vbus_set_peripheral() and gpio_vbus_remove() are always doing gpio_to_irq(pdata->gpio_vbus) to get an IRQ number. This is not just inconsistent, but also broken. There is no guarantee that an IRQ number obtained by platform_get_resource() is equal to gpio_to_irq(pdata->gpio_vbus). Cache an IRQ number in probe() function, and use it where necessary. Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | USB: twl6030-usb: pass IRQF_ONESHOT to request_threaded_irqMing Lei2012-05-171-2/+2
|/ | | | | | | | | | | | | | | | The flag of IRQF_ONESHOT should be passed to request_threaded_irq, otherwise the following failure message will be dumped because hardware handler is defined as NULL: [ 2.271148] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356 [ 2.279541] twl6030_usb twl6030_usb: can't get IRQ 356, err -22 [ 2.285919] twl6030_usb: probe of twl6030_usb failed with error -22 The patch fixes the twl6030-usb probe failure. Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: storage: fixed keyword related space issues.Jeffrin Jose2012-05-171-2/+2
| | | | | | | | Fixed keyword related space issues found by checkpatch.pl tool in drivers/usb/storage/usb.c Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: storage: fixed several trailing white spaces issues.Jeffrin Jose2012-05-171-9/+9
| | | | | | | | Fixed several trailing white spaces issues found by checkpatch.pl tool in drivers/usb/storage/usb.c Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: storage: fixed C99 comment issue.Jeffrin Jose2012-05-171-1/+1
| | | | | | | | Fixed C99 comment issue in drivers/usb/storage/usb.c found using checkpatch.pl tool. Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge branch 'v3.5-for-usb' of ↵Greg Kroah-Hartman2012-05-1754-388/+371
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into usb-next
| * Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6Linus Torvalds2012-05-122-35/+40
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull a few more GPIO bug fixes from Grant Likely: "Oops, missed a couple. Here's an updated pull req for GPIO" A set of PCH bug fixes, and one patch to fix up compile warnings * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: gpio/exynos: Fix compiler warnings when non-exynos machines are selected gpio: pch9: Use proper flow type handlers
| | * gpio/exynos: Fix compiler warnings when non-exynos machines are selectedSachin Kamat2012-05-111-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following compiler warnings: drivers/gpio/gpio-samsung.c: In function ‘samsung_gpiolib_init’: drivers/gpio/gpio-samsung.c:2980:1: warning: label ‘err_ioremap1’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2978:1: warning: label ‘err_ioremap2’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2976:1: warning: label ‘err_ioremap3’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2974:1: warning: label ‘err_ioremap4’ defined but not used [-Wunused-label] drivers/gpio/gpio-samsung.c:2722:55: warning: unused variable ‘gpio_base4’ [-Wunused-variable] drivers/gpio/gpio-samsung.c:455:32: warning: ‘exynos_gpio_cfg’ defined but not used [-Wunused-variable] drivers/gpio/gpio-samsung.c:2126:33: warning: ‘exynos4_gpios_1’ defined but not used [-Wunused-variable] drivers/gpio/gpio-samsung.c:2228:33: warning: ‘exynos4_gpios_2’ defined but not used [-Wunused-variable] drivers/gpio/gpio-samsung.c:2373:33: warning: ‘exynos4_gpios_3’ defined but not used [-Wunused-variable] Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
| | * gpio: pch9: Use proper flow type handlersThomas Gleixner2012-05-111-29/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jean-Francois Dagenais reported: Configuring a gpio pin with the gpio-pch driver with "IRQF_TRIGGER_LOW | IRQF_ONESHOT" generates an interrupt storm for threaded ISR until the ISR thread actually gets to physically clear the interrupt on the triggering chip!! The immediate observable symptom is the high CPU usage for my ISR thread task and the interrupt count in /proc/interrupts incrementing radically. The driver is wrong in several ways: 1) Using handle_simple_irq() does not provide proper flow control handling. In the case of oneshot threaded handlers for the demultiplexed interrupts this results in an interrupt storm because the simple handler does not deal with masking/unmasking. Even without threaded oneshot handlers an interrupt storm for level type interrupts can easily be triggered when the interrupt is disabled and the interrupt line is activated from the device. 2) Acknowlegding the demultiplexed interrupt before calling the handler is wrong for level type interrupts. 3) The set_type function unconditionally enables the interrupt. It's supposed to set the type and nothing else. The unmasking is done by the core code. Move the acknowledge code into a separate function and add it to the demux irqchip callbacks. Remove the unconditional enabling from the set_type() callback and set the proper flow handlers depending on the selected type (level/edge). Reported-and-tested-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
| * | Merge tag 'scsi-fixes' of ↵Linus Torvalds2012-05-129-18/+57
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of minor qla and virto fixes plus one major regression fix (oops in all legacy host drivers)." * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: [SCSI] virtio_scsi: fix TMF use-after-free [SCSI] fix oops in all legacy host adapters caused by 6f381fa [SCSI] qla2xxx: Update version number to 8.04.00.03-k. [SCSI] qla2xxx: Properly check for current state after the fabric-login request. [SCSI] qla2xxx: Proper completion to scsi-ml for scsi status task_set_full and busy. [SCSI] qla2xxx: Block flash access from application when device is initialized for ISP82xx. [SCSI] qla2xxx: Fix reset time out as qla2xxx not ack to reset request.
| | * | [SCSI] virtio_scsi: fix TMF use-after-freePaolo Bonzini2012-05-101-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a use-after-free in the TMF path, where cmd may have been already freed by virtscsi_complete_free when wait_for_completion restarts executing virtscsi_tmf. Technically a race, but in practice the command will always be freed long before the completion waiter is awoken. The fix is to make callers specifying a completion responsible for freeing the command in all cases. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| | * | [SCSI] fix oops in all legacy host adapters caused by 6f381faJames Bottomley2012-05-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6f381fa344911d5a234b13574433cf23036f9467 Author: Lin Ming <ming.m.lin@intel.com> [SCSI] scsi_lib: use correct DMA device in __scsi_alloc_queue Caused a regression where we oops in every legacy mode SCSI host driver because they supply a NULL pointer to scsi_add_host(). Fix this by checking for the NULL in scsi_add_host_with_dma() and changing the DMA device to being the platform_bus in that case (which replicates the original behaviour). Reported-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| | * | [SCSI] qla2xxx: Update version number to 8.04.00.03-k.Chad Dupuis2012-05-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| | * | [SCSI] qla2xxx: Properly check for current state after the fabric-login request.Saurav Kashyap2012-05-101-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [jejb: checkpatch fixes] Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| | * | [SCSI] qla2xxx: Proper completion to scsi-ml for scsi status task_set_full ↵Giridhar Malavali2012-05-102-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and busy. In case of firmmware detected under-run condition and scsi status of task_set_full or busy_condition, return that to the mid layer for proper error handling instead of DID_ERROR (which causes error handler activation and a full retry). Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| | * | [SCSI] qla2xxx: Block flash access from application when device is ↵Giridhar Malavali2012-05-102-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialized for ISP82xx. Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| | * | [SCSI] qla2xxx: Fix reset time out as qla2xxx not ack to reset request.Vikas Chaudhary2012-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Vikas Chaudhary <vikas.chaudhary@qlogic.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds2012-05-1226-93/+181
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull networking fixes from David S. Miller: 1) Since we do RCU lookups on ipv4 FIB entries, we have to test if the entry is dead before returning it to our caller. 2) openvswitch locking and packet validation fixes from Ansis Atteka, Jesse Gross, and Pravin B Shelar. 3) Fix PM resume locking in IGB driver, from Benjamin Poirier. 4) Fix VLAN header handling in vhost-net and macvtap, from Basil Gor. 5) Revert a bogus network namespace isolation change that was causing regressions on S390 networking devices. 6) If bonding decides to process and handle a LACPDU frame, we shouldn't bump the rx_dropped counter. From Jiri Bohac. 7) Fix mis-calculation of available TX space in r8169 driver when doing TSO, which can lead to crashes and/or hung device. From Julien Ducourthial. 8) SCTP does not validate cached routes properly in all cases, from Nicolas Dichtel. 9) Link status interrupt needs to be handled in ks8851 driver, from Stephen Boyd. 10) Use capable(), not cap_raised(), in connector/userns netlink code. From Eric W. Biederman via Andrew Morton. 11) Fix pktgen OOPS on module unload, from Eric Dumazet. 12) iwlwifi under-estimates SKB truesizes, also from Eric Dumazet. 13) Cure division by zero in SFC driver, from Ben Hutchings. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (26 commits) ks8851: Update link status during link change interrupt macvtap: restore vlan header on user read vhost-net: fix handle_rx buffer size bonding: don't increase rx_dropped after processing LACPDUs connector/userns: replace netlink uses of cap_raised() with capable() sctp: check cached dst before using it pktgen: fix crash at module unload Revert "net: maintain namespace isolation between vlan and real device" ehea: fix losing of NEQ events when one event occurred early igb: fix rtnl race in PM resume path ipv4: Do not use dead fib_info entries. r8169: fix unsigned int wraparound with TSO sfc: Fix division by zero when using one RX channel and no SR-IOV openvswitch: Validation of IPv6 set port action uses IPv4 header net: compare_ether_addr[_64bits]() has no ordering cdc_ether: Ignore bogus union descriptor for RNDIS devices bnx2x: bug fix when loading after SAN boot e1000: Silence sparse warnings by correcting type igb, ixgbe: netdev_tx_reset_queue incorrectly called from tx init path openvswitch: Release rtnl_lock if ovs_vport_cmd_build_info() failed. ...
| | * | | ks8851: Update link status during link change interruptStephen Boyd2012-05-111-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a link change interrupt comes in we just clear the interrupt and continue along without notifying the upper networking layers that the link has changed. Use the mii_check_link() function to update the link status whenever a link change interrupt occurs. Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| | * | | macvtap: restore vlan header on user readBasil Gor2012-05-111-5/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ethernet vlan header is not on the packet and kept in the skb->vlan_tci when it comes from lower dev. This patch inserts vlan header in user buffer during skb copy on user read. Signed-off-by: Basil Gor <basil.gor@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| | * | | vhost-net: fix handle_rx buffer sizeBasil Gor2012-05-111-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take vlan header length into account, when vlan id is stored as vlan_tci. Otherwise tagged packets coming from macvtap will be truncated. Signed-off-by: Basil Gor <basil.gor@gmail.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-01 02:44:04 +0000