- 10 Aug, 2010 40 commits
-
-
Michal Nazarewicz authored
Removed entry referencing g_eth_ffs.c file from Makefile. The file never existed and the line was a leftover from a developing process. Signed-off-by:
Michal Nazarewicz <m.nazarewicz@samsung.com> Reported-by:
Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
This patch (as1409) removes some dead code from the ehci-hcd scheduler. Thanks to the previous patch in this series, stream->depth is no longer used. And stream->start and stream->rescheduled apparently have not been used for quite a while, except in some statistics-reporting code that never gets invoked. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Alan Stern authored
This patch (as1408) rearranges the scheduling code in ehci-hcd, partly to improve its structure, but mainly to change the way it works. Whether or not a transfer exceeds the hardware schedule length will now be determined by looking at the last frame the transfer would use, instead of the first available frame following the end of the transfer. The benefit of this change is that it allows the driver to accept valid URBs which would otherwise be rejected. For example, suppose the schedule length is 1024 frames, the endpoint period is 256 frames, and a four-packet URB is submitted. The four transfers would occupy slots that are 0, 256, 512, and 768 frames past the current frame (plus an extra slop factor). These don't exceed the 1024-frame limit, so the URB should be accepted. But the current code notices that the next available slot would be 1024 frames (plus slop) in the future, which is beyond the limit, and so the URB is rejected unnecessarily. Signed-off-by:
-
Alan Stern authored
This patch (as1407) fixes a bug in ehci-hcd's isochronous scheduler. All its calculations should be done in terms of microframes, but for full-speed devices, sched->span is stored in frames. It needs to be converted. This fix is liable to expose problems in other drivers. The old code would accept URBs that should not have been accepted, so drivers have had no reason to avoid submitting URBs that exceeded the maximum schedule length. In an attempt to partially compensate for this, the patch also adjusts the schedule length from a minimum of 256 frames up to a minimum of 512 frames. Signed-off-by:
-
Alan Stern authored
This patch (as1406) adds a micro-optimization to ehci-hcd's scheduling code. Instead of computing remainders with respect to the schedule length, use bitwise-and (which is quicker). We know that the schedule length will always be a power of two, but the compiler doesn't have this information. Signed-off-by:
-
Alan Stern authored
This patch (as1405) fixes a small bug in ehci-hcd's isochronous scheduler. Not all EHCI controllers are PCI, and the code shouldn't assume that they are. Instead, introduce a special flag for controllers which need to delay iso scheduling for full-speed devices beyond the scheduling threshold. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com>
-
Dong Nguyen authored
Enable MSI/MSI-X supporting in xhci driver. Provide the mechanism to fall back using MSI and Legacy IRQs if MSI-X IRQs register failed. Signed-off-by:
Dong Nguyen <Dong.Nguyen@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>, Signed-off-by:
-
Igor Grinberg authored
1) Introduce ulpi specific flags for control of the ulpi phy 2) Extend the generic ulpi driver with support for Function and Interface control of upli phy 3) Update the platforms using the generic ulpi driver with new ulpi flags 4) Remove the otg control flags not in use Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Mike Rapoport <mike@compulab.co.il> Signed-off-by:
-
Igor Grinberg authored
Signed-off-by:
-
Igor Grinberg authored
Signed-off-by:
-
Eric Bénard authored
ulpi_set_vbus and ulpi_set_flags are using ULPI_SET(register) to write to the PHY's registers, which means we can only set bits in the PHY's register and not clear them. By directly using the address of the register without any offset, we now get the expected behaviour for these functions. Signed-off-by:
Eric Bénard <eric@eukrea.com> Cc: Daniel Mack <daniel@caiaq.de> Cc: linux-arm-kernel@lists.infradead.org Cc: Sascha Hauer <kernel@pengutronix.de> Signed-off-by:
-
Roel Kluin authored
If the write download record failed we shouldn't return 0. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Christian Dietrich authored
CONFIG_ARCH_KARO doesn't exist in Kconfig and is never defined anywhere else, therefore removing all references for it from the source code. Signed-off-by:
Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de> Acked-by:
Ryan Mallon <ryan@bluewatersys.com> Signed-off-by:
-
Ming Lei authored
Usb serial port device is child of its usb interface device, so we can enable async suspend of usb serial port device to speedup system suspend. Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
stephane duverger authored
This is a patch for the musb usb controller. It allows forwarding of the debug mode feature to its gadget in order to be able to act as an ehci debug device. This patch has been tested on an IGEPv2 board running a 2.6.35-rc1 kernel. Signed-off-by:
Stephane Duverger <stephane.duverger@gmail.com> Cc: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
-
stephane duverger authored
This is a patch that implements an USB EHCI Debug Device using the Gadget API. This patch applies to a 2.6.35-rc3 kernel. The gadget needs a compliant usb controller that forwards the USB_DEVICE_DEBUG_MODE feature to its gadget. The gadget provides two configuration modes, one that only printk() the received data, and one that exposes a serial device to userland (/dev/ttyGSxxx). The gadget has been tested on an IGEPv2 board running a 2.6.35-rc1 kernel. The debug port was fed on the host side by a 2.6.34 kernel. Signed-off-by:
-
Joe Perches authored
Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Arnd Bergmann authored
All these files use the big kernel lock in a trivial way to serialize their private file operations, typically resulting from an earlier semi-automatic pushdown from VFS. None of these drivers appears to want to lock against other code, and they all use the BKL as the top-level lock in their file operations, meaning that there is no lock-order inversion problem. Consequently, we can remove the BKL completely, replacing it with a per-file mutex in every case. Using a scripted approach means we can avoid typos. file=$1 name=$2 if grep -q lock_kernel ${file} ; then if grep -q 'include.*linux.mutex.h' ${file} ; then sed -i '/include.*<linux\/smp_lock.h>/d' ${file} else sed -i 's/include.*<linux\/smp_lock.h>.*$/include <linux\/mutex.h>/g' ${file} fi sed -i ${file} \ -e "/^#include.*linux.mutex.h/,$ { 1,/^\(static\|int\|long\)/ { /^\(static\|int\|long\)/istatic DEFINE_MUTEX(${name}_mutex); } }" \ -e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \ -e '/[ ]*cycle_kernel_lock();/d' else sed -i -e '/include.*\<smp_lock.h\>/d' ${file} \ -e '/cycle_kernel_lock()/d' fi Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Martin Enderleit authored
Fixed several coding style issues in freecom.c. Signed-off-by:
Martin Enderleit <menderleit@gmail.com> Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Cc: Daniel Mack <daniel@caiaq.de> Signed-off-by:
-
Anand Gadiyar authored
There is no reason for the DMA channel program to override the DMA mode passed down by its caller. Use the passed parameter directly, and let the caller handle the decision on which mode is to be used. Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Acked-by:
Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
-
Anand Gadiyar authored
This pin-muxing is best done in the board files. The driver should not do this explicitly. Also, this code causes a warning to be thrown when OMAP2430 and OMAP3/4 support are enabled in the same kernel. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Ajay Kumar Gupta authored
Currently devices don't get detected automatically if the ehci module is inserted 2nd time onward. We need to disconnect and reconnect the device for it to get detected and enumerated. Resetting the USB PHY using PHY reset comamnd over ULPI fixes this issue. Tested on OMAP3EVM. Signed-off-by:
-
Ajay Kumar Gupta authored
Fixes below compilation warning from ulpi.h include/linux/usb/ulpi.h:145: warning: 'struct otg_io_access_ops' declared inside parameter list include/linux/usb/ulpi.h:145: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: -
Ajay Kumar Gupta authored
Fixes below compilation warning when host only configuration is selected. drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq': drivers/usb/musb/musb_core.c:711: warning: unused variable 'mbase' Signed-off-by:
-
Anand Gadiyar authored
DMA_ADDR and DMA_COUNT are 32-bit registers, not 16-bit. Marking them as 16-bit in the table causes only the lower 16-bits to be dumped and this is misleading. Signed-off-by:
-
Kulikov Vasiliy authored
Use for_each_pci_dev() to simplify the code. Signed-off-by:
Kulikov Vasiliy <segooon@gmail.com> Acked-by:
-
Roel Kluin authored
If the write download record failed we shouldn't return 0. Signed-off-by:
-
Michal Nazarewicz authored
Updated comment to describe why printing macros are needed even thought they are copied form the composite.h. Also, made multiline comments follow the coding standard. Signed-off-by:
-
stephane duverger authored
Here is the patch for the following issue: drivers/usb/gadget/u_serial.c: In function ‘gs_start_tx’: drivers/usb/gadget/u_serial.c:369: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function) drivers/usb/gadget/u_serial.c:369: error: (Each undeclared identifier is reported only once drivers/usb/gadget/u_serial.c:369: error: for each function it appears in.) drivers/usb/gadget/u_serial.c: In function ‘gs_rx_push’: drivers/usb/gadget/u_serial.c:546: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function) drivers/usb/gadget/u_serial.c: In function ‘gs_close’: drivers/usb/gadget/u_serial.c:857: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function) drivers/usb/gadget/u_serial.c:857: error: implicit declaration of function ‘signal_pending’ drivers/usb/gadget/u_serial.c:857: error: implicit declaration of function ‘schedule_timeout’ drivers/usb/gadget/u_serial.c: In function ‘gserial_cleanup’: drivers/usb/gadget/u_serial.c:1190: error: ‘TASK_UNINTERRUPTIBLE’ undeclared (first use in this function) drivers/usb/gadget/u_serial.c:1190: error: implicit declaration of function ‘schedule’ drivers/usb/gadget/u_serial.c: In function ‘gserial_disconnect’: drivers/usb/gadget/u_serial.c:1311: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function) Signed-off-by:
-
Andrea Righi authored
If we use the HCD_LOCAL_MEM flag and dma_declare_coherent_memory() to enforce the host controller's local memory utilization we also need to disable native scatter-gather support, otherwise hcd_alloc_coherent() in map_urb_for_dma() is called with urb->transfer_buffer == NULL, that triggers a NULL pointer dereference. We can also consider to add a WARN_ON() and return an error code to better catch this problem in the future. At the moment no driver seems to hit this bug, so I should consider this a low-priority fix. Signed-off-by:
Andrea Righi <arighi@develer.com> Acked-by:
-
Kulikov Vasiliy authored
Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x). Signed-off-by:
-
Nicolas Kaiser authored
Don't descend to the EARLY_PRINTK_DBGP directory unless it is actually used. Signed-off-by:
Nicolas Kaiser <nikai@nikai.net> Signed-off-by:
-
Nicolas Kaiser authored
Fixed switch, brace, whitespace and spacing coding style issues. Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
This patch (as1386) adds runtime-PM support for PCI-based USB host controllers. By default autosuspend is disallowed; the user must enable it by writing "auto" to the controller's power/control sysfs attribute. Signed-off-by:
-
Alan Stern authored
This patch (as1396) adds code to uhci-hcd to support the vendor-specific wakeup settings found in Intel's ICHx hardware. A couple of unnecessary memory barriers are removed. And the root hub isn't put back into the "suspended" state if power was lost during a system sleep -- there's not much point in doing so because the root hub will be resumed shortly. Signed-off-by:
-
Alan Stern authored
This patch (as1395) adds code to hcd_pci_suspend() for handling wakeup races. This is another general race pattern, similar to the "open vs. unregister" race we're all familiar with. Here, the race is between suspending a device and receiving a wakeup request from one of the device's suspended children. In particular, if a root-hub wakeup is requested at about the same time as the corresponding USB controller is suspended, and if the controller is enabled for wakeup, then the controller should either fail to suspend or else wake right back up again. During system sleep this won't happen very much, especially since host controllers generally aren't enabled for wakeup during sleep. However it is definitely an issue for runtime PM. Something like this will be needed to prevent the controller from autosuspending while waiting for a root-hub resume to take place. (That is, in fact, the common case, for which there is an extra test.) Signed-off-by:
-
Alan Stern authored
This patch (as1394) adds code to ehci-hcd, ohci-hcd, and uhci-hcd for automatically resuming the root hub when the controller is resumed, if the root hub has a wakeup request pending on some port. During resume from system sleep this doesn't matter, because the root hubs will naturally be resumed along with every other device in the system. However it _will_ matter for runtime PM: If the controller is suspended and a remote wakeup request is received then the controller will autoresume, but we need to ensure that the root hub also autoresumes. Otherwise the wakeup request would be ignored, the controller would go back to sleep, and the cycle would repeat a large number of times (I saw this happen before the patch was written). Signed-off-by:
-
Alan Stern authored
This patch (as1385) adds a "do_wakeup" parameter to the pci_suspend method used by PCI-based host controller drivers. ehci-hcd in particular needs to know whether or not to enable wakeup when suspending a controller. Although that information is currently available through device_may_wakeup(), when support is added for runtime suspend this will no longer be true. Signed-off-by:
-
