- 09 Dec, 2013 8 commits
-
-
Majunath Goudar authored
Suspend scenario in case of ohci-exynos glue was not properly handled as it was not suspending generic part of ohci controller. Alan Stern suggested, properly handle ohci-exynos suspend scenario. Calling explicitly the ohci_suspend() routine in exynos_ohci_suspend() will ensure proper handling of suspend scenario. Signed-off-by:
Manjunath Goudar <csmanjuvijay@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-usb@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Majunath Goudar authored
Suspend scenario in case of ohci-da8xx glue was not properly handled as it was not suspending generic part of ohci controller. Alan Stern suggested, properly handle ohci-da8xx suspend scenario. Calling explicitly the ohci_suspend() routine in ohci_da8xx_suspend() will ensure proper handling of suspend scenario. Signed-off-by:
-
Majunath Goudar authored
Suspend scenario in case of ohci-s3c2410 glue was not properly handled as it was not suspending generic part of ohci controller. Alan Stern suggested, properly handle ohci-s3c2410 suspend scenario. Calling explicitly the ohci_suspend() routine in ohci_hcd_s3c2410_drv_suspend() will ensure proper handling of suspend scenario. Signed-off-by:
-
Majunath Goudar authored
Suspend scenario in case of ohci-at91 glue was not properly handled as it was not suspending generic part of ohci controller. Alan Stern suggested, properly handle ohci-at91 suspend scenario. Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend() will ensure proper handling of suspend scenario. This task is sugested by Alan Stern. Signed-off-by:
-
Majunath Goudar authored
Suspend scenario in case of OHCI was not properly handled in ochi_suspend()routine. Alan Stern suggested, properly handle OHCI suspend scenario. This does generic proper handling of suspend scenario to all OHCI SOC. Signed-off-by:
-
Huang Rui authored
The commit "usb: usbtest: support bos descriptor test for usb 3.0" introduced a test for bos descriptor. And USB 2.1 device also can be checked. So this patch extends the test coverage to support USB 2.1 device. Reported-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Huang Rui <ray.huang@amd.com> Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Huang Rui authored
USB 2.1 Link PM adds to use bits[1:15] according to USB 2.0 ECN Errata for Link Power Management spec. Bit Encoding 0 Reserved 1 LPM 2 BESL & Altemate HIRD definitions supported 3 Recommended Baseline BESL valid 4 Recommended Deep BESL valid 11:8 Recommended Baseline BESL value 15:12 Recommended Deep BESL value 31:16 Reserved So fix the bit mask from 0x1e to 0xfffe. Reported-by:
-
Huang Rui authored
In Test 10 of usbtest module, it queues multiple control messages and thereby tests control message queuing, protocol stalls, short reads, and fault handling. And this patch add a test case to support queue BOS control request for USB 3.0 SPEC. Signed-off-by:
-
- 05 Dec, 2013 2 commits
-
-
Fengguang Wu authored
drivers/usb/host/ehci-mv.c:181:26-27: WARNING comparing pointer to 0, suggest !E /c/kernel-tests/src/cocci/drivers/usb/host/ehci-mv.c:181:26-27: WARNING comparing pointer to 0 Compare pointer-typed values to NULL rather than 0 Semantic patch information: This makes an effort to choose between !x and x == NULL. !x is used if it has previously been used with the function used to initialize x. This relies on type information. More type information can be obtained using the option -all_includes and the option -I to specify an include path. Generated by: coccinelle/null/badzero.cocci CC: Jingoo Han <jg1.han@samsung.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:Fengguang Wu <fengguang.wu@intel.com>
-
Jingoo Han authored
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro is not preferred. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
- 03 Dec, 2013 30 commits
-
-
Geert Uytterhoeven authored
device_driver.name is "const char *" Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
device_driver.name is "const char *" Signed-off-by:
-
Geert Uytterhoeven authored
device_driver.name is "const char *" Signed-off-by:
-
Oliver Neukum authored
It is useless now. Straight removal. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Oliver Neukum authored
In the drivers that no longer need it, it is removed. It is removed from the Makefile. Drivers not fully converted to dynamic debug have it shifted down into the individual drivers. Signed-off-by:
-
Oliver Neukum authored
With dynamic debugging this log level is no longer supported. The decision which messages are interesting is done in user space. Signed-off-by:
-
Oliver Neukum authored
This allows removal of much conditional compilation. Signed-off-by:
-
Oliver Neukum authored
This is a step in the conversion to only use dynamic debugging. Signed-off-by:
-
Oliver Neukum authored
That logging is overkill. Simply remove it. Signed-off-by:
-
Oliver Neukum authored
These helpers are used only during setup of a HCD. A small overhead is no problem. Signed-off-by:
-
Oliver Neukum authored
This makes sure the header files are all there Signed-off-by:
-
Oliver Neukum authored
To allow a full switch to dynamic debugging make the debug parameter conditional on defined(DEBUF) || defined(CONFIG_DYNAMIC_DEBUG) Signed-off-by:
-
Oliver Neukum authored
This gets rid of conditional compilation. Signed-off-by:
-
Oliver Neukum authored
The decision what is interesting is shifted to user space by dynamic debugging. Signed-off-by:
-
Oliver Neukum authored
The decision what is interesting is made in user space. Signed-off-by:
-
Oliver Neukum authored
For dynamic debug the overhead for evaluating parameters must be sacrificed only if the message is actually printed Signed-off-by:
-
Oliver Neukum authored
Simply remove the conditional compilation and remove the empty stubs. Signed-off-by:
-
Oliver Neukum authored
Always compile in the debugfs support Signed-off-by: -
Oliver Neukum authored
This is overkill. Just removeit. Signed-off-by:
-
Oliver Neukum authored
Simple elemination of the conditional compilation Signed-off-by:
-
Oliver Neukum authored
With dynamic debugging the selection is done in user space Signed-off-by:
-
Oliver Neukum authored
Just remove the conditional compilation. Signed-off-by:
-
Oliver Neukum authored
With the introduction of dynamic debugging it has become redundant. Collapse it with ohci_dbg() Signed-off-by:
-
Oliver Neukum authored
Conditional compilation for debugging is removed in favor of dynamic debugging. To do so 1. the support for debugfs is always compiled 2. the support for the ancient print_urb debugging aid is removed Signed-off-by:
-
Oliver Neukum authored
An ioctl that does depends on communication with a device should prevent suspension of teh device. Signed-off-by:
-
Oliver Neukum authored
Simple straightforward implementation. Just returning the statistics gathered for TIOCMIWAIT Signed-off-by:
-
Oliver Neukum authored
This implements TIOCMIWAIT for TIOCM_DSR, TIOCM_RI and TIOCM_CD Disconnect is handled as TIOCM_CD or an error. Signed-off-by:
-
Jingoo Han authored
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro is not preferred. Signed-off-by:
-
Fabio Estevam authored
Commit 40ed51a4 (usb: chipidea: host: add vbus regulator control) introduced a smatch complaint because regulator_disable() is called without checking whether ci->platdata->reg_vbus is not NULL. Fix this by adding the check. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'for-usb-next-2013-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next Sarah writes: xhci: Cleanup for 3.14: Sparse fixes, replace xhci_read/write, misc Hi Greg, Here's fifteen patches for 3.14. They include some non-urgent cleanups, and the patches to replace the xhci_read/write variants with standard read/write calls. As you asked, the big endian fixes are being queued for 3.14 and they aren't marked for stable. This also includes a couple of streams fixes, but not the full set from Hans. (I'll test those later this week.) The goal is to get both the xHCI driver streams support and the UAS driver fixed up for 3.14. We don't want to mark the fixes for stable, as all the code changes are really too big for stable. Please queue for 3.14. Sarah Sharp
-
