The otg queue work include operations: one is disable interrupt,
another one is call kernel queue work API. Many codes do this
operation, using one inline function to instead of them.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/core.c|6 +--
On Tue, May 20, 2014 at 5:27 PM, Greg KH gre...@linuxfoundation.org wrote:
Greg,
Sorry, I don't think it is fair to users to force them to re-compile
their kernel to get their device to work.
I totally agree.
Granted, I'm new to USB
development, but the rate of reports of endpoint devices
On Tue, May 20, 2014 at 11:21:03PM -0700, Dan Williams wrote:
On Tue, May 20, 2014 at 5:27 PM, Greg KH gre...@linuxfoundation.org wrote:
Greg,
Sorry, I don't think it is fair to users to force them to re-compile
their kernel to get their device to work.
I totally agree.
Granted,
Hi,
(2014/05/20 19:11), Arnd Bergmann wrote:
On Monday 19 May 2014 19:08:05 Yoshihiro Shimoda wrote:
#include xhci.h
#include xhci-mvebu.h
+#include xhci-rcar.h
static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
{
@@ -39,6 +40,12 @@ static int
Hi Geert-san,
Thank you for the reply again.
(2014/05/20 19:14), Geert Uytterhoeven wrote:
Hi Shimoda-san,
On Tue, May 20, 2014 at 11:35 AM, Yoshihiro Shimoda
yoshihiro.shimoda...@renesas.com wrote:
(2014/05/19 20:58), Geert Uytterhoeven wrote:
On Mon, May 19, 2014 at 12:08 PM, Yoshihiro
On Wednesday 21 May 2014 16:54:00 Yoshihiro Shimoda wrote:
(2014/05/20 19:11), Arnd Bergmann wrote:
On Monday 19 May 2014 19:08:05 Yoshihiro Shimoda wrote:
#include xhci.h
#include xhci-mvebu.h
+#include xhci-rcar.h
static void xhci_plat_quirks(struct device *dev, struct
On Tue, May 20, 2014 at 04:27:40PM +0200, oneu...@suse.de wrote:
From: Oliver Neukum oneu...@suse.de
Reported by Alif Mubarak Ahmad:
This device vendor and product id is 1c9e:9800
It is working as serial interface with generic usbserial driver.
I thought it is more suitable to use
Hello,
I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian)
I see that XHCI fails during xhci_device_alloc() because of
wait_for_completion_interruptible_timeout () when I connect a device.
So, I thought of initializing host controller as BE as my host is BE.
But this time, it failed
Syscall mount returns -ENODEV error if requested FS type
has not been found. Returning the same error from FFS mount
callback makes value returned to userspace misleading.
Other file systems returns -ENOENT if requested device
has not been found. Adjust FFS to this convention to make
error codes
Dear Michal and Felipe,
According to my last conversation with Michal[1] I have
prepared patch which adjust error returning policy in function FS.
Previously when FunctionFS was unable to find device configured via
ConfigFS returned -ENODEV. This error looks quite suitable there but
by default
The error handling is confusing in this function, but if you look
closely it is returning success after the allocation fails. I have
changed it to return -ENOMEM and re-written it to be more clear.
Fixes: 37a3a533429e ('usb: gadget: OS Feature Descriptors support')
Signed-off-by: Dan Carpenter
This should be return -ENOMEM. The current code returns successs.
Fixes: de7a8d2d534f ('usb: gadget: f_rndis: OS descriptors support')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index eed3ad8..31274f7 100644
---
Hi Greg,
On 15/05/2014 12:17, Gregory CLEMENT wrote:
Hello,
This patch set adds the USB support for the Armada 38x and Armada 375
SOCs. These SoCs use an xHCI but still need specific initialization,
mainly to setup the MBus memory windows. They also have another USB
controller for EHCI,
On Tue, May 20, 2014 at 08:37:10PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 15:12:49 Catalin Marinas wrote:
On Tue, May 20, 2014 at 12:08:58PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 12:02:46 Catalin Marinas wrote:
On Mon, May 19, 2014 at 05:55:56PM +0100, Arnd
On Wednesday 21 May 2014 14:56:36 Catalin Marinas wrote:
On Tue, May 20, 2014 at 08:37:10PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 15:12:49 Catalin Marinas wrote:
On Tue, May 20, 2014 at 12:08:58PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 12:02:46 Catalin Marinas
On Wed, May 21, 2014 at 9:43 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014 14:56:36 Catalin Marinas wrote:
On Tue, May 20, 2014 at 08:37:10PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 15:12:49 Catalin Marinas wrote:
On Tue, May 20, 2014 at 12:08:58PM +0100, Arnd
On Wed, May 21, 2014 at 03:43:39PM +0100, Arnd Bergmann wrote:
On Wednesday 21 May 2014 14:56:36 Catalin Marinas wrote:
On Tue, May 20, 2014 at 08:37:10PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 15:12:49 Catalin Marinas wrote:
So what we need is setting the default dma mask
On Wednesday 21 May 2014 10:26:01 Rob Herring wrote:
On Wed, May 21, 2014 at 9:43 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014 14:56:36 Catalin Marinas wrote:
On Tue, May 20, 2014 at 08:37:10PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 15:12:49 Catalin Marinas
Hi,
I have a problem with a USB device (4255:1000), running various kernels
from 3.12.6 (Fedora) up to 2.14.4 (ArchLinux). When I connect the
device, it appears all right. But after a few seconds of idle, it
disconnects itself.
When I manage to use the device (read or write files to the mounted
On Wednesday 21 May 2014 16:32:16 Catalin Marinas wrote:
On Wed, May 21, 2014 at 03:43:39PM +0100, Arnd Bergmann wrote:
On Wednesday 21 May 2014 14:56:36 Catalin Marinas wrote:
On Tue, May 20, 2014 at 08:37:10PM +0100, Arnd Bergmann wrote:
On Tuesday 20 May 2014 15:12:49 Catalin Marinas
On Wed, May 21, 2014 at 10:48 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014 10:26:01 Rob Herring wrote:
On Wed, May 21, 2014 at 9:43 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014 14:56:36 Catalin Marinas wrote:
On Tue, May 20, 2014 at 08:37:10PM +0100,
On Wed, May 21, 2014 at 05:15:06PM +0100, Rob Herring wrote:
On Wed, May 21, 2014 at 10:48 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014 10:26:01 Rob Herring wrote:
What are you checking against to cause a failure and what do you do on
failure? I'm guessing that PCI masks
On Wed, May 21, 2014 at 11:35 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Wed, May 21, 2014 at 05:15:06PM +0100, Rob Herring wrote:
On Wed, May 21, 2014 at 10:48 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014 10:26:01 Rob Herring wrote:
What are you checking
On Wednesday 21 May 2014 12:01:29 Rob Herring wrote:
On Wed, May 21, 2014 at 11:35 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Wed, May 21, 2014 at 05:15:06PM +0100, Rob Herring wrote:
On Wed, May 21, 2014 at 10:48 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 21 May 2014
On Tue, 20 May 2014, Heinz Diehl wrote:
On 20.05.2014, Heinz Diehl wrote:
The usbmon dump of the whole process is here:
http://www.fritha.org/usblog.zip
And here's another one, while popping in and out.
http://www.fritha.org/usblog2.zip
Nothing very informative stands out in those
On Tue, May 20, 2014 at 11:31 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, May 20, 2014 at 11:21:03PM -0700, Dan Williams wrote:
On Tue, May 20, 2014 at 5:27 PM, Greg KH gre...@linuxfoundation.org wrote:
Greg,
Sorry, I don't think it is fair to users to force them to re-compile
On 21.05.2014, Alan Stern wrote:
Your problems were probably caused by those spontaneous disconnects.
Yes, I got the same impression while encountering this.
They could be caused by a small electrical incompatibility between the
computer and the device.
In this case, most probably all of
On Wed, 21 May 2014, Mildred Ki'Lya wrote:
Hi,
I have a problem with a USB device (4255:1000), running various kernels
from 3.12.6 (Fedora) up to 2.14.4 (ArchLinux). When I connect the
device, it appears all right. But after a few seconds of idle, it
disconnects itself.
When I manage to
On Wed, 21 May 2014, Dan Williams wrote:
On Tue, May 20, 2014 at 11:31 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, May 20, 2014 at 11:21:03PM -0700, Dan Williams wrote:
On Tue, May 20, 2014 at 5:27 PM, Greg KH gre...@linuxfoundation.org
wrote:
Greg,
Sorry, I don't think
On Wed, 21 May 2014, Heinz Diehl wrote:
On 21.05.2014, Alan Stern wrote:
Your problems were probably caused by those spontaneous disconnects.
Yes, I got the same impression while encountering this.
They could be caused by a small electrical incompatibility between the
computer and
On Tue, 20 May 2014, Dan Williams wrote:
We want to manipulate -did_runtime_put in usb_port_runtime_resume(),
but we don't want that to collide with other updates. Move usb_port
flags to new port-bitmap fields in usb_hub. did_runtime_put is renamed
child_usage_bits to reflect that it is
Commit [ac8dde11: “usb: gadget: f_fs: Add flags to descriptors block”]
which introduced a new descriptor format for FunctionFS removed the
usb_functionfs_descs_head structure, which is still used by ffs-test.
tool.
Convert ffs-test by converting it to use the new header format. For
testing
On 21.05.2014, Alan Stern wrote:
Maybe the problem involves USB-3 Link Power Management. Unfortunately
there isn't any way I know of to disable it without rebuilding the
kernel.
No problem.
The patch below will disable LPM for all devices. You can try it and
see if it helps.
On Wed, May 21 2014, Krzysztof Opasiak k.opas...@samsung.com wrote:
Syscall mount returns -ENODEV error if requested FS type
has not been found. Returning the same error from FFS mount
callback makes value returned to userspace misleading.
Other file systems returns -ENOENT if requested
On Tue, 20 May 2014, Dan Williams wrote:
Resuming a powered down port sometimes results in the port state being
stuck in the training sequence.
hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
port1: can't get reconnection after setting port power on, status -110
hub
On Tue, 20 May 2014, Dan Williams wrote:
From: Lan Tianyu tianyu@intel.com
describe the mechanisms for controlling port power policy and
discovering the port power state.
+Example of the relevant files for port power control.
+
+ child device link +
+
On Wed, 21 May 2014, Heinz Diehl wrote:
On 21.05.2014, Alan Stern wrote:
Maybe the problem involves USB-3 Link Power Management. Unfortunately
there isn't any way I know of to disable it without rebuilding the
kernel.
No problem.
The patch below will disable LPM for all
On Wed, May 21, 2014 at 10:29:09AM -0700, Dan Williams wrote:
On Tue, May 20, 2014 at 11:31 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, May 20, 2014 at 11:21:03PM -0700, Dan Williams wrote:
On Tue, May 20, 2014 at 5:27 PM, Greg KH gre...@linuxfoundation.org
wrote:
Greg,
On Wed, May 21, 2014 at 03:50:47PM +0200, Gregory CLEMENT wrote:
Hi Greg,
On 15/05/2014 12:17, Gregory CLEMENT wrote:
Hello,
This patch set adds the USB support for the Armada 38x and Armada 375
SOCs. These SoCs use an xHCI but still need specific initialization,
mainly to setup the
Hi Greg,
Here's my big dump for v3.16 merge window. Even though we have a lot of
patches, most of them are just doing cleanups and small bug fixes.
Consider merging it to your usb-next branch. There will be a conflict
with drivers/usb/phy/phy-mv-u3d.c (deleted in your tree, modified on
mine).
The series does some refactoring on dwc3_probe()
Patch 1 - Now that we use driver compatible for revision check, remove the
unnecessary logic.
Patch 2-4 - reduce the size of dwc3_probe()
Patch 5 - Fix the crash on dwc3_omap removal
Patch 6 - Addresses the issue of xhci hang while resuming from
Move find and set the utmi mode to its own seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 44 +---
1 file changed, 25 insertions(+), 19
Following crash is seen on dwc3_omap removal
Unable to handle kernel NULL pointer dereference at virtual address 0018
pgd = ec098000
[0018] *pgd=ad1f9831, *pte=, *ppte=
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in: usb_f_ss_lb g_zero usb_f_acm u_serial usb_f_ecm
Move the extcon related code to its own function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 65 ++--
1 file changed, 39 insertions(+), 26 deletions(-)
Move map offset to its own seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git
The dwc3 wrapper driver should not be fiddling with the core interrupts.
Disabling the core interrupts in prepare stops xhci from proper operation.
So remove disable/enable of core interrupts from prepare/complete.
Signed-off-by: George Cherian george.cher...@ti.com
---
Remove the x_major calculation logic from the wrapper revision register
to differentiate between OMAP5 and AM437x. This was done to find the
register offsets of wrapper register. Now that We do it using dt
compatible, remove the whole logic.
Signed-off-by: George Cherian george.cher...@ti.com
---
W dniu 21.05.2014 14:26, Dan Carpenter pisze:
This should be return -ENOMEM. The current code returns successs.
Fixes: de7a8d2d534f ('usb: gadget: f_rndis: OS descriptors support')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Acked-by: Andrzej Pietrasiewicz andrze...@samsung.com
W dniu 21.05.2014 14:26, Dan Carpenter pisze:
The error handling is confusing in this function, but if you look
closely it is returning success after the allocation fails. I have
changed it to return -ENOMEM and re-written it to be more clear.
Fixes: 37a3a533429e ('usb: gadget: OS Feature
49 matches
Mail list logo
