- 25 2月, 2012 9 次提交
-
-
由 Neil Zhang 提交于
This ehci driver is mainly designed to support host controller found on Marvell PXA and MMP Soc series. Add the dependence to avoid the potential build failure which may include two EHCI controller drivers. Signed-off-by: NNeil Zhang <zhangwm@marvell.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jingoo Han 提交于
This patch removes uses of hcd->state and replaces hcd->state with ohci->rh_state field. Signed-off-by: NJingoo Han <jg1.han@samsung.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Deepak Sikri 提交于
This patch adds support for standby/S2R/hibernate for ehci-spear driver. Signed-off-by: NDeepak Sikri <deepak.sikri@st.com> Signed-off-by: NPratyush Anand <pratyush.anand@st.com> Signed-off-by: NViresh Kumar <viresh.kumar@st.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Shengzhou Liu 提交于
If USB UTMI PHY is not enable, writing to portsc register will lead to kernel hang during boot up. Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com> Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Chen 提交于
When build i.mx platform with imx_v6_v7_defconfig, and after adding USB Gadget support, it has below build error: CC drivers/usb/host/fsl-mph-dr-of.o drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register': drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata' has no member named 'dma_mask' It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html For PowerPC, there is dma_mask at struct pdev_archdata, but there is no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is related to specific platform, it should NOT be accessed by cross platform drivers, like USB. The code for pdev_archdata should be useless, as for PowerPC, it has already gotten the value for pdev->dev.dma_mask at function arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c. Tested-by: NRamneek Mehresh <ramneek.mehresh@freescale.com> Signed-off-by: NPeter Chen <peter.chen@freescale.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Masanari Iida 提交于
Correct spelling "peridic" to "periodic" in drivers/usb/host/ehci-dbg.c Signed-off-by: NMasanari Iida <standby24x7@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Tobias Klauser 提交于
Move the usb_disabled() check to the probe function and get rid of the rather pointless message on module load. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Acked-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Pan Jiafei 提交于
If a MPC8xxx was being used, 'have_sysif_regs' should be set and it should setup cache snooping for all the 4GB space on both PPC32 and PPC64. Signed-off-by: NPan Jiafei <Jiafei.Pan@freescale.com> Acked-by: NLi Yang <leoli@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Neil Zhang 提交于
Since ehci-mv.c can cover Marvell PXA and MMP series including PXA168, so this driver seems redundant now. Signed-off-by: NNeil Zhang <zhangwm@marvell.com> Cc: <tanmay.upadhyay@einfochips.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 2月, 2012 2 次提交
-
-
由 Sarah Sharp 提交于
The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must be encoded as an exponent of two number of microframes. The endpoint descriptor has the NAK rate encoded in number of microframes. We were just copying the value from the endpoint descriptor into the endpoint context interval field, which was not correct. This lead to the VIA host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass storage device. The fix is to use the correct encoding. Refactor the code to convert number of frames to an exponential number of microframes, and make sure we convert the number of microframes in HS bulk and control endpoints to an exponent. This should be back ported to kernels as old as 2.6.31, that contain the commit dfa49c4a "USB: xhci - fix math in xhci_get_endpoint_interval" Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: NFelipe Contreras <felipe.contreras@gmail.com> Suggested-by: NAndiry Xu <andiry.xu@amd.com> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
On some systems with an Intel Panther Point xHCI host controller, the BIOS disables the xHCI PCI device during boot, and switches the xHCI ports over to EHCI. This allows the BIOS to access USB devices without having xHCI support. The downside is that the xHCI BIOS handoff mechanism will fail because memory mapped I/O is not enabled for the disabled PCI device. Jesse Barnes says this is expected behavior. The PCI core will enable BARs before quirks run, but it will leave it in an undefined state, and it may not have memory mapped I/O enabled. Make the generic USB quirk handler call pci_enable_device() to re-enable MMIO, and call pci_disable_device() once the host-specific BIOS handoff is finished. This will balance the ref counts in the PCI core. When the PCI probe function is called, usb_hcd_pci_probe() will call pci_enable_device() again. This should be back ported to kernels as old as 2.6.31. That was the first kernel with xHCI support, and no one has complained about BIOS handoffs failing due to memory mapped I/O being disabled on other hosts (EHCI, UHCI, or OHCI). Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NOliver Neukum <oneukum@suse.de> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org
-
- 16 2月, 2012 1 次提交
-
-
由 Felipe Balbi 提交于
not all platforms will use all of those ehci_* symbols on their hc_driver structure. Sometimes we might need to provide a modified version of a certain method or not provide it at all, as is the case with OMAPs which don't support port handoff feature. Whenever we compile a kernel for an OMAP board with EHCI enabled, we get compile warnings: drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' \ defined but not used drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' \ defined but not used In order to cleanup those warnings, we're adding __maybe_unused annotation to those functions. Signed-off-by: NFelipe Balbi <balbi@ti.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 2月, 2012 5 次提交
-
-
由 Sarah Sharp 提交于
USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs. USB 2.0 hubs, once they have remote wakeup enabled, will always send remote wakes when anything changes on a port. However, USB 3.0 hubs have a per-port remote wake up policy that is off by default. The Set Feature remote wake mask can be changed for any port, enabling remote wakeup for a connect, disconnect, or overcurrent event, much like EHCI and xHCI host controller "wake on" port status bits. The bits are cleared to zero on the initial hub power on, or after the hub has been reset. Without this patch, when a USB 3.0 hub gets suspended, it will not send a remote wakeup on device connect or disconnect. This would show up to the user as "dead ports" unless they ran lsusb -v (since newer versions of lsusb use the sysfs files, rather than sending control transfers). Change the hub driver's suspend method to enable remote wake up for disconnect, connect, and overcurrent for all ports on the hub. Modify the xHCI driver's roothub code to handle that request, and set the "wake on" bits in the port status registers accordingly. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
When the USB 3.0 hub support went in, I disabled selective suspend for all external USB 3.0 hubs because they used a different mechanism to enable remote wakeup. In fact, other USB 3.0 devices that could signal remote wakeup would have been prevented from going into suspend because they would have stalled the SetFeature Device Remote Wakeup request. This patch adds support for the USB 3.0 way of enabling remote wake up (with a SetFeature Function Suspend request), and enables selective suspend for all hubs during hub_probe. It assumes that all USB 3.0 have only one "function" as defined by the interface association descriptor, which is true of all the USB 3.0 devices I've seen so far. FIXME if that turns out to change later. After a device signals a remote wakeup, it is supposed to send a Device Notification packet to the host controller, signaling which function sent the remote wakeup. The host can then put any other functions back into function suspend. Since we don't have support for function suspend (and no devices currently support it), we'll just assume the hub function will resume the device properly when it received the port status change notification, and simply ignore any device notification events from the xHCI host controller. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
xHCI roothubs go through slightly different port state machines when either a device initiates a remote wakeup and signals resume, or when the host initiates a resume. According to section 4.19.1.2.13 of the xHCI 1.0 spec, on host-initiated resume, the xHC port state machine automatically goes through the U3Exit state into the U0 state, setting the port link state change (PLC) bit in the process. When a device initiates resume, the xHCI port state machine goes into the "Resume" state and sets the PLC bit. Then the xHCI driver writes U0 into the port link state register to transition the port to U0 from the Resume state. We can't be sure the device is actually in the U0 state until we receive the next port status change event with the PLC bit set. We really don't want khubd to be polling the roothub port status bits until the device is really in U0. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAndiry Xu <andiry.xu@amd.com>
-
由 Sarah Sharp 提交于
Intel has a PCI USB xhci host controller on a new platform. It doesn't have a line IRQ definition in BIOS. The Linux driver refuses to initialize this controller, but Windows works well because it only depends on MSI. Actually, Linux also can work for MSI. This patch avoids the line IRQ checking for USB3 HCDs in usb core PCI probe. It allows the xHCI driver to try to enable MSI or MSI-X first. It will fail the probe if MSI enabling failed and there's no legacy PCI IRQ. This patch should be backported to kernels as old as 2.6.32. Signed-off-by: NAlex Shi <alex.shi@intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 14 2月, 2012 1 次提交
-
-
由 Masanari Iida 提交于
Correct spelling "alocate" to "allocate" in drivers/usb/host/imx21-dbg.c Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 2月, 2012 1 次提交
-
-
由 Sarah Sharp 提交于
The code to set the device removable bits in the USB 2.0 roothub descriptor was accidentally looking at the USB 3.0 port registers instead of the USB 2.0 registers. This can cause an oops if there are more USB 2.0 registers than USB 3.0 registers. This should be backported to kernels as old as 2.6.39, that contain the commit 4bbb0ace "xhci: Return a USB 3.0 hub descriptor for USB3 roothub." Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 03 2月, 2012 4 次提交
-
-
由 Randy Dunlap 提交于
Fix kconfig warnings and build errors in UWB/WUSB/USB_HWA etc. by making all of these related symbols depend on UWB. warning: (USB_WHCI_HCD && USB_HWA_HCD) selects USB_WUSB which has unmet direct dependencies (USB_SUPPORT && EXPERIMENTAL && USB && PCI && UWB) warning: (USB_HWA_HCD) selects UWB_HWA which has unmet direct dependencies (UWB && USB) which lead to: ERROR: "uwb_rsv_establish" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_pal_register" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_rsv_get_usable_mas" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_rsv_destroy" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_radio_stop" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_rsv_terminate" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_pal_unregister" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_pal_init" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_rc_reset_all" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_radio_start" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_rsv_create" [drivers/usb/wusbcore/wusbcore.ko] undefined! ERROR: "uwb_rc_put" [drivers/usb/host/whci/whci-hcd.ko] undefined! ERROR: "uwb_rc_get_by_grandpa" [drivers/usb/host/whci/whci-hcd.ko] undefined! ERROR: "__umc_driver_register" [drivers/usb/host/whci/whci-hcd.ko] undefined! ERROR: "umc_driver_unregister" [drivers/usb/host/whci/whci-hcd.ko] undefined! ERROR: "whci_wait_for" [drivers/usb/host/whci/whci-hcd.ko] undefined! ERROR: "uwb_rc_get_by_grandpa" [drivers/usb/host/hwa-hc.ko] undefined! ERROR: "uwb_rc_put" [drivers/usb/host/hwa-hc.ko] undefined! Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jayachandran C 提交于
The Netlogic XLP SoC's on-chip USB controller appears as a PCI USB device, but does not need the EHCI/OHCI handoff done in usb/host/pci-quirks.c. The pci-quirks.c is enabled for all vendors and devices, and is enabled if USB and PCI are configured. If we do not skip the qurik handling on XLP, the readb() call in ehci_bios_handoff() will cause a crash since byte access is not supported for EHCI registers in XLP. Signed-off-by: NJayachandran C <jayachandranc@netlogicmicro.com> Cc: stable <stable@vger.kernel.org> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Shengzhou Liu 提交于
when missing USB PHY clock, kernel booting up will halt during USB initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid CPU hang in this case. Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Fabio Estevam 提交于
Distinguish Kconfig text by providing the Freescale family name. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 26 1月, 2012 1 次提交
-
-
由 Andiry Xu 提交于
When a TD length mismatch is found during isoc TRB enqueue, it directly returns -EINVAL. However, isoc transfer is partially enqueued at this time, and the ring should be cleared. This should be backported to kernels as old as 2.6.36, which contain the commit 522989a2 "xhci: Fix failed enqueue in the middle of isoch TD." Signed-off-by: NAndiry Xu <andiry.xu@amd.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 25 1月, 2012 8 次提交
-
-
由 Greg Kroah-Hartman 提交于
This reverts commit 0dd2b62a. It causes a bunch of Kconfig errors: drivers/usb/host/Kconfig:559:error: recursive dependency detected! drivers/usb/host/Kconfig:559: symbol USB_HWA_HCD depends on UWB drivers/uwb/Kconfig:5: symbol UWB is selected by USB_WUSB drivers/usb/wusbcore/Kconfig:4: symbol USB_WUSB is selected by USB_HWA_HCD showing that this really wasn't the correct fix at all. Cc: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Kelvin Cheung 提交于
Use ehci_setup() in ehci_ls1x_reset(). The Loongson1x SoCs have a built-in EHCI controller. This patch adds the necessary glue code to make the generic EHCI driver usable for them. Signed-off-by: NKelvin Cheung <keguang.zhang@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Anatolij Gustschin 提交于
Use INCR8 mode for system bus interface of the USB controller on MPC512x. This is a work-around for the AHB bus lock up problem observed on MPC512x when there is heavy simultaneous PATA write or network (FEC) activity. See also "12.4 The USB controller can issue transactions that lock up the AHB bus under certain conditions" in MPC5121e (M36P) Errata. Signed-off-by: NAnatolij Gustschin <agust@denx.de> Tested-by: NMatthias Fuchs <matthias.fuchs@esd.ue> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
Commit 689d6eac ("USB: UHCI: add native scatter-gather support(v1)) added sg support to uhci but forgot to set the sg_table so this feature remained unused. Cc: Ming Lei <tom.leiming@gmail.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alessandro Rubini 提交于
Signed-off-by: NAlessandro Rubini <rubini@gnudd.com> Acked-by: NGiancarlo Asnaghi <giancarlo.asnaghi@st.com> Cc: Alan Cox <alan@linux.intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Fabio Estevam 提交于
Fix the following build warning: warning: (USB_HWA_HCD) selects UWB_HWA which has unmet direct dependencies (UWB && USB) Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
This patch (as1515) fixes some unavoidably dumb compiler warnings: CC [M] drivers/usb/renesas_usbhs/mod.o In file included from drivers/usb/host/ohci-hcd.c:101:0: drivers/usb/host/ohci-dbg.c: In function ‘fill_registers_buffer’: drivers/usb/host/ohci-dbg.c:656:2: warning: the comparison will always evaluate as ‘true’ for the address of ‘next’ will never be NULL [-Waddress] drivers/usb/host/ohci-dbg.c:675:3: warning: the comparison will always evaluate as ‘true’ for the address of ‘next’ will never be NULL [-Waddress] Instead of trying to fix the macro to work under all cirumstances, just add a second macro for use in cases where the "next" argument is the address of a local variable. Unfortunately the macro cannot be replaced by a real subroutine, because there's no va_list version of ohci_dbg() or dev_dbg(). Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Julia Lawall 提交于
Add missing iounmap in error handling code, in a case where the function already preforms iounmap on some other execution path. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e; statement S,S1; int ret; @@ e = \(ioremap\|ioremap_nocache\)(...) ... when != iounmap(e) if (<+...e...+>) S ... when any when != iounmap(e) *if (...) { ... when != iounmap(e) return ...; } ... when any iounmap(e); // </smpl> Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 20 1月, 2012 2 次提交
-
-
Allows to configure independently the vbus_pin associated with each port. Matches usual naming scheme. Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Cc: linux-usb@vger.kernel.org
-
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Cc: linux-usb@vger.kernel.org
-
- 16 1月, 2012 1 次提交
-
-
由 Michal Simek 提交于
Drivers shouldn't use NO_IRQ. This driver is used by Microblaze and PPC. PPC defines NO_IRQ as 0 and Microblaze has removed it. Signed-off-by: NMichal Simek <monstr@monstr.eu> Acked-by: NAlan Stern <stern@rowland.harvard.edu> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Grant Likely <grant.likely@secretlab.ca> CC: linux-usb@vger.kernel.org CC: devicetree-discuss@lists.ozlabs.org
-
- 13 1月, 2012 1 次提交
-
-
由 Rusty Russell 提交于
module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. It's time to remove the int/unsigned int option. For this version it'll simply give a warning, but it'll break next kernel version. Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 11 1月, 2012 1 次提交
-
-
由 Sarah Sharp 提交于
The xHCI hub port code gets passed a zero-based port number by the USB core. It then adds one to in order to find a device slot by port number and device speed by calling xhci_find_slot_id_by_port. That function clearly states it requires a one-based port number. The xHCI port status change event handler was using a zero-based port number that it got from find_faked_portnum_from_hw_portnum, not a one-based port number. This lead to the doorbells never being rung for a device after a resume, or worse, a different device with the same speed having its doorbell rung (which could lead to bad power management in the xHCI host controller). This patch should be backported to kernels as old as 2.6.39. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: NAndiry Xu <andiry.xu@amd.com> Cc: stable@vger.kernel.org
-
- 05 1月, 2012 3 次提交
-
-
由 Sarah Sharp 提交于
Randy Dunlap points out that commit 9258c0b2 "xhci: Better debugging for critical host errors." introduces some new build warnings on 32-bit builds: drivers/usb/host/xhci-ring.c:1936:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t' drivers/usb/host/xhci-ring.c:1958:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t' Cast the results of xhci_trb_virt_to_dma() from a dma_addr_t to an unsigned long long. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
-
由 Julia Lawall 提交于
drvdata needds to be freed before leaving the function in an error case. A simplified version of the semantic match that finds the problem is as follows: (http://coccinelle.lip6.fr) // <smpl> @r exists@ local idexpression x; statement S; identifier f1; position p1,p2; expression *ptr != NULL; @@ x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } x->f1 ...> ( return \(0\|<+...x...+>\|ptr\); | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Felipe Balbi 提交于
According to USB 3.0 Specification Table 9-22, if bmAttributes [4:0] are set to zero, it means "no streams supported", but the way this helper was defined on Linux, we will *always* have one stream which might cause several problems. For example on DWC3, we would tell the controller endpoint has streams enabled and yet start transfers with Stream ID set to 0, which would goof up the host side. While doing that, convert the macro to an inline function due to the different checks we now need. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-