re: usb: gadget: FunctionFS: convert to new function interface with backward compatibility

[Dan Carpenter]

Hello Andrzej Pietrasiewicz,

This is a semi-automatic email about new static checker warnings.

The patch 5920cda62768: usb: gadget: FunctionFS: convert to new
function interface with backward compatibility from Dec 3, 2013,
leads to the following Smatch complaint:

drivers/usb/gadget/f_fs.c:2596 ffs_release_dev()
 error: we previously assumed 'ffs_dev' could be null (see line 2593)

drivers/usb/gadget/f_fs.c
  2592  ffs_dev = ffs_data-private_data;
  2593  if (ffs_dev)
^^^
Existing check.

  2594  ffs_dev-mounted = false;
  2595  
  ^^
Patch introduces an unwanted tab char here.  Use checkpatch.pl.

2596if (ffs_dev-ffs_release_dev_callback)
^
Patch adds unchecked dereference.

  2597  ffs_dev-ffs_release_dev_callback(ffs_dev);
  2598  

regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gadgetfs USB2.0 Chapter 9 Tests: Test after Addressed State fails

[Marco Zamponi]

 Shouldn't the usb.c user space application be compliant (e.g. pass all
 the CV Tests) ?

 Yes it should.

For some reason though, it does not. The Endpoint Descriptor Test -
Configured State is where it fails.

- regards

On Tue, Jan 7, 2014 at 5:02 PM, Michal Nazarewicz min...@mina86.com wrote:
 On Tue, Jan 07 2014, Marco Zamponi wrote:
 Actually, I was referring to gadgetFS all along.

 In that case everything I've written may be inapplicable.

 Shouldn't the usb.c user space application be compliant (e.g. pass all
 the CV Tests) ?

 Yes it should.

 --
 Best regards, _ _
 .o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
 ..o | Computer Science,  Michał mina86 Nazarewicz(o o)
 ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gadgetfs USB2.0 Chapter 9 Tests: Test after Addressed State fails

[Marco Zamponi]

The first Warning occurs in the test before (Interface Descriptor Test):

...
INFO Device does not use a class-specific protocol on this interface
INFO   ENGLISH_USlanguage string descriptor is : Source/Sink
INFO Calling SetInterface(), InterfaceNumber=0, AlternateSetting=0
WARNING SetInterface with interface number : 0 failed.

And then the next test (Endpoint Descriptor Test - Configured State):

ERROR Get configuration descriptor failed for configuration index : 0

On Wed, Jan 8, 2014 at 9:05 AM, Marco Zamponi mzamp...@gmail.com wrote:
 Shouldn't the usb.c user space application be compliant (e.g. pass all
 the CV Tests) ?

 Yes it should.

 For some reason though, it does not. The Endpoint Descriptor Test -
 Configured State is where it fails.

 - regards

 On Tue, Jan 7, 2014 at 5:02 PM, Michal Nazarewicz min...@mina86.com wrote:
 On Tue, Jan 07 2014, Marco Zamponi wrote:
 Actually, I was referring to gadgetFS all along.

 In that case everything I've written may be inapplicable.

 Shouldn't the usb.c user space application be compliant (e.g. pass all
 the CV Tests) ?

 Yes it should.

 --
 Best regards, _ _
 .o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
 ..o | Computer Science,  Michał mina86 Nazarewicz(o o)
 ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xhci_hcd and Canon Lide 110 not playing well together

[Xenia Ragiadakou]

On 07/01/2014 11:46 μμ, Sarah Sharp wrote:

On Wed, Dec 25, 2013 at 09:51:28PM -0500, Alan Stern wrote:

Okay, now we know that usb_enable_interface takes a long time.  That
routine does nothing but call usb_enable_endpoint, which does nothing
but call usb_hcd_reset_endpoint, which calls the xhci_endpoint_reset
routine.

So we have traced the problem into xhci-hcd.  You could trace it
farther down if you want, but at this point it probably would be more
productive to see what Sarah has to say.  She may know about some new
changes that are not yet available in the development kernel.

I suspect the patch I asked Matthias and Holger to apply [1] has some
issues, and it's entirely possible that there's deadlocks.  One other
tester (Michal) confirms it fixes his issue with a Samsung scanner, but
the patch leads to list corruption in some xHCI structures:

https://bugzilla.kernel.org/show_bug.cgi?id=47421

In any case, all three testers (Matthias, Holger, and Michal) confirm
the patch fixes the underlying issue.  So we just need to get the
remaining race conditions and locking issues fixed up.

Xenia, would you mind if Dan or I finished your patch?  I know you don't
have much time for xHCI work since you started your new job.

Sarah Sharp

[1] http://marc.info/?l=linux-usbm=138116117104619w=2


Yes, sure you can finish the patch.

regards,
xenia
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Sebastian Reichel]

On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote:
 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
 b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 index b381fa6..5635202 100644
 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 @@ -32,6 +32,10 @@ Optional properties:
  - single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
  
 +- clocks: phandle to 60MHz functional clock to the USB Host module.
 +
 +- clock-names: must be init_60m_fclk
 +
  Required properties if child node exists:
  
  - #address-cells: Must be 1

I have some questions:

What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't
all of those be provided by via the DT phandle?

Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
driver? This would potentially remove the need of the init_60m_fclk name.

$ grep clk_get drivers/mfd/omap-usb-host.c
omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk);
omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk);
omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck);
omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck);
omap-init_60m_fclk = clk_get(dev, init_60m_fclk);
omap-utmi_clk[i] = clk_get(dev, clkname);
omap-hsic480m_clk[i] = clk_get(dev, clkname);
omap-hsic60m_clk[i] = clk_get(dev, clkname);

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()

[Lee Jones]

 pm_runtime_get/put_sync() can sleep so don't hold spinlock while
 calling them.
 
 This patch prevents a BUG() during system suspend when
 CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
 
 Bug is present in Kernel versions v3.9 onwards.
 
 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Signed-off-by: Roger Quadros rog...@ti.com
 Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.9+
 ---
  drivers/mfd/omap-usb-tll.c | 36 
  1 file changed, 12 insertions(+), 24 deletions(-)

Patch looks good to me now.

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] usb: Skip U1/U2 LPM disable if device is disconnected.

[Venkatesh Murthy, HemanthX]

-Original Message-
From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
Sent: Tuesday, January 07, 2014 12:16 AM
To: Alan Stern
Cc: linux-usb@vger.kernel.org; Nandibasappa, GirishX; Venkatesh Murthy, 
HemanthX
Subject: Re: [PATCH] usb: Skip U1/U2 LPM disable if device is disconnected.

On Sat, Jan 04, 2014 at 12:09:27PM -0500, Alan Stern wrote:
 On Fri, 3 Jan 2014, Sarah Sharp wrote:

  Occasionally when a USB 3.0 device is disconnected, the roothub port
  goes into the SS.Inactive state, rather than reporting a disconnect.
  A warm reset is the only way to get out of this state.  khubd
  notices the link state in hub_port_events(),

 Do you mean hub_events()?  There is no hub_port_events() routine.

Yes.

 LPM is disabled before the port is reset.  At that time, the port is
 still in the SS.Inactive state, and the port-connect bit is the same
 as it was when hub_events() first read the port status.  So how will
 your new hub_is_device_disconnected() routine be able to do any better
 than the existing code already does?

 It sounds like what you really want to do is balance the LPM count but
 skip sending the actual request if the port is in the SS.Inactive
 state.

Yes, that's what this patch is trying to do.  It skips sending the
U1/U2 disable request if the device is disconnected.  The connect status bit 
is always set to disconnected if the port is in SS.Inactive.

Hmm, and now I see why you're confused.  The current code in
hub_events() skips usb_reset_device() if the connect status is
disconnected:

if (hub_port_warm_reset_required(hub, portstatus)) {
int status;
struct usb_device *udev =
hub-ports[i - 1]-child;

dev_dbg(hub_dev, warm reset port %d\n, i);
if (!udev ||
!(portstatus  USB_PORT_STAT_CONNECTION) ||
udev-state == USB_STATE_NOTATTACHED) {
status = hub_port_reset(hub, i,
NULL, 
 HUB_BH_RESET_TIME,
true);
if (status  0)
hub_port_disable(hub, i, 1);
} else {
usb_lock_device(udev);
status = usb_reset_device(udev);
usb_unlock_device(udev);
connect_change = 0;
}

I missed that when preparing the patch.  I now suspect that the only reason 
Girish and Hemanth ran into the U1/U2 timeout issue is
because they're working on an older kernel that doesn't have commit
f3e94aa15dc3d9155f8fc4a3295866d7a207b4e5 usb: core: don't try to
reset_device() a port that got just disconnected (added in 3.12).

We tried pulling this commit to our tree, we still see below errors multiple 
times.
Should hub_port_reset also be avoided in Inactive state.

7[  181.542976] hub 2-0:1.0: port 2 not reset yet, waiting 50ms
7[  181.593907] hub 2-0:1.0: port 2 not reset yet, waiting 200ms
7[  181.794881] hub 2-0:1.0: port 2 not reset yet, waiting 200ms
7[  181.995826] hub 2-0:1.0: port 2 not reset yet, waiting 200ms
7[  182.196746] hub 2-0:1.0: port 2 not reset yet, waiting 200ms
7[  182.196766] hub 2-0:1.0: port_wait_reset: err = -16

Thanks
Hemanth
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] xhci: Allocate the td array and urb_priv together.

[David Laight]

 From: 'David Cohen'
...
   The new kmalloc is going to be n * sizeof(struct) - n * sizeof(pointer)
   bigger. I don't know what is the usual range of values for n, but my
   experience with android devices with non-abundant memory size is that
   they are sensible to kmalloc  PAGE_SIZE.
 
  It is much easier to assume that we are keeping the second malloc
  are getting rid of the first one. The header is only one pointer.
 
 The header is not only one pointer. I believe the most relevant changes
 from your patch happen here:

My memory failed me - the 8 bytes are the two integers.

 --- a/drivers/usb/host/xhci.h
 +++ b/drivers/usb/host/xhci.h
 @@ -1363,7 +1363,7 @@ struct xhci_scratchpad {
  struct urb_priv {
 int length;
 int td_cnt;
 -   struct  xhci_td *td[0];
 +   struct  xhci_td td[0];
  };
 
 This is a dynamic array. It's not 1 pointer, it's how many you want it
 to be...

Yes, but each of the original td[] entries pointed to consecutive
entries of the original second malloc.
Maybe, at some point, they were each allocated separately.

 sizeof(struct urb_priv) does not consider the dynamic array at all, then
 you have the second value size * sizeof(struct xhci_td *) where size
 is the number of pointers you're going to have in the dynamic array.
 By doing your change you're increasing in the size of kmalloc in
 size * (sizeof(struct xhci_td) - sizeof(struct xhci_td *)) bytes.

Yes, but I'm removing a kmalloc of size * (sizeof (struct xhci_td)).

As I keep saying, I've moved the 'length' and 'td_cnt' fields to the
start of kmalloc that contains the actual data and completely removed
the allocation of an array of pointers (and all the code that dereferences
them).

sizeof (struct xhci_td) is something like 32, certainly less than 64 bytes.
So you need a moderate 'td_cnt' for the kmalloc to exceed a page size.

David



--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/10] usb: chipidea: host:vbus control change for OTG HNP.

[Li Jun]

Leave vbus on/off hanlded by OTG fsm if in OTG mode, init OTG port number.

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/host.c |   13 +
 drivers/usb/chipidea/host.h |9 +
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 526cd77..bba54c3 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -66,7 +66,7 @@ static int host_start(struct ci_hdrc *ci)
ehci-has_hostpc = ci-hw_bank.lpm;
ehci-has_tdi_phy_lpm = ci-hw_bank.lpm;
 
-   if (ci-platdata-reg_vbus) {
+   if ((ci-platdata-reg_vbus)  !ci_host_is_otg(ci)) {
ret = regulator_enable(ci-platdata-reg_vbus);
if (ret) {
dev_err(ci-dev,
@@ -79,8 +79,13 @@ static int host_start(struct ci_hdrc *ci)
ret = usb_add_hcd(hcd, 0, 0);
if (ret)
goto disable_reg;
-   else
+   else {
ci-hcd = hcd;
+   if (ci_host_is_otg(ci)) {
+   ci-transceiver-otg-host = hcd-self;
+   ci-transceiver-otg-host-otg_port = 1;
+   }
+   }
 
if (ci-platdata-flags  CI_HDRC_DISABLE_STREAMING)
hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
@@ -88,7 +93,7 @@ static int host_start(struct ci_hdrc *ci)
return ret;
 
 disable_reg:
-   if (ci-platdata-reg_vbus)
+   if ((ci-platdata-reg_vbus)  !ci_host_is_otg(ci))
regulator_disable(ci-platdata-reg_vbus);
 
 put_hcd:
@@ -104,7 +109,7 @@ static void host_stop(struct ci_hdrc *ci)
if (hcd) {
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
-   if (ci-platdata-reg_vbus)
+   if ((ci-platdata-reg_vbus)  !ci_host_is_otg(ci))
regulator_disable(ci-platdata-reg_vbus);
}
 }
diff --git a/drivers/usb/chipidea/host.h b/drivers/usb/chipidea/host.h
index 5707bf3..f98d084 100644
--- a/drivers/usb/chipidea/host.h
+++ b/drivers/usb/chipidea/host.h
@@ -6,6 +6,15 @@
 int ci_hdrc_host_init(struct ci_hdrc *ci);
 void ci_hdrc_host_destroy(struct ci_hdrc *ci);
 
+static inline bool ci_host_is_otg(struct ci_hdrc *ci)
+{
+#ifdef CONFIG_USB_OTG_FSM
+   return (ci-is_otg)  (ci-platdata-dr_mode == USB_DR_MODE_OTG);
+#else
+   return false;
+#endif
+}
+
 #else
 
 static inline int ci_hdrc_host_init(struct ci_hdrc *ci)
-- 
1.7.8


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/10] usb: chipidea: usb OTG fsm initlization.

[Li Jun]

This patch adds OTG fsm related initizations when do otg init,
add a seperate file for OTG fsm related utilities.

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/Makefile  |1 +
 drivers/usb/chipidea/ci.h  |1 +
 drivers/usb/chipidea/otg.c |6 +++
 drivers/usb/chipidea/otg_fsm.c |   70 
 drivers/usb/chipidea/otg_fsm.h |   27 +++
 5 files changed, 105 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 7345d21..5e1ecc5 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -6,6 +6,7 @@ ci_hdrc-y   := core.o otg.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)+= host.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG)   += debug.o
+ci_hdrc-$(CONFIG_USB_OTG_FSM)  += otg_fsm.o
 
 # Glue/Bridge layers go here
 
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 1c94fc5..0f1abc1 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -144,6 +144,7 @@ struct ci_hdrc {
struct ci_role_driver   *roles[CI_ROLE_END];
enum ci_rolerole;
boolis_otg;
+   struct otg_fsm  *fsm;
struct work_struct  work;
struct workqueue_struct *wq;
 
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 39bd7ec..2e13f2f 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -95,6 +95,12 @@ static void ci_otg_work(struct work_struct *work)
  */
 int ci_hdrc_otg_init(struct ci_hdrc *ci)
 {
+   int retval = 0;
+
+   retval = ci_hdrc_otg_fsm_init(ci);
+   if (retval)
+   return retval;
+
INIT_WORK(ci-work, ci_otg_work);
ci-wq = create_singlethread_workqueue(ci_otg);
if (!ci-wq) {
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
new file mode 100644
index 000..1f8907d
--- /dev/null
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -0,0 +1,70 @@
+/*
+ * otg_fsm.c - ChipIdea USB IP core OTG FSM driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ * Author: Jun Li
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * This file mainly handles otgsc register, it may include OTG operation
+ * in the future.
+ */
+
+#include linux/usb/otg.h
+#include linux/usb/otg-fsm.h
+#include linux/usb/gadget.h
+#include linux/usb/chipidea.h
+
+#include ci.h
+#include bits.h
+#include otg.h
+#include otg_fsm.h
+
+int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
+{
+   if (ci-transceiver == NULL)
+   return -EPROBE_DEFER;
+
+   ci-transceiver-otg = devm_kzalloc(ci-dev,
+   sizeof(struct usb_otg), GFP_KERNEL);
+   if (!ci-transceiver-otg) {
+   dev_err(ci-dev,
+   Failed to allocate usb_otg structure for ci hdrc otg!\n);
+   return -ENOMEM;
+   }
+
+   ci-fsm = devm_kzalloc(ci-dev,
+   sizeof(struct otg_fsm), GFP_KERNEL);
+   if (!ci-fsm) {
+   dev_err(ci-dev,
+   Failed to allocate otg_fsm structure for ci hdrc otg!\n);
+   return -ENOMEM;
+   }
+
+   ci-fsm-power_up = 1;
+   ci-fsm-id = hw_read(ci, OP_OTGSC, OTGSC_ID);
+   ci-fsm-otg = ci-transceiver-otg;
+   ci-fsm-otg-phy = ci-transceiver;
+   ci-fsm-otg-gadget = ci-gadget;
+   ci-transceiver-state = OTG_STATE_UNDEFINED;
+
+   mutex_init(ci-fsm-lock);
+
+   /* enable ID and A vbus valid irq */
+   hw_write(ci, OP_OTGSC, OTGSC_INT_EN_BITS | OTGSC_INT_STATUS_BITS,
+   OTGSC_IDIE | OTGSC_AVVIE);
+
+   if (ci-fsm-id) {
+   ci-fsm-b_ssend_srp =
+   hw_read(ci, OP_OTGSC, OTGSC_BSV) ? 0 : 1;
+   ci-fsm-b_sess_vld =
+   hw_read(ci, OP_OTGSC, OTGSC_BSV) ? 1 : 0;
+   }
+
+   return 0;
+}
diff --git a/drivers/usb/chipidea/otg_fsm.h b/drivers/usb/chipidea/otg_fsm.h
new file mode 100644
index 000..1a7ca11
--- /dev/null
+++ b/drivers/usb/chipidea/otg_fsm.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ * Author: Jun Li
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DRIVERS_USB_CHIPIDEA_OTG_FSM_H
+#define __DRIVERS_USB_CHIPIDEA_OTG_FSM_H
+
+#ifdef CONFIG_USB_OTG_FSM
+
+int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci);
+
+#else
+
+static inline int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
+{
+   return 0;
+}
+
+#endif
+
+#endif /* 

[PATCH 04/10] usb: chipidea: udc:driver update for OTG HNP.

[Li Jun]

Add b_hnp_enable request handling and enable gadget-is_otg

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/udc.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 73a39ef..ccdc277 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -20,6 +20,7 @@
 #include linux/pm_runtime.h
 #include linux/usb/ch9.h
 #include linux/usb/gadget.h
+#include linux/usb/otg-fsm.h
 #include linux/usb/chipidea.h
 
 #include ci.h
@@ -1106,6 +1107,14 @@ __acquires(ci-lock)
default:
break;
}
+   break;
+   case USB_DEVICE_B_HNP_ENABLE:
+   if (gadget_is_otg(ci-gadget)) {
+   ci-gadget.b_hnp_enable = 1;
+   err = isr_setup_status_phase(
+   ci);
+   }
+   break;
default:
goto delegate;
}
@@ -1762,7 +1771,7 @@ static int udc_start(struct ci_hdrc *ci)
ci-gadget.ops  = usb_gadget_ops;
ci-gadget.speed= USB_SPEED_UNKNOWN;
ci-gadget.max_speed= USB_SPEED_HIGH;
-   ci-gadget.is_otg   = 0;
+   ci-gadget.is_otg   = ci-is_otg ? 1 : 0;
ci-gadget.name = ci-platdata-name;
 
INIT_LIST_HEAD(ci-gadget.ep_list);
-- 
1.7.8


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/10] usb: chipidea: Add USB OTG HNP and SRP support on Chipidea usb driver.

[Li Jun]

This patchset adds USB OTG HNP and SRP support on chipidea usb driver,
existing OTG port role swtich function by ID pin status kept unchanged,
based on that, if select CONFIG_USB_OTG_FSM, OTG HNP and SRP will be
supported. Also some update on common otg fsm driver according to OTG
and EH Rev 2.0.

Reference to:
On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification 
July 27, 2012
Revision 2.0 version 1.1a

Li Jun (10):
  usb: otg-fsm: update OTG HNP state transition conditions according to
OTG and EH 2.0 spec.
  usb: chipidea: usb OTG fsm initlization.
  usb: chipidea: host:vbus control change for OTG HNP.
  usb: chipidea: udc:driver update for OTG HNP.
  usb: chipidea: add OTG fsm operation functions implemenation.
  usb: chipidea: OTG fsm timers initialization.
  usb: chipidea: OTG HNP and SRP fsm implementation.
  usb: chipidea: add OTG HNP polling support.
  usb: chipidea: add sys inputs for OTG fsm input.
  usb: chipidea: debug: add debug file for OTG variables show and
registers dump.

 drivers/usb/chipidea/Makefile  |1 +
 drivers/usb/chipidea/bits.h|   14 +
 drivers/usb/chipidea/ci.h  |3 +
 drivers/usb/chipidea/core.c|   10 +-
 drivers/usb/chipidea/debug.c   |  100 
 drivers/usb/chipidea/host.c|   13 +-
 drivers/usb/chipidea/host.h|9 +
 drivers/usb/chipidea/otg.c |   13 +
 drivers/usb/chipidea/otg_fsm.c | 1022 
 drivers/usb/chipidea/otg_fsm.h |  127 +
 drivers/usb/chipidea/udc.c |   22 +-
 drivers/usb/phy/phy-fsm-usb.c  |   15 +-
 include/linux/usb/gadget.h |1 +
 include/linux/usb/otg-fsm.h|   13 +
 14 files changed, 1351 insertions(+), 12 deletions(-)
 create mode 100644 drivers/usb/chipidea/otg_fsm.c
 create mode 100644 drivers/usb/chipidea/otg_fsm.h

-- 
1.7.8


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/10] usb: phy-fsm: update OTG HNP state transition conditions according to OTG and EH 2.0 spec.

[Li Jun]

According to:On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification July 27, 2012 Revision 2.0 version 1.1a
- From a_host to a_wait_bcon if !b_conn
- Add transition from a_host to a_wait_vfall if id state is high or a_bus_drop
- From a_wait_vfall to a_idle if a_wait_vfall_tmout

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/phy/phy-fsm-usb.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/phy-fsm-usb.c b/drivers/usb/phy/phy-fsm-usb.c
index 7aa314e..c47e5a6 100644
--- a/drivers/usb/phy/phy-fsm-usb.c
+++ b/drivers/usb/phy/phy-fsm-usb.c
@@ -317,10 +317,12 @@ int otg_statemachine(struct otg_fsm *fsm)
otg_set_state(fsm, OTG_STATE_A_WAIT_VFALL);
break;
case OTG_STATE_A_HOST:
-   if ((!fsm-a_bus_req || fsm-a_suspend_req_inf) 
+   if (fsm-id || fsm-a_bus_drop)
+   otg_set_state(fsm, OTG_STATE_A_WAIT_VFALL);
+   else if ((!fsm-a_bus_req || fsm-a_suspend_req_inf) 
fsm-otg-host-b_hnp_enable)
otg_set_state(fsm, OTG_STATE_A_SUSPEND);
-   else if (fsm-id || !fsm-b_conn || fsm-a_bus_drop)
+   else if (!fsm-b_conn)
otg_set_state(fsm, OTG_STATE_A_WAIT_BCON);
else if (!fsm-a_vbus_vld)
otg_set_state(fsm, OTG_STATE_A_VBUS_ERR);
@@ -346,8 +348,7 @@ int otg_statemachine(struct otg_fsm *fsm)
otg_set_state(fsm, OTG_STATE_A_VBUS_ERR);
break;
case OTG_STATE_A_WAIT_VFALL:
-   if (fsm-a_wait_vfall_tmout || fsm-id || fsm-a_bus_req ||
-   (!fsm-a_sess_vld  !fsm-b_conn))
+   if (fsm-a_wait_vfall_tmout)
otg_set_state(fsm, OTG_STATE_A_IDLE);
break;
case OTG_STATE_A_VBUS_ERR:
-- 
1.7.8


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/10] usb: chipidea: add OTG HNP polling support.

[Li Jun]

This patch add OTG HNP polling support for both A and B device.
After A/B in host state, host request polling message will be sent
from host to peripheral every 1.5s, if host found the host request
flag is set to be 1 by peripheral, a role switch will be started.

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/ci.h  |2 +
 drivers/usb/chipidea/otg_fsm.c |   80 
 drivers/usb/chipidea/otg_fsm.h |3 +
 drivers/usb/chipidea/udc.c |   11 -
 drivers/usb/phy/phy-fsm-usb.c  |6 +++
 include/linux/usb/gadget.h |1 +
 include/linux/usb/otg-fsm.h|   13 ++
 7 files changed, 114 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 0f1abc1..1780945 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -135,6 +135,7 @@ struct hw_bank {
  * @id_event: indicates there is an id event, and handled at ci_otg_work
  * @b_sess_valid_event: indicates there is a vbus event, and handled
  * at ci_otg_work
+ * @hnp_polling_event: indicate HNP polling request should be sent out
  */
 struct ci_hdrc {
struct device   *dev;
@@ -174,6 +175,7 @@ struct ci_hdrc {
struct dentry   *debugfs;
boolid_event;
boolb_sess_valid_event;
+   boolhnp_polling_event;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index cfdfebd..60465ab 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -475,6 +475,76 @@ int ci_otg_start_gadget(struct otg_fsm *fsm, int on)
return 0;
 }
 
+void ci_otg_start_hnp_polling(struct otg_fsm *fsm)
+{
+   mod_timer(fsm-hnp_polling_timer,
+   jiffies + msecs_to_jiffies(T_HOST_REQ_POLL));
+
+   return;
+}
+
+static void hnp_polling_timer_work(unsigned long arg)
+{
+   struct ci_hdrc *ci = (struct ci_hdrc *)arg;
+
+   ci-hnp_polling_event = true;
+   disable_irq_nosync(ci-irq);
+   queue_work(ci-wq, ci-work);
+}
+
+static int ci_hnp_polling(struct ci_hdrc *ci)
+{
+   struct usb_device   *udev;
+   int err = 0;
+   u16 data;
+
+   if (ci-transceiver-state != OTG_STATE_A_HOST
+ci-transceiver-state != OTG_STATE_B_HOST)
+   return -EINVAL;
+
+   if (ci-transceiver-otg-host 
+   ci-transceiver-otg-host-root_hub) {
+   udev = usb_hub_find_child(
+   ci-transceiver-otg-host-root_hub, 1);
+   if (!udev) {
+   dev_dbg(ci-dev,
+   no usb dev connected, stop HNP polling\n);
+   return -ENODEV;
+   } else if (udev-state  USB_STATE_DEFAULT) {
+   ci_otg_start_hnp_polling(ci-fsm);
+   return -EAGAIN;
+   }
+   } else {
+   dev_dbg(ci-dev, no host or root_hub registered\n);
+   return -ENODEV;
+   }
+
+   /* get host request flag from connected USB device */
+   err = usb_get_status(udev, USB_RECIP_DEVICE, OTG_STS_SELECTOR, data);
+   if (err) {
+   dev_warn(ci-dev,
+   ERR in HNP polling = %d, stop HNP polling\n, err);
+   return -EINVAL;
+   }
+
+   if ((data  0xff) == HOST_REQUEST_FLAG) {
+   /* Start role switch */
+   dev_dbg(ci-dev, host request flag = 1\n);
+   if (ci-transceiver-state == OTG_STATE_A_HOST)
+   ci-fsm-a_bus_req = 0;
+   else if (ci-transceiver-state == OTG_STATE_B_HOST)
+   ci-fsm-b_bus_req = 0;
+   return 0;
+   } else if ((data  0xff) == 0) {
+   /* Continue polling */
+   ci_otg_start_hnp_polling(ci-fsm);
+   return -EAGAIN;
+   } else
+   dev_err(ci-dev, host request flag is invalid value\n);
+
+   return err;
+}
+
 static struct otg_fsm_ops ci_otg_ops = {
.chrg_vbus = ci_otg_chrg_vbus,
.drv_vbus = ci_otg_drv_vbus,
@@ -482,6 +552,7 @@ static struct otg_fsm_ops ci_otg_ops = {
.loc_sof = ci_otg_loc_sof,
.start_pulse = ci_otg_start_pulse,
.start_adp_prb = ci_otg_start_adp_prb,
+   .start_hnp_polling = ci_otg_start_hnp_polling,
 
.add_timer = ci_otg_fsm_add_timer,
.del_timer = ci_otg_fsm_del_timer,
@@ -495,6 +566,13 @@ int ci_otg_fsm_work(struct ci_hdrc *ci)
if (!ci-transceiver-otg || !ci-fsm)
return -ENODEV;
 
+   if (ci-hnp_polling_event) {
+   ci-hnp_polling_event = false;
+   if (ci_hnp_polling(ci)) {
+   return 0;
+   }
+   }
+
if 

[PATCH 10/10] usb: chipidea: debug: add debug file for OTG variables show and registers dump.

[Li Jun]

This patch add a debug file for OTG vairables show and registers dump.

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/debug.c |  100 ++
 1 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 96d899a..95daa22 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -7,6 +7,9 @@
 #include linux/uaccess.h
 #include linux/usb/ch9.h
 #include linux/usb/gadget.h
+#include linux/usb/phy.h
+#include linux/usb/otg.h
+#include linux/usb/otg-fsm.h
 
 #include ci.h
 #include udc.h
@@ -204,6 +207,96 @@ static const struct file_operations ci_requests_fops = {
.release= single_release,
 };
 
+int ci_otg_show(struct seq_file *s, void *unused)
+{
+   struct ci_hdrc *ci = s-private;
+   struct otg_fsm *fsm = ci-fsm;
+   u32 tmp_reg;
+
+   if (!ci-is_otg)
+   return 0;
+
+   /* -- Registers - */
+   tmp_reg = hw_read(ci, OP_OTGSC, ~0);
+   seq_printf(s, OTGSC reg: %08x\n, tmp_reg);
+
+   tmp_reg = hw_read(ci, OP_PORTSC, ~0);
+   seq_printf(s, PORTSC reg: %08x\n, tmp_reg);
+
+   tmp_reg = hw_read(ci, OP_USBMODE, ~0);
+   seq_printf(s, USBMODE reg: %08x\n, tmp_reg);
+
+   tmp_reg = hw_read(ci, OP_USBCMD, ~0);
+   seq_printf(s, USBCMD reg: %08x\n, tmp_reg);
+
+   tmp_reg = hw_read(ci, OP_USBSTS, ~0);
+   seq_printf(s, USBSTS reg: %08x\n, tmp_reg);
+
+   /* -- State - */
+   seq_printf(s,
+ OTG state: %s\n\n,
+ usb_otg_state_string(ci-transceiver-state));
+
+   /* -- State Machine Variables - */
+   seq_printf(s, a_bus_drop: %d\n, fsm-a_bus_drop);
+
+   seq_printf(s, a_bus_req: %d\n, fsm-a_bus_req);
+
+   seq_printf(s, a_srp_det: %d\n, fsm-a_srp_det);
+
+   seq_printf(s, a_vbus_vld: %d\n, fsm-a_vbus_vld);
+
+   seq_printf(s, b_conn: %d\n, fsm-b_conn);
+
+   seq_printf(s, adp_change: %d\n, fsm-adp_change);
+
+   seq_printf(s, power_up: %d\n, fsm-power_up);
+
+   seq_printf(s, a_bus_resume: %d\n, fsm-a_bus_resume);
+
+   seq_printf(s, a_bus_suspend: %d\n, fsm-a_bus_suspend);
+
+   seq_printf(s, a_conn: %d\n, fsm-a_conn);
+
+   seq_printf(s, b_bus_req: %d\n, fsm-b_bus_req);
+
+   seq_printf(s, b_bus_suspend: %d\n, fsm-b_bus_suspend);
+
+   seq_printf(s, b_se0_srp: %d\n, fsm-b_se0_srp);
+
+   seq_printf(s, b_ssend_srp: %d\n, fsm-b_ssend_srp);
+
+   seq_printf(s, b_sess_vld: %d\n, fsm-b_sess_vld);
+
+   seq_printf(s, b_srp_done: %d\n, fsm-b_srp_done);
+
+   seq_printf(s, drv_vbus: %d\n, fsm-drv_vbus);
+
+   seq_printf(s, loc_conn: %d\n, fsm-loc_conn);
+
+   seq_printf(s, loc_sof: %d\n, fsm-loc_sof);
+
+   seq_printf(s, adp_prb: %d\n, fsm-adp_prb);
+
+   seq_printf(s, id: %d\n, fsm-id);
+
+   seq_printf(s, protocol: %d\n, fsm-protocol);
+
+   return 0;
+}
+
+static int ci_otg_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, ci_otg_show, inode-i_private);
+}
+
+static const struct file_operations ci_otg_fops = {
+   .open   = ci_otg_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
 static int ci_role_show(struct seq_file *s, void *data)
 {
struct ci_hdrc *ci = s-private;
@@ -287,6 +380,13 @@ int dbg_create_files(struct ci_hdrc *ci)
if (!dent)
goto err;
 
+   if (ci-is_otg) {
+   dent = debugfs_create_file(otg, S_IRUGO, ci-debugfs, ci,
+   ci_otg_fops);
+   if (!dent)
+   goto err;
+   }
+
dent = debugfs_create_file(role, S_IRUGO | S_IWUSR, ci-debugfs, ci,
   ci_role_fops);
if (dent)
-- 
1.7.8


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/10] usb: chipidea: OTG HNP and SRP fsm implementation.

[Li Jun]

USB OTG interrupt handling and fsm transition according to USB OTG
spec 2.0, update otg timer time out handlers.

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/bits.h|3 +
 drivers/usb/chipidea/core.c|   10 ++-
 drivers/usb/chipidea/otg.c |6 +
 drivers/usb/chipidea/otg_fsm.c |  264 ++--
 drivers/usb/chipidea/otg_fsm.h |   18 +++
 5 files changed, 292 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 4347414..9a1c4c0 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -33,6 +33,8 @@
 #define USBCMD_ATDTW  BIT(14)
 
 /* USBSTS  USBINTR */
+#define USBSTS_PCIBIT(2)
+#define USBSTS_SLIBIT(8)
 #define USBi_UI   BIT(0)
 #define USBi_UEI  BIT(1)
 #define USBi_PCI  BIT(2)
@@ -81,6 +83,7 @@
 #define OTGSC_VC BIT(1)
 #define OTGSC_IDPU   BIT(5)
 #define OTGSC_HADP   BIT(6)
+#define OTGSC_HABABIT(7)
 #define OTGSC_ID BIT(8)
 #define OTGSC_AVVBIT(9)
 #define OTGSC_ASVBIT(10)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 9a5ef20..2f29791 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -73,6 +73,7 @@
 #include host.h
 #include debug.h
 #include otg.h
+#include otg_fsm.h
 
 /* Controller register map */
 static uintptr_t ci_regs_nolpm[] = {
@@ -356,8 +357,12 @@ static irqreturn_t ci_irq(int irq, void *data)
irqreturn_t ret = IRQ_NONE;
u32 otgsc = 0;
 
-   if (ci-is_otg)
+   if (ci-is_otg) {
otgsc = hw_read(ci, OP_OTGSC, ~0);
+   ret = ci_otg_fsm_irq(ci);
+   if (ret == IRQ_HANDLED)
+   return ret;
+   }
 
/*
 * Handle id change interrupt, it indicates device/host function
@@ -659,6 +664,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (ret)
goto stop;
 
+   if (ci-is_otg)
+   ci_hdrc_otg_fsm_start(ci);
+
ret = dbg_create_files(ci);
if (!ret)
return 0;
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 2e13f2f..5914c92 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -22,6 +22,7 @@
 #include ci.h
 #include bits.h
 #include otg.h
+#include otg_fsm.h
 
 /**
  * ci_otg_role - pick role based on ID pin state
@@ -76,6 +77,11 @@ static void ci_otg_work(struct work_struct *work)
 {
struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
 
+   if (!ci_otg_fsm_work(ci)) {
+   enable_irq(ci-irq);
+   return;
+   }
+
if (ci-id_event) {
ci-id_event = false;
ci_handle_id_switch(ci);
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 86bed68..cfdfebd 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -192,6 +192,60 @@ void set_tmout(void *ptr, unsigned long indicator)
*(int *)indicator = 1;
 }
 
+void set_tmout_and_fsm(void *ptr, unsigned long indicator)
+{
+   struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
+
+   set_tmout(ci, indicator);
+
+   /* trans from a_wait_bcon to a_wait_vfall */
+   disable_irq_nosync(ci-irq);
+   queue_work(ci-wq, ci-work);
+}
+
+void b_ssend_srp_tmout_handler(void *ptr, unsigned long indicator)
+{
+   struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
+   set_tmout(ci, indicator);
+
+   /* only vbus fall below B_sess_vld in b_idle state */
+   if (ci-transceiver-state == OTG_STATE_B_IDLE) {
+   disable_irq_nosync(ci-irq);
+   queue_work(ci-wq, ci-work);
+   }
+}
+
+void b_sess_vld_tmout_handler(void *ptr, unsigned long indicator)
+{
+   struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
+
+   /* Check if A detached */
+   if (!(hw_read(ci, OP_OTGSC, OTGSC_BSV))) {
+   ci-fsm-b_sess_vld = 0;
+   ci_otg_add_timer(ci, b_ssend_srp_tmr);
+   disable_irq_nosync(ci-irq);
+   queue_work(ci-wq, ci-work);
+   }
+}
+
+void b_data_pulse_end(void *ptr, unsigned long indicator)
+{
+   struct ci_hdrc *ci = (struct ci_hdrc *)ptr;
+
+   ci-fsm-b_srp_done = 1;
+   ci-fsm-b_bus_req = 0;
+   if (ci-fsm-power_up)
+   ci-fsm-power_up = 0;
+#ifdef HA_DATA_PULSE
+   hw_write(ci, OP_OTGSC, OTGSC_INT_STATUS_BITS | OTGSC_HABA, 0);
+
+   disable_irq_nosync(ci-irq);
+   queue_work(ci-wq, ci-work);
+#else
+   ci_otg_loc_conn(ci-fsm, 0);
+#endif
+}
+
 /* Initialize timers */
 int ci_otg_init_timers(struct otg_fsm *fsm)
 {
@@ -201,22 +255,22 @@ int ci_otg_init_timers(struct otg_fsm *fsm)
if (a_wait_vrise_tmr == NULL)
return -ENOMEM;
 
-   a_wait_vfall_tmr = otg_timer_initializer(set_tmout,
+   

[PATCH 06/10] usb: chipidea: OTG fsm timers initialization.

[Li Jun]

This patch adds OTG fsm timers initialization, which use controller's 1ms
interrupt as time out counter, also adds some local timers which are not
in otg_fsm_timer list.

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/otg_fsm.c |  111 +++-
 drivers/usb/chipidea/otg_fsm.h |   65 +++
 2 files changed, 175 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 31a046d..86bed68 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -33,7 +33,23 @@ static struct list_head active_timers;
 /* FSM timers */
 struct ci_otg_fsm_timer *a_wait_vrise_tmr, *a_wait_vfall_tmr, *a_wait_bcon_tmr,
*a_aidl_bdis_tmr, *a_bidl_adis_tmr, *b_ase0_brst_tmr,
-   *b_se0_srp_tmr, *b_srp_fail_tmr, *b_data_pulse_tmr;
+   *b_se0_srp_tmr, *b_srp_fail_tmr, *b_data_pulse_tmr,
+   *b_ssend_srp_tmr, *b_sess_vld_tmr;
+
+inline struct ci_otg_fsm_timer *otg_timer_initializer
+(void (*function)(void *, unsigned long), unsigned long expires,
+   unsigned long data)
+{
+   struct ci_otg_fsm_timer *timer;
+
+   timer = kmalloc(sizeof(struct ci_otg_fsm_timer), GFP_KERNEL);
+   if (!timer)
+   return NULL;
+   timer-function = function;
+   timer-expires = expires;
+   timer-data = data;
+   return timer;
+}
 
 /* Add timer to timer list */
 void ci_otg_add_timer(struct ci_hdrc *ci, struct ci_otg_fsm_timer  *gtimer)
@@ -170,6 +186,89 @@ int ci_otg_tick_timer(struct ci_hdrc *ci)
return expired;
 }
 
+/* The timeout callback function to set time out bit */
+void set_tmout(void *ptr, unsigned long indicator)
+{
+   *(int *)indicator = 1;
+}
+
+/* Initialize timers */
+int ci_otg_init_timers(struct otg_fsm *fsm)
+{
+   /* FSM used timers */
+   a_wait_vrise_tmr = otg_timer_initializer(set_tmout, TA_WAIT_VRISE,
+   (unsigned long)fsm-a_wait_vrise_tmout);
+   if (a_wait_vrise_tmr == NULL)
+   return -ENOMEM;
+
+   a_wait_vfall_tmr = otg_timer_initializer(set_tmout,
+   TA_WAIT_VFALL, (unsigned long)fsm-a_wait_vfall_tmout);
+   if (a_wait_vfall_tmr == NULL)
+   return -ENOMEM;
+
+   a_wait_bcon_tmr = otg_timer_initializer(set_tmout,
+   TA_WAIT_BCON, (unsigned long)fsm-a_wait_bcon_tmout);
+   if (a_wait_bcon_tmr == NULL)
+   return -ENOMEM;
+
+   a_aidl_bdis_tmr = otg_timer_initializer(set_tmout,
+   TA_AIDL_BDIS, (unsigned long)fsm-a_aidl_bdis_tmout);
+   if (a_aidl_bdis_tmr == NULL)
+   return -ENOMEM;
+
+   a_bidl_adis_tmr = otg_timer_initializer(set_tmout,
+   TA_BIDL_ADIS, (unsigned long)fsm-a_bidl_adis_tmout);
+   if (a_bidl_adis_tmr == NULL)
+   return -ENOMEM;
+
+   b_ase0_brst_tmr = otg_timer_initializer(set_tmout, TB_ASE0_BRST,
+   (unsigned long)fsm-b_ase0_brst_tmout);
+   if (b_ase0_brst_tmr == NULL)
+   return -ENOMEM;
+
+   b_se0_srp_tmr = otg_timer_initializer(set_tmout, TB_SE0_SRP,
+   (unsigned long)fsm-b_se0_srp);
+   if (b_se0_srp_tmr == NULL)
+   return -ENOMEM;
+
+   b_ssend_srp_tmr = otg_timer_initializer(set_tmout,
+   TB_SSEND_SRP, (unsigned long)fsm-b_ssend_srp);
+   if (b_ssend_srp_tmr == NULL)
+   return -ENOMEM;
+
+   b_srp_fail_tmr = otg_timer_initializer(set_tmout,
+   TB_SRP_FAIL, (unsigned long)fsm-b_srp_done);
+   if (b_srp_fail_tmr == NULL)
+   return -ENOMEM;
+
+   b_data_pulse_tmr = otg_timer_initializer(set_tmout, TB_DATA_PLS, 0);
+   if (b_data_pulse_tmr == NULL)
+   return -ENOMEM;
+
+   b_sess_vld_tmr = otg_timer_initializer(set_tmout, TB_SESS_VLD, 0);
+   if (b_sess_vld_tmr == NULL)
+   return -ENOMEM;
+
+   return 0;
+}
+
+/* Uninitialize timers */
+void ci_otg_uninit_timers(void)
+{
+   /* FSM used timers */
+   kfree(a_wait_vrise_tmr);
+   kfree(a_wait_vfall_tmr);
+   kfree(a_wait_bcon_tmr);
+   kfree(a_aidl_bdis_tmr);
+   kfree(a_bidl_adis_tmr);
+   kfree(b_ase0_brst_tmr);
+   kfree(b_se0_srp_tmr);
+   kfree(b_ssend_srp_tmr);
+   kfree(b_srp_fail_tmr);
+   kfree(b_data_pulse_tmr);
+   kfree(b_sess_vld_tmr);
+}
+
 /* -*/
 /* Operations that will be called from OTG Finite State Machine */
 
@@ -337,6 +436,8 @@ static struct otg_fsm_ops ci_otg_ops = {
 
 int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
 {
+   int retval = 0;
+
if (ci-transceiver == NULL)
return -EPROBE_DEFER;
 
@@ -366,6 +467,14 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
 
   

[PATCH 05/10] usb: chipidea: add OTG fsm operation functions implemenation.

[Li Jun]

Add OTG HNP and SRP operation functions implementation:
- charge vbus
- drive vbus
- connection signaling
- drive sof
- start data pulse
- add fsm timer
- delete fsm timer
- start host
- start gadget

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/bits.h|   11 ++
 drivers/usb/chipidea/otg_fsm.c |  311 
 drivers/usb/chipidea/otg_fsm.h |8 +
 3 files changed, 330 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index a857131..4347414 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -44,9 +44,14 @@
 #define DEVICEADDR_USBADR (0x7FUL  25)
 
 /* PORTSC */
+#define PORTSC_CCS   BIT(0)
+#define PORTSC_CSC   BIT(1)
+#define PORTSC_PEC   BIT(3)
+#define PORTSC_OCC   BIT(5)
 #define PORTSC_FPRBIT(6)
 #define PORTSC_SUSP   BIT(7)
 #define PORTSC_HSPBIT(9)
+#define PORTSC_PP BIT(12)
 #define PORTSC_PTC(0x0FUL  16)
 #define PORTSC_PHCD(d)   ((d) ? BIT(22) : BIT(23))
 /* PTS and PTW for non lpm version only */
@@ -55,6 +60,9 @@
 #define PORTSC_PTWBIT(28)
 #define PORTSC_STSBIT(29)
 
+#define PORTSC_W1C_BITS\
+   (PORTSC_CSC | PORTSC_PEC | PORTSC_OCC)
+
 /* DEVLC */
 #define DEVLC_PSPD(0x03UL  25)
 #define DEVLC_PSPD_HS (0x02UL  25)
@@ -69,7 +77,10 @@
 #define PTS_HSIC  4
 
 /* OTGSC */
+#define OTGSC_VD BIT(0)
+#define OTGSC_VC BIT(1)
 #define OTGSC_IDPU   BIT(5)
+#define OTGSC_HADP   BIT(6)
 #define OTGSC_ID BIT(8)
 #define OTGSC_AVVBIT(9)
 #define OTGSC_ASVBIT(10)
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 1f8907d..31a046d 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -19,12 +19,322 @@
 #include linux/usb/otg-fsm.h
 #include linux/usb/gadget.h
 #include linux/usb/chipidea.h
+#include linux/regulator/consumer.h
 
 #include ci.h
 #include bits.h
 #include otg.h
 #include otg_fsm.h
 
+static struct list_head active_timers;
+
+#define HA_DATA_PULSE 1
+
+/* FSM timers */
+struct ci_otg_fsm_timer *a_wait_vrise_tmr, *a_wait_vfall_tmr, *a_wait_bcon_tmr,
+   *a_aidl_bdis_tmr, *a_bidl_adis_tmr, *b_ase0_brst_tmr,
+   *b_se0_srp_tmr, *b_srp_fail_tmr, *b_data_pulse_tmr;
+
+/* Add timer to timer list */
+void ci_otg_add_timer(struct ci_hdrc *ci, struct ci_otg_fsm_timer  *gtimer)
+{
+   struct ci_otg_fsm_timer *timer = gtimer;
+   struct ci_otg_fsm_timer *tmp_timer;
+
+   /* Check if the timer is already in the active list,
+* if so update timer count
+*/
+   list_for_each_entry(tmp_timer, active_timers, list)
+   if (tmp_timer == timer) {
+   timer-count = timer-expires;
+   return;
+   }
+
+   timer-count = timer-expires;
+   list_add_tail(timer-list, active_timers);
+
+   /* enable 1ms irq in otgsc */
+   if (!(hw_read(ci, OP_OTGSC, OTGSC_1MSIE))) {
+   hw_write(ci, OP_OTGSC, OTGSC_INT_STATUS_BITS | OTGSC_1MSIE,
+   OTGSC_1MSIE);
+   }
+}
+
+static struct ci_otg_fsm_timer *ci_otg_get_timer(enum otg_fsm_timer t)
+{
+   struct ci_otg_fsm_timer *timer;
+
+   /* REVISIT: use array of pointers to timers instead */
+   switch (t) {
+   case A_WAIT_VRISE:
+   timer = a_wait_vrise_tmr;
+   break;
+   case A_WAIT_VFALL:
+   timer = a_wait_vfall_tmr;
+   break;
+   case A_WAIT_BCON:
+   timer = a_wait_bcon_tmr;
+   break;
+   case A_AIDL_BDIS:
+   timer = a_aidl_bdis_tmr;
+   break;
+   case A_BIDL_ADIS:
+   timer = a_bidl_adis_tmr;
+   break;
+   case B_ASE0_BRST:
+   timer = b_ase0_brst_tmr;
+   break;
+   case B_SE0_SRP:
+   timer = b_se0_srp_tmr;
+   break;
+   case B_SRP_FAIL:
+   timer = b_srp_fail_tmr;
+   break;
+   default:
+   timer = NULL;
+   }
+
+   return timer;
+}
+
+static void ci_otg_fsm_add_timer(struct otg_fsm *fsm, enum otg_fsm_timer t)
+{
+   struct ci_otg_fsm_timer *timer;
+   struct ci_hdrc  *ci = container_of(fsm-otg-gadget,
+   struct ci_hdrc, gadget);
+
+   timer = ci_otg_get_timer(t);
+   if (!timer)
+   return;
+
+   ci_otg_add_timer(ci, timer);
+}
+
+/* Remove timer from the timer list; clear timeout status */
+void ci_otg_del_timer(struct ci_hdrc *ci, struct ci_otg_fsm_timer *gtimer)
+{
+   struct ci_otg_fsm_timer *timer = gtimer;
+   struct ci_otg_fsm_timer *tmp_timer, *del_tmp;
+   int flag = 0;
+
+

[PATCH 09/10] usb: chipidea: add sys inputs for OTG fsm input.

[Li Jun]

This patch adds sys input to control and show OTG fsm inputs by application,
user can do host and preipheral role switch by change these inputs.

Signed-off-by: Li Jun b47...@freescale.com
---
 drivers/usb/chipidea/otg.c |1 +
 drivers/usb/chipidea/otg_fsm.c |  204 
 drivers/usb/chipidea/otg_fsm.h |6 +
 3 files changed, 211 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 5914c92..09099e5 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -129,4 +129,5 @@ void ci_hdrc_otg_destroy(struct ci_hdrc *ci)
}
ci_disable_otg_interrupt(ci, OTGSC_INT_EN_BITS);
ci_clear_otg_interrupt(ci, OTGSC_INT_STATUS_BITS);
+   ci_hdrc_otg_fsm_remove(ci);
 }
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 60465ab..8124a64 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -27,6 +27,7 @@
 #include otg_fsm.h
 
 static struct list_head active_timers;
+static struct ci_hdrc *ci_hdrc_p;
 
 #define HA_DATA_PULSE 1
 
@@ -51,6 +52,195 @@ inline struct ci_otg_fsm_timer *otg_timer_initializer
return timer;
 }
 
+/* Add for otg: interact with user space app */
+static ssize_t
+get_a_bus_req(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   char*next;
+   unsignedsize, t;
+   struct ci_hdrc *ci = ci_hdrc_p;
+
+   next = buf;
+   size = PAGE_SIZE;
+
+   if (ci-transceiver  ci-transceiver-otg  ci-fsm) {
+   t = scnprintf(next, size, %d, ci-fsm-a_bus_req);
+   size -= t;
+   next += t;
+   } else
+   dev_err(ci-dev, error: otg setup is not completed!\n);
+
+   return PAGE_SIZE - size;
+}
+
+static ssize_t
+set_a_bus_req(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct ci_hdrc *ci = ci_hdrc_p;
+
+   if (count  2)
+   return -1;
+
+   mutex_lock(ci-fsm-lock);
+   if (ci-transceiver  ci-transceiver-otg  ci-fsm) {
+   if (buf[0] == '0') {
+   ci-fsm-a_bus_req = 0;
+   } else if (buf[0] == '1') {
+   /* If a_bus_drop is TRUE, a_bus_req can't be set */
+   if (ci-fsm-a_bus_drop)
+   goto end;
+   ci-fsm-a_bus_req = 1;
+   if (ci-transceiver-state == OTG_STATE_A_PERIPHERAL) {
+   ci-gadget.host_request_flag = 1;
+   goto end;
+   }
+   }
+
+   disable_irq_nosync(ci-irq);
+   queue_work(ci-wq, ci-work);
+   } else
+   dev_err(ci-dev, error: otg setup is not completed!\n);
+end:
+   mutex_unlock(ci-fsm-lock);
+
+   return count;
+}
+static DEVICE_ATTR(a_bus_req, S_IRUGO | S_IWUSR, get_a_bus_req, set_a_bus_req);
+
+static ssize_t
+get_a_bus_drop(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   char*next;
+   unsignedsize, t;
+   struct ci_hdrc *ci = ci_hdrc_p;
+
+   next = buf;
+   size = PAGE_SIZE;
+   if (ci-transceiver  ci-transceiver-otg  ci-fsm) {
+   t = scnprintf(next, size, %d, ci-fsm-a_bus_drop);
+   size -= t;
+   next += t;
+   } else
+   dev_err(ci-dev, error: otg setup is not completed!\n);
+
+   return PAGE_SIZE - size;
+}
+
+static ssize_t
+set_a_bus_drop(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct ci_hdrc *ci = ci_hdrc_p;
+
+   if (count  2)
+   return -1;
+
+   mutex_lock(ci-fsm-lock);
+   if (ci-transceiver  ci-transceiver-otg  ci-fsm) {
+   if (buf[0] == '0') {
+   ci-fsm-a_bus_drop = 0;
+   } else if (buf[0] == '1') {
+   ci-fsm-a_bus_drop = 1;
+   ci-fsm-a_bus_req = 0;
+   }
+
+   disable_irq_nosync(ci-irq);
+   queue_work(ci-wq, ci-work);
+   }
+   mutex_unlock(ci-fsm-lock);
+
+   return count;
+}
+static DEVICE_ATTR(a_bus_drop, S_IRUGO | S_IWUSR, get_a_bus_drop,
+   set_a_bus_drop);
+
+static ssize_t
+get_b_bus_req(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   char*next;
+   unsignedsize, t;
+   struct ci_hdrc *ci = ci_hdrc_p;
+
+   next = buf;
+   size = PAGE_SIZE;
+
+   if (ci-transceiver  ci-transceiver-otg  ci-fsm) {
+   t = scnprintf(next, size, %d, ci-fsm-b_bus_req);
+   size -= t;
+   next += t;
+   }
+
+   return 

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Mark Rutland]

On Wed, Jan 08, 2014 at 06:15:38AM +, Roger Quadros wrote:
 The omap-usb-host driver expects the 60MHz functional clock
 of the USB host module to be named as init_60m_fclk.
 Add this information in the DT binding document.
 
 CC: Lee Jones lee.jo...@linaro.org
 CC: Samuel Ortiz sa...@linux.intel.com
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
 b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 index b381fa6..5635202 100644
 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 @@ -32,6 +32,10 @@ Optional properties:
  - single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
  
 +- clocks: phandle to 60MHz functional clock to the USB Host module.
 +
 +- clock-names: must be init_60m_fclk
 +

Nit: clocks aren't just phandles, there's a clock-specifier too.

Also, it would be nicer if clocks was defined in terms of clock-names,
as it makes the relationship between clocks and clock-names clear, and
makes it easier to extend the list in future. Something like:

- clocks: a list of phandles + clock-specifiers, one for each entry in
  clock-names

- clock-names: should include:
  * init_60m_fclk - the 60MHz functional clock to the USB host module.

Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.

[David Laight]

 From: tatxarata
 Since reporting this bug I've invested some time to get myself familiar
 with USB protocol and analyzed attached capture files. It seems like
 device resetoccurs after device returns urb_status=-75 (-EOVERFLOW).
...
 In case of USB2.0 host-device traffic looks pretty the same way as in
 case of USB3.0. Host also tries to read device by chunks of 240 sectors
 and device returns only 120. However for some reason this doesn't lead
 to EOVERFLOW.

Is that using ehci, or forcing xhci to run at USB2 speeds (eg by using
a USB2 extension cable)?

David

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Roger Quadros]

+Tero

Hi Sebastian,

On 01/08/2014 02:38 PM, Sebastian Reichel wrote:
 On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote:
 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
 b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 index b381fa6..5635202 100644
 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 @@ -32,6 +32,10 @@ Optional properties:
  - single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
  
 +- clocks: phandle to 60MHz functional clock to the USB Host module.
 +
 +- clock-names: must be init_60m_fclk
 +
  Required properties if child node exists:
  
  - #address-cells: Must be 1
 
 I have some questions:
 
 What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't
 all of those be provided by via the DT phandle?
 

All those clocks are identically named across the OMAP SoCs and are unique for 
each
SoC, so providing DT phandle for all of them is not required.

The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need 
for
this binding.

 Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
 driver? This would potentially remove the need of the init_60m_fclk name.
 

If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 as
well to explicitly provide the clock phandle. For now we make use of the fact 
that
SoC clock data names the clock rightly i.e. init_60m_fclk.

 $ grep clk_get drivers/mfd/omap-usb-host.c
 omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
 omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk);
 omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk);
 omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck);
 omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck);
 omap-init_60m_fclk = clk_get(dev, init_60m_fclk);
 omap-utmi_clk[i] = clk_get(dev, clkname);
 omap-hsic480m_clk[i] = clk_get(dev, clkname);
 omap-hsic60m_clk[i] = clk_get(dev, clkname);
 

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Roger Quadros]

Hi Mark,

On 01/08/2014 03:26 PM, Mark Rutland wrote:
 On Wed, Jan 08, 2014 at 06:15:38AM +, Roger Quadros wrote:
 The omap-usb-host driver expects the 60MHz functional clock
 of the USB host module to be named as init_60m_fclk.
 Add this information in the DT binding document.

 CC: Lee Jones lee.jo...@linaro.org
 CC: Samuel Ortiz sa...@linux.intel.com
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4 
  1 file changed, 4 insertions(+)

 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
 b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 index b381fa6..5635202 100644
 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 @@ -32,6 +32,10 @@ Optional properties:
  - single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
  
 +- clocks: phandle to 60MHz functional clock to the USB Host module.
 +
 +- clock-names: must be init_60m_fclk
 +
 
 Nit: clocks aren't just phandles, there's a clock-specifier too.
 
 Also, it would be nicer if clocks was defined in terms of clock-names,
 as it makes the relationship between clocks and clock-names clear, and
 makes it easier to extend the list in future. Something like:
 
 - clocks: a list of phandles + clock-specifiers, one for each entry in
   clock-names
 
 - clock-names: should include:
   * init_60m_fclk - the 60MHz functional clock to the USB host module.
 

OK, I'll update it as per your suggestion.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Arnd Bergmann]

On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
  What about the other clocks acquired in drivers/mfd/omap-usb-host.c? 
  Shouldn't
  all of those be provided by via the DT phandle?
  
 
 All those clocks are identically named across the OMAP SoCs and are unique 
 for each
 SoC, so providing DT phandle for all of them is not required.
 
 The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need 
 for
 this binding.

What do you mean it was renamed? Is it a different version of the omap-usb-host
device then?

  Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
  driver? This would potentially remove the need of the init_60m_fclk name.
  
 
 If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 
 as
 well to explicitly provide the clock phandle. For now we make use of the fact 
 that
 SoC clock data names the clock rightly i.e. init_60m_fclk.

I'm getting the feeling that init_60m_fclk is not the name of the clock input
of the omap-usb-host device at all, but rather the name of a signal on the
omap soc, which would not be an appropriate identifier for the binding.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Roger Quadros]

On 01/08/2014 03:49 PM, Arnd Bergmann wrote:
 On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
 What about the other clocks acquired in drivers/mfd/omap-usb-host.c? 
 Shouldn't
 all of those be provided by via the DT phandle?


 All those clocks are identically named across the OMAP SoCs and are unique 
 for each
 SoC, so providing DT phandle for all of them is not required.

 The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the 
 need for
 this binding.
 
 What do you mean it was renamed? Is it a different version of the 
 omap-usb-host
 device then?

I meant the clock gates name on the SoC was renamed. The omap-usb-host device 
version
is revised as well.

 Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
 driver? This would potentially remove the need of the init_60m_fclk name.


 If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and 
 OMAP3 as
 well to explicitly provide the clock phandle. For now we make use of the 
 fact that
 SoC clock data names the clock rightly i.e. init_60m_fclk.
 
 I'm getting the feeling that init_60m_fclk is not the name of the clock input
 of the omap-usb-host device at all, but rather the name of a signal on the
 omap soc, which would not be an appropriate identifier for the binding.

It is a clock gate defined like so in the DT clock data

on OMAP4
init_60m_fclk: init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};

on OMAP5
l3init_60m_fclk: l3init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};

So you can see that it is the same thing with a different name.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Arnd Bergmann]

On Wednesday 08 January 2014 15:57:19 Roger Quadros wrote:
 It is a clock gate defined like so in the DT clock data
 
 on OMAP4
 init_60m_fclk: init_60m_fclk {
 #clock-cells = 0;
 compatible = ti,divider-clock;
 clocks = dpll_usb_m2_ck;
 reg = 0x0104;
 ti,dividers = 1, 8;
 };
 
 on OMAP5
 l3init_60m_fclk: l3init_60m_fclk {
 #clock-cells = 0;
 compatible = ti,divider-clock;
 clocks = dpll_usb_m2_ck;
 reg = 0x0104;
 ti,dividers = 1, 8;
 };
 
 So you can see that it is the same thing with a different name.

Right, but init_60m_fclk is the name of the clock output of the
divider here, which is /not/ what you should put in the clock-names
property of the consumer. The clock input name should reflect what
the clock is used for instead.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Sebastian Reichel]

Hi,

On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
  What about the other clocks acquired in drivers/mfd/omap-usb-host.c? 
  Shouldn't
  all of those be provided by via the DT phandle?
 
 All those clocks are identically named across the OMAP SoCs and are unique 
 for each
 SoC, so providing DT phandle for all of them is not required.
 
 The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need 
 for
 this binding.

I understand the intention of this patch. I was just wondering if
all the clocks should be referenced from DT even if that is not
strictly needed at the moment. This would make clocks similar to
other resources like regulators, gpios, irqs, ...

Having the clocks referenced from DT looks cleaner to me. It means I
can check the DT file for any resources used by a driver. It also
creates some kind of consistency in the kernel.

  Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
  driver? This would potentially remove the need of the init_60m_fclk name.
 
 If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 
 as
 well to explicitly provide the clock phandle.

I'm aware of this.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Arnd Bergmann]

On Wednesday 08 January 2014 11:52:44 Sebastian Reichel wrote:
 
 On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
   What about the other clocks acquired in drivers/mfd/omap-usb-host.c? 
   Shouldn't
   all of those be provided by via the DT phandle?
  
  All those clocks are identically named across the OMAP SoCs and are unique 
  for each
  SoC, so providing DT phandle for all of them is not required.
  
  The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the 
  need for
  this binding.
 
 I understand the intention of this patch. I was just wondering if
 all the clocks should be referenced from DT even if that is not
 strictly needed at the moment. This would make clocks similar to
 other resources like regulators, gpios, irqs, ...
 
 Having the clocks referenced from DT looks cleaner to me. It means I
 can check the DT file for any resources used by a driver. It also
 creates some kind of consistency in the kernel.

I think that would be best, yes. AFAIK most other platforms do this
already, OMAP is a bit behind because it started using clocks when the
infrastructure for doing this right was still incomplete.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Roger Quadros]

On 01/08/2014 04:10 PM, Arnd Bergmann wrote:
 On Wednesday 08 January 2014 15:57:19 Roger Quadros wrote:
 It is a clock gate defined like so in the DT clock data

 on OMAP4
 init_60m_fclk: init_60m_fclk {
 #clock-cells = 0;
 compatible = ti,divider-clock;
 clocks = dpll_usb_m2_ck;
 reg = 0x0104;
 ti,dividers = 1, 8;
 };

 on OMAP5
 l3init_60m_fclk: l3init_60m_fclk {
 #clock-cells = 0;
 compatible = ti,divider-clock;
 clocks = dpll_usb_m2_ck;
 reg = 0x0104;
 ti,dividers = 1, 8;
 };

 So you can see that it is the same thing with a different name.
 
 Right, but init_60m_fclk is the name of the clock output of the
 divider here, which is /not/ what you should put in the clock-names
 property of the consumer. The clock input name should reflect what
 the clock is used for instead.

Ah, now I get it. :). I agree that the name should reflect the function.

Looking more closely, the driver doesn't enable/disable the init_60m_fclk but 
just
uses it to configure the parent of utmi_p1_gfclk which is a clock input to the
USB module. 

Based on this I would call it refclk_int for internal reference clock.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Roger Quadros]

On 01/08/2014 04:25 PM, Arnd Bergmann wrote:
 On Wednesday 08 January 2014 11:52:44 Sebastian Reichel wrote:

 On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
 What about the other clocks acquired in drivers/mfd/omap-usb-host.c? 
 Shouldn't
 all of those be provided by via the DT phandle?

 All those clocks are identically named across the OMAP SoCs and are unique 
 for each
 SoC, so providing DT phandle for all of them is not required.

 The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the 
 need for
 this binding.

 I understand the intention of this patch. I was just wondering if
 all the clocks should be referenced from DT even if that is not
 strictly needed at the moment. This would make clocks similar to
 other resources like regulators, gpios, irqs, ...

 Having the clocks referenced from DT looks cleaner to me. It means I
 can check the DT file for any resources used by a driver. It also
 creates some kind of consistency in the kernel.
 
 I think that would be best, yes. AFAIK most other platforms do this
 already, OMAP is a bit behind because it started using clocks when the
 infrastructure for doing this right was still incomplete.
 

OK. I'll update the binding information to reflect all the clocks.

But what about clk_get() vs of_clk_get_by_name() ?

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Arnd Bergmann]

On Wednesday 08 January 2014, Roger Quadros wrote:
 OK. I'll update the binding information to reflect all the clocks.
 
 But what about clk_get() vs of_clk_get_by_name() ?

I think the convention these days is to just use clk_get(), which calls
of_clk_get_by_name() internally. Not sure if that's what you are asking.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

[Roger Quadros]

On 01/08/2014 05:05 PM, Arnd Bergmann wrote:
 On Wednesday 08 January 2014, Roger Quadros wrote:
 OK. I'll update the binding information to reflect all the clocks.

 But what about clk_get() vs of_clk_get_by_name() ?
 
 I think the convention these days is to just use clk_get(), which calls
 of_clk_get_by_name() internally. Not sure if that's what you are asking.


OK fine. I'll continue to use clk_get() then.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method

[Marc Kleine-Budde]

On 01/08/2014 01:23 AM, Greg KH wrote:
 On Mon, Jan 06, 2014 at 10:10:41AM +0800, Peter Chen wrote:
 According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
 register error issue, All USB register write operations must
 use the ARM SWP instruction. So, we implement a special ehci_write
 for imx28.

 Discussion for it at below:
 http://marc.info/?l=linux-usbm=137996395529294w=2

 Signed-off-by: Peter Chen peter.c...@freescale.com
 Acked-by: Alan Stern st...@rowland.harvard.edu
 Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
 Tested-by: Marc Kleine-Budde m...@pengutronix.de
 ---
  drivers/usb/host/ehci.h |   18 +-
  1 files changed, 17 insertions(+), 1 deletions(-)

 diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
 index c35a6e2b..e26099b 100644
 --- a/drivers/usb/host/ehci.h
 +++ b/drivers/usb/host/ehci.h
 @@ -225,6 +225,7 @@ struct ehci_hcd {/* one per 
 controller */
  unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
  unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
  unsignedneed_oc_pp_cycle:1; /* MPC834X port power */
 +unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
  
  /* required for usb32 quirk */
  #define OHCI_CTRL_HCFS  (3  6)
 @@ -728,6 +729,18 @@ static inline unsigned int ehci_readl(const struct 
 ehci_hcd *ehci,
  #endif
  }
  
 +#ifdef CONFIG_SOC_IMX28
 +static inline void imx28_ehci_writel(const unsigned int val,
 +volatile __u32 __iomem *addr)
 +{
 +__asm__ (swp %0, %0, [%1] : : r(val), r(addr));
 +}
 +#else
 +static inline void imx28_ehci_writel(const unsigned int val,
 +volatile __u32 __iomem *addr)
 +{
 +}
 +#endif
  static inline void ehci_writel(const struct ehci_hcd *ehci,
  const unsigned int val, __u32 __iomem *regs)
  {
 @@ -736,7 +749,10 @@ static inline void ehci_writel(const struct ehci_hcd 
 *ehci,
  writel_be(val, regs) :
  writel(val, regs);
  #else
 -writel(val, regs);
 +if (IS_ENABLED(CONFIG_SOC_IMX28)  ehci-imx28_write_fix)
 +imx28_ehci_writel(val, regs);
 +else
 +writel(val, regs);
  #endif
 
 This IS_ENABLED() isn't needed at all, so please remove it.

It's an optimisation for the hot path, if kernel isn't build for a mx28
the newly added if() is completely optimized out. The same argument
applies to the next patch.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.

[tatxarata]

On 01/08/2014 01:59 PM, David Laight wrote:

From: tatxarata
Since reporting this bug I've invested some time to get myself familiar
with USB protocol and analyzed attached capture files. It seems like
device resetoccurs after device returns urb_status=-75 (-EOVERFLOW).

...

In case of USB2.0 host-device traffic looks pretty the same way as in
case of USB3.0. Host also tries to read device by chunks of 240 sectors
and device returns only 120. However for some reason this doesn't lead
to EOVERFLOW.


Is that using ehci, or forcing xhci to run at USB2 speeds (eg by using
a USB2 extension cable)?

David



USB2.0 case was tested with ehci. Luckily my notebook has dedicated 
USB2.0 port.

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] xhci: Switch Intel Lynx Point ports to EHCI on shutdown

[Denis Turischev]

On 01/08/2014 01:11 AM, Sarah Sharp wrote:
 Denis, what do you mean by works for Lynx Point?  Do you mean that
 adding the quirk to switch the ports on EHCI on shutdown (e95829f474)
 for the Intense-PC2 *instead of* the commit to put the host in D3 on
 shutdown (638298dc66) works?  Or do you mean you need both patches for
 your system?
 
 If you only need the quirk to switch the ports to EHCI on shutdown, then
 we could apply that broadly to Lynx Point LP, and see whether other
 BIOSes tolerate that quirk.

Yes, switching the ports on EHCI on shutdown is enough for Intense-PC2.
I don't need both patches.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC

[Andreas Larsson]

On 2014-01-06 17:22, Mark Rutland wrote:

Hi,

Apologies for the late reply, I wasn't able to access my mail much over
the Christmas break.


The patch is already applied to both the next branch of Felipe Balbi's 
usb/next branch and merged from there into Greg Kroah-Hartman's 
usb/usb-next branch, so it might be too late for including in the 
initial patch.


I'll be happy to send a patch series to improve things as indicated 
inline below. There are no functional bugs running on SPARC which is the 
ordinary environment for this core, so adding patches to do these 
improvements should work fine.




On Mon, Dec 23, 2013 at 08:25:49PM +, Andreas Larsson wrote:

This adds an UDC driver for GRUSBDC USB Device Controller cores available in the
GRLIB VHDL IP core library. The driver only supports DMA mode.

Signed-off-by: Andreas Larsson andr...@gaisler.com
---

Differences since v1:
- Use hexprint for debug printoutes instead of homemade equivalent
- Use the dev_* printk variants over the board
- Get rid of unnecessary casts and includes
- Use USB_STATE_NOTATTACHED instead of USB_STATE_ATTACHED for clarity
- Get rid of commented out VERBOSE_DEBUG definition
- Do not devm-allocate any requests
- Get rid of unnecessary resqueduling of the workqueue handler
- Make sure that gadget setup function is called with interrupts disabled
Differences since v2:
- Fixed an error printout
- Got rid of the work queue in favor of threaded interrupts
Differences since v3:
- Disable interrupts when locking spinlocks instead of using
   local_irq_save deeper within critical section
Differences since v4:
- Set quirk_ep_out_aligned_size
- Use usb_ep_set_maxpacket_limit
- Add devicetree documentation
Differences since v5:
- Declare unexpected spin_unlock and spin_lock for sparse
- Fix a bad comment
- Use ACCESS_ONCE instead of gr_read32 when checking for update of dma 
descriptor

  Documentation/devicetree/bindings/usb/gr-udc.txt |   28 +
  drivers/usb/gadget/Kconfig   |7 +
  drivers/usb/gadget/Makefile  |1 +
  drivers/usb/gadget/gr_udc.c  | 2242 ++
  drivers/usb/gadget/gr_udc.h  |  220 +++
  5 files changed, 2498 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/gr-udc.txt
  create mode 100644 drivers/usb/gadget/gr_udc.c
  create mode 100644 drivers/usb/gadget/gr_udc.h

diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt 
b/Documentation/devicetree/bindings/usb/gr-udc.txt
new file mode 100644
index 000..0c5118f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/gr-udc.txt
@@ -0,0 +1,28 @@
+USB Peripheral Controller driver for Aeroflex Gaisler GRUSBDC.
+
+The GRUSBDC USB Device Controller core is available in the GRLIB VHDL
+IP core library.
+
+Note: In the ordinary environment for the core, a Leon SPARC system,
+these properties are built from information in the AMBA plugplay.
+
+Required properties:
+
+- name : Should be GAISLER_USBDC or 01_021


What's this for?

Why is this not matched using a compatible string?

What does 01_021 mean?


Regarding using name, this is standard for SPARC. The names in the
device tree originates from the PROM.

The name field is the actually the first field checked for a match in
of_match_node, followed by type then compatible. See
http://lxr.free-electrons.com/source/drivers/of/base.c?v=3.12#L723

Examples can be found among others in:
- drivers/watchdog/riowd.c
- drivers/watchdog/cpwd.c
- drivers/mtd/maps/sun_uflash.c
- drivers/input/misc/sparcspkr.c
- drivers/input/serio/i8042-sparcio.h
- drivers/hwmon/ultra45_env.c

As for the 01_021, the LEON SPARC systems uses a plugplay to identify
different IP cores in the system. When the PROM is unaware of the name
of a certain core, the name field presented from the PROM will be on
this form. This is standard handling for LEON SPARC drivers.
Examples of this can be found in:
- drivers/gpio/gpio-grgpio.c
- drivers/usb/host/uhci-grlib.c
- drivers/usb/host/ehci-grlib.c
- drivers/video/grvga.c
- drivers/net/can/grcan.c
- drivers/net/ethernet/aeroflex/greth.c
- drivers/tty/serial/apbuart.c
- drivers/gpio/gpio-grgpio.c



+
+- reg : Address and length of the register set for the device
+
+- interrupts : Interrupt numbers for this device


How many, and what do they correspond to?


I'll add text on that




+
+Optional properties:
+
+- epobufsizes : An array of buffer sizes for OUT endpoints. If the property is
+   not present, or for endpoints outside of the array, 1024 is assumed by
+   the driver.
+
+- epibufsizes : An array of buffer sizes for IN endpoints. If the property is
+   not present, or for endpoints outside of the array, 1024 is assumed by
+   the driver.


These names are rather opaque. Something like {input,output}-buf-lens
would be far clearer.


Unless Felipe wants to merge with the original patch I don't think it is 
a good idea to have the property name change from 

Re: [PATCH v6] usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC

[Mark Rutland]

On Wed, Jan 08, 2014 at 01:23:04PM +, Andreas Larsson wrote:
 On 2014-01-06 17:22, Mark Rutland wrote:
  Hi,
 
  Apologies for the late reply, I wasn't able to access my mail much over
  the Christmas break.
 
 The patch is already applied to both the next branch of Felipe Balbi's 
 usb/next branch and merged from there into Greg Kroah-Hartman's 
 usb/usb-next branch, so it might be too late for including in the 
 initial patch.
 
 I'll be happy to send a patch series to improve things as indicated 
 inline below. There are no functional bugs running on SPARC which is the 
 ordinary environment for this core, so adding patches to do these 
 improvements should work fine.
 
 
  On Mon, Dec 23, 2013 at 08:25:49PM +, Andreas Larsson wrote:
  This adds an UDC driver for GRUSBDC USB Device Controller cores available 
  in the
  GRLIB VHDL IP core library. The driver only supports DMA mode.
 
  Signed-off-by: Andreas Larsson andr...@gaisler.com
  ---
 
  Differences since v1:
  - Use hexprint for debug printoutes instead of homemade equivalent
  - Use the dev_* printk variants over the board
  - Get rid of unnecessary casts and includes
  - Use USB_STATE_NOTATTACHED instead of USB_STATE_ATTACHED for clarity
  - Get rid of commented out VERBOSE_DEBUG definition
  - Do not devm-allocate any requests
  - Get rid of unnecessary resqueduling of the workqueue handler
  - Make sure that gadget setup function is called with interrupts disabled
  Differences since v2:
  - Fixed an error printout
  - Got rid of the work queue in favor of threaded interrupts
  Differences since v3:
  - Disable interrupts when locking spinlocks instead of using
 local_irq_save deeper within critical section
  Differences since v4:
  - Set quirk_ep_out_aligned_size
  - Use usb_ep_set_maxpacket_limit
  - Add devicetree documentation
  Differences since v5:
  - Declare unexpected spin_unlock and spin_lock for sparse
  - Fix a bad comment
  - Use ACCESS_ONCE instead of gr_read32 when checking for update of dma 
  descriptor
 
Documentation/devicetree/bindings/usb/gr-udc.txt |   28 +
drivers/usb/gadget/Kconfig   |7 +
drivers/usb/gadget/Makefile  |1 +
drivers/usb/gadget/gr_udc.c  | 2242 
  ++
drivers/usb/gadget/gr_udc.h  |  220 +++
5 files changed, 2498 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/gr-udc.txt
create mode 100644 drivers/usb/gadget/gr_udc.c
create mode 100644 drivers/usb/gadget/gr_udc.h
 
  diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt 
  b/Documentation/devicetree/bindings/usb/gr-udc.txt
  new file mode 100644
  index 000..0c5118f
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/usb/gr-udc.txt
  @@ -0,0 +1,28 @@
  +USB Peripheral Controller driver for Aeroflex Gaisler GRUSBDC.
  +
  +The GRUSBDC USB Device Controller core is available in the GRLIB VHDL
  +IP core library.
  +
  +Note: In the ordinary environment for the core, a Leon SPARC system,
  +these properties are built from information in the AMBA plugplay.
  +
  +Required properties:
  +
  +- name : Should be GAISLER_USBDC or 01_021
 
  What's this for?
 
  Why is this not matched using a compatible string?
 
  What does 01_021 mean?
 
 Regarding using name, this is standard for SPARC. The names in the
 device tree originates from the PROM.
 
 The name field is the actually the first field checked for a match in
 of_match_node, followed by type then compatible. See
 http://lxr.free-electrons.com/source/drivers/of/base.c?v=3.12#L723
 
 Examples can be found among others in:
 - drivers/watchdog/riowd.c
 - drivers/watchdog/cpwd.c
 - drivers/mtd/maps/sun_uflash.c
 - drivers/input/misc/sparcspkr.c
 - drivers/input/serio/i8042-sparcio.h
 - drivers/hwmon/ultra45_env.c
 
 As for the 01_021, the LEON SPARC systems uses a plugplay to identify
 different IP cores in the system. When the PROM is unaware of the name
 of a certain core, the name field presented from the PROM will be on
 this form. This is standard handling for LEON SPARC drivers.
 Examples of this can be found in:
 - drivers/gpio/gpio-grgpio.c
 - drivers/usb/host/uhci-grlib.c
 - drivers/usb/host/ehci-grlib.c
 - drivers/video/grvga.c
 - drivers/net/can/grcan.c
 - drivers/net/ethernet/aeroflex/greth.c
 - drivers/tty/serial/apbuart.c
 - drivers/gpio/gpio-grgpio.c

OK. Sorry for the confusion there.

 
 
  +
  +- reg : Address and length of the register set for the device
  +
  +- interrupts : Interrupt numbers for this device
 
  How many, and what do they correspond to?
 
 I'll add text on that
 
 
  +
  +Optional properties:
  +
  +- epobufsizes : An array of buffer sizes for OUT endpoints. If the 
  property is
  +   not present, or for endpoints outside of the array, 1024 is 
  assumed by
  +   the driver.
  +
  +- epibufsizes : An array of buffer sizes for IN endpoints. If the 
  property is
  +   

Re: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method

[Greg KH]

On Wed, Jan 08, 2014 at 12:54:25PM +0100, Marc Kleine-Budde wrote:
 On 01/08/2014 01:23 AM, Greg KH wrote:
  On Mon, Jan 06, 2014 at 10:10:41AM +0800, Peter Chen wrote:
  According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
  register error issue, All USB register write operations must
  use the ARM SWP instruction. So, we implement a special ehci_write
  for imx28.
 
  Discussion for it at below:
  http://marc.info/?l=linux-usbm=137996395529294w=2
 
  Signed-off-by: Peter Chen peter.c...@freescale.com
  Acked-by: Alan Stern st...@rowland.harvard.edu
  Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
  Tested-by: Marc Kleine-Budde m...@pengutronix.de
  ---
   drivers/usb/host/ehci.h |   18 +-
   1 files changed, 17 insertions(+), 1 deletions(-)
 
  diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
  index c35a6e2b..e26099b 100644
  --- a/drivers/usb/host/ehci.h
  +++ b/drivers/usb/host/ehci.h
  @@ -225,6 +225,7 @@ struct ehci_hcd {  /* one per 
  controller */
 unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
 unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
 unsignedneed_oc_pp_cycle:1; /* MPC834X port power */
  +  unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
   
 /* required for usb32 quirk */
 #define OHCI_CTRL_HCFS  (3  6)
  @@ -728,6 +729,18 @@ static inline unsigned int ehci_readl(const struct 
  ehci_hcd *ehci,
   #endif
   }
   
  +#ifdef CONFIG_SOC_IMX28
  +static inline void imx28_ehci_writel(const unsigned int val,
  +  volatile __u32 __iomem *addr)
  +{
  +  __asm__ (swp %0, %0, [%1] : : r(val), r(addr));
  +}
  +#else
  +static inline void imx28_ehci_writel(const unsigned int val,
  +  volatile __u32 __iomem *addr)
  +{
  +}
  +#endif
   static inline void ehci_writel(const struct ehci_hcd *ehci,
 const unsigned int val, __u32 __iomem *regs)
   {
  @@ -736,7 +749,10 @@ static inline void ehci_writel(const struct ehci_hcd 
  *ehci,
 writel_be(val, regs) :
 writel(val, regs);
   #else
  -  writel(val, regs);
  +  if (IS_ENABLED(CONFIG_SOC_IMX28)  ehci-imx28_write_fix)
  +  imx28_ehci_writel(val, regs);
  +  else
  +  writel(val, regs);
   #endif
  
  This IS_ENABLED() isn't needed at all, so please remove it.
 
 It's an optimisation for the hot path, if kernel isn't build for a mx28
 the newly added if() is completely optimized out. The same argument
 applies to the next patch.

If the kernel isn't built for mx28 then the if statment goes away
without the IS_ENABLED() call as well, due to the empty inline
function, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] xhci: Allocate the td array and urb_priv together.

['David Cohen']

On Wed, Jan 08, 2014 at 09:25:42AM +, David Laight wrote:
  From: 'David Cohen'
 ...
The new kmalloc is going to be n * sizeof(struct) - n * 
sizeof(pointer)
bigger. I don't know what is the usual range of values for n, but my
experience with android devices with non-abundant memory size is that
they are sensible to kmalloc  PAGE_SIZE.
  
   It is much easier to assume that we are keeping the second malloc
   are getting rid of the first one. The header is only one pointer.
  
  The header is not only one pointer. I believe the most relevant changes
  from your patch happen here:
 
 My memory failed me - the 8 bytes are the two integers.
 
  --- a/drivers/usb/host/xhci.h
  +++ b/drivers/usb/host/xhci.h
  @@ -1363,7 +1363,7 @@ struct xhci_scratchpad {
   struct urb_priv {
  int length;
  int td_cnt;
  -   struct  xhci_td *td[0];
  +   struct  xhci_td td[0];
   };
  
  This is a dynamic array. It's not 1 pointer, it's how many you want it
  to be...
 
 Yes, but each of the original td[] entries pointed to consecutive
 entries of the original second malloc.
 Maybe, at some point, they were each allocated separately.
 
  sizeof(struct urb_priv) does not consider the dynamic array at all, then
  you have the second value size * sizeof(struct xhci_td *) where size
  is the number of pointers you're going to have in the dynamic array.
  By doing your change you're increasing in the size of kmalloc in
  size * (sizeof(struct xhci_td) - sizeof(struct xhci_td *)) bytes.
 
 Yes, but I'm removing a kmalloc of size * (sizeof (struct xhci_td)).
 
 As I keep saying, I've moved the 'length' and 'td_cnt' fields to the
 start of kmalloc that contains the actual data and completely removed
 the allocation of an array of pointers (and all the code that dereferences
 them).

Of course. I should had paid more attention to struct urb_priv content :)

 
 sizeof (struct xhci_td) is something like 32, certainly less than 64 bytes.
 So you need a moderate 'td_cnt' for the kmalloc to exceed a page size.

I actually don't know what's the regular range of 'td_cnt'. But what got my
attention was this comment from patch description:

The only possible downside is for isochronous tranfers with 64 td
when the allocate is 8+4096 bytes (on 64bit systems) so requires
an additional page.

My experience says even if you keep the pointers in first kmalloc but
let both  PAGE_SIZE, android device will still behave better.

Br, David Cohen

 
   David
 
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] xhci: Allocate the td array and urb_priv together.

[David Laight]

 From: 'David Cohen'
...
 I actually don't know what's the regular range of 'td_cnt'. But what got my
 attention was this comment from patch description:
 
 The only possible downside is for isochronous tranfers with 64 td
 when the allocate is 8+4096 bytes (on 64bit systems) so requires
 an additional page.

I wrote that just in case anyone knew that 64 td would be common.
I suspect the typical number is much lower.

David



--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()

[Alan Stern]

On Tue, 7 Jan 2014, Greg KH wrote:

 On Tue, Jan 07, 2014 at 05:44:26PM -0800, David Cohen wrote:
  From: jianqian jianqiang.t...@intel.com
  
  There is a possible kernel panic faced on xhci_suspend().
  Due to kernel modified the hub autosupend_delay to 0s, after usb1 root
  hub finishes initialization, it will trigger runtime_suspend and then
  it will trigger xhci runtime suspend. But at that time, if
  xhci-shared_hcd is still doing initialization, it is possible to face
  null pointer kernel panic in xhci_suspend() function.
  
  This patch checks if xhci-shared_hcd is null to avoid panic.
 
 That sounds like this is a race that should be fixed properly, not just
 papered over, right?

That was my reaction too.  The best way to solve the problem is to 
prevent the USB-2 root hub from suspending until after the USB-3 root 
hub has been registered.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device

[Peter Palúch]

Greetings,

Regarding the issue with WD MyBook 1230 stalling and being reset when 
connected to an HP EliteBook 8560p, I have tested the 3.13-rc7 kernel 
from kernel.org to no avail - the drive still stalls and is reset after 
a couple of seconds. I am attaching a dmesg output (relevant lines 
regarding the drive and the xHCI reset are at the end) and the usbmon 
trace. The lspci and lsusb outputs have been attached to the original 
mail I've opened this thread with (if necessary, I will gladly repost them).


The usbmon trace covers the complete session with the drive, starting 
with its connection to my USB 3.0 slot, then accessing the drive with 
gdisk -l /dev/sdb, across its stall and reset, up to its physical 
disconnection.


The actual transcript of the communication with the drive that ensued 
after the gdisk -l /dev/sdb command that led to the stall starts at 
the decimal offset 82582 in the usbmon trace file.


Thank you!

Best regards,
Peter



files.tar.bz2
Description: application/bzip

Re: Alcatel usb modem

[Lars Melin]

On 2014-01-02 23:59, Dan Williams wrote:

On Sun, 2013-12-29 at 15:35 +0700, Lars Melin wrote:

On 2013-12-29 00:55, Greg KH wrote:

On Sat, Dec 28, 2013 at 02:13:08PM +, thomas.takacs.a...@gmail.com wrote:

Hi,
I've seen this message: tell linux-usb... to add your device to a proper device.
My USB modem is Alcatel One Touch X080C.
Please kindly add it or inform me how can I fix it.

What is the full message that is printed out?  What is the vendor and
device id of this device?  You are using the module parameters to add a
device id to the usb-serial module, we can add the id to the proper
driver if we know the ids of it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alcatel X085C  1bbb:0012

%DEVICE1BBB0012% = Modem6k, USB\VID_1BBBPID_0012MI_00
%DEVICE1BBB0012% = OEMportInstall6k, USB\VID_1BBBPID_0012MI_01
%DEVICE1BBB0012% = OEMportInstall6k, USB\VID_1BBBPID_0012MI_02
%DEVICE1BBB0012% = OEMportInstallSound, USB\VID_1BBBPID_0012MI_03

The 6k indicates that it's likely a Qualcomm-based device like other
Alcatel/TCT.  I would add the Modem, Service, and AT ports to the
'option' driver using USB inteface numbers (eg,
USB_DEVICE_INTERFACE_NUMBER using the MI_0x number).  Don't bind the
Voice port since it's likely not a serial port.


DEVICE1BBB0012 = ALCATEL CDMA Modem USB Modem
DEVICE1BBB0012 = ALCATEL CDMA Modem Service Port
DEVICE1BBB0012 = ALCATEL CDMA Modem AT Port
DEVICE1BBB0012 = ALCATEL CDMA Modem Voice Port


Alcatel X080C 1bbb:00ca

%DEVICE1BBB00CA% = Modem6k, USB\VID_1BBBPID_00CAMI_00
%DEVICE1BBB00CA% = OEMportInstall6k, USB\VID_1BBBPID_00CAMI_01
%DEVICE1BBB00CA% = OEMportInstall6k, USB\VID_1BBBPID_00CAMI_02
%DEVICE1BBB00CA% = OEMportInstallSound, USB\VID_1BBBPID_00CAMI_03

DEVICE1BBB00CA = Modem X080C CDMA Modem USB Modem
DEVICE1BBB00CA = Modem X080C CDMA Modem Service Port  (Diag)
DEVICE1BBB00CA = Modem X080C CDMA Modem AT Port
DEVICE1BBB00CA = Modem X080C CDMA Modem Voice Port

Same here.  Bind 'option' to the device's Modem, Service, and AT ports
by USB interface number but leave Voice alone.

Dan


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




The Voice Port is afaik serialised PCM data and the interface is present 
in other option supported

Alcatel dongles made by TA Mobile Phones without being blacklisted.
It's up to you or Greg K-H to decide, the info from Windows .inf file I 
posted above was in response

to his request for more info which the reporter couldn't provide.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/2] dual scan thread bug fix

[Alan Stern]

On Wed, 8 Jan 2014, James Bottomley wrote:

 OK, Agreed, but that means modifying the 1/2 patch with the below.  This
 should make the proposed diff to 2/2 correct.
 
 James
 
 ---
 diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
 index ef3f958..5fad646 100644
 --- a/drivers/scsi/scsi_scan.c
 +++ b/drivers/scsi/scsi_scan.c
 @@ -417,7 +417,7 @@ static struct scsi_target *scsi_alloc_target(struct 
 device *parent,
   + shost-transportt-target_size;
   struct scsi_target *starget;
   struct scsi_target *found_target;
 - int error;
 + int error, ref_got;
  
   starget = kzalloc(size, GFP_KERNEL);
   if (!starget) {
 @@ -466,15 +466,15 @@ static struct scsi_target *scsi_alloc_target(struct 
 device *parent,
   return starget;
  
   found:
 - if (!kref_get_unless_zero(found_target-reap_ref))
 - /*
 -  * release routine already fired.  Target is dead, but
 -  * STARGET_DEL may not yet be set (set in the release
 -  * routine), so set here as well, just in case
 -  */
 - found_target-state = STARGET_DEL;
 + /*
 +  * release routine already fired if kref is zero, so if we can still
 +  * take the reference, the target must be alive.  If we can't, it must
 +  * be dying and we need to wait for a new target
 +  */
 + ref_got = kref_get_unless_zero(found_target-reap_ref);
 +
   spin_unlock_irqrestore(shost-host_lock, flags);
 - if (found_target-state != STARGET_DEL) {
 + if (ref_got) {
   put_device(dev);
   return found_target;
   }
 @@ -482,8 +482,8 @@ static struct scsi_target *scsi_alloc_target(struct 
 device *parent,
* Unfortunately, we found a dying target; need to wait until it's
* dead before we can get a new one.  There is an anomaly here.  We
* *should* call scsi_target_reap() to balance the kref_get() of the
 -  * reap_ref above.  However, since the target is in state STARGET_DEL,
 -  * it's already invisible and the reap_ref is irrelevant.  If we call
 +  * reap_ref above.  However, since the target being released, it's
 +  * already invisible and the reap_ref is irrelevant.  If we call
* scsi_target_reap() we might spuriously do another device_del() on
* an already invisible target.
*/

In fact, most of this comment (everything after the first sentence) is
no longer needed.  If the target is dying then kref_get_unless_zero
must have failed, so there is no need to worry about unbalanced
refcounts.

Otherwise this looks good.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ohci-platform: Add support for devicetree instantiation

[Hans de Goede]

Hi,

On 01/06/2014 08:50 AM, Hans de Goede wrote:

snip


Otherwise you don't know the difference between no clock
provided, error getting the clock reference and clock controller not
initialized yet, try again.


I guess of these 3 we really only want to continue on no clock provided,
so I think something like this (for both clks and the phy) would be best:

 priv-ahb_clk = devm_clk_get(dev-dev, ahb);
 if (IS_ERR(priv-ahb_clk)) {
 err = PTR_ERR(priv-ahb_clk);
 if (err != -EINVAL  err != -ENODATA)
 goto err_put_hcd;
 priv-ahb_clk = NULL; /* No clock provided */
 }

To clarify -EINVAL will be returned when there is no clock-names, and
-ENODATA when the specified name is not found in clock-names.


Ok, so I've got this wrong, if there is no clk by that name specified
in dt -ENOENT will be returned. Actually -ENOENT is the only
error clk_get and thus devm_clk_get will ever return.

So it seems that clk_get currently is not properly passing along
probe-deferral. To make things future proof I will add a probe
deferral check to the next version of my patch.

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

[David Laight]

 From: Sarah Sharp
 On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
  On 01/07/2014 01:21 PM, Sarah Sharp wrote:
 
   Can you please try the attached patch, on top of the previous three
   patches, and send me dmesg?
 
  Hi Sarah, I just now finished running 0001-More-debugging.patch for the
  first time.  The previous dmesg didn't include that patch, but this one
  does.
 
  I read through this dmesg but I nodded off somewhere around line 500.
  I hope you can stay awake :)
 
 Well, it has all the info I need, but the results don't make me too
 happy.  Everything I've checked seems consistent, and I don't know why
 the host stopped.  The link TRBs are intact, the dequeue pointer for the
 endpoint was pointing to the transfer that timed out and it had the
 cycle bit set correctly, etc.  Perhaps the no-op TRBs are really the
 issue.
 
 I'll have to take a look at the log again tomorrow.  I posted the dmesg
 on pastebin if David wants to check it out as well:
 http://pastebin.com/a4AUpsL1

I can't see anything obvious either.
However there is no response to the 'stop endpoint' command.
Section 4.6.9 (page 107 of rev1.0) states that the controller will complete
any USB IN or OUT transaction before raising the command completion event.
Possibly it is too 'stuck' to complete the transaction?

The endpoint status is also still '1' (running).
This also means that the 'TR dequeue pointer' is undefined - so the
controller could easily be processing a later TRB.
This field might even still contain the ring base address written by
the driver much earlier.

This might mean that something 'catastrophic' has happened earlier.
Maybe the controller isn't actually seeing any doorbell writes at all.
Maybe the base addresses it has for the rings have all got corrupted.
At least this looks like amd64 - so there aren't memory coherency issues.

Some hacks that might help isolate the problem:
1) Request an interrupt from the last nop data TRB.
2) Put a command nop (decimal 23) TRB into the command ring before
   the 'stop endpoint'.
3) Comment out the code that adds the nop data TRBs.
The first two might need code adding to handle the responses.

Do we know the actual xhci device?
I think it reports version 0x96.
(Sarah - it might be useful if that version were in one of the trace
messages that is output by default.)

David


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: delete non-required instances of include linux/init.h

[Paul Gortmaker]

None of these files are actually using any __init type directives
and hence don't need to include linux/init.h.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---

[build tested drivers/usb for allyes/modconfig on x86, x86-64
 and ARM; all on yesterday's usb-next in gregkh/usb.git ]

 drivers/usb/atm/cxacru.c | 1 -
 drivers/usb/atm/speedtch.c   | 1 -
 drivers/usb/atm/ueagle-atm.c | 1 -
 drivers/usb/class/usblp.c| 1 -
 drivers/usb/class/usbtmc.c   | 1 -
 drivers/usb/core/config.c| 1 -
 drivers/usb/core/message.c   | 1 -
 drivers/usb/core/urb.c   | 1 -
 drivers/usb/gadget/amd5536udc.c  | 1 -
 drivers/usb/gadget/at91_udc.c| 1 -
 drivers/usb/gadget/bcm63xx_udc.c | 1 -
 drivers/usb/gadget/epautoconf.c  | 1 -
 drivers/usb/gadget/fsl_qe_udc.c  | 1 -
 drivers/usb/gadget/goku_udc.c| 1 -
 drivers/usb/gadget/gr_udc.c  | 1 -
 drivers/usb/gadget/mv_u3d_core.c | 1 -
 drivers/usb/gadget/mv_udc_core.c | 1 -
 drivers/usb/gadget/omap_udc.c| 1 -
 drivers/usb/gadget/pxa25x_udc.c  | 1 -
 drivers/usb/gadget/rndis.c   | 1 -
 drivers/usb/gadget/usbstring.c   | 1 -
 drivers/usb/host/hwa-hc.c| 1 -
 drivers/usb/host/isp116x-hcd.c   | 1 -
 drivers/usb/host/isp1362-hcd.c   | 1 -
 drivers/usb/host/ohci-tmio.c | 1 -
 drivers/usb/host/oxu210hp-hcd.c  | 1 -
 drivers/usb/host/pci-quirks.c| 1 -
 drivers/usb/host/r8a66597-hcd.c  | 1 -
 drivers/usb/host/sl811-hcd.c | 1 -
 drivers/usb/host/sl811_cs.c  | 1 -
 drivers/usb/host/whci/int.c  | 1 -
 drivers/usb/host/whci/wusb.c | 1 -
 drivers/usb/image/microtek.c | 1 -
 drivers/usb/misc/adutux.c| 1 -
 drivers/usb/misc/cypress_cy7c63.c| 1 -
 drivers/usb/misc/cytherm.c   | 1 -
 drivers/usb/misc/emi26.c | 1 -
 drivers/usb/misc/emi62.c | 1 -
 drivers/usb/misc/ezusb.c | 1 -
 drivers/usb/misc/idmouse.c   | 1 -
 drivers/usb/misc/iowarrior.c | 1 -
 drivers/usb/misc/ldusb.c | 1 -
 drivers/usb/misc/legousbtower.c  | 1 -
 drivers/usb/misc/rio500.c| 1 -
 drivers/usb/misc/sisusbvga/sisusb_init.c | 1 -
 drivers/usb/misc/trancevibrator.c| 1 -
 drivers/usb/misc/usblcd.c| 1 -
 drivers/usb/misc/usbled.c| 1 -
 drivers/usb/misc/usbsevseg.c | 1 -
 drivers/usb/misc/yurex.c | 1 -
 drivers/usb/musb/am35x.c | 1 -
 drivers/usb/musb/blackfin.c  | 1 -
 drivers/usb/musb/da8xx.c | 1 -
 drivers/usb/musb/davinci.c   | 1 -
 drivers/usb/musb/musb_am335x.c   | 1 -
 drivers/usb/musb/musb_core.c | 1 -
 drivers/usb/musb/musb_dsps.c | 1 -
 drivers/usb/musb/musb_host.c | 1 -
 drivers/usb/musb/musb_virthub.c  | 1 -
 drivers/usb/musb/tusb6010.c  | 1 -
 drivers/usb/musb/tusb6010_omap.c | 1 -
 drivers/usb/musb/ux500.c | 1 -
 drivers/usb/phy/phy-fsl-usb.c| 1 -
 drivers/usb/phy/phy-mv-usb.c | 1 -
 drivers/usb/serial/ark3116.c | 1 -
 drivers/usb/serial/belkin_sa.c   | 1 -
 drivers/usb/serial/ch341.c   | 1 -
 drivers/usb/serial/console.c | 1 -
 drivers/usb/serial/cyberjack.c   | 1 -
 drivers/usb/serial/cypress_m8.c  | 1 -
 drivers/usb/serial/digi_acceleport.c | 1 -
 drivers/usb/serial/empeg.c   | 1 -
 drivers/usb/serial/f81232.c  | 1 -
 drivers/usb/serial/ftdi_sio.c| 1 -
 drivers/usb/serial/garmin_gps.c  | 1 -
 drivers/usb/serial/io_edgeport.c | 1 -
 drivers/usb/serial/io_ti.c   | 1 -
 drivers/usb/serial/ipaq.c| 1 -
 drivers/usb/serial/ipw.c | 1 -
 drivers/usb/serial/iuu_phoenix.c | 1 -
 drivers/usb/serial/keyspan.c | 1 -
 drivers/usb/serial/keyspan_pda.c | 1 -
 drivers/usb/serial/kl5kusb105.c  | 1 -
 drivers/usb/serial/kobil_sct.c   | 1 -
 drivers/usb/serial/mct_u232.c| 1 -
 drivers/usb/serial/metro-usb.c   | 1 -
 drivers/usb/serial/mos7720.c | 1 -
 drivers/usb/serial/mos7840.c | 1 -
 drivers/usb/serial/mxuport.c | 1 -
 drivers/usb/serial/navman.c  | 1 -
 drivers/usb/serial/omninet.c | 1 -
 drivers/usb/serial/opticon.c | 1 -
 drivers/usb/serial/oti6858.c | 1 -
 drivers/usb/serial/pl2303.c  | 1 -
 drivers/usb/serial/qcaux.c   | 1 -
 

[PATCH] xhci: make warnings greppable

[oliver]

From: Oliver Neukum oneu...@suse.de

This changes debug messages and warnings in xhci-ring.c
to be on a single line so grep can find them. grep must
have precedence over the 80 column limit.

Signed-off-by: Oliver Neukum oneu...@suse.de
---
 drivers/usb/host/xhci-ring.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 09b2b55..34dce53 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1081,8 +1081,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
 
ep_ring = xhci_stream_id_to_ring(dev, ep_index, stream_id);
if (!ep_ring) {
-   xhci_warn(xhci, WARN Set TR deq ptr command for 
-   freed stream ID %u\n,
+   xhci_warn(xhci, WARN Set TR deq ptr command for freed stream 
ID %u\n,
stream_id);
/* XXX: Harmless??? */
dev-eps[ep_index].ep_state = ~SET_DEQ_PENDING;
@@ -1098,12 +1097,10 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
 
switch (cmd_comp_code) {
case COMP_TRB_ERR:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd invalid 
because 
-   of stream ID configuration\n);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd invalid 
because of stream ID configuration\n);
break;
case COMP_CTX_STATE:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed due 
-   to incorrect slot or ep state.\n);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed due to 
incorrect slot or ep state.\n);
ep_state = le32_to_cpu(ep_ctx-ep_info);
ep_state = EP_STATE_MASK;
slot_state = le32_to_cpu(slot_ctx-dev_state);
@@ -1113,13 +1110,12 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
slot_state, ep_state);
break;
case COMP_EBADSLT:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed because 

-   slot %u was not enabled.\n, slot_id);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed because 
slot 
+   %u was not enabled.\n, slot_id);
break;
default:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd with unknown 
-   completion code of %u.\n,
- cmd_comp_code);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd with unknown 
completion code of 
+   %u.\n, cmd_comp_code);
break;
}
/* OK what do we do now?  The endpoint state is hosed, and we
@@ -1141,8 +1137,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
update_ring_for_set_deq_completion(xhci, dev,
ep_ring, ep_index);
} else {
-   xhci_warn(xhci, Mismatch between completed Set TR Deq 
-   Ptr command  xHCI internal state.\n);
+   xhci_warn(xhci, Mismatch between completed Set TR Deq 
Ptr command  xHCI internal state.\n);
xhci_warn(xhci, ep deq seg = %p, deq ptr = %p\n,
dev-eps[ep_index].queued_deq_seg,
dev-eps[ep_index].queued_deq_ptr);
-- 
1.8.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] xhci: make warnings greppable

[oliver]

From: Oliver Neukum oneu...@suse.de

This changes debug messages and warnings in xhci-ring.c
to be on a single line so grep can find them. grep must
have precedence over the 80 column limit.

Signed-off-by: Oliver Neukum oneu...@suse.de
---
 drivers/usb/host/xhci-ring.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 09b2b55..34dce53 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1081,8 +1081,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
 
ep_ring = xhci_stream_id_to_ring(dev, ep_index, stream_id);
if (!ep_ring) {
-   xhci_warn(xhci, WARN Set TR deq ptr command for 
-   freed stream ID %u\n,
+   xhci_warn(xhci, WARN Set TR deq ptr command for freed stream 
ID %u\n,
stream_id);
/* XXX: Harmless??? */
dev-eps[ep_index].ep_state = ~SET_DEQ_PENDING;
@@ -1098,12 +1097,10 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
 
switch (cmd_comp_code) {
case COMP_TRB_ERR:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd invalid 
because 
-   of stream ID configuration\n);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd invalid 
because of stream ID configuration\n);
break;
case COMP_CTX_STATE:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed due 
-   to incorrect slot or ep state.\n);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed due to 
incorrect slot or ep state.\n);
ep_state = le32_to_cpu(ep_ctx-ep_info);
ep_state = EP_STATE_MASK;
slot_state = le32_to_cpu(slot_ctx-dev_state);
@@ -1113,13 +1110,12 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
slot_state, ep_state);
break;
case COMP_EBADSLT:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed because 

-   slot %u was not enabled.\n, slot_id);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd failed because 
slot 
+   %u was not enabled.\n, slot_id);
break;
default:
-   xhci_warn(xhci, WARN Set TR Deq Ptr cmd with unknown 
-   completion code of %u.\n,
- cmd_comp_code);
+   xhci_warn(xhci, WARN Set TR Deq Ptr cmd with unknown 
completion code of 
+   %u.\n, cmd_comp_code);
break;
}
/* OK what do we do now?  The endpoint state is hosed, and we
@@ -1141,8 +1137,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd 
*xhci, int slot_id,
update_ring_for_set_deq_completion(xhci, dev,
ep_ring, ep_index);
} else {
-   xhci_warn(xhci, Mismatch between completed Set TR Deq 
-   Ptr command  xHCI internal state.\n);
+   xhci_warn(xhci, Mismatch between completed Set TR Deq 
Ptr command  xHCI internal state.\n);
xhci_warn(xhci, ep deq seg = %p, deq ptr = %p\n,
dev-eps[ep_index].queued_deq_seg,
dev-eps[ep_index].queued_deq_ptr);
-- 
1.8.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: c67x00: correct spelling mistakes in comments

[Rahul Bedarkar]

Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
 drivers/usb/c67x00/c67x00-hcd.h| 2 +-
 drivers/usb/c67x00/c67x00-ll-hpi.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/c67x00/c67x00-hcd.h b/drivers/usb/c67x00/c67x00-hcd.h
index b4b2b01..d441a98 100644
--- a/drivers/usb/c67x00/c67x00-hcd.h
+++ b/drivers/usb/c67x00/c67x00-hcd.h
@@ -45,7 +45,7 @@
 /*
  * The current implementation switches between _STD (default) and _ISO (when
  * isochronous transfers are scheduled), in order to optimize the throughput
- * in normal cicrumstances, but also provide good isochronous behaviour.
+ * in normal circumstances, but also provide good isochronous behaviour.
  *
  * Bandwidth is described in bit time so with a 12MHz USB clock and 1ms
  * frames; there are 12000 bit times per frame.
diff --git a/drivers/usb/c67x00/c67x00-ll-hpi.c 
b/drivers/usb/c67x00/c67x00-ll-hpi.c
index d9aaf1f..7553121 100644
--- a/drivers/usb/c67x00/c67x00-ll-hpi.c
+++ b/drivers/usb/c67x00/c67x00-ll-hpi.c
@@ -62,8 +62,8 @@ struct c67x00_lcp_int_data {
  * HPI implementation
  *
  * The c67x00 chip also support control via SPI or HSS serial
- * interfaces.  However, this driver assumes that register access can
- * be performed from IRQ context.  While this is a safe assuption with
+ * interfaces. However, this driver assumes that register access can
+ * be performed from IRQ context. While this is a safe assumption with
  * the HPI interface, it is not true for the serial interfaces.
  */
 
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] ohci and ehci-platform clks, phy and dt support

[Hans de Goede]

Hi All,

Here is v2 of my ohci and ehci-platform clks, phy and dt support patch-set.

Changes since v1:
-Various improvements to dt-bindings as suggested by various people
-Support up-to 3 clocks

Regards,

Hans
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] ehci-platform: Add support for clks and phy passed through devicetree

[Hans de Goede]

Currently ehci-platform is only used in combination with devicetree when used
with some via socs. By extending it to (optionally) get clks and a phy from
devicetree, and enabling / disabling those on power_on / off, it can be used
more generically. Specifically after this commit it can be used for the
ehci controller on Allwinner sunxi SoCs.

Somehow we've ended up with 2 device-bindings documents for ehci-platform.c,
this patch renames and updates one to platform-ehci.txt to reflect that this
is a generic platform driver, and removes the other.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 .../devicetree/bindings/usb/platform-ehci.txt  |  25 
 .../devicetree/bindings/usb/via,vt8500-ehci.txt|  15 ---
 .../devicetree/bindings/usb/vt8500-ehci.txt|  12 --
 drivers/usb/host/ehci-platform.c   | 126 +
 4 files changed, 131 insertions(+), 47 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/platform-ehci.txt
 delete mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
 delete mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt

diff --git a/Documentation/devicetree/bindings/usb/platform-ehci.txt 
b/Documentation/devicetree/bindings/usb/platform-ehci.txt
new file mode 100644
index 000..56c478d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/platform-ehci.txt
@@ -0,0 +1,25 @@
+Generic Platform EHCI controller
+
+Required properties:
+- compatible : via,vt8500-ehci or wm,prizm-ehci
+- reg : ehci controller register range (address and length)
+- interrupts : ehci controller interrupt
+
+Optional properties:
+- clocks : a list of phandle + clock specifier pairs, one for each entry
+   in clock-names.
+- clock-names : clk0, clk1, ...
+- phys : phy
+- phy-names : phy0
+
+Example:
+
+   ehci@d8007900 {
+   compatible = via,vt8500-ehci;
+   reg = 0xd8007900 0x200;
+   interrupts = 43;
+   clocks = usb_clk 6, ahb_gates 2;
+   clock-names = clk0, clk1;
+   phys = usbphy 1;
+   phy-names = phy0;
+   };
diff --git a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt 
b/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
deleted file mode 100644
index 17b3ad1..000
--- a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-VIA/Wondermedia VT8500 EHCI Controller
--
-
-Required properties:
-- compatible : via,vt8500-ehci
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : ehci controller interrupt
-
-Example:
-
-   ehci@d8007900 {
-   compatible = via,vt8500-ehci;
-   reg = 0xd8007900 0x200;
-   interrupts = 43;
-   };
diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt 
b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
deleted file mode 100644
index 5fb8fd6..000
--- a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
-
-Required properties:
- - compatible: Should be via,vt8500-ehci or wm,prizm-ehci.
- - reg: Address range of the ehci registers. size should be 0x200
- - interrupts: Should contain the ehci interrupt.
-
-usb: ehci@D8007100 {
-   compatible = wm,prizm-ehci, usb-ehci;
-   reg = 0xD8007100 0x200;
-   interrupts = 1;
-};
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 7f30b71..ce76659 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -3,6 +3,7 @@
  *
  * Copyright 2007 Steven Brown sbr...@cortland.com
  * Copyright 2010-2012 Hauke Mehrtens ha...@hauke-m.de
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
  *
  * Derived from the ohci-ssb driver
  * Copyright 2007 Michael Buesch m...@bues.ch
@@ -18,6 +19,7 @@
  *
  * Licensed under the GNU/GPL. See COPYING for details.
  */
+#include linux/clk.h
 #include linux/dma-mapping.h
 #include linux/err.h
 #include linux/kernel.h
@@ -25,6 +27,7 @@
 #include linux/io.h
 #include linux/module.h
 #include linux/of.h
+#include linux/phy/phy.h
 #include linux/platform_device.h
 #include linux/usb.h
 #include linux/usb/hcd.h
@@ -34,6 +37,12 @@
 
 #define DRIVER_DESC EHCI generic platform driver
 
+#define EHCI_MAX_CLKS 3
+struct ehci_platform_priv {
+   struct clk *clks[EHCI_MAX_CLKS];
+   struct phy *phy;
+};
+
 static const char hcd_name[] = ehci-platform;
 
 static int ehci_platform_reset(struct usb_hcd *hcd)
@@ -64,28 +73,84 @@ static int ehci_platform_reset(struct usb_hcd *hcd)
return 0;
 }
 
+static int ehci_platform_power_on(struct platform_device *dev)
+{
+   struct usb_hcd *hcd = platform_get_drvdata(dev);
+   struct ehci_platform_priv *priv =
+   (struct ehci_platform_priv *)hcd_to_ehci(hcd)-priv;
+   int clk, ret;
+
+   for (clk = 0; 

Re: Isochronous transfer error on USB3

[Mauro Carvalho Chehab]

Em Thu, 02 Jan 2014 14:07:22 -0800
Sarah Sharp sarah.a.sh...@linux.intel.com escreveu:

 On Sun, Dec 29, 2013 at 02:54:40AM -0200, Mauro Carvalho Chehab wrote:
  It seems that usb_unlink_urb() is causing troubles with xHCI: the
  endpoint stops streaming, but, after that, it doesn't start again,
  and lots of debug messages are produced. I emailed you the full log
  after start streaming in priv (too big for vger), but basically, 
  it produces:
  
  [ 1635.754546] xhci_hcd :00:14.0: Endpoint 0x81 not halted, refusing to 
  reset.
  [ 1635.754562] xhci_hcd :00:14.0: Endpoint 0x82 not halted, refusing to 
  reset.
  [ 1635.754577] xhci_hcd :00:14.0: Endpoint 0x83 not halted, refusing to 
  reset.
  [ 1635.754594] xhci_hcd :00:14.0: Endpoint 0x84 not halted, refusing to 
  reset.
 
 I think that's due to the driver (or userspace) attempting to reset the
 endpoint when it didn't actually receive a stall (-EPIPE) status from an
 URB.  When that happens, the xHCI host controller endpoint toggle bits
 get out of sync with the device toggle bits, and the result is that all
 transfers will fail to the endpoint from then on until you switch
 alternate interface settings or unplug/replug the device.
 
 Try this patch:
 
 http://marc.info/?l=linux-usbm=138116117104619w=2
 
 It's still under RFC, and I know it has race conditions, but it will let
 you quickly test whether this fixes your issue.

Didn't work fine, or at least it didn't solve all the problems. Also, it
started to cause OOPSes due to the race conditions.

 
 This has been a long-standing xHCI driver bug.  I asked my OPW intern to
 work on the patch to fix it, but she may be a bit busy with her new job
 to finish up the RFC.  I'll probably have to take over finishing the
 patch, if this turns out to be your issue.
 
  (Not sure why it is trying to stop all endpoints - as just one endpoint was
  requested to restart).
 
 Something is calling into usb_clear_halt() with all the endpoints.
 Userspace, perhaps? 

No, userspace is not doing it. The userspace doesn't even know that this
device is USB (and were written at the time that all media drivers were
PCI only - so it doesn't have any USB specific call on it).

 You could add WARN() calls to usb_clear_halt() to
 see what code is resetting the endpoints.  In any case, it's not part of
 the USB core code to change configuration or alt settings, since I don't
 see any xHCI driver output from the endpoint bandwidth code in this
 chunk of the dmesg you sent:

The em28xx-audio.c driver may need to call usb_set_interface() while
the video is still streaming, in order to unmute the audio. That happens
when the audio device is opened.

With EHCI, this works properly.

 [ 1649.640783] xhci_hcd :00:14.0: Removing canceled TD starting at 
 0xb41e8580 (dma).
 [ 1649.640784] xhci_hcd :00:14.0: TRB to noop at offset 0xb41e8580
 [ 1649.643159] xhci_hcd :00:14.0: Endpoint 0x81 not halted, refusing to 
 reset.
 [ 1649.643188] xhci_hcd :00:14.0: Endpoint 0x82 not halted, refusing to 
 reset.
 [ 1649.643215] xhci_hcd :00:14.0: Endpoint 0x83 not halted, refusing to 
 reset.
 [ 1649.643239] xhci_hcd :00:14.0: Endpoint 0x84 not halted, refusing to 
 reset.
 [ 1649.735539] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
 expansion
 
 Sarah Sharp

Btw, sometimes, I get such logs:

[  646.192273] xhci_hcd :00:14.0: Miss service interval error, set skip flag
[  646.192292] xhci_hcd :00:14.0: Miss service interval error, set skip flag
[  646.192311] xhci_hcd :00:14.0: Miss service interval error, set skip flag
[  646.192329] xhci_hcd :00:14.0: Miss service interval error, set skip flag
[  646.192351] xhci_hcd :00:14.0: Miss service interval error, set skip flag
[  646.192376] xhci_hcd :00:14.0: Miss service interval error, set skip flag

After adding some debug at em28xx-audio, triggering alsa trigger start
events, I'm getting those:

[ 3078.971224] snd_em28xx_capture_trigger: start capture
[ 3078.971284] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
expansion
[ 3078.971311] xhci_hcd :00:14.0: ring expansion succeed, now has 4 segments
[ 3078.971350] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
expansion
[ 3078.971387] xhci_hcd :00:14.0: ring expansion succeed, now has 8 segments
[ 3079.034626] em28xx_audio_isocirq, 64 packets (first one with size 12)

Here, some audio data arrives.

[ 3079.034665] snd_em28xx_capture_trigger: stop capture

It seems, however, that this didn't arrive in time, and causes an alsa
buffer underrun. So, it cancels the existing URBs.

PS.: Even with EHCI, it causes a few ALSA underruns before it gets steady.
I suspect that this is due to em28xx time to synchronize audio and video
streams.

[ 3079.034736] xhci_hcd :00:14.0: Cancel URB 88020790, dev 4, ep 
0x83, starting at offset 0x1ffb13850
[ 3079.034755] xhci_hcd :00:14.0: // Ding dong!
[ 3079.034783] xhci_hcd :00:14.0: Stopped 

[PATCH] USB: image: correct spelling mistake in comment

[Rahul Bedarkar]

Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
 drivers/usb/image/mdc800.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/image/mdc800.c b/drivers/usb/image/mdc800.c
index 7121b50..a62865a 100644
--- a/drivers/usb/image/mdc800.c
+++ b/drivers/usb/image/mdc800.c
@@ -51,7 +51,7 @@
  *
  * version 0.7.3
  * bugfix : The mdc800-state field gets set to READY after the
- * the diconnect function sets it to NOT_CONNECTED. This makes the
+ * the disconnect function sets it to NOT_CONNECTED. This makes the
  * driver running like the camera is connected and causes some
  * hang ups.
  *
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: c67x00: fix up line break coding style issues

[Rahul Bedarkar]

Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
 drivers/usb/c67x00/c67x00-drv.c|  3 ++-
 drivers/usb/c67x00/c67x00-hcd.h|  2 +-
 drivers/usb/c67x00/c67x00-ll-hpi.c | 21 +-
 drivers/usb/c67x00/c67x00-sched.c  | 44 --
 drivers/usb/c67x00/c67x00.h|  4 ++--
 5 files changed, 39 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c
index 8db3380..34c6cbb 100644
--- a/drivers/usb/c67x00/c67x00-drv.c
+++ b/drivers/usb/c67x00/c67x00-drv.c
@@ -28,7 +28,8 @@
  * interrupt handling).
  *
  * The c67x00 has 2 SIE's (serial interface engine) which can be configured
- * to be host, device or OTG (with some limitations, E.G. only SIE1 can be 
OTG).
+ * to be host, device or OTG (with some limitations, E.G. only SIE1 can be
+ * OTG).
  *
  * Depending on the platform configuration, the SIE's are created and
  * the corresponding subdriver is initialized (c67x00_probe_sie).
diff --git a/drivers/usb/c67x00/c67x00-hcd.h b/drivers/usb/c67x00/c67x00-hcd.h
index cf8a455..d441a98 100644
--- a/drivers/usb/c67x00/c67x00-hcd.h
+++ b/drivers/usb/c67x00/c67x00-hcd.h
@@ -64,7 +64,7 @@
  */
 #define MAX_PERIODIC_BW(full_bw)   full_bw
 
-/* -- 
*/
+/* - */
 
 struct c67x00_hcd {
spinlock_t lock;
diff --git a/drivers/usb/c67x00/c67x00-ll-hpi.c 
b/drivers/usb/c67x00/c67x00-ll-hpi.c
index 18ae45d..ada34dc 100644
--- a/drivers/usb/c67x00/c67x00-ll-hpi.c
+++ b/drivers/usb/c67x00/c67x00-ll-hpi.c
@@ -33,7 +33,7 @@ struct c67x00_lcp_int_data {
u16 regs[COMM_REGS];
 };
 
-/* -- 
*/
+/* - */
 /* Interface definitions */
 
 #define COMM_ACK   0x0FED
@@ -101,7 +101,8 @@ static u16 hpi_read_word(struct c67x00_device *dev, u16 reg)
return value;
 }
 
-static void hpi_write_word_nolock(struct c67x00_device *dev, u16 reg, u16 
value)
+static void
+hpi_write_word_nolock(struct c67x00_device *dev, u16 reg, u16 value)
 {
hpi_write_reg(dev, HPI_ADDR, reg);
hpi_write_reg(dev, HPI_DATA, value);
@@ -234,7 +235,7 @@ void c67x00_ll_hpi_disable_sofeop(struct c67x00_sie *sie)
   SOFEOP_TO_HPI_EN(sie-sie_num));
 }
 
-/* -- 
*/
+/* - */
 /* Transactions */
 
 static inline int ll_recv_msg(struct c67x00_device *dev)
@@ -247,7 +248,7 @@ static inline int ll_recv_msg(struct c67x00_device *dev)
return (res == 0) ? -EIO : 0;
 }
 
-/* -- 
*/
+/* - */
 /* General functions */
 
 u16 c67x00_ll_fetch_siemsg(struct c67x00_device *dev, int sie_num)
@@ -279,7 +280,7 @@ u16 c67x00_ll_usb_get_status(struct c67x00_sie *sie)
return hpi_read_word(sie-dev, USB_STAT_REG(sie-sie_num));
 }
 
-/* -- 
*/
+/* - */
 
 static int c67x00_comm_exec_int(struct c67x00_device *dev, u16 nr,
struct c67x00_lcp_int_data *data)
@@ -297,7 +298,7 @@ static int c67x00_comm_exec_int(struct c67x00_device *dev, 
u16 nr,
return rc;
 }
 
-/* -- 
*/
+/* - */
 /* Host specific functions */
 
 void c67x00_ll_set_husb_eot(struct c67x00_device *dev, u16 value)
@@ -372,7 +373,7 @@ void c67x00_ll_husb_reset_port(struct c67x00_sie *sie, int 
port)
hpi_set_bits(sie-dev, USB_CTL_REG(sie-sie_num), PORT_RES_EN(port));
 }
 
-/* -- 
*/
+/* - */
 
 void c67x00_ll_irq(struct c67x00_device *dev, u16 int_status)
 {
@@ -383,7 +384,7 @@ void c67x00_ll_irq(struct c67x00_device *dev, u16 
int_status)
complete(dev-hpi.lcp.msg_received);
 }
 
-/* -- 
*/
+/* - */
 
 int c67x00_ll_reset(struct c67x00_device *dev)
 {
@@ -397,7 +398,7 @@ int c67x00_ll_reset(struct c67x00_device *dev)
return rc;
 }
 
-/* -- 
*/
+/* - */
 
 /**
  * c67x00_ll_write_mem_le16 - write into 

[PATCH] USB: chipidea: fix up coding style issues

[Rahul Bedarkar]

Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 3 ++-
 drivers/usb/chipidea/core.c| 9 +
 drivers/usb/chipidea/host.c| 3 ++-
 drivers/usb/chipidea/udc.c | 9 ++---
 4 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index bb5d976..4573cb9 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -53,7 +53,8 @@ static struct imx_usbmisc_data *usbmisc_get_init_data(struct 
device *dev)
ret = of_parse_phandle_with_args(np, fsl,usbmisc, #index-cells,
0, args);
if (ret) {
-   dev_err(dev, Failed to parse property fsl,usbmisc, errno %d\n,
+   dev_err(dev,
+   Failed to parse property fsl,usbmisc, errno %d\n,
ret);
return ERR_PTR(ret);
}
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index bfd08b6..0a221c9 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -184,7 +184,7 @@ static void ci_hdrc_enter_lpm(struct ci_hdrc *ci, bool 
enable)
} else  if (!enable  lpm) {
hw_write(ci, reg, PORTSC_PHCD(ci-hw_bank.lpm),
0);
-   /* 
+   /*
 * The controller needs at least 1ms to reflect
 * PHY's status, the PHY also needs some time (less
 * than 1ms) to leave low power mode.
@@ -596,9 +596,10 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ret = otg_set_peripheral(ci-transceiver-otg,
ci-gadget);
/*
-* If we implement all USB functions using chipidea 
drivers,
-* it doesn't need to call above API, meanwhile, if we 
only
-* use gadget function, calling above API is useless.
+* If we implement all USB functions using chipidea
+* drivers, it doesn't need to call above API,
+* meanwhile, if we only use gadget function, calling
+* above API is useless.
 */
if (ret  ret != -ENOTSUPP)
goto destroy_phy;
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 526cd77..3d0bf11 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -123,7 +123,8 @@ int ci_hdrc_host_init(struct ci_hdrc *ci)
if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_HC))
return -ENXIO;
 
-   rdrv = devm_kzalloc(ci-dev, sizeof(struct ci_role_driver), GFP_KERNEL);
+   rdrv = devm_kzalloc(ci-dev, sizeof(struct ci_role_driver),
+   GFP_KERNEL);
if (!rdrv)
return -ENOMEM;
 
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 5e7d164..a54b517 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -784,7 +784,8 @@ static int _ep_queue(struct usb_ep *ep, struct usb_request 
*req,
 
if (usb_endpoint_xfer_isoc(hwep-ep.desc) 
hwreq-req.length  (1 + hwep-ep.mult) * hwep-ep.maxpacket) {
-   dev_err(hwep-ci-dev, request length too big for 
isochronous\n);
+   dev_err(hwep-ci-dev,
+   request length too big for isochronous\n);
return -EMSGSIZE;
}
 
@@ -1368,7 +1369,8 @@ static int ep_set_halt(struct usb_ep *ep, int value)
 
direction = hwep-dir;
do {
-   retval |= hw_ep_set_halt(hwep-ci, hwep-num, hwep-dir, value);
+   retval |= hw_ep_set_halt(hwep-ci, hwep-num, hwep-dir,
+   value);
 
if (!value)
hwep-wedge = 0;
@@ -1862,7 +1864,8 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
return -ENXIO;
 
-   rdrv = devm_kzalloc(ci-dev, sizeof(struct ci_role_driver), GFP_KERNEL);
+   rdrv = devm_kzalloc(ci-dev, sizeof(struct ci_role_driver),
+   GFP_KERNEL);
if (!rdrv)
return -ENOMEM;
 
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

[Alan Stern]

On Tue, 7 Jan 2014, Sarah Sharp wrote:

 On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
  On 01/07/2014 01:21 PM, Sarah Sharp wrote:
  
   Can you please try the attached patch, on top of the previous three
   patches, and send me dmesg?
  
  Hi Sarah, I just now finished running 0001-More-debugging.patch for the
  first time.  The previous dmesg didn't include that patch, but this one
  does.
  
  I read through this dmesg but I nodded off somewhere around line 500.
  I hope you can stay awake :)
 
 Well, it has all the info I need, but the results don't make me too
 happy.  Everything I've checked seems consistent, and I don't know why
 the host stopped.  The link TRBs are intact, the dequeue pointer for the
 endpoint was pointing to the transfer that timed out and it had the
 cycle bit set correctly, etc.  Perhaps the no-op TRBs are really the
 issue.

This may be a foolish question, but why is xhci-hcd using no-op TRBs in 
the first place?

It makes sense that they would be needed if you have to unlink an URB 
that isn't the first one on the endpoint ring.  But usb-storage never 
does that; whenever it unlinks an URB, it always unlinks the earliest 
entry in the endpoint's queue.

After unlinking the first URB on the ring, you don't need to fill in
its TRBs with no-ops.  Instead, when you are ready to start the ring
againk, just tell the host controller to move the dequeue pointer up to
the start of the next surviving URB.  (You'll also have to adjust the
CYCLE bits of the TRBs that get skipped over, but that's trivial.)

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] ohci-platform: Add support for devicetree instantiation

[Hans de Goede]

Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.

This should allow using ohci-platform from devicetree in various cases.
Specifically after this commit it can be used for the ohci controller found
on Allwinner sunxi SoCs.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 .../devicetree/bindings/usb/platform-ohci.txt  |  25 
 drivers/usb/host/ohci-platform.c   | 148 ++---
 2 files changed, 153 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/platform-ohci.txt

diff --git a/Documentation/devicetree/bindings/usb/platform-ohci.txt 
b/Documentation/devicetree/bindings/usb/platform-ohci.txt
new file mode 100644
index 000..44bfa57
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/platform-ohci.txt
@@ -0,0 +1,25 @@
+Generic Platform OHCI controller
+
+Required properties:
+- compatible : allwinner,sun4i-ohci
+- reg : ohci controller register range (address and length)
+- interrupts : ohci controller interrupt
+
+Optional properties:
+- clocks : a list of phandle + clock specifier pairs, one for each entry
+   in clock-names.
+- clock-names : clk0, clk1, ...
+- phys : phy
+- phy-names : phy0
+
+Example:
+
+   ohci0: ohci@0x01c14400 {
+   compatible = allwinner,sun4i-ohci;
+   reg = 0x01c14400 0x100;
+   interrupts = 64;
+   clocks = usb_clk 6, ahb_gates 2;
+   clock-names = clk0, clk1;
+   phys = usbphy 1;
+   phy-names = phy0;
+   };
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index f351ff5..7cab768 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -3,6 +3,7 @@
  *
  * Copyright 2007 Michael Buesch m...@bues.ch
  * Copyright 2011-2012 Hauke Mehrtens ha...@hauke-m.de
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
  *
  * Derived from the OCHI-SSB driver
  * Derived from the OHCI-PCI driver
@@ -14,11 +15,14 @@
  * Licensed under the GNU/GPL. See COPYING for details.
  */
 
+#include linux/clk.h
+#include linux/dma-mapping.h
 #include linux/hrtimer.h
 #include linux/io.h
 #include linux/kernel.h
 #include linux/module.h
 #include linux/err.h
+#include linux/phy/phy.h
 #include linux/platform_device.h
 #include linux/usb/ohci_pdriver.h
 #include linux/usb.h
@@ -28,6 +32,12 @@
 
 #define DRIVER_DESC OHCI generic platform driver
 
+#define OHCI_MAX_CLKS 3
+struct ohci_platform_priv {
+   struct clk *clks[OHCI_MAX_CLKS];
+   struct phy *phy;
+};
+
 static const char hcd_name[] = ohci-platform;
 
 static int ohci_platform_reset(struct usb_hcd *hcd)
@@ -48,11 +58,69 @@ static int ohci_platform_reset(struct usb_hcd *hcd)
return ohci_setup(hcd);
 }
 
+static int ohci_platform_power_on(struct platform_device *dev)
+{
+   struct usb_hcd *hcd = platform_get_drvdata(dev);
+   struct ohci_platform_priv *priv =
+   (struct ohci_platform_priv *)hcd_to_ohci(hcd)-priv;
+   int clk, ret;
+
+   for (clk = 0; priv-clks[clk]  clk  OHCI_MAX_CLKS; clk++) {
+   ret = clk_prepare_enable(priv-clks[clk]);
+   if (ret)
+   goto err_disable_clks;
+   }
+
+   if (priv-phy) {
+   ret = phy_init(priv-phy);
+   if (ret)
+   goto err_disable_clks;
+
+   ret = phy_power_on(priv-phy);
+   if (ret)
+   goto err_exit_phy;
+   }
+
+   return 0;
+
+err_exit_phy:
+   phy_exit(priv-phy);
+err_disable_clks:
+   while (--clk = 0)
+   clk_disable_unprepare(priv-clks[clk]);
+
+   return ret;
+}
+
+static void ohci_platform_power_off(struct platform_device *dev)
+{
+   struct usb_hcd *hcd = platform_get_drvdata(dev);
+   struct ohci_platform_priv *priv =
+   (struct ohci_platform_priv *)hcd_to_ohci(hcd)-priv;
+   int clk;
+
+   if (priv-phy) {
+   phy_power_off(priv-phy);
+   phy_exit(priv-phy);
+   }
+
+   for (clk = OHCI_MAX_CLKS - 1; clk = 0; clk--)
+   if (priv-clks[clk])
+   clk_disable_unprepare(priv-clks[clk]);
+}
+
 static struct hc_driver __read_mostly ohci_platform_hc_driver;
 
 static const struct ohci_driver_overrides platform_overrides __initconst = {
-   .product_desc = Generic Platform OHCI controller,
-   .reset =ohci_platform_reset,
+   .product_desc = Generic Platform OHCI controller,
+   .reset =ohci_platform_reset,
+   .extra_priv_size =  sizeof(struct ohci_platform_priv),
+};
+
+static struct usb_ohci_pdata ohci_platform_defaults = {
+   .power_on = ohci_platform_power_on,
+   .power_suspend =ohci_platform_power_off,
+   .power_off =

Re: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.

[Alan Stern]

On Wed, 8 Jan 2014, tatxarata wrote:

 Since reporting this bug I've invested some time to get myself familiar 
 with USB protocol and analyzed attached capture files. It seems like 
 device resetoccurs after device returns urb_status=-75 (-EOVERFLOW). 

Yes.  The EOVERFLOW error is what causes the driver to do a reset.

 This can be seen in attachment 
 https://bugzilla.kernel.org/attachment.cgi?id=120901 in packet #1987. 
 Also I've noticed that host tries to read device by chunks of 240 
 sectors while device returns on each query no more than 120 sectors 
 (61440 bytes).

That's not true in the log file you just mentioned.  See packet #1955.

  From traffic it is clearly seen that EOVERFLOW occurs after the device 
 is already mounted and while software tries to browse it's content.
 When I do something like 'dd if=/dev/sdb of=/dev/null' where sdb is CF 
 card or mount and copy with shell commands host-device communication 
 scheme is the same (240 sectors requested, 120 returned), but this 
 doesn't lead to EOVERFLOW. In that cases read speed is at about 80Mb/s.
 So I suppose that something wrong happens only while software like 
 thunar or midnight commander tries to browse the contents of card (maybe 
 parallel threads trying to access card simultaneously?).

That wouldn't matter.  usb-storage serializes accesses to the device.

 With that knowledge I've tried to tweak some device parameters in /sys
 filesystem. When I put value 60 in /sys/block/sd?/queue/max_sectors_kb 
 then all operates correctly without any resets. However in this case 
 read speed of card drops down by factor of two at around 40Mb/s.
 
 When I set max_sectors_kb to 64 then device does reset upon mount in 
 thunar, however, surprisingly, this doesn't lead to dropping of device 
 mount, like in case of default value of 120. In this case read speed is 
 at about 89.5Mb/s, as expected by card specs. So I've added udev rule 
 that corrects value of max_sectors_kb to 64 upon device connection. For 
 now I can live with this 10 seconds latency of device mounting if latter 
 it works properly. However I think that the reason of this issue must be 
 clarified and fixed.

It seems like a bug in the device.

 Also tried to set queue/scheduler to noop with no effect.
 
 In case of USB2.0 host-device traffic looks pretty the same way as in 
 case of USB3.0. Host also tries to read device by chunks of 240 sectors 
 and device returns only 120. However for some reason this doesn't lead 
 to EOVERFLOW.
 
 Main difference I've managed to find between usb 2.0 and 3.0 traffic is 
 the device initialization. In case of 3.0 there are some 
 CLEAR_FEATURE/SET_FEATURE requests that are missing in case of 2.0, so 
 maybe device operates differently by that reason.

Maybe, but I doubt it.  Those requests are mostly concerned with Link 
Power Management.

What happens if you connect the card reader to a USB-3 port using a 
USB-2 cable?

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

[David Laight]

 From: Alan Stern
 
 This may be a foolish question, but why is xhci-hcd using no-op TRBs in
 the first place?

Because it can't write in a link TRB because other parts of the
code use link TRBs to detect the end of the ring.

The problem is that it can't put a link TRB in the middle of
a chain of data fragments unless it is at a 'suitable' offset
from the start of the data TD. Given arbitrary input fragmentation
this means that you can't put a link TRB in the middle of a TD.
(The documented alignment might be as high as 16kB.)

If the rest of the code used a 'ring end pointer' then a link TRB
could be used instead.

David



--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ohci-platform: Add support for devicetree instantiation

[Alan Stern]

On Tue, 7 Jan 2014, Hans de Goede wrote:

 Hi,
 
 On 01/07/2014 10:16 PM, Arnd Bergmann wrote:
  On Tuesday 07 January 2014 22:03:11 Hans de Goede wrote:
  +
  +Optional properties:
  + - clocks: array of clocks
  + - clock-names: clock names ahb and/or ohci
 
  Where does ahb come from, what does it mean, and how is it relevant
  to generic platforms?
 
  ahb is an ARM specific thing, so your right it does not belong in a
  generic driver. I'll use clk1 and clk2 as names in my next version.
 
  While AHB is a bus created by ARM Ltd, it's not actually specific
  to the ARM architecture. My guess is that it is in fact used on 95%
  of all SoCs, so I would leave it at that. For the other clock, I
  think that's actually the bus clock for the USB interface, so I would
  not call it ohci but rather just usb or phy.
 
  I think it's important to distinguish the names and not just use
  clk1 and clk2, because the driver may actually want to access
  a particular clock in some scenario.
 
 The idea here is to have a generic driver, if a driver needs to know
 about a specific clock, it will likely be another device specific
 driver and it can use its own dt-bindings and clock names. I believe
 that for a generic driver meant to cover common hardware configs,
 simply having X clks and then on power_on enabling clk1, then clk2,
 then clk3, etc. and on power off do the same in reverse other is
 a good approach.

I agree.

Alan Stern


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Isochronous transfer error on USB3

[Mauro Carvalho Chehab]

Em Wed, 08 Jan 2014 14:31:28 -0200
Mauro Carvalho Chehab m.che...@samsung.com escreveu:

 Em Thu, 02 Jan 2014 14:07:22 -0800
 Sarah Sharp sarah.a.sh...@linux.intel.com escreveu:
 
  On Sun, Dec 29, 2013 at 02:54:40AM -0200, Mauro Carvalho Chehab wrote:
   It seems that usb_unlink_urb() is causing troubles with xHCI: the
   endpoint stops streaming, but, after that, it doesn't start again,
   and lots of debug messages are produced. I emailed you the full log
   after start streaming in priv (too big for vger), but basically, 
   it produces:
   
   [ 1635.754546] xhci_hcd :00:14.0: Endpoint 0x81 not halted, refusing 
   to reset.
   [ 1635.754562] xhci_hcd :00:14.0: Endpoint 0x82 not halted, refusing 
   to reset.
   [ 1635.754577] xhci_hcd :00:14.0: Endpoint 0x83 not halted, refusing 
   to reset.
   [ 1635.754594] xhci_hcd :00:14.0: Endpoint 0x84 not halted, refusing 
   to reset.
  
  I think that's due to the driver (or userspace) attempting to reset the
  endpoint when it didn't actually receive a stall (-EPIPE) status from an
  URB.  When that happens, the xHCI host controller endpoint toggle bits
  get out of sync with the device toggle bits, and the result is that all
  transfers will fail to the endpoint from then on until you switch
  alternate interface settings or unplug/replug the device.
  
  Try this patch:
  
  http://marc.info/?l=linux-usbm=138116117104619w=2
  
  It's still under RFC, and I know it has race conditions, but it will let
  you quickly test whether this fixes your issue.
 
 Didn't work fine, or at least it didn't solve all the problems. Also, it
 started to cause OOPSes due to the race conditions.
 
  
  This has been a long-standing xHCI driver bug.  I asked my OPW intern to
  work on the patch to fix it, but she may be a bit busy with her new job
  to finish up the RFC.  I'll probably have to take over finishing the
  patch, if this turns out to be your issue.
  
   (Not sure why it is trying to stop all endpoints - as just one endpoint 
   was
   requested to restart).
  
  Something is calling into usb_clear_halt() with all the endpoints.
  Userspace, perhaps? 
 
 No, userspace is not doing it. The userspace doesn't even know that this
 device is USB (and were written at the time that all media drivers were
 PCI only - so it doesn't have any USB specific call on it).
 
  You could add WARN() calls to usb_clear_halt() to
  see what code is resetting the endpoints.  In any case, it's not part of
  the USB core code to change configuration or alt settings, since I don't
  see any xHCI driver output from the endpoint bandwidth code in this
  chunk of the dmesg you sent:
 
 The em28xx-audio.c driver may need to call usb_set_interface() while
 the video is still streaming, in order to unmute the audio. That happens
 when the audio device is opened.
 
 With EHCI, this works properly.
 
  [ 1649.640783] xhci_hcd :00:14.0: Removing canceled TD starting at 
  0xb41e8580 (dma).
  [ 1649.640784] xhci_hcd :00:14.0: TRB to noop at offset 0xb41e8580
  [ 1649.643159] xhci_hcd :00:14.0: Endpoint 0x81 not halted, refusing to 
  reset.
  [ 1649.643188] xhci_hcd :00:14.0: Endpoint 0x82 not halted, refusing to 
  reset.
  [ 1649.643215] xhci_hcd :00:14.0: Endpoint 0x83 not halted, refusing to 
  reset.
  [ 1649.643239] xhci_hcd :00:14.0: Endpoint 0x84 not halted, refusing to 
  reset.
  [ 1649.735539] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
  expansion
  
  Sarah Sharp
 
 Btw, sometimes, I get such logs:
 
 [  646.192273] xhci_hcd :00:14.0: Miss service interval error, set skip 
 flag
 [  646.192292] xhci_hcd :00:14.0: Miss service interval error, set skip 
 flag
 [  646.192311] xhci_hcd :00:14.0: Miss service interval error, set skip 
 flag
 [  646.192329] xhci_hcd :00:14.0: Miss service interval error, set skip 
 flag
 [  646.192351] xhci_hcd :00:14.0: Miss service interval error, set skip 
 flag
 [  646.192376] xhci_hcd :00:14.0: Miss service interval error, set skip 
 flag
 
 After adding some debug at em28xx-audio, triggering alsa trigger start
 events, I'm getting those:
 
 [ 3078.971224] snd_em28xx_capture_trigger: start capture
 [ 3078.971284] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
 expansion
 [ 3078.971311] xhci_hcd :00:14.0: ring expansion succeed, now has 4 
 segments
 [ 3078.971350] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
 expansion
 [ 3078.971387] xhci_hcd :00:14.0: ring expansion succeed, now has 8 
 segments
 [ 3079.034626] em28xx_audio_isocirq, 64 packets (first one with size 12)
 
 Here, some audio data arrives.
 
 [ 3079.034665] snd_em28xx_capture_trigger: stop capture
 
 It seems, however, that this didn't arrive in time, and causes an alsa
 buffer underrun. So, it cancels the existing URBs.
 
 PS.: Even with EHCI, it causes a few ALSA underruns before it gets steady.
 I suspect that this is due to em28xx time to synchronize audio and video
 

Re: [PATCH] RFC: Allow to blacklist xhci_hcd module and use ports with EHCI

[Alan Stern]

On Tue, 7 Jan 2014, Holger Hans Peter Freyther wrote:

 On Tue, Jan 07, 2014 at 10:32:08AM -0500, Alan Stern wrote:
 
   I think in my case quirk_usb_handoff_xhci is called during boot that
   will switch the ports to the XHCI.
  
  That's what I said.  Early PCI processing occurs during boot.
 
 Sure, I was referring to run only when the computer is turned off.
 
  
  One possibility: noxhci-port-switch
 
 Okay. Any opinion of having xhci-hcd switch the routing during module
 unloading? I will prepare a boot param patch this week.

I would leave everything else the same as it is now.  Simply prevent
all port switching if the boot flag is given.  That will keep 
everything nice and simple.

A slightly more complicated approach would be noxhci-port-switch=0xYY
where YY is a bitmask of the ports which should never be allowed to be 
switched.  (This becomes unwieldy if there is more than one xHCI 
controller on the motherboard, but I don't think Intel is making any 
systems like that.)

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Alcatel usb modem

[Greg KH]

On Wed, Jan 08, 2014 at 10:45:43PM +0700, Lars Melin wrote:
 On 2014-01-02 23:59, Dan Williams wrote:
 On Sun, 2013-12-29 at 15:35 +0700, Lars Melin wrote:
 On 2013-12-29 00:55, Greg KH wrote:
 On Sat, Dec 28, 2013 at 02:13:08PM +, thomas.takacs.a...@gmail.com 
 wrote:
 Hi,
 I've seen this message: tell linux-usb... to add your device to a proper 
 device.
 My USB modem is Alcatel One Touch X080C.
 Please kindly add it or inform me how can I fix it.
 What is the full message that is printed out?  What is the vendor and
 device id of this device?  You are using the module parameters to add a
 device id to the usb-serial module, we can add the id to the proper
 driver if we know the ids of it.
 
 thanks,
 
 greg k-h
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Alcatel X085C  1bbb:0012
 
 %DEVICE1BBB0012% = Modem6k, USB\VID_1BBBPID_0012MI_00
 %DEVICE1BBB0012% = OEMportInstall6k, USB\VID_1BBBPID_0012MI_01
 %DEVICE1BBB0012% = OEMportInstall6k, USB\VID_1BBBPID_0012MI_02
 %DEVICE1BBB0012% = OEMportInstallSound, USB\VID_1BBBPID_0012MI_03
 The 6k indicates that it's likely a Qualcomm-based device like other
 Alcatel/TCT.  I would add the Modem, Service, and AT ports to the
 'option' driver using USB inteface numbers (eg,
 USB_DEVICE_INTERFACE_NUMBER using the MI_0x number).  Don't bind the
 Voice port since it's likely not a serial port.
 
 DEVICE1BBB0012 = ALCATEL CDMA Modem USB Modem
 DEVICE1BBB0012 = ALCATEL CDMA Modem Service Port
 DEVICE1BBB0012 = ALCATEL CDMA Modem AT Port
 DEVICE1BBB0012 = ALCATEL CDMA Modem Voice Port
 
 
 Alcatel X080C 1bbb:00ca
 
 %DEVICE1BBB00CA% = Modem6k, USB\VID_1BBBPID_00CAMI_00
 %DEVICE1BBB00CA% = OEMportInstall6k, USB\VID_1BBBPID_00CAMI_01
 %DEVICE1BBB00CA% = OEMportInstall6k, USB\VID_1BBBPID_00CAMI_02
 %DEVICE1BBB00CA% = OEMportInstallSound, USB\VID_1BBBPID_00CAMI_03
 
 DEVICE1BBB00CA = Modem X080C CDMA Modem USB Modem
 DEVICE1BBB00CA = Modem X080C CDMA Modem Service Port  (Diag)
 DEVICE1BBB00CA = Modem X080C CDMA Modem AT Port
 DEVICE1BBB00CA = Modem X080C CDMA Modem Voice Port
 Same here.  Bind 'option' to the device's Modem, Service, and AT ports
 by USB interface number but leave Voice alone.
 
 Dan
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
 The Voice Port is afaik serialised PCM data and the interface is present in
 other option supported
 Alcatel dongles made by TA Mobile Phones without being blacklisted.
 It's up to you or Greg K-H to decide, the info from Windows .inf file I
 posted above was in response
 to his request for more info which the reporter couldn't provide.

Can you convert the above information into a patch for the option driver
that people could test out and I could possibly apply?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

[David Laight]

 From: Alan Stern
 On Wed, 8 Jan 2014, David Laight wrote:
 
   From: Alan Stern
  
   This may be a foolish question, but why is xhci-hcd using no-op TRBs in
   the first place?
 
  Because it can't write in a link TRB because other parts of the
  code use link TRBs to detect the end of the ring.
 
  The problem is that it can't put a link TRB in the middle of
  a chain of data fragments unless it is at a 'suitable' offset
  from the start of the data TD. Given arbitrary input fragmentation
  this means that you can't put a link TRB in the middle of a TD.
  (The documented alignment might be as high as 16kB.)
 
  If the rest of the code used a 'ring end pointer' then a link TRB
  could be used instead.
 
 I see.  Sounds like a poor design decision in hindsight.  Can it be
 changed?

Anything can be changed :-)
But it is a bit pervasive.
Padding out with nops isolated the change.

David



--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH RFC alternative ver 1] phy: Exynos 421x USB 2.0 PHY support

[Kamil Debski]

Hi Kishon,

Thank you for your review.

 From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
 Sent: Monday, January 06, 2014 11:24 AM
 
 Hi,
 
 On Friday 20 December 2013 06:54 PM, Kamil Debski wrote:
  This the alternative version of the support for Exynos 421x USB 2.0
  PHY in the Generic PHY framework. In this version the support for
  Exynos
  4210 and 4212 was joined into one file.
 
  Signed-off-by: Kamil Debski k.deb...@samsung.com
  ---
  Hi,
 
  Me and Kishon were discussing for quite a long time the way how
 Exynos
  4 should be handled. I have decided to post the original patches and
  try to make an alternative version with support for Exynos 4210 and
  4212 joined in one file. I have prepared two versions. The first one
  has 506 lines (vs
  563 when two files are used). When doing the second version I was a
  little more aggresive in removing code. This was done at a cost of
  adding if's deciding which SoC version the driver is dealing with in
 some internal functions.
  This resulted in a better number of removed lines - the second
 version
  has only 452 lines (vs 563 original and 506 version 1).
 
 Alright.. If the alternate approach doesn't give too much of advantage,
 lets stick with the original one. I would recommend creating a
 documentation (Documentation/phy/?) for the samsung PHY since that
 actually creates a layer on top of generic PHY framework. That would
 help while adding new samsung PHY drivers.

Ok, I will prepare an updated set of patches with the documentation
added. Also I will fix other issues you pointed out in reply to other
patches from this series.

 
 Btw thank you for preparing alternate versions for your original
 patches.

No problem :)

Best wishes,
-- 
Kamil Debski
Samsung RD Institute Poland

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb:hub set hub-change_bits when over-current happens

[Alan Stern]

On Wed, 8 Jan 2014, Greg KH wrote:

 On Wed, Jan 08, 2014 at 02:45:42PM +0800, Shen Guang wrote:
  When we are doing compliance test with xHCI, we found that if we
  enable CONFIG_USB_SUSPEND and plug in a bad device which causes
  over-current condition to the root port, software will not be noticed.
  The reason is that current code don't set hub-change_bits in
  hub_activate() when over-current happens, and then hub_events() will
  not check the port status because it thinks nothing changed.
  If CONFIG_USB_SUSPEND is disabled, the interrupt pipe of the hub will
  report the change and set hub-event_bits, and then hub_events() will
  check what events happened.In this case over-current can be detected.
  
  Signed-off-by: Shen Guang shenguan...@gmail.com
  ---
   drivers/usb/core/hub.c |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
  index bd9dc35..98b5679 100644
  --- a/drivers/usb/core/hub.c
  +++ b/drivers/usb/core/hub.c
  @@ -1154,7 +1154,8 @@ static void hub_activate(struct usb_hub *hub,
  enum hub_activation_type type)
  /* Tell khubd to disconnect the device or
   * check for a new connection
   */
  -   if (udev || (portstatus  USB_PORT_STAT_CONNECTION))
  +   if (udev || (portstatus  USB_PORT_STAT_CONNECTION) 
  ||
  +   (portstatus  USB_PORT_STAT_OVERCURRENT))
  set_bit(port1, hub-change_bits);
  
  } else if (portstatus  USB_PORT_STAT_ENABLE) {
  --
  1.7.9.5
 
 Alan and Sarah, any objection to this patch?

It seems okay to me.

Acked-by: Alan Stern st...@rowland.harvard.edu

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v5 3/9] phy: Add new Exynos USB 2.0 PHY driver

[Kamil Debski]

Hi,

 From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
 Sent: Monday, January 06, 2014 11:12 AM
 
 Hi,
 
 On Friday 20 December 2013 06:54 PM, Kamil Debski wrote:
  Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the
  generic PHY framework. The driver includes support for the Exynos
 4x10
  and 4x12 SoC families.
 
  Signed-off-by: Kamil Debski k.deb...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
.../devicetree/bindings/phy/samsung-phy.txt|   55 
drivers/phy/Kconfig|   29 ++
drivers/phy/Makefile   |3 +
drivers/phy/phy-exynos4210-usb2.c  |  257
 
drivers/phy/phy-exynos4212-usb2.c  |  306
 
drivers/phy/phy-samsung-usb2.c |  226
 +++
drivers/phy/phy-samsung-usb2.h |   67 +
7 files changed, 943 insertions(+)
create mode 100644 drivers/phy/phy-exynos4210-usb2.c
create mode 100644 drivers/phy/phy-exynos4212-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.h
 
 .
 .
 snip
 .
 .
 
  diff --git a/drivers/phy/phy-samsung-usb2.h
  b/drivers/phy/phy-samsung-usb2.h new file mode 100644 index
  000..ab89f91
  --- /dev/null
  +++ b/drivers/phy/phy-samsung-usb2.h
  @@ -0,0 +1,67 @@
  +/*
  + * Samsung SoC USB 1.1/2.0 PHY driver
  + *
  + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
  + * Author: Kamil Debski k.deb...@samsung.com
  + *
  + * This program is free software; you can redistribute it and/or
  +modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + */
  +
  +#ifndef _PHY_EXYNOS_USB2_H
  +#define _PHY_EXYNOS_USB2_H
  +
  +#include linux/clk.h
  +#include linux/phy/phy.h
  +#include linux/device.h
  +#include linux/regmap.h
  +#include linux/spinlock.h
  +
  +#define KHZ 1000
  +#define MHZ (KHZ * KHZ)
  +
  +struct samsung_usb2_phy_driver;
  +struct samsung_usb2_phy_instance;
  +struct samsung_usb2_phy_config;
  +
  +struct samsung_usb2_phy_instance {
  +   const struct samsung_usb2_common_phy *cfg;
  +   struct clk *clk;
  +   struct phy *phy;
  +   struct samsung_usb2_phy_driver *drv;
  +   unsigned long rate;
  +   u32 clk_reg_val;
  +   bool enabled;
  +};
  +
  +struct samsung_usb2_phy_driver {
  +   const struct samsung_usb2_phy_config *cfg;
  +   struct clk *clk;
  +   struct device *dev;
  +   void __iomem *reg_phy;
  +   struct regmap *reg_pmu;
  +   struct regmap *reg_sys;
  +   spinlock_t lock;
  +   struct samsung_usb2_phy_instance instances[0];
 
 I think having instances as array here would allocate more space while
 allocating 'samsung_usb2_phy_driver' in 'samsung_usb2_phy_probe'.
 

I am not sure if I understand you correctly here. Maybe I will explain
what I intended to write. An array with size 0 at the end of a structure
takes no space in the structure. The benefit of using it is that after
the structure one can allocate a number of the array elements and
address them easily. Another option would be placing pointer in the
samsung_usb2_phy_instance and allocate memory separately, but this would
involve two allocations and a pointer would be always present in the 
structure.

Best wishes,
-- 
Kamil Debski
Samsung RD Institute Poland



--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Isochronous transfer error on USB3

[Mauro Carvalho Chehab]

Em Wed, 08 Jan 2014 15:05:12 -0200
Mauro Carvalho Chehab m.che...@samsung.com escreveu:

 Em Wed, 08 Jan 2014 14:31:28 -0200
 Mauro Carvalho Chehab m.che...@samsung.com escreveu:
 
  Em Thu, 02 Jan 2014 14:07:22 -0800
  Sarah Sharp sarah.a.sh...@linux.intel.com escreveu:
  
   On Sun, Dec 29, 2013 at 02:54:40AM -0200, Mauro Carvalho Chehab wrote:
It seems that usb_unlink_urb() is causing troubles with xHCI: the
endpoint stops streaming, but, after that, it doesn't start again,
and lots of debug messages are produced. I emailed you the full log
after start streaming in priv (too big for vger), but basically, 
it produces:

[ 1635.754546] xhci_hcd :00:14.0: Endpoint 0x81 not halted, 
refusing to reset.
[ 1635.754562] xhci_hcd :00:14.0: Endpoint 0x82 not halted, 
refusing to reset.
[ 1635.754577] xhci_hcd :00:14.0: Endpoint 0x83 not halted, 
refusing to reset.
[ 1635.754594] xhci_hcd :00:14.0: Endpoint 0x84 not halted, 
refusing to reset.
   
   I think that's due to the driver (or userspace) attempting to reset the
   endpoint when it didn't actually receive a stall (-EPIPE) status from an
   URB.  When that happens, the xHCI host controller endpoint toggle bits
   get out of sync with the device toggle bits, and the result is that all
   transfers will fail to the endpoint from then on until you switch
   alternate interface settings or unplug/replug the device.
   
   Try this patch:
   
   http://marc.info/?l=linux-usbm=138116117104619w=2
   
   It's still under RFC, and I know it has race conditions, but it will let
   you quickly test whether this fixes your issue.
  
  Didn't work fine, or at least it didn't solve all the problems. Also, it
  started to cause OOPSes due to the race conditions.
  
   
   This has been a long-standing xHCI driver bug.  I asked my OPW intern to
   work on the patch to fix it, but she may be a bit busy with her new job
   to finish up the RFC.  I'll probably have to take over finishing the
   patch, if this turns out to be your issue.
   
(Not sure why it is trying to stop all endpoints - as just one endpoint 
was
requested to restart).
   
   Something is calling into usb_clear_halt() with all the endpoints.
   Userspace, perhaps? 
  
  No, userspace is not doing it. The userspace doesn't even know that this
  device is USB (and were written at the time that all media drivers were
  PCI only - so it doesn't have any USB specific call on it).
  
   You could add WARN() calls to usb_clear_halt() to
   see what code is resetting the endpoints.  In any case, it's not part of
   the USB core code to change configuration or alt settings, since I don't
   see any xHCI driver output from the endpoint bandwidth code in this
   chunk of the dmesg you sent:
  
  The em28xx-audio.c driver may need to call usb_set_interface() while
  the video is still streaming, in order to unmute the audio. That happens
  when the audio device is opened.
  
  With EHCI, this works properly.
  
   [ 1649.640783] xhci_hcd :00:14.0: Removing canceled TD starting at 
   0xb41e8580 (dma).
   [ 1649.640784] xhci_hcd :00:14.0: TRB to noop at offset 0xb41e8580
   [ 1649.643159] xhci_hcd :00:14.0: Endpoint 0x81 not halted, refusing 
   to reset.
   [ 1649.643188] xhci_hcd :00:14.0: Endpoint 0x82 not halted, refusing 
   to reset.
   [ 1649.643215] xhci_hcd :00:14.0: Endpoint 0x83 not halted, refusing 
   to reset.
   [ 1649.643239] xhci_hcd :00:14.0: Endpoint 0x84 not halted, refusing 
   to reset.
   [ 1649.735539] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
   expansion
   
   Sarah Sharp
  
  Btw, sometimes, I get such logs:
  
  [  646.192273] xhci_hcd :00:14.0: Miss service interval error, set skip 
  flag
  [  646.192292] xhci_hcd :00:14.0: Miss service interval error, set skip 
  flag
  [  646.192311] xhci_hcd :00:14.0: Miss service interval error, set skip 
  flag
  [  646.192329] xhci_hcd :00:14.0: Miss service interval error, set skip 
  flag
  [  646.192351] xhci_hcd :00:14.0: Miss service interval error, set skip 
  flag
  [  646.192376] xhci_hcd :00:14.0: Miss service interval error, set skip 
  flag
  
  After adding some debug at em28xx-audio, triggering alsa trigger start
  events, I'm getting those:
  
  [ 3078.971224] snd_em28xx_capture_trigger: start capture
  [ 3078.971284] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
  expansion
  [ 3078.971311] xhci_hcd :00:14.0: ring expansion succeed, now has 4 
  segments
  [ 3078.971350] xhci_hcd :00:14.0: ERROR no room on ep ring, try ring 
  expansion
  [ 3078.971387] xhci_hcd :00:14.0: ring expansion succeed, now has 8 
  segments
  [ 3079.034626] em28xx_audio_isocirq, 64 packets (first one with size 12)
  
  Here, some audio data arrives.
  
  [ 3079.034665] snd_em28xx_capture_trigger: stop capture
  
  It seems, however, that this didn't arrive in time, and causes an alsa
  

Re: [PATCH v2 2/2] ehci-platform: Add support for clks and phy passed through devicetree

[Maxime Ripard]

On Wed, Jan 08, 2014 at 05:30:08PM +0100, Hans de Goede wrote:
 Currently ehci-platform is only used in combination with devicetree when used
 with some via socs. By extending it to (optionally) get clks and a phy from
 devicetree, and enabling / disabling those on power_on / off, it can be used
 more generically. Specifically after this commit it can be used for the
 ehci controller on Allwinner sunxi SoCs.
 
 Somehow we've ended up with 2 device-bindings documents for ehci-platform.c,
 this patch renames and updates one to platform-ehci.txt to reflect that this
 is a generic platform driver, and removes the other.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  .../devicetree/bindings/usb/platform-ehci.txt  |  25 
  .../devicetree/bindings/usb/via,vt8500-ehci.txt|  15 ---
  .../devicetree/bindings/usb/vt8500-ehci.txt|  12 --
  drivers/usb/host/ehci-platform.c   | 126 
 +
  4 files changed, 131 insertions(+), 47 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/platform-ehci.txt
  delete mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
  delete mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
 
 diff --git a/Documentation/devicetree/bindings/usb/platform-ehci.txt 
 b/Documentation/devicetree/bindings/usb/platform-ehci.txt
 new file mode 100644
 index 000..56c478d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/platform-ehci.txt
 @@ -0,0 +1,25 @@
 +Generic Platform EHCI controller
 +
 +Required properties:
 +- compatible : via,vt8500-ehci or wm,prizm-ehci
 +- reg : ehci controller register range (address and length)
 +- interrupts : ehci controller interrupt
 +
 +Optional properties:
 +- clocks : a list of phandle + clock specifier pairs, one for each entry
 +   in clock-names.
 +- clock-names : clk0, clk1, ...
 +- phys : phy
 +- phy-names : phy0
 +
 +Example:
 +
 + ehci@d8007900 {
 + compatible = via,vt8500-ehci;
 + reg = 0xd8007900 0x200;
 + interrupts = 43;
 + clocks = usb_clk 6, ahb_gates 2;
 + clock-names = clk0, clk1;

I'm really not convinced by this either. It prevents you from doing
anything useful out of these clocks, and the only thing you can
actually do with it is calling clk_get, and that's pretty much it.

What if you some platform needs to adjust the rate of one of the two?
Or wants to cut one but not the other for any reason? You're just
screwed, and you can do anything about it, because you have no way of
telling what clk0 is used for.

Especially, since what you really want is to access the clocks by
index, that you can do with of_clk_get.

Calling it bus and phy or whatever it's used for both provide a
way of differentiating the two, yet being rather generic. And if we
need to add a third one, I'm pretty sure we will be able to come up
with a generic name then.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH] usb:hub set hub-change_bits when over-current happens

[Sarah Sharp]

On Wed, Jan 08, 2014 at 12:49:57PM -0500, Alan Stern wrote:
 On Wed, 8 Jan 2014, Greg KH wrote:
 
  On Wed, Jan 08, 2014 at 02:45:42PM +0800, Shen Guang wrote:
   When we are doing compliance test with xHCI, we found that if we
   enable CONFIG_USB_SUSPEND and plug in a bad device which causes
   over-current condition to the root port, software will not be noticed.
   The reason is that current code don't set hub-change_bits in
   hub_activate() when over-current happens, and then hub_events() will
   not check the port status because it thinks nothing changed.
   If CONFIG_USB_SUSPEND is disabled, the interrupt pipe of the hub will
   report the change and set hub-event_bits, and then hub_events() will
   check what events happened.In this case over-current can be detected.
   
   Signed-off-by: Shen Guang shenguan...@gmail.com
   ---
drivers/usb/core/hub.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
   
   diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
   index bd9dc35..98b5679 100644
   --- a/drivers/usb/core/hub.c
   +++ b/drivers/usb/core/hub.c
   @@ -1154,7 +1154,8 @@ static void hub_activate(struct usb_hub *hub,
   enum hub_activation_type type)
   /* Tell khubd to disconnect the device or
* check for a new connection
*/
   -   if (udev || (portstatus  
   USB_PORT_STAT_CONNECTION))
   +   if (udev || (portstatus  
   USB_PORT_STAT_CONNECTION) ||
   +   (portstatus  USB_PORT_STAT_OVERCURRENT))
   set_bit(port1, hub-change_bits);
   
   } else if (portstatus  USB_PORT_STAT_ENABLE) {
   --
   1.7.9.5
  
  Alan and Sarah, any objection to this patch?
 
 It seems okay to me.
 
 Acked-by: Alan Stern st...@rowland.harvard.edu

Looks fine to me as well.

Acked-by: Sarah Sharp sarah.a.sh...@linux.intel.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v2 6/6] r8152: support RTL8153

[Ben Hutchings]

On Tue, 2014-01-07 at 20:35 +0800, hayeswang wrote:
  Bjørn Mork [mailto:bj...@mork.no] 
  Sent: Monday, January 06, 2014 5:22 PM
  To: Hayeswang
  Cc: oli...@neukum.org; net...@vger.kernel.org; nic_swsd; 
  linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
  Subject: Re: [PATCH net-next v2 6/6] r8152: support RTL8153
 [...]
  Exactly the same device, but now cfg #1 is active and a 
  different set of
  drivers have bound to the interfaces.  This is possible 
  because none of
  the involved drivers disable the support for this device at 
  build-time.
  Instead they use the available interface descriptors for matching and
  probing supported functions.
  
  End users will of course normally not go around writing stuff to sysfs
  attributes like this.  Creating an udev rule to select a specific
  counfiguration when the device is plugged is more useful for normal
  usage.
 
 Thanks for your answer. I would study udev rule first.
 Does the udev alwayes exist for all Linux system, such as
 Android, embedded system, and so on?

They may not have udev, but if not they will normally have an alternate
such as mdev.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fw: Isochronous transfer error on USB3

[Mauro Carvalho Chehab]

Hi Hans/Takashi,

I'm getting an weird behavior with em28xx, especially when the device
is connected into an audio port.

I'm using, on my tests, an em28xx HVR-950 device, using this tree:

http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/em28xx-v4l2-v6
Where the alsa driver is at:

http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c

I'm testing it with xawtv3 (http://git.linuxtv.org/xawtv3.git). The
ALSA userspace code there is at:
http://git.linuxtv.org/xawtv3.git/blob/HEAD:/common/alsa_stream.c

What happens is that, when I require xawtv3 to use any latency lower 
than 65 ms, the audio doesn't work, as it gets lots of underruns per
second. 

FYI, em28xx works at a 48000 KHz sampling rate, and its PM capture Hw
is described as:

static struct snd_pcm_hardware snd_em28xx_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP   |
SNDRV_PCM_INFO_INTERLEAVED|
SNDRV_PCM_INFO_BATCH  |
SNDRV_PCM_INFO_MMAP_VALID,

.formats = SNDRV_PCM_FMTBIT_S16_LE,

.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,

.rate_min = 48000,
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
.buffer_bytes_max = 62720 * 8,  /* just about the value in usbaudio.c */
.period_bytes_min = 64, /* 12544/2, */
.period_bytes_max = 12544,
.periods_min = 2,
.periods_max = 98,  /* 12544, */
};

On my tests, I experimentally discovered that the minimal latency to
avoid ALSA library underruns is:
- 65ms when using xHCI;
- 25ms when using EHCI.

Any latency lower than that causes lots of overruns. Very high
latency also causes overruns (but on a lower rate, as the period
is bigger).

I'm wandering if is there anything that could be done either at Kernel
side or at userspace side to automatically get some configuration that
works as-is, without requiring the user to play with the latency parameter
by hand.

The alsa-info data is enclosed.

Thank you!
Mauro

PS.: I'm still trying to understand why the minimal allowed latency is
different when using xHCI, but I suspect that it is because it uses a
different urb-interval than EHCI.

Forwarded message:

Date: Wed, 08 Jan 2014 16:03:51 -0200
From: Mauro Carvalho Chehab m.che...@samsung.com
To: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: jean-philippe francois jp.franc...@cynove.com, linux-usb@vger.kernel.org, 
LMML linux-me...@vger.kernel.org, Shuah Khan shuah...@samsung.com
Subject: Re: Isochronous transfer error on USB3


Em Wed, 08 Jan 2014 15:05:12 -0200
Mauro Carvalho Chehab m.che...@samsung.com escreveu:

 Em Wed, 08 Jan 2014 14:31:28 -0200
 Mauro Carvalho Chehab m.che...@samsung.com escreveu:
 
  Em Thu, 02 Jan 2014 14:07:22 -0800
  Sarah Sharp sarah.a.sh...@linux.intel.com escreveu:
  
   On Sun, Dec 29, 2013 at 02:54:40AM -0200, Mauro Carvalho Chehab wrote:
It seems that usb_unlink_urb() is causing troubles with xHCI: the
endpoint stops streaming, but, after that, it doesn't start again,
and lots of debug messages are produced. I emailed you the full log
after start streaming in priv (too big for vger), but basically, 
it produces:

[ 1635.754546] xhci_hcd :00:14.0: Endpoint 0x81 not halted, 
refusing to reset.
[ 1635.754562] xhci_hcd :00:14.0: Endpoint 0x82 not halted, 
refusing to reset.
[ 1635.754577] xhci_hcd :00:14.0: Endpoint 0x83 not halted, 
refusing to reset.
[ 1635.754594] xhci_hcd :00:14.0: Endpoint 0x84 not halted, 
refusing to reset.
   
   I think that's due to the driver (or userspace) attempting to reset the
   endpoint when it didn't actually receive a stall (-EPIPE) status from an
   URB.  When that happens, the xHCI host controller endpoint toggle bits
   get out of sync with the device toggle bits, and the result is that all
   transfers will fail to the endpoint from then on until you switch
   alternate interface settings or unplug/replug the device.
   
   Try this patch:
   
   http://marc.info/?l=linux-usbm=138116117104619w=2
   
   It's still under RFC, and I know it has race conditions, but it will let
   you quickly test whether this fixes your issue.
  
  Didn't work fine, or at least it didn't solve all the problems. Also, it
  started to cause OOPSes due to the race conditions.
  
   
   This has been a long-standing xHCI driver bug.  I asked my OPW intern to
   work on the patch to fix it, but she may be a bit busy with her new job
   to finish up the RFC.  I'll probably have to take over finishing the
   patch, if this turns out to be your issue.
   
(Not sure why it is trying to stop all endpoints - as just one endpoint 
was
requested to restart).
   
   Something is calling into usb_clear_halt() with all the endpoints.
   

Re: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.

[tatxarata]

Oops.. my bad...

It seems like wireshark misses some data while capturing on usbmon 
device. According to LBA addresses in subsequent SCSI commands it looks 
like on a request of 240 sectors host really gets from device 240 
sectors. On the other hand for each such request in the capture exists 
only one URB_BULK packet with data and the size of this data covers only 
120 sectors (61440 bytes). As a consequence size of capture file is 
about twice less than size of files transferred to create this capture.


In my previous examinations I've took into account only size of URB_BULK 
packets and missed out the difference between subsequent LBA addresses.


For such URB_BULK packets wireshark states URB length: 122880, Data 
length: 61440. Reading of Documentation/usb/usbmon.txt didn't clarified 
for me what does this mean. Whether this is limitation of usbmon or a 
feature of wireshark.


Sorry for that inconvenience.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()

[David Cohen]

On Wed, Jan 08, 2014 at 10:48:06AM -0500, Alan Stern wrote:
 On Tue, 7 Jan 2014, Greg KH wrote:
 
  On Tue, Jan 07, 2014 at 05:44:26PM -0800, David Cohen wrote:
   From: jianqian jianqiang.t...@intel.com
   
   There is a possible kernel panic faced on xhci_suspend().
   Due to kernel modified the hub autosupend_delay to 0s, after usb1 root
   hub finishes initialization, it will trigger runtime_suspend and then
   it will trigger xhci runtime suspend. But at that time, if
   xhci-shared_hcd is still doing initialization, it is possible to face
   null pointer kernel panic in xhci_suspend() function.
   
   This patch checks if xhci-shared_hcd is null to avoid panic.
  
  That sounds like this is a race that should be fixed properly, not just
  papered over, right?
 
 That was my reaction too.  The best way to solve the problem is to 
 prevent the USB-2 root hub from suspending until after the USB-3 root 
 hub has been registered.

That makes sense. Thanks for the feedback.
I'll check for a new approach.

Br, David Cohen

 
 Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] xhci: Avoid infinite loop when sg urb requires too many trbs

[Sarah Sharp]

From: Ben Hutchings b...@decadent.org.uk

Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
single ring segment.  usb_sg_wait() treats this error as a temporary
condition and will keep retrying until something else goes wrong.

The number of retries should be limited in usb_sg_wait(), but also
prepare_ring() should not return an error code that suggests it might
be worth retrying.  Change it to -EINVAL.

Reported-by: jida...@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload 
burst')
Cc: stable sta...@vger.kernel.org # 3.12
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
 drivers/usb/host/xhci-ring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 09b2b551be72..a0b248c34526 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3000,7 +3000,7 @@ static int prepare_ring(struct xhci_hcd *xhci, struct 
xhci_ring *ep_ring,
if (num_trbs = TRBS_PER_SEGMENT) {
xhci_err(xhci, Too many fragments %d, max 
%d\n,
num_trbs, TRBS_PER_SEGMENT - 1);
-   return -ENOMEM;
+   return -EINVAL;
}
 
nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
-- 
1.8.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] xhci: Set scatter-gather limit to avoid failed block writes.

[Sarah Sharp]

Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e usb: xhci: Link TRB
must not occur within a USB payload burst attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices.  The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).

usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:

http://marc.info/?l=linux-usbm=138498190419312w=2

That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):

Jan  1 07:04:49 jidanni5 kernel: [  559.624704] xhci_hcd :00:14.0: Too many 
fragments 79, max 63
...
Jan  1 07:04:58 jidanni5 kernel: [  568.622583] Write(10): 2a 00 00 06 85 0e 00 
00 da 00

Limit the number of scatter-gather entries to half a ring segment.  That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.

Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: jida...@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload 
burst')
Cc: stable sta...@vger.kernel.org # 3.12
---
 drivers/usb/host/xhci.c | 4 ++--
 drivers/usb/host/xhci.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f8ffc512faf1..ad364394885a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4730,8 +4730,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t 
get_quirks)
struct device   *dev = hcd-self.controller;
int retval;
 
-   /* Accept arbitrarily long scatter-gather lists */
-   hcd-self.sg_tablesize = ~0;
+   /* Limit the block layer scatter-gather lists to half a segment. */
+   hcd-self.sg_tablesize = TRBS_PER_SEGMENT / 2;
 
/* support to build packet from discontinuous buffers */
hcd-self.no_sg_constraint = 1;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 24344aab2107..f8416639bf31 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1279,7 +1279,7 @@ union xhci_trb {
  * since the command ring is 64-byte aligned.
  * It must also be greater than 16.
  */
-#define TRBS_PER_SEGMENT   64
+#define TRBS_PER_SEGMENT   256
 /* Allow two commands + a link TRB, along with any reserved command TRBs */
 #define MAX_RSVD_CMD_TRBS  (TRBS_PER_SEGMENT - 3)
 #define TRB_SEGMENT_SIZE   (TRBS_PER_SEGMENT*16)
-- 
1.8.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] xhci: Urgent bug fixes for usb-next and 3.14.

[Sarah Sharp]

The following changes since commit d85b277ed1d3ff7b6084bf13963ab0a66544e81c:

  usb: gadget: remove unused variable in gr_queue_int() (2014-01-07 16:30:25 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
tags/for-usb-next-2014-01-08

for you to fetch changes up to f2d9b991c549f159dc9ae81f77d8206c790cbfee:

  xhci: Set scatter-gather limit to avoid failed block writes. (2014-01-08 
11:00:52 -0800)


xhci: Urgent bug fixes for usb-next and 3.14.

Hi Greg,

Please queue these two patches to usb-next for 3.14.

An xHCI driver fix for USB ethernet devices that went into 3.13 and 3.12
stable is causing usb-storage to go into an infinite loop, and these two
patches fix the issue.  I would like these to get into 3.14-rc1 so we
can avoid any potential data corruption for users.

Sarah Sharp


Ben Hutchings (1):
  xhci: Avoid infinite loop when sg urb requires too many trbs

Sarah Sharp (1):
  xhci: Set scatter-gather limit to avoid failed block writes.

 drivers/usb/host/xhci-ring.c |2 +-
 drivers/usb/host/xhci.c  |4 ++--
 drivers/usb/host/xhci.h  |2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.

[Alan Stern]

On Wed, 8 Jan 2014, tatxarata wrote:

 Oops.. my bad...
 
 It seems like wireshark misses some data while capturing on usbmon 
 device. According to LBA addresses in subsequent SCSI commands it looks 
 like on a request of 240 sectors host really gets from device 240 
 sectors. On the other hand for each such request in the capture exists 
 only one URB_BULK packet with data and the size of this data covers only 
 120 sectors (61440 bytes). As a consequence size of capture file is 
 about twice less than size of files transferred to create this capture.
 
 In my previous examinations I've took into account only size of URB_BULK 
 packets and missed out the difference between subsequent LBA addresses.
 
 For such URB_BULK packets wireshark states URB length: 122880, Data 
 length: 61440. Reading of Documentation/usb/usbmon.txt didn't clarified 
 for me what does this mean. Whether this is limitation of usbmon or a 
 feature of wireshark.

You may get better results if instead of Wireshark, you use the text
interface for usbmon as described in the the usbmon.txt file.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fw: Isochronous transfer error on USB3

[Alan Stern]

On Wed, 8 Jan 2014, Mauro Carvalho Chehab wrote:

 Hi Hans/Takashi,
 
 I'm getting an weird behavior with em28xx, especially when the device
 is connected into an audio port.
 
 I'm using, on my tests, an em28xx HVR-950 device, using this tree:
   
 http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/em28xx-v4l2-v6
 Where the alsa driver is at:
   
 http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c
 
 I'm testing it with xawtv3 (http://git.linuxtv.org/xawtv3.git). The
 ALSA userspace code there is at:
   http://git.linuxtv.org/xawtv3.git/blob/HEAD:/common/alsa_stream.c
 
 What happens is that, when I require xawtv3 to use any latency lower 
 than 65 ms, the audio doesn't work, as it gets lots of underruns per
 second. 
 
 FYI, em28xx works at a 48000 KHz sampling rate, and its PM capture Hw
 is described as:
 
 static struct snd_pcm_hardware snd_em28xx_hw_capture = {
   .info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
   SNDRV_PCM_INFO_MMAP   |
   SNDRV_PCM_INFO_INTERLEAVED|
   SNDRV_PCM_INFO_BATCH  |
   SNDRV_PCM_INFO_MMAP_VALID,
 
   .formats = SNDRV_PCM_FMTBIT_S16_LE,
 
   .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,
 
   .rate_min = 48000,
   .rate_max = 48000,
   .channels_min = 2,
   .channels_max = 2,
   .buffer_bytes_max = 62720 * 8,  /* just about the value in usbaudio.c */
   .period_bytes_min = 64, /* 12544/2, */
   .period_bytes_max = 12544,
   .periods_min = 2,
   .periods_max = 98,  /* 12544, */
 };
 
 On my tests, I experimentally discovered that the minimal latency to
 avoid ALSA library underruns is:
   - 65ms when using xHCI;
   - 25ms when using EHCI.
 
 Any latency lower than that causes lots of overruns. Very high
 latency also causes overruns (but on a lower rate, as the period
 is bigger).
 
 I'm wandering if is there anything that could be done either at Kernel
 side or at userspace side to automatically get some configuration that
 works as-is, without requiring the user to play with the latency parameter
 by hand.
 
 The alsa-info data is enclosed.
 
 Thank you!
 Mauro
 
 PS.: I'm still trying to understand why the minimal allowed latency is
 different when using xHCI, but I suspect that it is because it uses a
 different urb-interval than EHCI.

You may be able to answer some of these questions by collecting usbmon 
traces (see Documentation/usb/usbmon.txt).  That would help pinpoint 
sources of latency and tell you the actual URB intervals.

25 ms to avoid underruns seems pretty large.  Other people, using audio 
only (no video), find that EHCI can work well with latencies as low as 
2 ms or so.  (That's using 3.13-rc, which includes some changes in the 
snd-usb-audio driver.)

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] xhci: Urgent bug fixes for usb-next and 3.14.

[Greg Kroah-Hartman]

On Wed, Jan 08, 2014 at 11:59:14AM -0800, Sarah Sharp wrote:
 The following changes since commit d85b277ed1d3ff7b6084bf13963ab0a66544e81c:
 
   usb: gadget: remove unused variable in gr_queue_int() (2014-01-07 16:30:25 
 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
 tags/for-usb-next-2014-01-08

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] ohci-platform: Add support for devicetree instantiation

[Florian Fainelli]

Hello,

2014/1/8 Hans de Goede hdego...@redhat.com:
 Add support for ohci-platform instantiation from devicetree, including
 optionally getting clks and a phy from devicetree, and enabling / disabling
 those on power_on / off.

 This should allow using ohci-platform from devicetree in various cases.
 Specifically after this commit it can be used for the ohci controller found
 on Allwinner sunxi SoCs.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  .../devicetree/bindings/usb/platform-ohci.txt  |  25 
  drivers/usb/host/ohci-platform.c   | 148 
 ++---
  2 files changed, 153 insertions(+), 20 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/platform-ohci.txt

 diff --git a/Documentation/devicetree/bindings/usb/platform-ohci.txt 
 b/Documentation/devicetree/bindings/usb/platform-ohci.txt
 new file mode 100644
 index 000..44bfa57
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/platform-ohci.txt

ohci-mmio might be a better name than platform maybe?

[snip]

 +static int ohci_platform_power_on(struct platform_device *dev)
 +{
 +   struct usb_hcd *hcd = platform_get_drvdata(dev);
 +   struct ohci_platform_priv *priv =
 +   (struct ohci_platform_priv *)hcd_to_ohci(hcd)-priv;
 +   int clk, ret;
 +
 +   for (clk = 0; priv-clks[clk]  clk  OHCI_MAX_CLKS; clk++) {
 +   ret = clk_prepare_enable(priv-clks[clk]);
 +   if (ret)
 +   goto err_disable_clks;
 +   }

Do we really need to cap this to OHCI_MAX_CLKS, the next driver which
has 4 clocks will have to bump this, so maybe a linked-list would be
best?

 +
 +   if (priv-phy) {
 +   ret = phy_init(priv-phy);
 +   if (ret)
 +   goto err_disable_clks;
 +
 +   ret = phy_power_on(priv-phy);
 +   if (ret)
 +   goto err_exit_phy;
 +   }

Although I do value the idea of having DT probing for ohci-platform,
ehci-platform et al, I am not sure if this really belongs in the
generic OHCI platform driver, or if we should rather have small glue
drivers which register the ohci-platform driver and which provides all
the platform-specific power_on, power_off, suspend callbacks to the
ohci platform driver? Such glue driver would be the one which gets
probed based off a specific compatible string a

At first glance it does look like this covers 80% of the existing OHCI
drivers out there, so this is good. We might also want to support
clock pointers provided via platform_data so we can remove ohci-at91,
ohci-ep93xx, ohci-spear and friends in the future.

ohci-ppc-of could also probably be removed once we add quirks and
endian properties parsing to ohci-platform?

 +
 +   return 0;
 +
 +err_exit_phy:
 +   phy_exit(priv-phy);
 +err_disable_clks:
 +   while (--clk = 0)
 +   clk_disable_unprepare(priv-clks[clk]);
 +
 +   return ret;
 +}
 +
 +static void ohci_platform_power_off(struct platform_device *dev)
 +{
 +   struct usb_hcd *hcd = platform_get_drvdata(dev);
 +   struct ohci_platform_priv *priv =
 +   (struct ohci_platform_priv *)hcd_to_ohci(hcd)-priv;
 +   int clk;
 +
 +   if (priv-phy) {
 +   phy_power_off(priv-phy);
 +   phy_exit(priv-phy);
 +   }
 +
 +   for (clk = OHCI_MAX_CLKS - 1; clk = 0; clk--)
 +   if (priv-clks[clk])
 +   clk_disable_unprepare(priv-clks[clk]);
 +}
 +
  static struct hc_driver __read_mostly ohci_platform_hc_driver;

  static const struct ohci_driver_overrides platform_overrides __initconst = {
 -   .product_desc = Generic Platform OHCI controller,
 -   .reset =ohci_platform_reset,
 +   .product_desc = Generic Platform OHCI controller,
 +   .reset =ohci_platform_reset,
 +   .extra_priv_size =  sizeof(struct ohci_platform_priv),
 +};
 +
 +static struct usb_ohci_pdata ohci_platform_defaults = {
 +   .power_on = ohci_platform_power_on,
 +   .power_suspend =ohci_platform_power_off,
 +   .power_off =ohci_platform_power_off,
  };

  static int ohci_platform_probe(struct platform_device *dev)
 @@ -60,12 +128,24 @@ static int ohci_platform_probe(struct platform_device 
 *dev)
 struct usb_hcd *hcd;
 struct resource *res_mem;
 struct usb_ohci_pdata *pdata = dev_get_platdata(dev-dev);
 -   int irq;
 -   int err = -ENOMEM;
 +   int clk, irq, err;
 +   char name[8];

 +   /*
 +* Use reasonable defaults so platforms don't have to provide these
 +* with DT probing on ARM.
 +*/
 if (!pdata) {
 -   WARN_ON(1);
 -   return -ENODEV;
 +   pdata = dev-dev.platform_data = ohci_platform_defaults;
 +   /*
 +* Right now device-tree probed devices don't get dma_mask 
 set.
 + 

Re: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.

[tatxarata]

On 01/08/2014 08:50 PM, Alan Stern wrote:

On Wed, 8 Jan 2014, tatxarata wrote:


Since reporting this bug I've invested some time to get myself familiar
with USB protocol and analyzed attached capture files. It seems like
device resetoccurs after device returns urb_status=-75 (-EOVERFLOW).


Yes.  The EOVERFLOW error is what causes the driver to do a reset.


This can be seen in attachment
https://bugzilla.kernel.org/attachment.cgi?id=120901 in packet #1987.
Also I've noticed that host tries to read device by chunks of 240
sectors while device returns on each query no more than 120 sectors
(61440 bytes).


That's not true in the log file you just mentioned.  See packet #1955.



Sorry... my bad... Described reason of my confusion in the previous 
message on the mailing list.



  From traffic it is clearly seen that EOVERFLOW occurs after the device
is already mounted and while software tries to browse it's content.
When I do something like 'dd if=/dev/sdb of=/dev/null' where sdb is CF
card or mount and copy with shell commands host-device communication
scheme is the same (240 sectors requested, 120 returned), but this
doesn't lead to EOVERFLOW. In that cases read speed is at about 80Mb/s.
So I suppose that something wrong happens only while software like
thunar or midnight commander tries to browse the contents of card (maybe
parallel threads trying to access card simultaneously?).


That wouldn't matter.  usb-storage serializes accesses to the device.


With that knowledge I've tried to tweak some device parameters in /sys
filesystem. When I put value 60 in /sys/block/sd?/queue/max_sectors_kb
then all operates correctly without any resets. However in this case
read speed of card drops down by factor of two at around 40Mb/s.

When I set max_sectors_kb to 64 then device does reset upon mount in
thunar, however, surprisingly, this doesn't lead to dropping of device
mount, like in case of default value of 120. In this case read speed is
at about 89.5Mb/s, as expected by card specs. So I've added udev rule
that corrects value of max_sectors_kb to 64 upon device connection. For
now I can live with this 10 seconds latency of device mounting if latter
it works properly. However I think that the reason of this issue must be
clarified and fixed.


It seems like a bug in the device.



However in Windows 8 all (I mean this particular combination of 
notebook, card reader and CF card) works fine with stable speed of about 
75Mb/s. CF card also works without any issues in Nikon D800 body.


Also I really can't understand the difference of 
mount/cd/ls/cp/mv/rm/umount in shell and the same operations in GUI via 
Thunar.



Also tried to set queue/scheduler to noop with no effect.

In case of USB2.0 host-device traffic looks pretty the same way as in
case of USB3.0. Host also tries to read device by chunks of 240 sectors
and device returns only 120. However for some reason this doesn't lead
to EOVERFLOW.

Main difference I've managed to find between usb 2.0 and 3.0 traffic is
the device initialization. In case of 3.0 there are some
CLEAR_FEATURE/SET_FEATURE requests that are missing in case of 2.0, so
maybe device operates differently by that reason.


Maybe, but I doubt it.  Those requests are mostly concerned with Link
Power Management.

What happens if you connect the card reader to a USB-3 port using a
USB-2 cable?



With USB-2 cable all works fine except the speed.


Alan Stern




Things are getting more interesting.
I've tried to format card with ext4 and restored default value 120 of 
max_sectors_kb . In that case mounting and writing to card with thunar 
works fine at a solid speed of 90Mb/s, but reading is at about awful 
1Mb/s. Capture shows a frequent stalls when after reading a chunk of 
data device after 7 seconds of silence reports status -EPIPE (-32). No 
EOVERFLOW errors occurred.
Same thing when I formatted it with mkfs.vfat, but write speed is at 
about 50Mb/s.
At last I've formatted the card with photo camera and situation returned 
to initial state.


Also I've ran into one more issue: after some extensive testing of this 
device all of my USB3.0 ports stop working at all until reboot. dmesg on 
kernel-3.10.17 on which I've done today's tests says something like:


[131396.290944] hub 3-0:1.0: hub_resume
[131396.290953] hub 3-0:1.0: port 4: status 0507 change 
[131396.290956] hub 3-0:1.0: state 7 ports 4 chg  evt 
[131396.290959] hub 3-0:1.0: hub_suspend
[131396.290961] usb usb3: bus auto-suspend, wakeup 1
[131396.290962] usb usb3: bus suspend fail, err -16
...
[131396.290987] usb usb3: bus suspend fail, err -16
[131396.290989] hub 3-0:1.0: hub_resume
[131396.291003] hub 3-0:1.0: port 4: status 0503 change 0004
[131396.291010] hub 3-0:1.0: state 7 ports 4 chg 0010 evt 
[131396.301990] usb 3-4: usb wakeup-resume
[131396.302000] usb 3-4: finish resume
[131396.302062] hub 3-4:1.0: hub_resume
[131396.302104] hub 3-4:1.0: port 1: status 0503 change 0004
[131396.302187] hub 3-0:1.0: 

Re: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL

[Belisko Marek]

Any pointers? Still present in 3.13-rc7.

On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros rog...@ti.com wrote:
 +Kishon

 On 12/03/2013 11:33 PM, Belisko Marek wrote:
 Hi,

 current 3.13-rcX break usb support on gta04 board (similar to
 beagleboard) when booting via board file.

 In console we can see messages:
  [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL 
 clock
 [ 5232.936096] omap_musb_mailbox: musb core is not yet ready
 [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL 
 clock
 [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL 
 clock

 Any pointer what could cause that? (in 3.12 usb works fine)

 BR,

 marek



BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] usb: chipidea: add OTG HNP polling support.

[Felipe Balbi]

Hi,

On Wed, Jan 08, 2014 at 05:06:23PM +0800, Li Jun wrote:
 This patch add OTG HNP polling support for both A and B device.
 After A/B in host state, host request polling message will be sent
 from host to peripheral every 1.5s, if host found the host request
 flag is set to be 1 by peripheral, a role switch will be started.
 
 Signed-off-by: Li Jun b47...@freescale.com
 ---
  drivers/usb/chipidea/ci.h  |2 +
  drivers/usb/chipidea/otg_fsm.c |   80 
 
  drivers/usb/chipidea/otg_fsm.h |3 +
  drivers/usb/chipidea/udc.c |   11 -
  drivers/usb/phy/phy-fsm-usb.c  |6 +++

you need to figure out a way to split this patch, the dependency you
created here is really pointless.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC 2/2] dual scan thread bug fix

[James Bottomley]

On Wed, 2014-01-08 at 10:57 -0500, Alan Stern wrote:
 On Wed, 8 Jan 2014, James Bottomley wrote:
 
  OK, Agreed, but that means modifying the 1/2 patch with the below.  This
  should make the proposed diff to 2/2 correct.
  
  James
  
  ---
  diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
  index ef3f958..5fad646 100644
  --- a/drivers/scsi/scsi_scan.c
  +++ b/drivers/scsi/scsi_scan.c
  @@ -417,7 +417,7 @@ static struct scsi_target *scsi_alloc_target(struct 
  device *parent,
  + shost-transportt-target_size;
  struct scsi_target *starget;
  struct scsi_target *found_target;
  -   int error;
  +   int error, ref_got;
   
  starget = kzalloc(size, GFP_KERNEL);
  if (!starget) {
  @@ -466,15 +466,15 @@ static struct scsi_target *scsi_alloc_target(struct 
  device *parent,
  return starget;
   
found:
  -   if (!kref_get_unless_zero(found_target-reap_ref))
  -   /*
  -* release routine already fired.  Target is dead, but
  -* STARGET_DEL may not yet be set (set in the release
  -* routine), so set here as well, just in case
  -*/
  -   found_target-state = STARGET_DEL;
  +   /*
  +* release routine already fired if kref is zero, so if we can still
  +* take the reference, the target must be alive.  If we can't, it must
  +* be dying and we need to wait for a new target
  +*/
  +   ref_got = kref_get_unless_zero(found_target-reap_ref);
  +
  spin_unlock_irqrestore(shost-host_lock, flags);
  -   if (found_target-state != STARGET_DEL) {
  +   if (ref_got) {
  put_device(dev);
  return found_target;
  }
  @@ -482,8 +482,8 @@ static struct scsi_target *scsi_alloc_target(struct 
  device *parent,
   * Unfortunately, we found a dying target; need to wait until it's
   * dead before we can get a new one.  There is an anomaly here.  We
   * *should* call scsi_target_reap() to balance the kref_get() of the
  -* reap_ref above.  However, since the target is in state STARGET_DEL,
  -* it's already invisible and the reap_ref is irrelevant.  If we call
  +* reap_ref above.  However, since the target being released, it's
  +* already invisible and the reap_ref is irrelevant.  If we call
   * scsi_target_reap() we might spuriously do another device_del() on
   * an already invisible target.
   */
 
 In fact, most of this comment (everything after the first sentence) is
 no longer needed.  If the target is dying then kref_get_unless_zero
 must have failed, so there is no need to worry about unbalanced
 refcounts.

I'd like to keep the comment: I get a lot of email from people who write
static checkers for this.  In principle, I agree, they should treat
kref_get_unless_zero() as a spin_trylock(), but it's nice to have
something concrete in the code to point to when the email arrives.

 Otherwise this looks good.

Great, thanks, I'll re-roll and repost.

James



--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] xhci: Allocate the td array and urb_priv together.

['David Cohen']

On Wed, Jan 08, 2014 at 03:29:31PM +, David Laight wrote:
  From: 'David Cohen'
 ...
  I actually don't know what's the regular range of 'td_cnt'. But what got my
  attention was this comment from patch description:
  
  The only possible downside is for isochronous tranfers with 64 td
  when the allocate is 8+4096 bytes (on 64bit systems) so requires
  an additional page.
 
 I wrote that just in case anyone knew that 64 td would be common.
 I suspect the typical number is much lower.

Ah :) That clears things up. Your patch won't influence kmalloc 
PAGE_SIZE in general. Although leaving the pointers in a different
struct preserves the possibility to call kmalloc multiple times when
xhci_td's allocation requires more than PAGE_SIZE.

But again, I'm not sure how often this happens, so I have not much
arguments in favor or against it.

Br, David Cohen

 
   David
 
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: c67x00: fix up line break coding style issues

[Greg Kroah-Hartman]

On Wed, Jan 08, 2014 at 10:01:54PM +0530, Rahul Bedarkar wrote:
 
 Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
 ---
  drivers/usb/c67x00/c67x00-drv.c|  3 ++-
  drivers/usb/c67x00/c67x00-hcd.h|  2 +-
  drivers/usb/c67x00/c67x00-ll-hpi.c | 21 +-
  drivers/usb/c67x00/c67x00-sched.c  | 44 
 --
  drivers/usb/c67x00/c67x00.h|  4 ++--
  5 files changed, 39 insertions(+), 35 deletions(-)

Why are these changes made?  checkpatch doesn't seem to complain to
require these, so what am I missing?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers: dwc2: Mark function as static in core.c

[Greg Kroah-Hartman]

On Sat, Dec 21, 2013 at 03:50:29PM +0530, Rashika Kheria wrote:
 Mark function dwc2_set_param_uframe_sched() as static in core.c because
 it is not used outside this file.
 
 This eliminates the following warning in core.c:
 drivers/staging/dwc2/core.c:2739:5: warning: no previous prototype for 
 ‘dwc2_set_param_uframe_sched’ [-Wmissing-prototypes]
 
 Signed-off-by: Rashika Kheria rashika.khe...@gmail.com

This patch doesn't apply to my tree.

And please stop sending patches in base64 mode, it makes it impossible
to add reviewed-by: markings to them.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

[walt]

On 01/03/2014 03:29 PM, Sarah Sharp wrote:

 I'll let you know when I have some diagnostic patches ready.

Hi Sarah.  I see today gregkh committed the patches you've already sent
me, so I assume someone (other than me) has tested those patches and
discovered some benefit from them?

I'm still wondering if I'm suffering from hardware quirks.  From the
first day I installed my usb3 adapter card and the usb3 disk docking
station I've noticed some quirky behavior.

e.g. I boot the machine with the docking station powered-off, and then
later I power it on, the usb3 disk is not detected at all -- until I
reboot the machine with the docking station still powered on.

Minor stuff, yes, but maybe relevant?  I dunno.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method

[Peter Chen]

On Wed, Jan 08, 2014 at 06:25:01AM -0800, Greg KH wrote:
 On Wed, Jan 08, 2014 at 12:54:25PM +0100, Marc Kleine-Budde wrote:
  On 01/08/2014 01:23 AM, Greg KH wrote:
   On Mon, Jan 06, 2014 at 10:10:41AM +0800, Peter Chen wrote:
   According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
   register error issue, All USB register write operations must
   use the ARM SWP instruction. So, we implement a special ehci_write
   for imx28.
  
   Discussion for it at below:
   http://marc.info/?l=linux-usbm=137996395529294w=2
  
   Signed-off-by: Peter Chen peter.c...@freescale.com
   Acked-by: Alan Stern st...@rowland.harvard.edu
   Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
   Tested-by: Marc Kleine-Budde m...@pengutronix.de
   ---
drivers/usb/host/ehci.h |   18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
  
   diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
   index c35a6e2b..e26099b 100644
   --- a/drivers/usb/host/ehci.h
   +++ b/drivers/usb/host/ehci.h
   @@ -225,6 +225,7 @@ struct ehci_hcd {/* one per 
   controller */
unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
unsignedframe_index_bug:1; /* MosChip (AKA 
   NetMos) */
unsignedneed_oc_pp_cycle:1; /* MPC834X port 
   power */
   +unsignedimx28_write_fix:1; /* For Freescale 
   i.MX28 */

/* required for usb32 quirk */
#define OHCI_CTRL_HCFS  (3  6)
   @@ -728,6 +729,18 @@ static inline unsigned int ehci_readl(const struct 
   ehci_hcd *ehci,
#endif
}

   +#ifdef CONFIG_SOC_IMX28
   +static inline void imx28_ehci_writel(const unsigned int val,
   +volatile __u32 __iomem *addr)
   +{
   +__asm__ (swp %0, %0, [%1] : : r(val), r(addr));
   +}
   +#else
   +static inline void imx28_ehci_writel(const unsigned int val,
   +volatile __u32 __iomem *addr)
   +{
   +}
   +#endif
static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
{
   @@ -736,7 +749,10 @@ static inline void ehci_writel(const struct 
   ehci_hcd *ehci,
writel_be(val, regs) :
writel(val, regs);
#else
   -writel(val, regs);
   +if (IS_ENABLED(CONFIG_SOC_IMX28)  ehci-imx28_write_fix)
   +imx28_ehci_writel(val, regs);
   +else
   +writel(val, regs);
#endif
   
   This IS_ENABLED() isn't needed at all, so please remove it.
  
  It's an optimisation for the hot path, if kernel isn't build for a mx28
  the newly added if() is completely optimized out. The same argument
  applies to the next patch.
 
 If the kernel isn't built for mx28 then the if statment goes away
 without the IS_ENABLED() call as well, due to the empty inline
 function, right?
 

With IS_ENABLED(), the non-imx28 platform don't need to judge the
condition of ehci-imx28_write_fix, if you don't think we need
to care one or two instructions for every other platforms, I can
delete it.

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method

[Peter Chen]

On Tue, Jan 07, 2014 at 04:20:25PM -0800, Greg KH wrote:
 On Mon, Jan 06, 2014 at 09:42:26AM +0100, Marc Kleine-Budde wrote:
  Hello Peter and Greg,
  
  On 01/06/2014 03:10 AM, Peter Chen wrote:
   According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
   register error issue, All USB register write operations must
   use the ARM SWP instruction. So, we implement a special ehci_write
   for imx28.
   
   Discussion for it at below:
   http://marc.info/?l=linux-usbm=137996395529294w=2
   
   Signed-off-by: Peter Chen peter.c...@freescale.com
   Acked-by: Alan Stern st...@rowland.harvard.edu
   Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
   Tested-by: Marc Kleine-Budde m...@pengutronix.de
  
  please add stable on Cc for this and the next two patches:
  
  [PATCH 4/8] usb: ehci: add freescale imx28 special write register method
  [PATCH 5/8] usb: chipidea: add freescale imx28 special write register method
  [PATCH 6/8] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
 
 How do those patches meet the Documentation/stable_kernel_rules.txt
 guidelines?
 
 

- It must be obviously correct and tested.
It has Marc Kleine-Budde's tested-by tag.

- It cannot be bigger than 100 lines, with context.
I think it is.

- It must fix only one thing.
It only fixes the imx28 special write problem.

- It must fix a real bug that bothers people (not a, This could be a
problem... type thing).
Robert Hodaszi reported this problem at below link:
http://marc.info/?l=linux-usbm=137996395529294w=2

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/8] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

[Peter Chen]

On Tue, Jan 07, 2014 at 04:27:30PM -0800, Greg KH wrote:
 On Mon, Jan 06, 2014 at 10:10:44AM +0800, Peter Chen wrote:
  From: Chris Ruehl chris.ru...@gtsys.com.hk
  
  * init the sts flag to 0 (missed)
  * fix write the real bit not sts value
  * Set PORTCS_STS and DEVLC_STS only if sts = 1
  
  Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
  Signed-off-by: Peter Chen peter.c...@freescale.com
  ---
   drivers/usb/chipidea/core.c |8 +---
   1 files changed, 5 insertions(+), 3 deletions(-)
 
 Why isn't this patch ok for the -stable trees?
 

The usb code for the platform which this problem occurs is
just in your usb-next tree [3.14], the same for PATCH 8/8.

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method

[Greg KH]

On Thu, Jan 09, 2014 at 09:36:09AM +0800, Peter Chen wrote:
 On Tue, Jan 07, 2014 at 04:20:25PM -0800, Greg KH wrote:
  On Mon, Jan 06, 2014 at 09:42:26AM +0100, Marc Kleine-Budde wrote:
   Hello Peter and Greg,
   
   On 01/06/2014 03:10 AM, Peter Chen wrote:
According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
register error issue, All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.

Discussion for it at below:
http://marc.info/?l=linux-usbm=137996395529294w=2

Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
Tested-by: Marc Kleine-Budde m...@pengutronix.de
   
   please add stable on Cc for this and the next two patches:
   
   [PATCH 4/8] usb: ehci: add freescale imx28 special write register method
   [PATCH 5/8] usb: chipidea: add freescale imx28 special write register 
   method
   [PATCH 6/8] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
  
  How do those patches meet the Documentation/stable_kernel_rules.txt
  guidelines?
  
  
 
 - It must be obviously correct and tested.
 It has Marc Kleine-Budde's tested-by tag.
 
 - It cannot be bigger than 100 lines, with context.
 I think it is.
 
 - It must fix only one thing.
 It only fixes the imx28 special write problem.
 
 - It must fix a real bug that bothers people (not a, This could be a
 problem... type thing).
 Robert Hodaszi reported this problem at below link:
 http://marc.info/?l=linux-usbm=137996395529294w=2

You are adding new functionality for something that never worked before
(i.e. new features), which is not ok for stable kernel patches, with the
exception of new quirks or device ids.

sorry, this is something new, not a stable kernel patch.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL

[Roger Quadros]

Hi Marek,

I have no idea what is happening there. Have you tried using device tree boot?
Board file boot support would be dropped eventually.

Did you try if I2C read write to the twl4030 device works and all necessary 
clocks/supplies are
present?

Kishon, do you know what is causing the USB DPLL failure there?

cheers,
-roger

On 01/09/2014 02:31 AM, Belisko Marek wrote:
 Any pointers? Still present in 3.13-rc7.
 
 On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros rog...@ti.com wrote:
 +Kishon

 On 12/03/2013 11:33 PM, Belisko Marek wrote:
 Hi,

 current 3.13-rcX break usb support on gta04 board (similar to
 beagleboard) when booting via board file.

 In console we can see messages:
  [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL 
 clock
 [ 5232.936096] omap_musb_mailbox: musb core is not yet ready
 [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL 
 clock
 [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL 
 clock

 Any pointer what could cause that? (in 3.12 usb works fine)

 BR,

 marek


 
 BR,
 
 marek
 

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/9] phy: Add new Exynos USB 2.0 PHY driver

[Kishon Vijay Abraham I]

Hi,

On Wednesday 08 January 2014 11:26 PM, Kamil Debski wrote:
 Hi,
 
 From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
 Sent: Monday, January 06, 2014 11:12 AM

 Hi,

 On Friday 20 December 2013 06:54 PM, Kamil Debski wrote:
 Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the
 generic PHY framework. The driver includes support for the Exynos
 4x10
 and 4x12 SoC families.

 Signed-off-by: Kamil Debski k.deb...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
   .../devicetree/bindings/phy/samsung-phy.txt|   55 
   drivers/phy/Kconfig|   29 ++
   drivers/phy/Makefile   |3 +
   drivers/phy/phy-exynos4210-usb2.c  |  257
 
   drivers/phy/phy-exynos4212-usb2.c  |  306
 
   drivers/phy/phy-samsung-usb2.c |  226
 +++
   drivers/phy/phy-samsung-usb2.h |   67 +
   7 files changed, 943 insertions(+)
   create mode 100644 drivers/phy/phy-exynos4210-usb2.c
   create mode 100644 drivers/phy/phy-exynos4212-usb2.c
   create mode 100644 drivers/phy/phy-samsung-usb2.c
   create mode 100644 drivers/phy/phy-samsung-usb2.h

 .
 .
 snip
 .
 .

 diff --git a/drivers/phy/phy-samsung-usb2.h
 b/drivers/phy/phy-samsung-usb2.h new file mode 100644 index
 000..ab89f91
 --- /dev/null
 +++ b/drivers/phy/phy-samsung-usb2.h
 @@ -0,0 +1,67 @@
 +/*
 + * Samsung SoC USB 1.1/2.0 PHY driver
 + *
 + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
 + * Author: Kamil Debski k.deb...@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or
 +modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#ifndef _PHY_EXYNOS_USB2_H
 +#define _PHY_EXYNOS_USB2_H
 +
 +#include linux/clk.h
 +#include linux/phy/phy.h
 +#include linux/device.h
 +#include linux/regmap.h
 +#include linux/spinlock.h
 +
 +#define KHZ 1000
 +#define MHZ (KHZ * KHZ)
 +
 +struct samsung_usb2_phy_driver;
 +struct samsung_usb2_phy_instance;
 +struct samsung_usb2_phy_config;
 +
 +struct samsung_usb2_phy_instance {
 +   const struct samsung_usb2_common_phy *cfg;
 +   struct clk *clk;
 +   struct phy *phy;
 +   struct samsung_usb2_phy_driver *drv;
 +   unsigned long rate;
 +   u32 clk_reg_val;
 +   bool enabled;
 +};
 +
 +struct samsung_usb2_phy_driver {
 +   const struct samsung_usb2_phy_config *cfg;
 +   struct clk *clk;
 +   struct device *dev;
 +   void __iomem *reg_phy;
 +   struct regmap *reg_pmu;
 +   struct regmap *reg_sys;
 +   spinlock_t lock;
 +   struct samsung_usb2_phy_instance instances[0];

 I think having instances as array here would allocate more space while
 allocating 'samsung_usb2_phy_driver' in 'samsung_usb2_phy_probe'.

 
 I am not sure if I understand you correctly here. Maybe I will explain
 what I intended to write. An array with size 0 at the end of a structure
 takes no space in the structure. The benefit of using it is that after
 the structure one can allocate a number of the array elements and
 address them easily. Another option would be placing pointer in the
 samsung_usb2_phy_instance and allocate memory separately, but this would
 involve two allocations and a pointer would be always present in the 
 structure.

Al-right.. makes sense.

Thanks
Kishon
 
 Best wishes,
 

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method

[Peter Chen]

On Wed, Jan 08, 2014 at 07:22:04PM -0800, Greg KH wrote:
 On Thu, Jan 09, 2014 at 09:36:09AM +0800, Peter Chen wrote:
  On Tue, Jan 07, 2014 at 04:20:25PM -0800, Greg KH wrote:
   On Mon, Jan 06, 2014 at 09:42:26AM +0100, Marc Kleine-Budde wrote:
Hello Peter and Greg,

On 01/06/2014 03:10 AM, Peter Chen wrote:
 According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
 register error issue, All USB register write operations must
 use the ARM SWP instruction. So, we implement a special ehci_write
 for imx28.
 
 Discussion for it at below:
 http://marc.info/?l=linux-usbm=137996395529294w=2
 
 Signed-off-by: Peter Chen peter.c...@freescale.com
 Acked-by: Alan Stern st...@rowland.harvard.edu
 Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
 Tested-by: Marc Kleine-Budde m...@pengutronix.de

please add stable on Cc for this and the next two patches:

[PATCH 4/8] usb: ehci: add freescale imx28 special write register method
[PATCH 5/8] usb: chipidea: add freescale imx28 special write register 
method
[PATCH 6/8] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
   
   How do those patches meet the Documentation/stable_kernel_rules.txt
   guidelines?
   
   
  
  - It must be obviously correct and tested.
  It has Marc Kleine-Budde's tested-by tag.
  
  - It cannot be bigger than 100 lines, with context.
  I think it is.
  
  - It must fix only one thing.
  It only fixes the imx28 special write problem.
  
  - It must fix a real bug that bothers people (not a, This could be a
  problem... type thing).
  Robert Hodaszi reported this problem at below link:
  http://marc.info/?l=linux-usbm=137996395529294w=2
 
 You are adding new functionality for something that never worked before
 (i.e. new features), which is not ok for stable kernel patches, with the
 exception of new quirks or device ids.
 
 sorry, this is something new, not a stable kernel patch.
 

Thanks, I will re-work on that patch and add your comment at
another email.

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] usb: gadget: gr_udc: debugfs functions return NULL on error

[Greg Kroah-Hartman]

On Thu, Jan 09, 2014 at 08:39:37AM +0300, Dan Carpenter wrote:
 Debugfs functions return NULL on error.  They return an ERR_PTR if you
 don't have debugfs configured.
 
 The way it's designed is that normally you are only supposed to test for
 NULL.  In this code, if dev-dfs_root is an ERR_PTR then passing it to
 debugfs_create_file() will not cause a problem because
 debugfs_create_file() would also just a stub.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 
 diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
 index 5f9c65959dd2..b34a52171568 100644
 --- a/drivers/usb/gadget/gr_udc.c
 +++ b/drivers/usb/gadget/gr_udc.c
 @@ -226,13 +226,13 @@ static void gr_dfs_create(struct gr_udc *dev)
   const char *name = gr_udc_state;
  
   dev-dfs_root = debugfs_create_dir(dev_name(dev-dev), NULL);
 - if (IS_ERR(dev-dfs_root)) {
 + if (!dev-dfs_root) {
   dev_err(dev-dev, Failed to create debugfs directory\n);
   return;
   }
   dev-dfs_state = debugfs_create_file(name, 0444, dev-dfs_root,
dev, gr_dfs_fops);
 - if (IS_ERR(dev-dfs_state))
 + if (!dev-dfs_state)
   dev_err(dev-dev, Failed to create debugfs file %s\n, name);
  }

Don't even check the return value of the calls, I don't think it
matters, right?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] usb: gadget: gr_udc: debugfs functions return NULL on error

[Dan Carpenter]

On Wed, Jan 08, 2014 at 10:01:21PM -0800, Greg Kroah-Hartman wrote:
 On Thu, Jan 09, 2014 at 08:39:37AM +0300, Dan Carpenter wrote:
  Debugfs functions return NULL on error.  They return an ERR_PTR if you
  don't have debugfs configured.
  
  The way it's designed is that normally you are only supposed to test for
  NULL.  In this code, if dev-dfs_root is an ERR_PTR then passing it to
  debugfs_create_file() will not cause a problem because
  debugfs_create_file() would also just a stub.
  
  Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
  
  diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
  index 5f9c65959dd2..b34a52171568 100644
  --- a/drivers/usb/gadget/gr_udc.c
  +++ b/drivers/usb/gadget/gr_udc.c
  @@ -226,13 +226,13 @@ static void gr_dfs_create(struct gr_udc *dev)
  const char *name = gr_udc_state;
   
  dev-dfs_root = debugfs_create_dir(dev_name(dev-dev), NULL);
  -   if (IS_ERR(dev-dfs_root)) {
  +   if (!dev-dfs_root) {
  dev_err(dev-dev, Failed to create debugfs directory\n);
  return;
  }
  dev-dfs_state = debugfs_create_file(name, 0444, dev-dfs_root,
   dev, gr_dfs_fops);
  -   if (IS_ERR(dev-dfs_state))
  +   if (!dev-dfs_state)
  dev_err(dev-dev, Failed to create debugfs file %s\n, name);
   }
 
 Don't even check the return value of the calls, I don't think it
 matters, right?
 

I assume your question is rhetorical since you wrote debugfs...  :P
Yes, I looked and if we don't create the initial directory then the
files get put in parent directory instead.

I'll resend this.

regards,
dan carpenter

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 0/3] r8152: behavior modification

[Hayes Wang]

The purpose is to add a choice for determining whether add the
limitation between r8152 and ecm drivers or not.

Hayes Wang (3):
  r8152: change the descriptor
  r8152: fix the warnings and a error from checkpatch.pl
  r8152: add supporting the vendor mode only

 drivers/net/usb/Kconfig | 14 --
 drivers/net/usb/cdc_ether.c |  2 +-
 drivers/net/usb/r8152.c | 62 ++---
 drivers/net/usb/r815x.c |  4 +--
 4 files changed, 45 insertions(+), 37 deletions(-)

-- 
1.8.4.2

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html