date:20140415

On Tue, Apr 15, 2014 at 04:24:10PM +0800, Xiao Jin wrote:
 On 04/15/2014 03:58 AM, Johan Hovold wrote:

  Jin, did you check what closing_wait setting your application is using?
 
 I check the closing_wait is 30s by default. Below is the trace we get 
 when reproduced problem.
 
 ...-1360  [003] d.s5  1843.061418: acm_tty_write: 
 acm_tty_write - write 65
 ...-1360  [003] d.s5  1843.061425: acm_write_start: 
 acm_write_start - susp_count 2
 ...-2535  [002]   1843.180687: acm_tty_close: 
 acm_tty_close
 ...-2535  [002]   1843.181217: acm_wb_is_avail: avail n=15
 ...-2535  [002]   1843.181238: acm_port_shutdown: 
 acm_port_shutdown
 ...-438   [003]   1843.182803: acm_wb_is_avail: avail n=16
 ...-438   [003] d..1  1843.182817: acm_tty_write: 
 acm_tty_write - write 11
 ...-438   [003] d..1  1843.182826: acm_write_start: 
 acm_write_start - susp_count 2
 ...-37[003]   1843.202884: acm_resume: wgq[acm_resume]
 ...-37[003]   1843.202892: acm_resume: wgq[acm_resume]
 ...-37[003] d..1  1843.203195: acm_resume: send 
 d_wb-1046297992
 ...-37[003]   1843.203199: acm_start_wb: 
 acm_start_wb, acm-transmitting=0
idle-0 [000] d.h2  1843.203343: acm_write_done.isra.11: 
 acm_write_done, acm-transmitting=1
 ...-1989  [001]   1843.207197: acm_tty_cleanup: 
 acm_tty_cleanup
 
 There are two acms in the case, acm0 and acm3. acm0 have delayed 65 
 bytes before close. When acm0 close, ASYNCB_INITIALIZED flag is cleared, 
 that lead to acm0 have no chance to start delayed wb during acm resume.

The ASYNCB_INITIALIZED flag is not cleared until chars_in_buffer returns
0 (or closing_wait times out), so this should not be a problem.

What kernel are you using here?

Can you try to reproduce this using a single ACM device with the
diagnostic patch below applied (on top of v3.14 and my autosuspend fix)?

 acm3 delayed 11 bytes send out because it still is opened.
 It looks closing_wait didn't take effect at that time. I am not sure the 
 reason why because we have no more debug log. Now We are checking the 
 issue again.
 
  Could you give this patch a try as well?
 
 I try the write and resume part of this patch, anchor urb works well.

Thanks for testing.

Johan


From 3c622243c33a815f66e606531edd3a7ff4e579bf Mon Sep 17 00:00:00 2001
From: Johan Hovold jhov...@gmail.com
Date: Tue, 15 Apr 2014 10:44:59 +0200
Subject: [PATCH] USB: cdc-acm: add and enable some extra debugging

---
 drivers/usb/class/cdc-acm.c | 35 ---
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index ebbcc7a6a7c8..44aa8a620f89 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -28,8 +28,8 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
  */
 
-#undef DEBUG
-#undef VERBOSE_DEBUG
+#define DEBUG
+#define VERBOSE_DEBUG
 
 #include linux/kernel.h
 #include linux/errno.h
@@ -175,6 +175,7 @@ static int acm_wb_is_avail(struct acm *acm)
spin_lock_irqsave(acm-write_lock, flags);
for (i = 0; i  ACM_NW; i++)
n -= acm-wb[i].use;
+   dev_dbg(acm-data-dev, %s - %d\n, __func__, n);
spin_unlock_irqrestore(acm-write_lock, flags);
return n;
 }
@@ -433,6 +434,8 @@ static void acm_write_bulk(struct urb *urb)
struct acm *acm = wb-instance;
unsigned long flags;
 
+   dev_dbg(acm-data-dev, %s\n, __func__);
+
if (urb-status || (urb-actual_length != urb-transfer_buffer_length))
dev_vdbg(acm-data-dev, %s - len %d/%d, status %d\n,
__func__,
@@ -632,11 +635,11 @@ static int acm_tty_write(struct tty_struct *tty,
int wbn;
struct acm_wb *wb;
 
+   dev_vdbg(acm-data-dev, %s - count %d, data = %*ph\n, __func__,
+   count, count, buf);
if (!count)
return 0;
 
-   dev_vdbg(acm-data-dev, %s - count %d\n, __func__, count);
-
spin_lock_irqsave(acm-write_lock, flags);
wbn = acm_wb_alloc(acm);
if (wbn  0) {
@@ -658,6 +661,8 @@ static int acm_tty_write(struct tty_struct *tty,
 
usb_autopm_get_interface_async(acm-control);
if (acm-susp_count) {
+   dev_dbg(acm-data-dev, %s - suspended, __func__);
+
usb_anchor_urb(wb-urb, acm-delayed);
spin_unlock_irqrestore(acm-write_lock, flags);
return count;
@@ -675,26 +680,38 @@ static int acm_tty_write(struct tty_struct *tty,
 static int acm_tty_write_room(struct tty_struct *tty)
 {
struct acm *acm = tty-driver_data;
+   int room;
+
/*
 * Do not let the line discipline to know that we have a reserve,
 * or it might get too enthusiastic.
 */
-

Re: [RFC 1/4] dwc3: dts: Binding information for an optional property lpm_capable

2014-04-15 Thread Pratyush Anand

On Tue, Apr 15, 2014 at 01:48:00AM +0800, Paul Zimmerman wrote:
  From: linux-usb-ow...@vger.kernel.org 
  [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Pratyush Anand
  Sent: Monday, April 14, 2014 1:48 AM

  On Mon, Apr 14, 2014 at 09:42:25AM +0530, Pratyush Anand wrote:
   Hi Paul,

   On Sat, Apr 12, 2014 at 02:25:27AM +0800, Paul Zimmerman wrote:
 From: Pratyush Anand [mailto:pratyush.an...@gmail.com]
 Sent: Friday, April 11, 2014 11:06 AM

 On Fri, Apr 11, 2014 at 11:24 PM, Felipe Balbi ba...@ti.com wrote:
  On Fri, Apr 11, 2014 at 03:50:03PM +0530, Pratyush Anand wrote:
  If a dwc3 host implementation is lpm capable then enable 
  lpm_capable in
  device tree.

  Signed-off-by: Pratyush Anand pratyush.an...@st.com
  ---
   Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
   1 file changed, 2 insertions(+)

  diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
 b/Documentation/devicetree/bindings/usb/dwc3.txt
  index 7a95c65..a7a48f1 100644
  --- a/Documentation/devicetree/bindings/usb/dwc3.txt
  +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
  @@ -10,6 +10,7 @@ Required properties:

   Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  + - lpm-capable: determines if xhci host is lpm capable

   This is usually a subnode to DWC3 glue to which it is connected.

  @@ -19,4 +20,5 @@ dwc3@4a03 {
interrupts = 0 92 4
usb-phy = usb2_phy, usb3,phy;
tx-fifo-resize;
  + lpm-capable;

  I think there's a way to detect this in runtime but I can't seem to 
  find
  it on databook. Perhaps check with your IP designer/integrator which
  HWPARAMS register we can poke to verify core was configured with 
  LPM ?

 I too tried to look into databook first, But could not find. Lets 
 see, what Paul
 says.

Hi guys,

The Power Management section of the databook talks about hardware-
controlled LPM. It's section 12.4 in the latest databook. LPM is a
standard xHCI feature, so you can look at the xHCI spec to find the
info about it.

In the xHCI spec, section 4.23.5.1.1 USB2 LPM Support says this:

This section applies only if a USB2 xHCI Supported Protocol Capability
structure (section 7.2) is declared (i.e. the Major Revision field = 
02h).

And if you look at section 7.2.2.1.3.2 USB2, it shows that bit 19 in
the Protocol Defined field of the USB2 xHCI Supported Protocol 
Capability
structure indicates whether the controller supports hardware-controlled
LPM.

   Yes, for USB2 LPM we can use it. But These patches are mainly for USB3
   LPM where we program U1/U2 inactivity timeout. I am not sure if same
   bit can be used for USB3 LPM.

  It seems for USB3 LPM there is no defined bit available.
  For USB2:
  xhci driver already using the bit you have suggested.
  So for USB3:
  LPM capability info need to be passed from platform.

 I'm am pretty sure there was no DWC3 hardware released to customers
 that did not support USB 3.0 link power management. So it should be
 safe to assume that it is always supported.

Good, then passing the capability from platforms can be removed. So,
for all dwc3 xhci host software, LPM will be enabled by default. If a
device has the capability in its BOS descriptor then software will
enable LPM for that device.

Regards
Pratyush

 -- 
 Paul
--
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.15-rc1] a huge number of warnings produced by xhci

2014-04-15 Thread Grygorii Strashko


On 04/14/2014 08:12 PM, Christoph Lameter wrote:

n Mon, 14 Apr 2014, Grygorii Strashko wrote:


Hi All,

I'm observing a huge number of warnings produced during the boot of my Keystone 
2 board
when USB is enabled.

[2.496460] BUG: using __this_cpu_read() in preemptible [] code: 
khubd/202
[2.504030] caller is __mod_zone_page_state+0x20/0xc8
[2.509094] CPU: 1 PID: 202 Comm: khubd Not tainted 
3.15.0-rc1-00015-ge521fa3-dirty #55
[2.517122] [c0013788] (unwind_backtrace) from [c001129c] 
(show_stack+0x10/0x14)
[2.524854] [c001129c] (show_stack) from [c049f800] 
(dump_stack+0x68/0xb8)
[2.532086] [c049f800] (dump_stack) from [c02731c0] 
(check_preemption_disabled+0xe8/0x10c)
[2.540708] [c02731c0] (check_preemption_disabled) from [c00bc944] 
(__mod_zone_page_state+0x20/0xc8)
[2.550187] [c00bc944] (__mod_zone_page_state) from [c00b50c8] 
(reclaim_clean_pages_from_list+0x16c/0x178)
[2.560193] [c00b50c8] (reclaim_clean_pages_from_list) from [c00ac8f0] 
(alloc_contig_range+0x10c/0x2d0)
[2.569932] [c00ac8f0] (alloc_contig_range) from [c02b0e58] 
(dma_alloc_from_contiguous+0x70/0x118)
[2.579241] [c02b0e58] (dma_alloc_from_contiguous) from [c0017d24] 
(__alloc_from_contiguous+0x34/0x160)
[2.588974] [c0017d24] (__alloc_from_contiguous) from [c0018760] 
(__dma_alloc+0x18c/0x294)
[2.597582] [c0018760] (__dma_alloc) from [c00189f0] 
(arm_dma_alloc+0xac/0xd8)
[2.605140] [c00189f0] (arm_dma_alloc) from [c00d84a8] 
(dma_pool_alloc+0xc8/0x1b8)
[2.613067] [c00d84a8] (dma_pool_alloc) from [c0317120] 
(xhci_alloc_container_ctx+0x70/0xe0)
[2.621851] [c0317120] (xhci_alloc_container_ctx) from [c03194e8] 
(xhci_alloc_virt_device+0x98/0x220)
[2.631418] [c03194e8] (xhci_alloc_virt_device) from [c0315d28] 
(xhci_alloc_dev+0x158/0x1f0)
[2.640207] [c0315d28] (xhci_alloc_dev) from [c02f6310] 
(usb_alloc_dev+0x1d4/0x27c)
[2.648217] [c02f6310] (usb_alloc_dev) from [c02fb204] 
(hub_thread+0x670/0x1204)
[2.655943] [c02fb204] (hub_thread) from [c003d8d8] (kthread+0xcc/0xe8)
[2.662906] [c003d8d8] (kthread) from [c000e2f8] 
(ret_from_fork+0x14/0x3c)

Anyone else sees the same thing?


Either disable interrupts or use mod_zone_page_state instead.

This should fix it:




Subject: vmscan: reclaim_clean_pages_from_list must use mod_zone_page_state

Seems to be called with preemption enabled. Therefore it must use
mod_zone_page_state instead.

Signed-off-by: Christoph Lameter c...@linux.com


This patch fixes issue for me on Keystone 2, thanks.
Tested-by: Grygorii Strashko grygorii.stras...@ti.com



Index: linux/mm/vmscan.c
===
--- linux.orig/mm/vmscan.c  2014-04-09 11:35:43.917930976 -0500
+++ linux/mm/vmscan.c   2014-04-14 12:09:48.070745938 -0500
@@ -1158,7 +1158,7 @@ unsigned long reclaim_clean_pages_from_l
TTU_UNMAP|TTU_IGNORE_ACCESS,
dummy1, dummy2, dummy3, dummy4, dummy5, true);
list_splice(clean_pages, page_list);
-   __mod_zone_page_state(zone, NR_ISOLATED_FILE, -ret);
+   mod_zone_page_state(zone, NR_ISOLATED_FILE, -ret);
return ret;
  }



--
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: cdc-acm: fix broken runtime suspend

On Tue, Apr 15, 2014 at 10:35:19AM +0200, Oliver Neukum wrote:
 On Mon, 2014-04-14 at 21:58 +0200, Johan Hovold wrote:
 
  Fix this by implementing a delayed-write queue using urb anchors and
  making sure to discard the queue properly at shutdown.
 
 Looks very good, with one exception: acm_tty_close() must
 synchronously resume the device so that the anchor is emptied
 before ASYNCB is cleared.

That isn't necessary as the device is already about to be resumed and
the initialised flag will not be cleared until chars_in_buffer() returns
0 or closing wait times out.

In the first case, the queue has been emptied as the urbs are submitted
at resume(), and in the second case the queue is discarded at
shutdown().

Johan
--
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: Missing USB XHCI and EHCI reset for kexec

2014-04-15 Thread stefani



Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:


On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:


Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:

I don't know about EHCI specifically but this is a known issue with
XHCI, I observe similar issues on other powerpc platforms (servers)
and this isn't architecture specific (looks more like actualy xhc
implementation specific).

Thadeu Cascardo (on CC) has been the one investigating that on our side,
he might have more to add including patches.


I have now a kernel 3.14 dmesg log of the problem. After a kexec the
kexeced 3.14 kernel shows:

[1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
[1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
assigned bus number 1
[1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
microseconds.
[1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
[1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
[1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
[1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110



What is your controller vendor and device IDs? Is that a TI chip?



Yes it is a TI chip, vendor ID 104c and product ID 8241.


Can you check if the patch I sent a month ago fixes it? [1] There's the
whole story there. In fact, you will also need something like the patch
below. Can you apply only the first one, verify, and, then, the other
one as well, and report what worked for you?

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



I tried the attach patch and it did not help. This is what i expected  
because this is a fix in the shutdown path, which will never called  
when doing a forced kexec.


I have a running a 3.10.23 kernel. This kernel do a kexec for a kernel  
3.14. Since the kernel 3.10.23 did not performe a clean shutdown, the  
state of the XHCI Controller is undefined. So when kernel 3.14 will  
probe XHCI it will find a XHCI controller which was not performed a  
reset.


So i think it is necessary to reset the XHCI controller and all  
devices on this bus. This is what i do with a echo 1  
/sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.


- Stefani


--
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: About the DRD mode implementation of DWC3 driver]

2014-04-15 Thread Wang, Yu

On Fri, Apr 11, 2014 at 06:19:57PM -0500, Felipe Balbi wrote:
Hi,

On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote:
 Hi Balbi,
 
 At first, thank you to help give the response in patience.
 
  Hi,
 
  On Wed, Apr 09, 2014 at 02:08:32PM +0800, Wang, Yu wrote:
   Glad to see the OTG mode is prepare to support in your
   dwc3-role-switch branch. But it is not fit for intel
   Merrfield/Moorfield platforms. :(
 
  that's not what I heard when I asked some friends to test that branch
  on different platforms. It's certainly not perfect yet and that's why
  the code isn't merged in mainline, but claiming that it's not fit for
  Merrifield/Moorfield is just a lie.
 
 
 Can I get your friends' email address if they are in Intel? I would like to

You already have that. Just look at Cc list.

 contact them to make the branch work on my Merrifield/Moorefield board too.
 Currently I can't see any link change event with the branch.

how did you test it ? According to [1] Merrifield won't work for more
than 20s or so with v3.14 and, since there is no resolution on the
thread, I assume today's mainline won't work either.

Anyway, if you really did test, test again with enabling verbose debug
on dwc3 and show me the logs, I'm interested in what the IP is doing.

Yes. As you said, the v3.14 haven't get stable so far on Merrifield
platform. So I tried to back port your dwc3-role-switch branch solution
to our v3.10 base and verified.

I will waiting v3.14 get ready and do the test again to double confirm.
I will let you know the result. Sorry cause the misunderstanding for
you.


   The reason is we implemented DRD mode instead of OTG mode. So the
   GCTL.PortCapDir will be set as 01 for host mode, and 10 for device mode.
 
  from a SW perspective there is *no* difference. The only reason for
  using PortCapDir is to cope with platforms which want to switch roles
  but have screwed up ID pin reporting. And since most of the platforms
  actually have tha problem, it's just easier to implement it that way.
 
 
 Ok. Just confirm with you that you think it's not a matter to use
 GCTL.PortCapDir or OCTL.PeriMode to switch role, right?

As of today, I don't see a difference. Things *can* change though. We
can find out more details about the HW which forces us to use one of the
other.

I will help to try both DRD/OTG solution with your design on Merrifield
when v3.14 get stable on it.


   If no cable connected, we will trigger D0i3cold which will power
   gate every clock/power used by dwc3 controller.
 
  that's not in mainline though, why should I care ? Show me code adding
  support for D0i3cold for dwc3 then we can talk. Until then, I'll
  continue assuming there's no such PM state and continue with happy hacking
  sessions.
 
   And entering D0i3hot with hibernation mode when acting as host mode
   (micro A cable connected), also during device mode(micro B cable
   connected to PC host).
 
  Current driver also doesn't support any runtime PM, so why should I
  care about your out-of-tree changes ? If you have any code which is
  not in mainline and I change something in mainline you have to deal to 
  with it,
  not me.
 
 Get it. So we can treat this solution is working w/o PM implementation
 so far. And maybe we need to re-design DRD/OTG when we consider to
 support PM, right?

We probably don't need to redesign anything when adding PM. What we need
is that when we start to add PM support to this driver, in case there is
any regression, we find out why there is a regression. Then we solve it
properly, after looking at logs and fully understanding what's breaking
the driver.

In any case, that's something that won't happen in mainline for at least
a couple more major releases since there are still quite a few changes
pending.

Get your point. Thanks


  I just cannot spend time imagining all twisted scenarios Vendors
  (including my employer, for that matter) want to support with whatever
  hacked up version of mainline drivers they might have.
 
  My plan is to *not* add a lot of PM support until I know all other
  features are functional. When I'm happy with those features and know
  they have been thoroughly tested on *all* users of dwc3 then we can
  all get together in a conference (maybe have a DWC3 mini-summit or
  whatever) and discuss how we're gonna implement PM *together*.
 
  Since the driver is used by many different vendors, it would be unfair
  for me to treat Intel (or any vendor, really) differently just because
  someone dropped me an email commenting about all the out-of-tree changes
  they have.
 
 
 Understand. What are the other features you mean that need thorough testing
 before adding PM support?

DRD for one. Then there is a redesign of parts of the gadget API that I
want to do before PM too. Then there is the whole Link Power Management
(which has *nothing* to do with Linux PM - system or runtime; we can put
the USB bus in low power mode even though we don't gate any of the USB
IP's

Re: [RFC 0/2] Support for Super Speed Link Layer Test

2014-04-15 Thread Pratyush Anand

On Tue, Apr 15, 2014 at 02:20:13AM +0800, Alan Stern wrote:
 On Mon, 14 Apr 2014, Pratyush Anand wrote:
 
  Hi Alan,
  
  On Fri, Apr 11, 2014 at 06:56:37PM +0800, Pratyush ANAND wrote:
   Lecroy's USB Compliance suites provide option to test Link Layer Tests
   for Super Speed device as well as host.
   
   As of now there is no standard way to test embedded host for these
   tests.
   
   These patches modifies Linux USB host stack to carry out these tests for
   embedded hosts. Modifications are still not complete. Patch 2 will have
   few more sysfs nodes to support some failing tests. 
   
   I am sending these as RFC for mainly to have your comment on framework
   modifications. Please let me know, if there could be any better way to
   do it.
  
  Do you see a better way of doing it than this implementation (which is
  creating a platform device for each new connection request from Link
  Layer Validation (LVS) device)?
 
 How about just creating a normal USB device instead of a platform 
 device?  I think all you have to do is make usb_new_device() avoid 
 calling usb_enumerate_device() when the new flag is set.

I had thought of this. But, I had found that even hub_port_reset
creates issue for LVS device. hub_port_reset forces USB SS link to go
into recovery very soon, which is not expected as per Link Layer Test
specification. So, we can not even allow to execute hub_port_init when
a LVS device is connected.

 
 Also, instead of adding a new quirk flag to every single USB device, 
 you probably should use something that is hcd-specific.  Then xhci-hcd 
 could register the new sysfs file, and it wouldn't be present for other 
 controller types or non-root hubs.

That I will look into. Should be doable.

Regards
Pratyush
 
 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 v2 0/7] usb: gadget: gr_udc: OF and ep.maxpacket_limit improvements and fix of GFP_KERNEL in atomic context

2014-04-15 Thread Andreas Larsson


On 2014-03-27 16:15, Andreas Larsson wrote:

This patchset:
  - Adds some OF related improvements suggested by Mark
Rutland.
  - Adds ep.maxpacket_limit to the debugfs file and adds a check if
gr_ep_enable is called with a maxpacket value greater than
ep.maxpacket_limit.
  - Fixes a bug where GFP_KERNEL was used in atomic context

Andreas Larsson (7):
   usb: gadget: gr_udc: Make struct platform_device variable name
 clearer and use platform_set/get_drvdata
   usb: gadget: gr_udc: Expand devicetree documentation
   usb: gadget: gr_udc: Use platform_get_irq instead of
 irq_of_parse_and_map
   usb: gadget: gr_udc: Use of_property_read_u32_index to access arrays
   usb: gadget: gr_udc: Add ep.maxpacket_limit to debugfs information
   usb: gadget: gr_udc: Return error code when trying to set
 ep.maxpacket  ep.maxpacket_limit
   usb: gadget: gr_udc: Use GFP_ATOMIC when allocating under help
 spinlock

  Documentation/devicetree/bindings/usb/gr-udc.txt |   22 +
  drivers/usb/gadget/gr_udc.c  |   53 --
  2 files changed, 42 insertions(+), 33 deletions(-)



Anyone got feedback or reasons this cannot be accepted?

Best regards,
Andreas Larsson
--
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: phy: mv_u3d: Remove usb phy driver for mv_u3d

2014-04-15 Thread Paul Bolle

The usb phy driver for mv_u3d got added in v3.7 through commit
a67e76ac904c (usb: phy: mv_u3d: Add usb phy driver for mv_u3d). It
then depended on USB_MV_U3D. And that symbol depended
on CPU_MMP3 at that time. But CPU_MMP3 has never been part of the tree.
This means that this drive was unbuildable when it was added.

In commit 60630c2eabd4 (usb: gadget: mv_u3d: drop ARCH dependency)
MV_U3D_PHY was made depended directly on CPU_MMP3. That kept it
unbuildable, of course.

Remove this driver. It can be re-added once its dependencies are part of
the tree.

Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Tested with git grep.

This was triggered by Richard's [PATCH 01/28] Remove CPU_MMP3 of two
months ago, which I acked to eagerly. See
https://lkml.org/lkml/2014/2/11/714 for the details.

 drivers/usb/phy/Kconfig  |   8 -
 drivers/usb/phy/Makefile |   1 -
 drivers/usb/phy/phy-mv-u3d-usb.c | 338 ---
 drivers/usb/phy/phy-mv-u3d-usb.h | 105 
 4 files changed, 452 deletions(-)
 delete mode 100644 drivers/usb/phy/phy-mv-u3d-usb.c
 delete mode 100644 drivers/usb/phy/phy-mv-u3d-usb.h

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 416e0c8cf6ff..33dd6a6c320a 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -59,14 +59,6 @@ config KEYSTONE_USB_PHY
  interface to interact with USB 2.0 and USB 3.0 PHY that is part
  of the Keystone SOC.
 
-config MV_U3D_PHY
-   bool Marvell USB 3.0 PHY controller Driver
-   depends on CPU_MMP3
-   select USB_PHY
-   help
- Enable this to support Marvell USB 3.0 phy controller for Marvell
- SoC.
-
 config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_PHY
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index f8fa719a31b9..a2d05690d925 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_USB_OTG_FSM) += phy-fsm-usb.o
 obj-$(CONFIG_AB8500_USB)   += phy-ab8500-usb.o
 obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb.o
 obj-$(CONFIG_ISP1301_OMAP) += phy-isp1301-omap.o
-obj-$(CONFIG_MV_U3D_PHY)   += phy-mv-u3d-usb.o
 obj-$(CONFIG_NOP_USB_XCEIV)+= phy-generic.o
 obj-$(CONFIG_TAHVO_USB)+= phy-tahvo.o
 obj-$(CONFIG_AM335X_CONTROL_USB)   += phy-am335x-control.o
diff --git a/drivers/usb/phy/phy-mv-u3d-usb.c b/drivers/usb/phy/phy-mv-u3d-usb.c
deleted file mode 100644
index d317903022bf..
--- a/drivers/usb/phy/phy-mv-u3d-usb.c
+++ /dev/null
@@ -1,338 +0,0 @@
-/*
- * Copyright (C) 2011 Marvell International Ltd. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/clk.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/io.h
-#include linux/usb/otg.h
-#include linux/platform_data/mv_usb.h
-
-#include phy-mv-u3d-usb.h
-
-/*
- * struct mv_u3d_phy - transceiver driver state
- * @phy: transceiver structure
- * @dev: The parent device supplied to the probe function
- * @clk: usb phy clock
- * @base: usb phy register memory base
- */
-struct mv_u3d_phy {
-   struct usb_phy  phy;
-   struct mv_usb_platform_data *plat;
-   struct device   *dev;
-   struct clk  *clk;
-   void __iomem*base;
-};
-
-static u32 mv_u3d_phy_read(void __iomem *base, u32 reg)
-{
-   void __iomem *addr, *data;
-
-   addr = base;
-   data = base + 0x4;
-
-   writel_relaxed(reg, addr);
-   return readl_relaxed(data);
-}
-
-static void mv_u3d_phy_set(void __iomem *base, u32 reg, u32 value)
-{
-   void __iomem *addr, *data;
-   u32 tmp;
-
-   addr = base;
-   data = base + 0x4;
-
-   writel_relaxed(reg, addr);
-   tmp = readl_relaxed(data);
-   tmp |= value;
-   writel_relaxed(tmp, data);
-}
-
-static void mv_u3d_phy_clear(void __iomem *base, u32 reg, u32 value)
-{
-   void __iomem *addr, *data;
-   u32 tmp;
-
-   addr = base;
-   data = base + 0x4;
-
-   writel_relaxed(reg, addr);
-   tmp = readl_relaxed(data);
-   tmp = ~value;
-   writel_relaxed(tmp, data);
-}
-
-static void mv_u3d_phy_write(void __iomem *base, u32 reg, u32 value)
-{
-   void __iomem *addr, *data;
-
-   addr = base;
-   data = base + 0x4;
-
-   writel_relaxed(reg, addr);
-   writel_relaxed(value, data);
-}
-
-static void mv_u3d_phy_shutdown(struct usb_phy *phy)
-{
-   struct mv_u3d_phy *mv_u3d_phy;
-   void __iomem *base;
-   u32 val;
-
-   mv_u3d_phy = container_of(phy, struct mv_u3d_phy, phy);
-   base = mv_u3d_phy-base;
-
-   /* Power down Reference Analog current, bit 15
-* Power down PLL,

Re: [PATCH] USB: cdc-acm: fix broken runtime suspend

On Tue, Apr 15, 2014 at 11:13:17AM +0200, Johan Hovold wrote:
 On Tue, Apr 15, 2014 at 10:35:19AM +0200, Oliver Neukum wrote:
  On Mon, 2014-04-14 at 21:58 +0200, Johan Hovold wrote:
  
   Fix this by implementing a delayed-write queue using urb anchors and
   making sure to discard the queue properly at shutdown.
  
  Looks very good, with one exception: acm_tty_close() must
  synchronously resume the device so that the anchor is emptied
  before ASYNCB is cleared.
 
 That isn't necessary as the device is already about to be resumed and
 the initialised flag will not be cleared until chars_in_buffer() returns
 0 or closing wait times out.
 
 In the first case, the queue has been emptied as the urbs are submitted
 at resume(), and in the second case the queue is discarded at
 shutdown().

Turns out that the usb_wwan (and thus ipw, option, and qcserial) and
sierra usb-serial drivers also fail to get runtime-suspend right. The
first one leaks urbs and the second does synchronous resume and submits
urbs during shutdown.

I'll fix it up.

Johan
--
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: Missing USB XHCI and EHCI reset for kexec

2014-04-15 Thread Thadeu Lima de Souza Cascardo

On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
 
 Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
 
 On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
 
 Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:
 
 I don't know about EHCI specifically but this is a known issue with
 XHCI, I observe similar issues on other powerpc platforms (servers)
 and this isn't architecture specific (looks more like actualy xhc
 implementation specific).
 
 Thadeu Cascardo (on CC) has been the one investigating that on our side,
 he might have more to add including patches.
 
 
 I have now a kernel 3.14 dmesg log of the problem. After a kexec the
 kexeced 3.14 kernel shows:
 
 [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
 [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
 assigned bus number 1
 [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
 microseconds.
 [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
 [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
 [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
 [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
 
 
 What is your controller vendor and device IDs? Is that a TI chip?
 
 
 Yes it is a TI chip, vendor ID 104c and product ID 8241.
 
 Can you check if the patch I sent a month ago fixes it? [1] There's the
 whole story there. In fact, you will also need something like the patch
 below. Can you apply only the first one, verify, and, then, the other
 one as well, and report what worked for you?
 
 [1] http://marc.info/?l=linux-usbm=139483181809062w=2
 
 
 I tried the attach patch and it did not help. This is what i
 expected because this is a fix in the shutdown path, which will
 never called when doing a forced kexec.

Hi, Stefani.

Did you try with both patches applied? How do you evoke the forced
kexec? Is that a kexec on panic? Does it really need to be forced? With
no clean shutdown, platform and drivers would need to issue resets, like
you mentioned below, to get the system into a clean state.

 
 I have a running a 3.10.23 kernel. This kernel do a kexec for a
 kernel 3.14. Since the kernel 3.10.23 did not performe a clean
 shutdown, the state of the XHCI Controller is undefined. So when

And the clean shutdown requires both of my patches, for TI chips, as far
as I know. It looks like the problem is issuing a halt when there are
pending URBs.

 kernel 3.14 will probe XHCI it will find a XHCI controller which was
 not performed a reset.
 

The problem is not that a reset hasn't been issued. A PCI function reset
should fix most of the problems with a bad device state, when the reset
works. However, the problem is that it was not cleanly shut down. URBs
should have been canceled and removed from the controller queue, and it
should have halted after that.

 So i think it is necessary to reset the XHCI controller and all
 devices on this bus. This is what i do with a echo 1
 /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.
 

One way to look at that is making the PCI code issue resets to all buses
before doing any other access. That will make booting more slow, and
there are a lot of other corner cases where this might not be enough.
It's probably more sane to try to get the 3.10.23 kernel to do a clean
shutdown, if possible.

Regards.
Cascardo.

 - Stefani
 
 

--
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: xhci: Prefer endpoint context dequeue pointer over stopped_trb

2014-04-15 Thread Mathias Nyman


On 04/03/2014 12:29 AM, Julius Werner wrote:

Hi Mathias,


The patch looks fine.  Mathias is taking over for xHCI driver
maintainership in 3.15.  He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15.  Mathias,
will you test and queue this up for 3.14?


Did you pick this patch up anywhere yet or are there still issues with
it? I just want to make sure it doesn't slip through the cracks.
(Maybe I just didn't see it yet... are you still queueing patches in
sarah/xhci.git or do you have your own repository somewhere?)
--
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



I tried to apply this patch on top of 3.15-rc1, but it fails because of 
the streams support added to xhci_find_new_dequeue_state()


After some manual editing the interesting parts of 
xhci_find_new_dequeue_state() looks like this:


@@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd 
*xhci,

if (ep-ep_state  EP_HAS_STREAMS) {
struct xhci_stream_ctx *ctx =
ep-stream_info-stream_ctx_array[stream_id];
-   state-new_cycle_state = 0x1  
le64_to_cpu(ctx-stream_ring);

+   hw_dequeue = le64_to_cpu(ctx-stream_ring);
} else {
struct xhci_ep_ctx *ep_ctx
= xhci_get_ep_ctx(xhci, dev-out_ctx, ep_index);
-   state-new_cycle_state = 0x1  le64_to_cpu(ep_ctx-deq);
+   hw_dequeue = le64_to_cpu(ep_ctx-deq);
}

+   /* Find virtual address and segment of hardware dequeue pointer */
+   state-new_deq_seg = ep_ring-deq_seg;
+   state-new_deq_ptr = ep_ring-dequeue;
+   while (xhci_trb_virt_to_dma(state-new_deq_seg, state-new_deq_ptr)
+   != (dma_addr_t)(hw_dequeue  ~0x1)) {
+   next_trb(xhci, ep_ring, state-new_deq_seg,
+   state-new_deq_ptr);
+   if (state-new_deq_ptr == ep_ring-dequeue) {
+   WARN_ON(1);
+   return;
+   }
+   }


But I'm still concerned about the dequeue pointer in the streams case. 
streams may be nested, we might be pointing at another stream context 
instead of the dequeue pointer.


Also the comparison of the dequeue pointers, using (hw_dequeue  ~0x1) 
might have some troubles with streams. Endpoint context TR dequeue 
pointer LO field has bits 3:1 reserved (probably zero) but stream 
context uses those bits. Would it make sense to use (hw_dequeue  ~0xf) 
here instead?


So there's still some work needed. Are you interested in re-working this 
to fit on top of 3.15-rc1 or should I add it to my todo list?


-Mathias



--
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 3/4] xhci: Tune PHY for the DWC3-Exynos host controller

2014-04-15 Thread Vivek Gautam

Hi Heikki,


On Tue, Dec 10, 2013 at 7:25 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:

Giving life to this thread after long time.

 Hi,

 On Tue, Dec 10, 2013 at 04:25:25PM +0530, Vivek Gautam wrote:
 @@ -170,6 +189,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
   }

   /*
 +  * The parent of the xhci-plat device may pass in a PHY via
 +  * platform data.  If it exists, store it in our struct usb_hcd
 +  * so that we can use it later.
 +  */
 + phy_generic = dev_get_platdata(pdev-dev);
 + if (phy_generic)
 + xhci-shared_hcd-phy_generic = *phy_generic;

 Getting the handle to the phy from platform data like this is not
 going to work for long. It should be possible to get it normally with
 phy_get(). It's not going to be possible to get the handle from the
 platform data like this if the xhci-hcd platform device is created
 from ACPI or DT. You are also not considering case where you have two
 phys.

 Vivek, I have made a patch set for the phy framework allowing
 associations between the phys and their users to be made in same way
 gpios and clk make them. With those you should be able to create a
 lookup entry to the phy framework in drivers/usb/dwc3/host.c. Then we
 could use phy_get() here already. Please check them. Subject of the
 thread:

 phy: remove the need for the phys to know about their users

I had seen your patches in the mailing list, but i don't see any
updated version of these patches.
Are you planning to work on this above mentioned patch-series any time soon ?

Or, should i try to find a different approach for handling the phy
from the host controller (child of DWC3 in this case, which has the
phys).


 The lookup table can then be added in drivers/usb/dwc3/host.c with
 something like this:

 int dwc3_host_init(struct dwc3 *dwc)
 {
 struct platform_device  *xhci;
 struct phy_lookup_table *table;
 ...
 table-dev_id = dev_name(xhci-dev);
 if (dwc-usb2_generic_phy)
 table-table[0].phy_name = 
 dev_name(dwc-usb2_generic_phy-dev);
 if (dwc-usb3_generic_phy)
 table-table[1].phy_name = 
 dev_name(dwc-usb3_generic_phy-dev);
 phy_add_lookup_table(table);
 ...
--
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] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-15 Thread Kishon Vijay Abraham I


Hi,

On Monday 14 April 2014 07:19 PM, Tomasz Figa wrote:
 On 14.04.2014 15:40, Vivek Gautam wrote:
 On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I kis...@ti.com 
 wrote:


 On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
 On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I kis...@ti.com 
 wrote:


 On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
 Hi,


 On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I kis...@ti.com
 wrote:
 Hi,

 On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
   .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
   drivers/phy/Kconfig|   11 +
   drivers/phy/Makefile   |1 +
   drivers/phy/phy-exynos5-usbdrd.c   |  668
 
   4 files changed, 722 insertions(+)
   create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 28f9edb..6d99ba9 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -74,3 +74,45 @@ phy-consumer@1234 {

   Refer to DT bindings documentation of particular PHY consumer devices
 for more
   information about required PHYs and the way of specification.
 +
 +Samsung Exynos5 SoC series USB DRD PHY controller
 +--
 +
 +Required properties:
 +- compatible : Should be set to one of the following supported values:
 + - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
 + - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
 +- reg : Register offset and length of USB DRD PHY register set;
 +- clocks: Clock IDs array as required by the controller
 +- clock-names: names of clocks correseponding to IDs in the clock
 property;
 +Required clocks:
 + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP
 clock),
 +used for register access.
 + - ref: PHY's reference clock (usually crystal clock), associated 
 by
 +phy name, used to determine bit values for clock settings
 +register.
 + Additional clock required for Exynos5420:
 + - usb30_sclk_100m: Additional special clock used for PHY 
 operation
 +depicted as 'sclk_usbphy30' in CMU of 
 Exynos5420.
 +- samsung,syscon-phandle: phandle for syscon interface, which is used 
 to
 +   control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to
 pmu-system-controller
 +   base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and 
 samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 + usb3_phy: usbphy@1210 {
 + compatible = samsung,exynos5250-usbdrd-phy;
 + reg = 0x1210 0x100;
 + clocks = clock 286, clock 1;
 + clock-names = phy, usb3phy_refclk;
 + samsung,syscon-phandle = pmu_syscon;
 + samsung,pmu-offset = 0x704;
 + #phy-cells = 1;
 + };
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 8d3c49c..d955a05 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -166,4 +166,15 @@ config PHY_XGENE
help
  This option enables support for APM X-Gene SoC multi-purpose 
 PHY.

 +config PHY_EXYNOS5_USBDRD
 + tristate Exynos5 SoC series USB DRD PHY driver
 + depends on ARCH_EXYNOS5  OF
 + depends on HAS_IOMEM
 + select GENERIC_PHY
 + select MFD_SYSCON

 Lets try to avoid select in Kconfig. We've got enough problems with 
 that.

 I hope you meant with select MFD_SYSCON.
 We are referencing the syscon for accessing pmu reg, for which we need
 this config to be selected.
 Other Exynos phy drivers also need this config and for that they have
 selected this.

 Do you want me to do it any other way ?

 depends on is one option.

 Ok, i can see there are places where depends_on MFD_SYSCON is used.
 drivers/gpu/drm/exynos/Kconfig:60

 so, do you want me to fix at other places too ?

 But i also have a question here.
 MFD_SYSCON is a subsystem that's facilitating us in getting our work
 done here by giving an access to pmu_system_controller.
 So unless MFD_SYSCON is exposed, the phy driver will not be exposed to us.
 So is that valid enough really ?

 maybe in

Re: [RFC 0/2] Support for Super Speed Link Layer Test

On Tue, 15 Apr 2014, Pratyush Anand wrote:

  How about just creating a normal USB device instead of a platform 
  device?  I think all you have to do is make usb_new_device() avoid 
  calling usb_enumerate_device() when the new flag is set.
 
 I had thought of this. But, I had found that even hub_port_reset
 creates issue for LVS device. hub_port_reset forces USB SS link to go
 into recovery very soon, which is not expected as per Link Layer Test
 specification. So, we can not even allow to execute hub_port_init when
 a LVS device is connected.
 
  
  Also, instead of adding a new quirk flag to every single USB device, 
  you probably should use something that is hcd-specific.  Then xhci-hcd 
  could register the new sysfs file, and it wouldn't be present for other 
  controller types or non-root hubs.
 
 That I will look into. Should be doable.

Here's another idea: Unbind the hub driver from the root hub and
replace it with an LVS-specific driver.  That would require essentially
no changes to the existing code in usbcore.

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] USB: EHCI: tegra: set txfill_tuning

On Mon, 14 Apr 2014, Stephen Warren wrote:

 From: Stephen Warren swar...@nvidia.com
 
 To avoid memory fetch underflows with larger USB transfers, Tegra SoCs
 need txfill_tuning's txfifothresh register field set to a non-default
 value. Add a custom reset override in order to set this up.
 
 These values are recommended practice for all Tegra chips. However,
 I've only noticed practical problems when not setting them this way on
 systems using Tegra124. Hence, CC: stable only for recent kernels which
 actually support Tegra124.
 
 Cc: sta...@vger.kernel.org # 3.14+
 Signed-off-by: Stephen Warren swar...@nvidia.com

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] usb/serial/ch341: Add parity support

On Mon, Apr 14, 2014 at 07:54:17PM +, Karl Palsson wrote:
 Based on wireshark packet traces from a windows machine.
 
 ch340 and ch341 both seem to support all parity modes, but only the ch341
 appears to support variable data bits and variable stop bits, so those are 
 left
 unimplemented, as before.
 
 Tested on a generic usb-rs485 dongle with the chip label scratched off, and
 some Modbus/RTU devices that required various parity settings.
 
 Signed-off-by: Karl Palsson ka...@tweak.net.au
 ---
  drivers/usb/serial/ch341.c | 27 ++-
  1 file changed, 26 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
 index 82371f6..b870f6f 100644
 --- a/drivers/usb/serial/ch341.c
 +++ b/drivers/usb/serial/ch341.c
 @@ -346,6 +346,7 @@ static void ch341_set_termios(struct tty_struct *tty,
   struct ch341_private *priv = usb_get_serial_port_data(port);
   unsigned baud_rate;
   unsigned long flags;
 + unsigned int par_flags;
  
   baud_rate = tty_get_baud_rate(tty);
  
 @@ -366,9 +367,33 @@ static void ch341_set_termios(struct tty_struct *tty,
  
   /* Unimplemented:
* (cflag  CSIZE) : data bits [5, 8]
 -  * (cflag  PARENB) : parity {NONE, EVEN, ODD}
* (cflag  CSTOPB) : stop bits [1, 2]
*/
 + /* CH340 doesn't appear to support variable stop bits or data bits */
 + if (C_PARENB(tty)) {
 + if (C_PARODD(tty)) {
 + if (C_CMSPAR(tty)) {

Thanks for fixing the C_CMSPAR macro, but you didn't address my other
comments on v1.

 + dev_dbg(port-dev, parity = mark\n);
 + par_flags = 0xeb;
 + } else {
 + dev_dbg(port-dev, parity = odd\n);
 + par_flags = 0xcb;
 + }
 + } else {
 + if (C_CMSPAR(tty)) {
 + dev_dbg(port-dev, parity = space\n);
 + par_flags = 0xfb;
 + } else {
 + dev_dbg(port-dev, parity = even\n);
 + par_flags = 0xdb;
 + }
 + }
 + } else {
 + dev_dbg(port-dev, parity = none\n);
 + par_flags = 0xc3;
 + }
 + ch341_control_out(port-serial-dev, 0x9a, 0x2518, par_flags);

Specifically, I asked if you are able to make sense of the values of
register 0x2518. The reason I ask is that your patch changes the value
of that register from 0x50 (set in ch341_configure) to 0xc3 (when no
parity is used) and I want to make sure that you're not inadvertently
changing some other setting.

Do you know what those other bits do? Do they encode the number of data
and stop bits?

From a quick glance it seems like 

0xc0parity mode (2 bits)
0x08parity enable

but your patch now also sets bits 0x83 and clears bit 0x10.

 +

Again, you should remove this newline that your patch is adding.

  }
  
  static void ch341_break_ctl(struct tty_struct *tty, int break_state)
 -- 
 1.9.0

Thanks,
Johan
--
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: About the DRD mode implementation of DWC3 driver]

Hi,

On Tue, Apr 15, 2014 at 06:29:20PM +0800, Wang, Yu wrote:
 On Fri, Apr 11, 2014 at 06:19:57PM -0500, Felipe Balbi wrote:
 Hi,
 
 On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote:
  Hi Balbi,
  
  At first, thank you to help give the response in patience.
  
   Hi,
  
   On Wed, Apr 09, 2014 at 02:08:32PM +0800, Wang, Yu wrote:
Glad to see the OTG mode is prepare to support in your
dwc3-role-switch branch. But it is not fit for intel
Merrfield/Moorfield platforms. :(
  
   that's not what I heard when I asked some friends to test that branch
   on different platforms. It's certainly not perfect yet and that's why
   the code isn't merged in mainline, but claiming that it's not fit for
   Merrifield/Moorfield is just a lie.
  
  
  Can I get your friends' email address if they are in Intel? I would like to
 
 You already have that. Just look at Cc list.
 
  contact them to make the branch work on my Merrifield/Moorefield board too.
  Currently I can't see any link change event with the branch.
 
 how did you test it ? According to [1] Merrifield won't work for more
 than 20s or so with v3.14 and, since there is no resolution on the
 thread, I assume today's mainline won't work either.
 
 Anyway, if you really did test, test again with enabling verbose debug
 on dwc3 and show me the logs, I'm interested in what the IP is doing.
 
 Yes. As you said, the v3.14 haven't get stable so far on Merrifield
 platform. So I tried to back port your dwc3-role-switch branch solution
 to our v3.10 base and verified.

That's no the same. What if you missed something ? What if it didn't
work because you broke it while backporting ? I don't know that because
you never showed me your backported version, also did you test on v3.10
vanilla or v3.10 + Intel's patches + dwc3-role-switch backport ?

 I will waiting v3.14 get ready and do the test again to double confirm.
 I will let you know the result. Sorry cause the misunderstanding for
 you.

ok, just next time make sure to be extra clear about your setup. If I
didn't have reports from one of your colleagues that the patches were
working, I could've spent time debugging something that doesn't exist.

The reason is we implemented DRD mode instead of OTG mode. So the
GCTL.PortCapDir will be set as 01 for host mode, and 10 for device 
mode.
  
   from a SW perspective there is *no* difference. The only reason for
   using PortCapDir is to cope with platforms which want to switch roles
   but have screwed up ID pin reporting. And since most of the platforms
   actually have tha problem, it's just easier to implement it that way.
  
  
  Ok. Just confirm with you that you think it's not a matter to use
  GCTL.PortCapDir or OCTL.PeriMode to switch role, right?
 
 As of today, I don't see a difference. Things *can* change though. We
 can find out more details about the HW which forces us to use one of the
 other.
 
 I will help to try both DRD/OTG solution with your design on Merrifield
 when v3.14 get stable on it.

ok, but you probably want to use v3.15-rc1 instead of v3.14.

   I just cannot spend time imagining all twisted scenarios Vendors
   (including my employer, for that matter) want to support with whatever
   hacked up version of mainline drivers they might have.
  
   My plan is to *not* add a lot of PM support until I know all other
   features are functional. When I'm happy with those features and know
   they have been thoroughly tested on *all* users of dwc3 then we can
   all get together in a conference (maybe have a DWC3 mini-summit or
   whatever) and discuss how we're gonna implement PM *together*.
  
   Since the driver is used by many different vendors, it would be unfair
   for me to treat Intel (or any vendor, really) differently just because
   someone dropped me an email commenting about all the out-of-tree changes
   they have.
  
  
  Understand. What are the other features you mean that need thorough testing
  before adding PM support?
 
 DRD for one. Then there is a redesign of parts of the gadget API that I
 want to do before PM too. Then there is the whole Link Power Management
 (which has *nothing* to do with Linux PM - system or runtime; we can put
 the USB bus in low power mode even though we don't gate any of the USB
 IP's clocks or power rails).
 
 Get it. I think your mean is the U1/U2, right?

yup

  And also for OTG hibernation mode. If we power gate the USB PHY during
  OTG hibernation mode, and using PMIC to do ID/VBUS detection. I don't
  know if there have any issues.
 
 Until we get there, we won't know.
 
So with this PM design and DRD mode, we can't use your OTG mode. :(
  
   that's not my problem though, is it ? Since *your* PM design isn't
   available in mainline anyway. Not to mention that *my* DRD mode wasn't
   merged either, even though I have good reports from some friends
   stating it's working in 90% of the cases.
  
  
  Maybe I should add more explanation on the purpose of this

Re: [PATCH/RFC 0/3] Allow OHCI drivers to override hub control operations

Hi Alan,

Thank you for your comments.

On Monday 14 April 2014 10:35:43 Alan Stern wrote:
 On Mon, 14 Apr 2014, Laurent Pinchart wrote:
  Hello,
  
  The PXA27x OHCI implementation doesn't perform automatic control of port
  power supplies for all ports. While the PPS and LSDA bits of the
  HcRhPortStatus register are implemented, only a subset of ports have an
  external power enable pin controlled by the port status register. Other
  ports need their power supply to be controlled manually.
  
  In order to do so I've implemented manual regulator control in the
  ohci-pxa27x driver. This requires overriding the default behaviour of the
  CLEAR_FEATURE and SET_FEATURE requests for USB_PORT_FEAT_POWER with a
  custom hub control operation. In turn this requires calling the currently
  static ohci_hub_control function from the ohci-pxa27x driver.
  
  The ohci-s3c2410 driver already implements a similar feature, and accesses
  the ohci_hub_control function by saving the struct hc_driver hub_control
  value to a global variable right after calling ohci_init_driver. This is
  a bit of a hack, and as I need to call that function as well I've decided
  to export it instead.
 
 It only seems like a hack if you don't think about it the right way.  :-)
 
 The intention was to imitate an object-oriented style, by allowing a child
 class to override member functions in the parent class. The vtable mechanism
 in C++, for example, does essentially the same thing as ohci-s3c2410 (except
 that C++ doesn't save the original function pointer in a global variable;
 instead it reads the function pointer from the parent's vtable as needed --
 ohci-s3c2410 can't do that because ohci_hc_driver isn't exported).

gcc 4.9 has been released with a new speculative devirtualization optimization 
pass. As we don't use C++ we can't make use of that feature, so we need to 
perform the optimization manually, hence this change :-) 

 I'm open to the idea of exporting the hub functions. In the end, it doesn't
 make all that much difference (it would save a little object code).

I would have agreed to keep the code as it is today if you had thought that 
exporting the hub functions was a really bad idea, but as you're open to it, 
and as it removes a bit of code without much of a drawback, I think it makes 
sense to perform that optimization.

  Another option would have been to handle the regulators directly inside
  the ohci-hub implementation, but I'm not sure whether it's worth it yet.
  Comments (or acks :-)) will be appreciated.
  
  Please not that I haven't been able to test the third patch due to lack of
  hardware. I've however tested a similar implementation on an out of tree
  PXA270 board.
  
  Laurent Pinchart (3):
USB: OHCI: Export the ohci_hub_control function
USB: ohci-pxa27x: Add support for external vbus regulators
ARM: pxa: zeus: Replace OHCI init/exit functions with a regulator
   
   arch/arm/mach-pxa/zeus.c| 89 ++--
   drivers/usb/host/ohci-hub.c |  4 +-
   drivers/usb/host/ohci-pxa27x.c  | 67 +++
   drivers/usb/host/ohci-s3c2410.c |  7 +---
   drivers/usb/host/ohci.h |  2 +
   5 files changed, 121 insertions(+), 48 deletions(-)
 
 You missed ohci-at91.c.  And ehci-tegra.c plays similar games.  I'd prefer
 to do the same thing for both ehci-hcd and ohci-hcd.

OK. I'll work on a v2 of patch 1/3 that modifies ohci-at91.c as well, and I'll 
add a new patch to perform the same change for ehci-hub.c and ehci-tegra.c.

By the way, as a second step, do you think it would make sense to handle the 
vbus regulators directly in ohci_hub_control() ?

-- 
Regards,

Laurent Pinchart
--
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/4] Allow OHCI drivers to override hub control operations

Hello,

The PXA27x OHCI implementation doesn't perform automatic control of port power
supplies for all ports. While the PPS and LSDA bits of the HcRhPortStatus
register are implemented, only a subset of ports have an external power enable
pin controlled by the port status register. Other ports need their power supply
to be controlled manually.

In order to do so I've implemented manual regulator control in the ohci-pxa27x
driver. This requires overriding the default behaviour of the CLEAR_FEATURE
and SET_FEATURE requests for USB_PORT_FEAT_POWER with a custom hub control
operation. In turn this requires calling the currently static ohci_hub_control
function from the ohci-pxa27x driver.

The ohci-at91 and ohci-s3c2410 drivers already implement a similar feature,
and access the ohci_hub_control function by saving the struct hc_driver
hub_control value to a global variable right after calling ohci_init_driver.
This vtable-like implementation could be optimized by exporting the
ohci_hub_control function and calling it directly. As the ohci-pxa27x driver
needs to override hub control operations as well I've decided to export the
function.

For the sake of completeness I've also exported the ehci_hub_control function
and modified the ehci-tegra driver to call it directly.

As a side note regarding the ohci-at91 driver, the atmel,vbus-gpio DT
property should really have referenced a regulator instead of a GPIO. Fixing
this in a backward-compatible way would be messy :-(

Please not that I haven't been able to test the third and fourth patches due 
to lack of hardware. I've however tested a similar implementation for OHCI on
an out of tree PXA270 board.

Laurent Pinchart (4):
  USB: OHCI: Export the ohci_hub_control function
  USB: EHCI: Export the ehci_hub_control function
  USB: ohci-pxa27x: Add support for external vbus regulators
  ARM: pxa: zeus: Replace OHCI init/exit functions with a regulator

 arch/arm/mach-pxa/zeus.c| 89 ++---
 drivers/usb/host/ehci-hub.c | 12 +-
 drivers/usb/host/ehci-tegra.c   |  8 +---
 drivers/usb/host/ehci.h |  3 ++
 drivers/usb/host/ohci-at91.c|  6 +--
 drivers/usb/host/ohci-hub.c |  4 +-
 drivers/usb/host/ohci-pxa27x.c  | 67 +++
 drivers/usb/host/ohci-s3c2410.c |  7 +---
 drivers/usb/host/ohci.h |  2 +
 9 files changed, 128 insertions(+), 70 deletions(-)

-- 
Regards,

Laurent Pinchart

--
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 3/4] USB: ohci-pxa27x: Add support for external vbus regulators

Override the hub control operation to enable and disable external
regulators for the ports vbus power supply in response to clear/set
USB_PORT_FEAT_POWER requests.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/usb/host/ohci-pxa27x.c | 67 ++
 1 file changed, 67 insertions(+)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index d21d5fe..0c31265 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -30,6 +30,7 @@
 #include linux/platform_data/usb-ohci-pxa27x.h
 #include linux/platform_data/usb-pxa3xx-ulpi.h
 #include linux/platform_device.h
+#include linux/regulator/consumer.h
 #include linux/signal.h
 #include linux/usb.h
 #include linux/usb/hcd.h
@@ -120,6 +121,8 @@ static struct hc_driver __read_mostly ohci_pxa27x_hc_driver;
 struct pxa27x_ohci {
struct clk  *clk;
void __iomem*mmio_base;
+   struct regulator *vbus[3];
+   boolvbus_enabled[3];
 };
 
 #define to_pxa27x_ohci(hcd)(struct pxa27x_ohci *)(hcd_to_ohci(hcd)-priv)
@@ -166,6 +169,52 @@ static int pxa27x_ohci_select_pmm(struct pxa27x_ohci 
*pxa_ohci, int mode)
return 0;
 }
 
+static int pxa27x_ohci_set_vbus_power(struct pxa27x_ohci *pxa_ohci,
+ unsigned int port, bool enable)
+{
+   struct regulator *vbus = pxa_ohci-vbus[port];
+   int ret = 0;
+
+   if (IS_ERR_OR_NULL(vbus))
+   return 0;
+
+   if (enable  !pxa_ohci-vbus_enabled[port])
+   ret = regulator_enable(vbus);
+   else if (!enable  pxa_ohci-vbus_enabled[port])
+   ret = regulator_disable(vbus);
+
+   if (ret  0)
+   return ret;
+
+   pxa_ohci-vbus_enabled[port] = enable;
+
+   return 0;
+}
+
+static int pxa27x_ohci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 
wValue,
+  u16 wIndex, char *buf, u16 wLength)
+{
+   struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+   int ret;
+
+   switch (typeReq) {
+   case SetPortFeature:
+   case ClearPortFeature:
+   if (!wIndex || wIndex  3)
+   return -EPIPE;
+
+   if (wValue != USB_PORT_FEAT_POWER)
+   break;
+
+   ret = pxa27x_ohci_set_vbus_power(pxa_ohci, wIndex - 1,
+typeReq == SetPortFeature);
+   if (ret)
+   return ret;
+   break;
+   }
+
+   return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+}
 /*-*/
 
 static inline void pxa27x_setup_hc(struct pxa27x_ohci *pxa_ohci,
@@ -372,6 +421,7 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, 
struct platform_device
struct ohci_hcd *ohci;
struct resource *r;
struct clk *usb_clk;
+   unsigned int i;
 
retval = ohci_pxa_of_init(pdev);
if (retval)
@@ -417,6 +467,16 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, 
struct platform_device
pxa_ohci-clk = usb_clk;
pxa_ohci-mmio_base = (void __iomem *)hcd-regs;
 
+   for (i = 0; i  3; ++i) {
+   char name[6];
+
+   if (!(inf-flags  (ENABLE_PORT1  i)))
+   continue;
+
+   sprintf(name, vbus%u, i + 1);
+   pxa_ohci-vbus[i] = devm_regulator_get(pdev-dev, name);
+   }
+
retval = pxa27x_start_hc(pxa_ohci, pdev-dev);
if (retval  0) {
pr_debug(pxa27x_start_hc failed);
@@ -462,6 +522,10 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, 
struct platform_device
 void usb_hcd_pxa27x_remove (struct usb_hcd *hcd, struct platform_device *pdev)
 {
struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
+   unsigned int i;
+
+   for (i = 0; i  3; ++i)
+   pxa27x_ohci_set_vbus_power(pxa_ohci, i, false);
 
usb_remove_hcd(hcd);
pxa27x_stop_hc(pxa_ohci, pdev-dev);
@@ -563,7 +627,10 @@ static int __init ohci_pxa27x_init(void)
return -ENODEV;
 
pr_info(%s:  DRIVER_DESC \n, hcd_name);
+
ohci_init_driver(ohci_pxa27x_hc_driver, pxa27x_overrides);
+   ohci_pxa27x_hc_driver.hub_control = pxa27x_ohci_hub_control;
+
return platform_driver_register(ohci_hcd_pxa27x_driver);
 }
 module_init(ohci_pxa27x_init);
-- 
1.8.3.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 4/4] ARM: pxa: zeus: Replace OHCI init/exit functions with a regulator

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 arch/arm/mach-pxa/zeus.c | 89 ++--
 1 file changed, 48 insertions(+), 41 deletions(-)

diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index b19d1c3..205f9bf 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -413,7 +413,7 @@ static struct fixed_voltage_config can_regulator_pdata = {
 
 static struct platform_device can_regulator_device = {
.name   = reg-fixed-volage,
-   .id = -1,
+   .id = 0,
.dev= {
.platform_data  = can_regulator_pdata,
},
@@ -510,18 +510,6 @@ struct platform_device zeus_max6369_device = {
.num_resources  = 1,
 };
 
-static struct platform_device *zeus_devices[] __initdata = {
-   zeus_serial_device,
-   zeus_mtd_devices[0],
-   zeus_dm9k0_device,
-   zeus_dm9k1_device,
-   zeus_sram_device,
-   zeus_leds_device,
-   zeus_pcmcia_device,
-   zeus_max6369_device,
-   can_regulator_device,
-};
-
 /* AC'97 */
 static pxa2xx_audio_ops_t zeus_ac97_info = {
.reset_gpio = 95,
@@ -532,44 +520,50 @@ static pxa2xx_audio_ops_t zeus_ac97_info = {
  * USB host
  */
 
-static int zeus_ohci_init(struct device *dev)
-{
-   int err;
-
-   /* Switch on port 2. */
-   if ((err = gpio_request(ZEUS_USB2_PWREN_GPIO, USB2_PWREN))) {
-   dev_err(dev, Can't request USB2_PWREN\n);
-   return err;
-   }
-
-   if ((err = gpio_direction_output(ZEUS_USB2_PWREN_GPIO, 1))) {
-   gpio_free(ZEUS_USB2_PWREN_GPIO);
-   dev_err(dev, Can't enable USB2_PWREN\n);
-   return err;
-   }
+static struct regulator_consumer_supply zeus_ohci_regulator_supplies[] = {
+   REGULATOR_SUPPLY(vbus2, pxa27x-ohci),
+};
 
-   /* Port 2 is shared between host and client interface. */
-   UP2OCR = UP2OCR_HXOE | UP2OCR_HXS | UP2OCR_DMPDE | UP2OCR_DPPDE;
+static struct regulator_init_data zeus_ohci_regulator_data = {
+   .constraints = {
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(zeus_ohci_regulator_supplies),
+   .consumer_supplies  = zeus_ohci_regulator_supplies,
+};
 
-   return 0;
-}
+static struct fixed_voltage_config zeus_ohci_regulator_config = {
+   .supply_name= vbus2,
+   .microvolts = 500, /* 5.0V */
+   .gpio   = ZEUS_USB2_PWREN_GPIO,
+   .enable_high= 1,
+   .startup_delay  = 0,
+   .init_data  = zeus_ohci_regulator_data,
+};
 
-static void zeus_ohci_exit(struct device *dev)
-{
-   /* Power-off port 2 */
-   gpio_direction_output(ZEUS_USB2_PWREN_GPIO, 0);
-   gpio_free(ZEUS_USB2_PWREN_GPIO);
-}
+static struct platform_device zeus_ohci_regulator_device = {
+   .name   = reg-fixed-voltage,
+   .id = 1,
+   .dev = {
+   .platform_data = zeus_ohci_regulator_config,
+   },
+};
 
 static struct pxaohci_platform_data zeus_ohci_platform_data = {
.port_mode  = PMM_NPS_MODE,
/* Clear Power Control Polarity Low and set Power Sense
 * Polarity Low. Supply power to USB ports. */
.flags  = ENABLE_PORT_ALL | POWER_SENSE_LOW,
-   .init   = zeus_ohci_init,
-   .exit   = zeus_ohci_exit,
 };
 
+static void zeus_register_ohci(void)
+{
+   /* Port 2 is shared between host and client interface. */
+   UP2OCR = UP2OCR_HXOE | UP2OCR_HXS | UP2OCR_DMPDE | UP2OCR_DPPDE;
+
+   pxa_set_ohci_info(zeus_ohci_platform_data);
+}
+
 /*
  * Flat Panel
  */
@@ -677,6 +671,19 @@ static struct pxa2xx_udc_mach_info zeus_udc_info = {
.udc_command = zeus_udc_command,
 };
 
+static struct platform_device *zeus_devices[] __initdata = {
+   zeus_serial_device,
+   zeus_mtd_devices[0],
+   zeus_dm9k0_device,
+   zeus_dm9k1_device,
+   zeus_sram_device,
+   zeus_leds_device,
+   zeus_pcmcia_device,
+   zeus_max6369_device,
+   can_regulator_device,
+   zeus_ohci_regulator_device,
+};
+
 #ifdef CONFIG_PM
 static void zeus_power_off(void)
 {
@@ -847,7 +854,7 @@ static void __init zeus_init(void)
 
platform_add_devices(zeus_devices, ARRAY_SIZE(zeus_devices));
 
-   pxa_set_ohci_info(zeus_ohci_platform_data);
+   zeus_register_ohci();
 
if (zeus_setup_fb_gpios())
pr_err(Failed to setup fb gpios\n);
-- 
1.8.3.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 1/4] USB: OHCI: Export the ohci_hub_control function

Platform drivers sometimes need to perform specific handling of hub
control requests. Make this possible by exporting the ohci_hub_control()
function which can then be called from a custom hub control handler in
the default case.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/usb/host/ohci-at91.c| 6 +-
 drivers/usb/host/ohci-hub.c | 4 ++--
 drivers/usb/host/ohci-s3c2410.c | 7 ++-
 drivers/usb/host/ohci.h | 2 ++
 4 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 091ae49..0b7a999 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -46,8 +46,6 @@ static const char hcd_name[] = ohci-atmel;
 
 static struct hc_driver __read_mostly ohci_at91_hc_driver;
 static int clocked;
-static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
-   u16 wValue, u16 wIndex, char *buf, u16 wLength);
 static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
 
 extern int usb_disabled(void);
@@ -340,8 +338,7 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
break;
}
 
-   ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex + 1,
-   buf, wLength);
+   ret = ohci_hub_control(hcd, typeReq, wValue, wIndex + 1, buf, wLength);
if (ret)
goto out;
 
@@ -690,7 +687,6 @@ static int __init ohci_at91_init(void)
 * too easy.
 */
 
-   orig_ohci_hub_control = ohci_at91_hc_driver.hub_control;
orig_ohci_hub_status_data = ohci_at91_hc_driver.hub_status_data;
 
ohci_at91_hc_driver.hub_status_data = ohci_at91_hub_status_data;
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index c81c872..70013c6 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -646,7 +646,7 @@ static inline int root_port_reset (struct ohci_hcd *ohci, 
unsigned port)
return 0;
 }
 
-static int ohci_hub_control (
+int ohci_hub_control (
struct usb_hcd  *hcd,
u16 typeReq,
u16 wValue,
@@ -772,4 +772,4 @@ error:
}
return retval;
 }
-
+EXPORT_SYMBOL_GPL(ohci_hub_control);
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index ff7c8f1..95809c5 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -45,8 +45,6 @@ static struct clk *usb_clk;
 
 /* forward definitions */
 
-static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
-   u16 wValue, u16 wIndex, char *buf, u16 wLength);
 static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
 
 static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
@@ -181,7 +179,7 @@ static int ohci_s3c2410_hub_control(
 * process the request straight away and exit */
 
if (info == NULL) {
-   ret = orig_ohci_hub_control(hcd, typeReq, wValue,
+   ret = ohci_hub_control(hcd, typeReq, wValue,
   wIndex, buf, wLength);
goto out;
}
@@ -231,7 +229,7 @@ static int ohci_s3c2410_hub_control(
break;
}
 
-   ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+   ret = ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
if (ret)
goto out;
 
@@ -489,7 +487,6 @@ static int __init ohci_s3c2410_init(void)
 * override these functions by making it too easy.
 */
 
-   orig_ohci_hub_control = ohci_s3c2410_hc_driver.hub_control;
orig_ohci_hub_status_data = ohci_s3c2410_hc_driver.hub_status_data;
 
ohci_s3c2410_hc_driver.hub_status_data  = ohci_s3c2410_hub_status_data;
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index 9250cad..f317de6 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -727,3 +727,5 @@ extern int  ohci_setup(struct usb_hcd *hcd);
 extern int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup);
 extern int ohci_resume(struct usb_hcd *hcd, bool hibernated);
 #endif
+extern int ohci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+u16 wIndex, char *buf, u16 wLength);
-- 
1.8.3.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 2/4] USB: EHCI: Export the ehci_hub_control function

Platform drivers sometimes need to perform specific handling of hub
control requests. Make this possible by exporting the ehci_hub_control()
function which can then be called from a custom hub control handler in
the default case.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/usb/host/ehci-hub.c   | 12 ++--
 drivers/usb/host/ehci-tegra.c |  8 +---
 drivers/usb/host/ehci.h   |  3 +++
 3 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 7ae0c4d..fa2ede7 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -33,15 +33,6 @@
 
 #ifdef CONFIG_PM
 
-static int ehci_hub_control(
-   struct usb_hcd  *hcd,
-   u16 typeReq,
-   u16 wValue,
-   u16 wIndex,
-   char*buf,
-   u16 wLength
-);
-
 static int persist_enabled_on_companion(struct usb_device *udev, void *unused)
 {
return !udev-maxchild  udev-persist_enabled 
@@ -865,7 +856,7 @@ cleanup:
 #endif /* CONFIG_USB_HCD_TEST_MODE */
 /*-*/
 
-static int ehci_hub_control (
+int ehci_hub_control (
struct usb_hcd  *hcd,
u16 typeReq,
u16 wValue,
@@ -1285,6 +1276,7 @@ error_exit:
spin_unlock_irqrestore (ehci-lock, flags);
return retval;
 }
+EXPORT_SYMBOL_GPL(ehci_hub_control);
 
 static void ehci_relinquish_port(struct usb_hcd *hcd, int portnum)
 {
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 27ac6ad..8325a23 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -51,10 +51,6 @@ struct tegra_ehci_soc_config {
bool has_hostpc;
 };
 
-static int (*orig_hub_control)(struct usb_hcd *hcd,
-   u16 typeReq, u16 wValue, u16 wIndex,
-   char *buf, u16 wLength);
-
 struct tegra_ehci_hcd {
struct tegra_usb_phy *phy;
struct clk *clk;
@@ -236,7 +232,7 @@ static int tegra_ehci_hub_control(
spin_unlock_irqrestore(ehci-lock, flags);
 
/* Handle the hub control events here */
-   return orig_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+   return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
 
 done:
spin_unlock_irqrestore(ehci-lock, flags);
@@ -531,8 +527,6 @@ static int __init ehci_tegra_init(void)
 * too easy.
 */
 
-   orig_hub_control = tegra_ehci_hc_driver.hub_control;
-
tegra_ehci_hc_driver.map_urb_for_dma = tegra_ehci_map_urb_for_dma;
tegra_ehci_hc_driver.unmap_urb_for_dma = tegra_ehci_unmap_urb_for_dma;
tegra_ehci_hc_driver.hub_control = tegra_ehci_hub_control;
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 9dfc6c1..eee228a 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -872,4 +872,7 @@ extern int  ehci_suspend(struct usb_hcd *hcd, bool 
do_wakeup);
 extern int ehci_resume(struct usb_hcd *hcd, bool hibernated);
 #endif /* CONFIG_PM */
 
+extern int ehci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+u16 wIndex, char *buf, u16 wLength);
+
 #endif /* __LINUX_EHCI_HCD_H */
-- 
1.8.3.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: xhci: non-superspeed enumeration failure (was: Re: medtronic usb productId 0x8001: usbserial support, xhci enumeration)

On Sun, Apr 13, 2014 at 05:04:50PM -0700, Benjamin West wrote:
On Thu, Apr 3, 2014 at 9:32 AM, Johan Hovold jo...@hovold.com wrote:

Ok, looks like the same error as with usb-next. Could you provide a log
with debugging enabled when enumeration fails on v3.14-rc7? Perhaps
someone who knows more about xhci could be kind enough provide some
further insight as to what might be going on then.

Benjamin, did you look any further at this?

I thought I had enabled debugging.
My boot config has
* CONFIG_USB_DEBUG=y
* CONFIG_USB_SERIAL_DEBUG=m
and several other relevant looking items set to y, perhaps I simply
need to dynamically enable debug by setting something in sysfs?

Yes, dynamic debugging and

echo module xhci_hcd +p /sys/kernel/debug/dynamic_debug/control

should do the trick.

I've been playing with this this (v3.14-rc7) extensively over the past
few weeks.

* The first insert of the device rarely works, but occasionally it
does appear on boot
* usually lsusb blocks for a long time (10's of seconds) if the
enumeration is not working

What I've found is that removing the usb stick while lsusb is hanging,
and re-inserting, on the third try the device enumerates. After this,
plugging in/removing enumerates as expected. Once the device
enumerates successfully, it seems to consistently enumerate
afterwards.

Each port seems to experience this problem independently of the
others. Eg, plugging in the device 3 times on a port seems to make it
enumerate, but the first few times lsusb tends to hang for a long
time.

I guess that points to the HC rather than the device then.

To test this, I just tried waiting the full length between timeouts.
There is a log of the result here:

https://gist.githubusercontent.com/bewest/6488955/raw/77a431e50ebadd27641e2685dc1184aa96da05c6/annotated-runs-3.14.0-rc7-bewest-test-3.14-rc7-carelink-01.log

The procedure was to insert/remove the stick only after waiting for
the full timeout, eg, waiting for lsusb to return, and never
interrupting the process.
After several attempts, something happened, and the usb stack as a
whole seems to have reset or something, I lost access to my internal
bluetooth, and the Atheros entry usually present from lsusb output was
missing.

On reboot, I continued and kept the entire syslog from reboot | grep
kernel, here:
https://gist.githubusercontent.com/bewest/6488955/raw/c436764d806426d373c36b25d4eb96276a16c1ae/theory-grep-kernel-3.14.0-rc7-bewest-test-3.14-rc7-carelink-01.log

In this one, I did not wait for lsusb to timeout; the number of
attempts doesn't seem to matter, but the timing does. This time I
seem to be able to moderate what happens by removing the usb stick
just after I see:

Apr 13 15:51:16 patient kernel: [ 431.837705] xhci_hcd
:00:14.0: Timeout while waiting for setup address command

I'm doing watch lsusb in another terminal, and removing the device
as soon as I see this message, then inserting it again. I stop doing
the lsusb/syslog output indicates that the device has enumerated.

Benjamin, have you tried the device on a different host controller?

No, I haven't, my access to different machines is limited right now.
I have spares of this device, I'd be willing to mail one to someone
if it'd be helpful.

I guess that would be Mathias or some other xhci-person.

Johan
--
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: non-superspeed enumeration failure

On Sun, Apr 13, 2014 at 05:53:10PM -0700, Benjamin West wrote:
 On Tue, Apr 8, 2014 at 12:52 AM, Johan Hovold jo...@hovold.com wrote:
  On Mon, Apr 07, 2014 at 07:26:01PM +0300, Mathias Nyman wrote:
  On 04/03/2014 07:32 PM, Johan Hovold wrote:
   Hi Mathias and Benjamin,
  
   Mathias, I understand you've got quite a lot on your plate with xhci at
   the moment, but have you had a change to look at this issue yet? It's an
   xhci-issue (possibly due to buggy hw) which seems related to the
   non-superspeed enumeration work that was made by Sarah and Dan during
   the fall.
  
   In summary, the device works fine with ehci, but fails to enumerate
   with xhci. Prior to 3.14 this resulted in babble errors, but since 3.14
   it appears that enumeration times out instead:
  
   xhci_hcd :00:14.0: Timeout while waiting for setup address 
   command
  
   Sometimes it enumerates successfully with 3.14, though.
  
   Not sure if it's related, but Benjamin was also able to trigger:
  
   xhci_hcd :00:14.0: HC died; cleaning up
  
   The full thread is available here:
  
   http://marc.info/?l=linux-usbm=139464536212863w=2
  
   (The usb-serial related bits are really just about recognising the
   VID/PID and is unrelated to the xhci-enumeration problem.)
  
   Do you need any further information from Benjamin?
 
  It might be related to Dan's enumeration scheme change, but
  looking at the xhci parts of the logs there seems to be both Address
  command timeout and halting/stalling endpoint clearing issues.
 
  There is currently an issue with clearing halted endpoints and toggle
  bit getting out of sync on xhci which I'm about to take on, this could
  be related.
 
  http://marc.info/?l=libusb-develm=134930472420570w=2
 
  Hopefully, fixing that will solve some of the issues you are seeing as 
  well.
 
  There's also a rfc patchset which completely changes how xhci handles
  command timeouts. You could also test if it has any impact on the
  address command timeout.
 
  http://marc.info/?l=linux-usbm=139653559120996w=2
 
  Alright, thanks for taking a look.
 
  Benjamin, were you able to reproduce this on a different host
  controller? If you're interested in debugging this further you could try
  Mathias timeout RFC. I could prepare a branch for you to pull if that'd
  simplify things.

 This sounds interesting.
 If you prepare a branch, I'll certainly give it a try, thank you.

There's a completely untested xhci-cmdqueue branch in my tree now that
you could try:


https://git.kernel.org/cgit/linux/kernel/git/johan/usb-serial.git/log/?h=xhci-cmdqueue

I've simply applied Mathias series from here:

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

to v3.15-rc1.

 I'll look for a way to test this on other hardware/different host
 controller.

I'd definitely recommend that.

 It may or may not be relevant, but the vendor admits that there are
 issues in Windows and Mac that also prevents their software from
 working with USB 3.0 ports.  When I asked them on the phone, they told
 me the reason was because the ports are the wrong size and it's not a
 universal system.  So I know the issue is a generic one involving 3.0
 handling across different operating systems/hardware, not just mine.
 I'll look for an opportunity to test on other hardware.

Wrong size? :)

Well, if the device doesn't enumerate under those other OSes either,
this may be a long shot.

But best of luck!

Johan
--
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 2/4] USB: EHCI: Export the ehci_hub_control function

2014-04-15 Thread Stephen Warren

On 04/15/2014 10:06 AM, Laurent Pinchart wrote:
 Platform drivers sometimes need to perform specific handling of hub
 control requests. Make this possible by exporting the ehci_hub_control()
 function which can then be called from a custom hub control handler in
 the default case.

I recall trying to do something like this in the past, but IIRC Alan
Stern didn't want to make this easy for odd drivers needing this unusual
case. Witness the comment right above the context of the modified code
in ehci-tegra.c:

 diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c

/*
 * The Tegra HW has some unusual quirks, which require Tegra-specific
 * workarounds. We override certain hc_driver functions here to
 * achieve that. We explicitly do not enhance ehci_driver_overrides to
 * allow this more easily, since this is an unusual case, and we don't
 * want to encourage others to override these functions by making it
 * too easy.
 */

orig_hub_control = tegra_ehci_hc_driver.hub_control;

 @@ -531,8 +527,6 @@ static int __init ehci_tegra_init(void)
* too easy.
*/
  
 - orig_hub_control = tegra_ehci_hc_driver.hub_control;
 -

--
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] usb: gadget: Add xilinx axi usb2 device support

Hi,

On Wed, Mar 26, 2014 at 03:37:52PM +0530, sundeep subbaraya wrote:
  + INIT_LIST_HEAD(req-queue);
 
  remove this INIT_LIST_HEAD();
 
  also, before returning, I suppose you probably want to link the request
  to the endpoint somehow. Usually people save the endpoint pointer inside
  the private request structure (iow: req-ep = ep;)
 
 
 in ep_queue (say,for IN transaction) the driver copies the gadget
 driver buffer to HW endpoint buffer and if whole data
 has been transferred successfully then request is not added to
 endpoint request list. Hence  INIT_LIST_HEAD(req-queue)
 is required since list_add_tail is not done every time in ep_queue. Is
 it ok to let this be here?o

my bad, you _do_ need this INIT_LIST_HEAD() here. When I first read, I
thought you were initializing struct usb_request list_head, and that is
not necessary ;-)

  + if (req != NULL)
  + list_add_tail(req-queue, ep-queue);
 Here. INIT_LIST_HEAD(req-queue) is required in alloc_req since
 list_add_tail is not executed every time.
 
 Could you please clarify my questions regarding requests queuing.
 1. If Device need to send 5120 bytes to host and
 ep-desc-wMaxPacketSize is 512 then single request with length 5120
 is issued or 10 requests are issued?

single request.

 2. Does device need to know OUT transactions before hand so that OUT
 requests are queued for endpoint before packets are received
 from host?

well, no. Gadget driver shouldn't depend on that. That's UDC driver's
responsability to manage that. I mean, if host sends OUT token and
there's nothing in the out queue, then UDC need to start transfer as
soon as gadget driver queues the request. If, on the other hand, gadget
driver queues packet before host has sent OUT token then you have two
choices:

1) start the transfer - most HW will wait for OUT token
2) wait for out token

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: phy: mv_u3d: Remove usb phy driver for mv_u3d

On Tue, Apr 15, 2014 at 01:36:23PM +0200, Paul Bolle wrote:
 The usb phy driver for mv_u3d got added in v3.7 through commit
 a67e76ac904c (usb: phy: mv_u3d: Add usb phy driver for mv_u3d). It
 then depended on USB_MV_U3D. And that symbol depended
 on CPU_MMP3 at that time. But CPU_MMP3 has never been part of the tree.
 This means that this drive was unbuildable when it was added.
 
 In commit 60630c2eabd4 (usb: gadget: mv_u3d: drop ARCH dependency)
 MV_U3D_PHY was made depended directly on CPU_MMP3. That kept it
 unbuildable, of course.
 
 Remove this driver. It can be re-added once its dependencies are part of
 the tree.
 
 Signed-off-by: Paul Bolle pebo...@tiscali.nl
 ---
 Tested with git grep.
 
 This was triggered by Richard's [PATCH 01/28] Remove CPU_MMP3 of two
 months ago, which I acked to eagerly. See
 https://lkml.org/lkml/2014/2/11/714 for the details.

so this means that drivers/usb/gadget/mv_u3d_core.c isn't used either ?
Instead of deleting this and introducing a new driver, why don't you
just help fix what's already in-tree ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb/serial/ch341: Add parity support

On Tue, Apr 15, 2014 at 04:06:11PM +0200, Johan Hovold wrote:
 On Mon, Apr 14, 2014 at 07:54:17PM +, Karl Palsson wrote:

  +   if (C_PARENB(tty)) {
  +   if (C_PARODD(tty)) {
  +   if (C_CMSPAR(tty)) {
 
 Thanks for fixing the C_CMSPAR macro, but you didn't address my other
 comments on v1.
 
  +   dev_dbg(port-dev, parity = mark\n);
  +   par_flags = 0xeb;
  +   } else {
  +   dev_dbg(port-dev, parity = odd\n);
  +   par_flags = 0xcb;
  +   }
  +   } else {
  +   if (C_CMSPAR(tty)) {
  +   dev_dbg(port-dev, parity = space\n);
  +   par_flags = 0xfb;
  +   } else {
  +   dev_dbg(port-dev, parity = even\n);
  +   par_flags = 0xdb;
  +   }
  +   }
  +   } else {
  +   dev_dbg(port-dev, parity = none\n);
  +   par_flags = 0xc3;
  +   }
  +   ch341_control_out(port-serial-dev, 0x9a, 0x2518, par_flags);
 
 Specifically, I asked if you are able to make sense of the values of
 register 0x2518. The reason I ask is that your patch changes the value
 of that register from 0x50 (set in ch341_configure) to 0xc3 (when no
 parity is used) and I want to make sure that you're not inadvertently
 changing some other setting.
 
 Do you know what those other bits do? Do they encode the number of data
 and stop bits?
 
 From a quick glance it seems like 
 
   0xc0parity mode (2 bits)
   0x08parity enable

 but your patch now also sets bits 0x83 and clears bit 0x10.

That should have been:

0x30parity mode (2 bits)
0x08parity enable

and your patch now always sets bits 0x83.

Johan
--
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] usb: gadget: Add xilinx axi usb2 device support

On Tue, 15 Apr 2014, Felipe Balbi wrote:

  2. Does device need to know OUT transactions before hand so that OUT
  requests are queued for endpoint before packets are received
  from host?
 
 well, no. Gadget driver shouldn't depend on that. That's UDC driver's
 responsability to manage that. I mean, if host sends OUT token and
 there's nothing in the out queue, then UDC need to start transfer as
 soon as gadget driver queues the request. If, on the other hand, gadget
 driver queues packet before host has sent OUT token then you have two
 choices:
 
 1) start the transfer - most HW will wait for OUT token
 2) wait for out token

I'm not familiar with the variations in all the different UDC hardware.  
Nevertheless, I wouldn't describe the situation in those terms.

If an OUT transaction occurs and the gadget driver hasn't queued a
request, the UDC hardware could store the incoming data in an internal
buffer or it could NAK the transaction.  There aren't any other
choices.  If there isn't enough space available in an internal buffer,
the only possible action is NAK.

Regardless, gadget drivers do not need to queue requests for OUT
endpoints before the host starts sending data.  When the request does
get queued, the UDC driver will make sure that the transfer takes
place.

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 v2 2/4] USB: EHCI: Export the ehci_hub_control function

On Tue, 15 Apr 2014, Stephen Warren wrote:

 On 04/15/2014 10:06 AM, Laurent Pinchart wrote:
  Platform drivers sometimes need to perform specific handling of hub
  control requests. Make this possible by exporting the ehci_hub_control()
  function which can then be called from a custom hub control handler in
  the default case.
 
 I recall trying to do something like this in the past, but IIRC Alan
 Stern didn't want to make this easy for odd drivers needing this unusual
 case. Witness the comment right above the context of the modified code
 in ehci-tegra.c:
 
  diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
 
 /*
  * The Tegra HW has some unusual quirks, which require Tegra-specific
  * workarounds. We override certain hc_driver functions here to
  * achieve that. We explicitly do not enhance ehci_driver_overrides to
  * allow this more easily, since this is an unusual case, and we don't
  * want to encourage others to override these functions by making it
  * too easy.
  */

Yeah.  I sort of changed my mind about that.  While this sort of 
overriding is still discouraged, we may as well reduce the penalty for 
doing it.

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 v2 1/4] USB: OHCI: Export the ohci_hub_control function

On Tue, 15 Apr 2014, Laurent Pinchart wrote:

 Platform drivers sometimes need to perform specific handling of hub
 control requests. Make this possible by exporting the ohci_hub_control()
 function which can then be called from a custom hub control handler in
 the default case.

You should also export ohci_hub_status_data(), since it also gets
overridden by these other drivers.

For ehci-hcd, this doesn't seem to matter since ehci_hub_status_data 
doesn't get overridden anywhere.

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] usb: phy: mv_u3d: Remove usb phy driver for mv_u3d

2014-04-15 Thread Paul Bolle

On Tue, 2014-04-15 at 12:23 -0500, Felipe Balbi wrote:
 so this means that drivers/usb/gadget/mv_u3d_core.c isn't used either ?

Why should it? There's no dependency on CPU_MMP3 for USB_MV_U3D anymore,
is there?

 Instead of deleting this and introducing a new driver, why don't you
 just help fix what's already in-tree ?

Were any of the reasons I gave for removing this driver incorrect? Has
it actually ever been possible to build it?


Paul Bolle

--
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: Missing USB XHCI and EHCI reset for kexec


Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern:
 On Mon, 14 Apr 2014 stef...@seibold.net wrote:
 
  Zitat von Alan Stern st...@rowland.harvard.edu:
  
  
   6[  167.936921] usb 2-2.1: new full-speed USB device number 3  
   using ohci-pci
   6[  168.067890] usb 2-2.1: New USB device found, idVendor=076b,
   idProduct=a021
   6[  168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
   SerialNumber=0
   6[  168.082226] usb 2-2.1: Product: Smart Card Reader
   6[  168.086963] usb 2-2.1: Manufacturer: USB
   6[  168.172893] usb 2-2.2: new low-speed USB device number 4  
   using ohci-pci
   6[  168.300839] usb 2-2.2: New USB device found, idVendor=0aad,
   idProduct=0024
   6[  168.307823] usb 2-2.2: New USB device strings: Mfr=1, Product=2,
   SerialNumber=0
   6[  168.315180] usb 2-2.2: Product: FrontPanel USB Keyboard
   6[  168.320436] usb 2-2.2: Manufacturer: RohdeSchwarz
   6[  168.337895] input: RohdeSchwarz FrontPanel USB Keyboard as
   /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
   6[  168.360988] input: RohdeSchwarz FrontPanel USB Keyboard as
   /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1
  
   Since some devices work and some don't, maybe part of the problem lies
   in the particular devices.
  
  
  The problem lies on the Bus 001 Device 002: ID 0424:2514 Standard  
  Microsystems Corp. USB 2.0 Hub, which hangs for arround 162 seconds  
  after a kexec.
  
  The Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card  
  Reader and Bus 002 Device 004: ID 0aad:0024 Rohde  Schwarz GmbH   
  Co. KG are attached to this Hub.

   What about if you just do:
  
 rmmod ehci-pci
 modprobe ehci-pci
  
  
  The kernel is monolitic because the USB HW is needed in a early boot  
  stage. The problem also occurs with ehci-fsl used in by an other  
  PowerPC device, which is a part of the SoC and is not attached to the  
  PCI bus.
  
  One thing is that the echo 1  
   /sys/bus/pci/drivers/ehci-pci/\:00\:17.2/reset workaround will  
  no longer work for kernel 3.14.
 
 Instead, you could try
 
   echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/unbind
   echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/bind
 

I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
the following dmesg log:

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-pci :00:17.2: EHCI Host Controller
ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
ehci-pci :00:17.2: irq 22, io mem 0xc0006800
ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd :00:17.0: OHCI Host Controller
ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd :00:17.1: OHCI Host Controller
ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
mpc-i2c fef03000.i2c: timeout 100 us
rtc-rs5c372 0-0032: rs5c372a found, 24hr, driver version 0.6
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
mpc-i2c fef03100.i2c: timeout 100 us
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
rsfrontp: using key table SMBV (117)
usbcore: registered new interface driver rsfrontp
rsfrontp: RS USB HID Frontpanel driver (v1.2)
usbcore: registered new interface driver rsknop
rsknop: RS USB HID Knop support (v1.4)
usb 1-2: new high-speed USB device number 2 using ehci-pci
zram: Created 1 device(s) ...
TCP: cubic registered
NET: Registered protocol family 17
rtc-rs5c372 0-0032: setting system clock to 2014-04-14 14:51:50 UTC (1397487110)
Freeing unused kernel memory: 996K (c032e000 - c0427000)
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 4 ports detected
yaffs: dev is 32505859 name is mtdblock3 rw
yaffs: passed flags 
yaffs: yaffs: Attempting MTD mount of 31.3,mtdblock3
yaffs: auto selecting yaffs2
yaffs: yaffs_read_super: is_checkpointed 1
usb 2-2: new full-speed USB device number 2 using ohci_hcd
hub 2-2:1.0: USB hub found
hub 2-2:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
usb 2-2.1: new full-speed USB device number 3 using ohci_hcd
usb 2-2.2: new low-speed USB device number 4 using ohci_hcd
input: RohdeSchwarz FrontPanel USB Keyboard as 
/devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
fsl-gianfar fef24000.ethernet eth0: mac: 00:90:b8:1b:36:37
input: RohdeSchwarz FrontPanel USB Keyboard as 
/devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1
fsl-gianfar fef24000.ethernet eth0: Running

Re: Missing USB XHCI and EHCI reset for kexec

Am Montag, den 14.04.2014, 13:58 -0400 schrieb Alan Stern:
 On Mon, 14 Apr 2014, Stefani Seibold wrote:
 
An other PowerPC device which is nearly eactly the same HW but without  
this USB HUB works perfectly.
   
   Maybe you should replace that hub with a different brand.
   
  
  Thats not possible, because the Hub is soldered on the board. And it is
  also not a HW issue, since the Hub works perfectly which all previous
  kernels including 3.4.
 
 One other thing you can try is to increase the reset timeout in 
 drivers/usb/host/ehci-hub.c.  This is under the USB_PORT_FEAT_RESET 
 case in ehci_hub_control(), around line 1225:
 
   /*
* caller must wait, then call GetPortStatus
* usb 2.0 spec says 50 ms resets on root
*/
   ehci-reset_done [wIndex] = jiffies
   + msecs_to_jiffies (50);
 
 Increasing the 50 to 100 or more might help.
 
 Alan Stern
 

I tried this, when i increase the value to 1000, the reset and
enumeration process will be faster after a kexec: 28 Seconds vs. 162
Seconds.

- Stefani

--
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: Missing USB XHCI and EHCI reset for kexec

2014-04-15 Thread Thadeu Lima de Souza Cascardo

On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
 
 Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
 
 On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
 
 Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
 
 On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
 
 Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:
 
 I don't know about EHCI specifically but this is a known issue with
 XHCI, I observe similar issues on other powerpc platforms (servers)
 and this isn't architecture specific (looks more like actualy xhc
 implementation specific).
 
 Thadeu Cascardo (on CC) has been the one investigating that on our side,
 he might have more to add including patches.
 
 
 I have now a kernel 3.14 dmesg log of the problem. After a kexec the
 kexeced 3.14 kernel shows:
 
 [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
 [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
 assigned bus number 1
 [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
 microseconds.
 [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
 [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
 [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
 [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
 
 
 What is your controller vendor and device IDs? Is that a TI chip?
 
 
 Yes it is a TI chip, vendor ID 104c and product ID 8241.
 
 Can you check if the patch I sent a month ago fixes it? [1] There's the
 whole story there. In fact, you will also need something like the patch
 below. Can you apply only the first one, verify, and, then, the other
 one as well, and report what worked for you?
 
 [1] http://marc.info/?l=linux-usbm=139483181809062w=2
 
 
 I tried the attach patch and it did not help. This is what i
 expected because this is a fix in the shutdown path, which will
 never called when doing a forced kexec.
 
 Hi, Stefani.
 
 Did you try with both patches applied? How do you evoke the forced
 kexec? Is that a kexec on panic? Does it really need to be forced? With
 no clean shutdown, platform and drivers would need to issue resets, like
 you mentioned below, to get the system into a clean state.
 
 
 Yes, i applied both patches. But without success.
 
 IMHO i think it is necessary to bring the device i a clean state
 when the driver use the HW.
 
 
 I have a running a 3.10.23 kernel. This kernel do a kexec for a
 kernel 3.14. Since the kernel 3.10.23 did not performe a clean
 shutdown, the state of the XHCI Controller is undefined. So when
 
 And the clean shutdown requires both of my patches, for TI chips, as far
 as I know. It looks like the problem is issuing a halt when there are
 pending URBs.
 
 kernel 3.14 will probe XHCI it will find a XHCI controller which was
 not performed a reset.
 
 
 The problem is not that a reset hasn't been issued. A PCI function reset
 should fix most of the problems with a bad device state, when the reset
 works. However, the problem is that it was not cleanly shut down. URBs
 should have been canceled and removed from the controller queue, and it
 should have halted after that.
 
 Again, i think it is the job of the driver to bring the chip in a clean state
 before using them. A driver should never expect a reset state of a chip.
 
 
 So i think it is necessary to reset the XHCI controller and all
 devices on this bus. This is what i do with a echo 1
 /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.
 
 
 One way to look at that is making the PCI code issue resets to all buses
 before doing any other access. That will make booting more slow, and
 there are a lot of other corner cases where this might not be enough.
 It's probably more sane to try to get the 3.10.23 kernel to do a clean
 shutdown, if possible.
 
 
 With this driver design the kexec functionality is usesless on PowerPC.
 X86 looks a little bit better.
 
 - Stefani
 
 

What is the vendor and device ID you are using on your X86 system? This
is not a matter of what architecture you are using, it's the XHCI
controller which does not behave as well as the one you are using on
X86, which is likely an Intel one.

Cascardo.

--
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: Missing USB XHCI and EHCI reset for kexec

Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
Cascardo:
 On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
  
  Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
  
  On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
  
  Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
  
  On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
  
  Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:
  
  I don't know about EHCI specifically but this is a known issue with
  XHCI, I observe similar issues on other powerpc platforms (servers)
  and this isn't architecture specific (looks more like actualy xhc
  implementation specific).
  
  Thadeu Cascardo (on CC) has been the one investigating that on our 
  side,
  he might have more to add including patches.
  
  
  I have now a kernel 3.14 dmesg log of the problem. After a kexec the
  kexeced 3.14 kernel shows:
  
  [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
  [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
  assigned bus number 1
  [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
  microseconds.
  [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
  [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
  [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
  [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
  
  
  What is your controller vendor and device IDs? Is that a TI chip?
  
  
  Yes it is a TI chip, vendor ID 104c and product ID 8241.
  
  Can you check if the patch I sent a month ago fixes it? [1] There's the
  whole story there. In fact, you will also need something like the patch
  below. Can you apply only the first one, verify, and, then, the other
  one as well, and report what worked for you?
  
  [1] http://marc.info/?l=linux-usbm=139483181809062w=2
  
  
  I tried the attach patch and it did not help. This is what i
  expected because this is a fix in the shutdown path, which will
  never called when doing a forced kexec.
  
  Hi, Stefani.
  
  Did you try with both patches applied? How do you evoke the forced
  kexec? Is that a kexec on panic? Does it really need to be forced? With
  no clean shutdown, platform and drivers would need to issue resets, like
  you mentioned below, to get the system into a clean state.
  
  
  Yes, i applied both patches. But without success.
  
  IMHO i think it is necessary to bring the device i a clean state
  when the driver use the HW.
  
  
  I have a running a 3.10.23 kernel. This kernel do a kexec for a
  kernel 3.14. Since the kernel 3.10.23 did not performe a clean
  shutdown, the state of the XHCI Controller is undefined. So when
  
  And the clean shutdown requires both of my patches, for TI chips, as far
  as I know. It looks like the problem is issuing a halt when there are
  pending URBs.
  
  kernel 3.14 will probe XHCI it will find a XHCI controller which was
  not performed a reset.
  
  
  The problem is not that a reset hasn't been issued. A PCI function reset
  should fix most of the problems with a bad device state, when the reset
  works. However, the problem is that it was not cleanly shut down. URBs
  should have been canceled and removed from the controller queue, and it
  should have halted after that.
  
  Again, i think it is the job of the driver to bring the chip in a clean 
  state
  before using them. A driver should never expect a reset state of a chip.
  
  
  So i think it is necessary to reset the XHCI controller and all
  devices on this bus. This is what i do with a echo 1
  /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.
  
  
  One way to look at that is making the PCI code issue resets to all buses
  before doing any other access. That will make booting more slow, and
  there are a lot of other corner cases where this might not be enough.
  It's probably more sane to try to get the 3.10.23 kernel to do a clean
  shutdown, if possible.
  
  
  With this driver design the kexec functionality is usesless on PowerPC.
  X86 looks a little bit better.
  
  - Stefani
  
  
 
 What is the vendor and device ID you are using on your X86 system? This
 is not a matter of what architecture you are using, it's the XHCI
 controller which does not behave as well as the one you are using on
 X86, which is likely an Intel one.
 

It is an Intel 8086:8c31. But this was only a side note. We need a
generic solution not a vendor specific one. Otherwise kexec is useless
on other architectures.

- Stefani


--
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: Missing USB XHCI and EHCI reset for kexec

2014-04-15 Thread Thadeu Lima de Souza Cascardo

On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote:
 Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
 Cascardo:
  On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
   
   Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
   
   On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
   
   Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
   
   On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
   
   Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:
   
   I don't know about EHCI specifically but this is a known issue with
   XHCI, I observe similar issues on other powerpc platforms (servers)
   and this isn't architecture specific (looks more like actualy xhc
   implementation specific).
   
   Thadeu Cascardo (on CC) has been the one investigating that on our 
   side,
   he might have more to add including patches.
   
   
   I have now a kernel 3.14 dmesg log of the problem. After a kexec the
   kexeced 3.14 kernel shows:
   
   [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
   [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
   assigned bus number 1
   [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
   microseconds.
   [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
   [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
   [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
   [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
   
   
   What is your controller vendor and device IDs? Is that a TI chip?
   
   
   Yes it is a TI chip, vendor ID 104c and product ID 8241.
   
   Can you check if the patch I sent a month ago fixes it? [1] There's the
   whole story there. In fact, you will also need something like the patch
   below. Can you apply only the first one, verify, and, then, the other
   one as well, and report what worked for you?
   
   [1] http://marc.info/?l=linux-usbm=139483181809062w=2
   
   
   I tried the attach patch and it did not help. This is what i
   expected because this is a fix in the shutdown path, which will
   never called when doing a forced kexec.
   
   Hi, Stefani.
   
   Did you try with both patches applied? How do you evoke the forced
   kexec? Is that a kexec on panic? Does it really need to be forced? With
   no clean shutdown, platform and drivers would need to issue resets, like
   you mentioned below, to get the system into a clean state.
   
   
   Yes, i applied both patches. But without success.
   
   IMHO i think it is necessary to bring the device i a clean state
   when the driver use the HW.
   
   
   I have a running a 3.10.23 kernel. This kernel do a kexec for a
   kernel 3.14. Since the kernel 3.10.23 did not performe a clean
   shutdown, the state of the XHCI Controller is undefined. So when
   
   And the clean shutdown requires both of my patches, for TI chips, as far
   as I know. It looks like the problem is issuing a halt when there are
   pending URBs.
   
   kernel 3.14 will probe XHCI it will find a XHCI controller which was
   not performed a reset.
   
   
   The problem is not that a reset hasn't been issued. A PCI function reset
   should fix most of the problems with a bad device state, when the reset
   works. However, the problem is that it was not cleanly shut down. URBs
   should have been canceled and removed from the controller queue, and it
   should have halted after that.
   
   Again, i think it is the job of the driver to bring the chip in a clean 
   state
   before using them. A driver should never expect a reset state of a chip.
   
   
   So i think it is necessary to reset the XHCI controller and all
   devices on this bus. This is what i do with a echo 1
   /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.
   
   
   One way to look at that is making the PCI code issue resets to all buses
   before doing any other access. That will make booting more slow, and
   there are a lot of other corner cases where this might not be enough.
   It's probably more sane to try to get the 3.10.23 kernel to do a clean
   shutdown, if possible.
   
   
   With this driver design the kexec functionality is usesless on PowerPC.
   X86 looks a little bit better.
   
   - Stefani
   
   
  
  What is the vendor and device ID you are using on your X86 system? This
  is not a matter of what architecture you are using, it's the XHCI
  controller which does not behave as well as the one you are using on
  X86, which is likely an Intel one.
  
 
 It is an Intel 8086:8c31. But this was only a side note. We need a
 generic solution not a vendor specific one. Otherwise kexec is useless
 on other architectures.
 
 - Stefani
 
 

It's probably useless on X86 with a TI XHCI board. I just don't have
such an environment to test. Can you arrange to test that? If that shows
me wrong, we certainly need to investigate this

Re: Missing USB XHCI and EHCI reset for kexec

Am Dienstag, den 15.04.2014, 15:49 -0300 schrieb Thadeu Lima de Souza
Cascardo:
 On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote:
  Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
  Cascardo:
   On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:

Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:

On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:

Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:

On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:

Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:

I don't know about EHCI specifically but this is a known issue with
XHCI, I observe similar issues on other powerpc platforms (servers)
and this isn't architecture specific (looks more like actualy xhc
implementation specific).

Thadeu Cascardo (on CC) has been the one investigating that on our 
side,
he might have more to add including patches.


I have now a kernel 3.14 dmesg log of the problem. After a kexec the
kexeced 3.14 kernel shows:

[1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
[1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
assigned bus number 1
[1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
microseconds.
[1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
[1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
[1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
[1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error 
-110


What is your controller vendor and device IDs? Is that a TI chip?


Yes it is a TI chip, vendor ID 104c and product ID 8241.

Can you check if the patch I sent a month ago fixes it? [1] There's 
the
whole story there. In fact, you will also need something like the 
patch
below. Can you apply only the first one, verify, and, then, the other
one as well, and report what worked for you?

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


I tried the attach patch and it did not help. This is what i
expected because this is a fix in the shutdown path, which will
never called when doing a forced kexec.

Hi, Stefani.

Did you try with both patches applied? How do you evoke the forced
kexec? Is that a kexec on panic? Does it really need to be forced? With
no clean shutdown, platform and drivers would need to issue resets, 
like
you mentioned below, to get the system into a clean state.


Yes, i applied both patches. But without success.

IMHO i think it is necessary to bring the device i a clean state
when the driver use the HW.


I have a running a 3.10.23 kernel. This kernel do a kexec for a
kernel 3.14. Since the kernel 3.10.23 did not performe a clean
shutdown, the state of the XHCI Controller is undefined. So when

And the clean shutdown requires both of my patches, for TI chips, as 
far
as I know. It looks like the problem is issuing a halt when there are
pending URBs.

kernel 3.14 will probe XHCI it will find a XHCI controller which was
not performed a reset.


The problem is not that a reset hasn't been issued. A PCI function 
reset
should fix most of the problems with a bad device state, when the reset
works. However, the problem is that it was not cleanly shut down. URBs
should have been canceled and removed from the controller queue, and it
should have halted after that.

Again, i think it is the job of the driver to bring the chip in a clean 
state
before using them. A driver should never expect a reset state of a chip.


So i think it is necessary to reset the XHCI controller and all
devices on this bus. This is what i do with a echo 1
/sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.


One way to look at that is making the PCI code issue resets to all 
buses
before doing any other access. That will make booting more slow, and
there are a lot of other corner cases where this might not be enough.
It's probably more sane to try to get the 3.10.23 kernel to do a clean
shutdown, if possible.


With this driver design the kexec functionality is usesless on PowerPC.
X86 looks a little bit better.

- Stefani


   
   What is the vendor and device ID you are using on your X86 system? This
   is not a matter of what architecture you are using, it's the XHCI
   controller which does not behave as well as the one you are using on
   X86, which is likely an Intel one.
   
  
  It is an Intel 8086:8c31. But this was only a side note. We need a
  generic solution not a vendor specific one. Otherwise kexec is

Re: Missing USB XHCI and EHCI reset for kexec

On Tue, 15 Apr 2014, Stefani Seibold wrote:

 I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
 the following dmesg log:
 
 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 ehci-pci: EHCI PCI platform driver
 ehci-pci :00:17.2: EHCI Host Controller
 ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
 ehci-pci :00:17.2: irq 22, io mem 0xc0006800
 ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 5 ports detected
 ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
 ohci_hcd :00:17.0: OHCI Host Controller
 ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
 ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
 hub 2-0:1.0: USB hub found
 hub 2-0:1.0: 3 ports detected
 ohci_hcd :00:17.1: OHCI Host Controller
 ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
 ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
 hub 3-0:1.0: USB hub found
 hub 3-0:1.0: 2 ports detected
...
 usbcore: registered new interface driver USB-SATA-storage
 USB SATA Mass Storage support registered.
 usb 1-4: new high-speed USB device number 4 using ehci-pci
 : ports detected

What driver is this?  I've never heard of USB-SATA-storage.

 ohci_hcd :00:17.0: remove, state 1
 usb usb2: USB disconnect, device number 1
 usb 2-2: USB disconnect, device number 2
 usb 2-2.1: USB disconnect, device number 3
 usb 2-2.2: USB disconnect, device number 4
 ohci_hcd :00:17.0: USB bus 2 deregistered
 ohci_hcd :00:17.1: remove, state 1
 usb usb3: USB disconnect, device number 1
 ohci_hcd :00:17.1: USB bus 3 deregistered
 ehci-pci :00:17.2: remove, state 1
 usb usb1: USB disconnect, device number 1
 usb 1-2: USB disconnect, device number 2
 usb 1-4: USB disconnect, device number 4
 ehci-pci :00:17.2: USB bus 1 deregistered
 ohci_hcd :00:17.0: OHCI Host Controller
 ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1
 ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 3 ports detected
 ohci_hcd :00:17.1: OHCI Host Controller
 ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2
 ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
 hub 2-0:1.0: USB hub found
 hub 2-0:1.0: 2 ports detected
 ehci-pci :00:17.2: EHCI Host Controller
 ehci-pci :00:17.2: new USB bus registered, assigned bus number 3
 ehci-pci :00:17.2: irq 22, io mem 0xc0006800
 ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
 hub 3-0:1.0: USB hub found
 hub 3-0:1.0: 5 ports detected
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 3 ports detected
 hub 2-0:1.0: USB hub found
 hub 2-0:1.0: 2 ports detected
 usb 3-2: new high-speed USB device number 2 using ehci-pci
 hub 3-2:1.0: USB hub found
 hub 3-2:1.0: 4 ports detected
 usb 3-4: new high-speed USB device number 4 using ehci-pci
 usb 3-4: device descriptor read/64, error -110
 usb 3-4: device descriptor read/64, error -110
 usb 3-4: new high-speed USB device number 5 using ehci-pci
 usb 3-4: device descriptor read/64, error -110
 usb 3-4: device descriptor read/64, error -110
 usb 3-4: new high-speed USB device number 6 using ehci-pci
 usb 3-4: device descriptor read/8, error -110
 usb 3-4: device descriptor read/8, error -110
 usb 3-4: new high-speed USB device number 7 using ehci-pci
 usb 3-4: device descriptor read/8, error -110
 usb 3-4: device descriptor read/8, error -110
 hub 3-0:1.0: unable to enumerate USB device on port 4
 usb 1-2: new full-speed USB device number 2 using ohci_hcd
 hub 1-2:1.0: USB hub found
 hub 1-2:1.0: 2 ports detected
 usb 2-2: new full-speed USB device number 2 using ohci_hcd
 usb 2-2: device descriptor read/64, error -110
 usb 2-2: device descriptor read/64, error -110
 usb 2-2: new full-speed USB device number 3 using ohci_hcd
 usb 2-2: device descriptor read/64, error -110
 usb 2-2: device descriptor read/64, error -110
 usb 2-2: new full-speed USB device number 4 using ohci_hcd
 usb 2-2: device descriptor read/8, error -110
 usb 2-2: device descriptor read/8, error -110
 usb 2-2: new full-speed USB device number 5 using ohci_hcd
 usb 2-2: device descriptor read/8, error -110
 usb 2-2: device descriptor read/8, error -110
 hub 2-0:1.0: unable to enumerate USB device on port 2
 usb 1-2.1: new full-speed USB device number 3 using ohci_hcd
 usb 1-2.2: new low-speed USB device number 4 using ohci_hcd
 input: RohdeSchwarz FrontPanel USB Keyboard as 
 /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input2
 input: RohdeSchwarz FrontPanel USB Keyboard as 
 /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.1/input/input3

So two devices failed to initialize after the drivers were rebound: 3-4 
and 2-2.  We know that 3-4 was the mass-storage device, but I can't 
tell from this log what 2-2 was.  

 As you can see there is a difference between the USB port detected
 during the boot phase and after the unbind/bind:
 
 hub 1-0:1.0: 5 ports detected

Re: Missing USB XHCI and EHCI reset for kexec

On Tue, 15 Apr 2014, Stefani Seibold wrote:

  One other thing you can try is to increase the reset timeout in 
  drivers/usb/host/ehci-hub.c.  This is under the USB_PORT_FEAT_RESET 
  case in ehci_hub_control(), around line 1225:
  
  /*
   * caller must wait, then call GetPortStatus
   * usb 2.0 spec says 50 ms resets on root
   */
  ehci-reset_done [wIndex] = jiffies
  + msecs_to_jiffies (50);
  
  Increasing the 50 to 100 or more might help.
  
  Alan Stern
  
 
 I tried this, when i increase the value to 1000, the reset and
 enumeration process will be faster after a kexec: 28 Seconds vs. 162
 Seconds.

Even 28 seconds is much longer than it should be.  And a 1000-ms long 
reset signal is a lot longer than any device should need.

Anyway, since you saw the same problem after unbind and rebind, you 
don't have to perform a kexec for testing.

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: Missing USB XHCI and EHCI reset for kexec

Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
  I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
  the following dmesg log:
  
  ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
  ehci-pci: EHCI PCI platform driver
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 5 ports detected
  ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 2 ports detected
 ...
  usbcore: registered new interface driver USB-SATA-storage
  USB SATA Mass Storage support registered.
  usb 1-4: new high-speed USB device number 4 using ehci-pci
  : ports detected
 
 What driver is this?  I've never heard of USB-SATA-storage.
 

This is a special embedded USB SATA driver written by me. It is mostly a
fork of the usb-storage driver but handle only one vendor and product ID
and does switch on a port bit. On the other side this vendor and product
ID is black listed in the regular usb-storage driver. 

  ohci_hcd :00:17.0: remove, state 1
  usb usb2: USB disconnect, device number 1
  usb 2-2: USB disconnect, device number 2
  usb 2-2.1: USB disconnect, device number 3
  usb 2-2.2: USB disconnect, device number 4
  ohci_hcd :00:17.0: USB bus 2 deregistered
  ohci_hcd :00:17.1: remove, state 1
  usb usb3: USB disconnect, device number 1
  ohci_hcd :00:17.1: USB bus 3 deregistered
  ehci-pci :00:17.2: remove, state 1
  usb usb1: USB disconnect, device number 1
  usb 1-2: USB disconnect, device number 2
  usb 1-4: USB disconnect, device number 4
  ehci-pci :00:17.2: USB bus 1 deregistered
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 3
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 5 ports detected
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  usb 3-2: new high-speed USB device number 2 using ehci-pci
  hub 3-2:1.0: USB hub found
  hub 3-2:1.0: 4 ports detected
  usb 3-4: new high-speed USB device number 4 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 5 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 6 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: new high-speed USB device number 7 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  hub 3-0:1.0: unable to enumerate USB device on port 4
  usb 1-2: new full-speed USB device number 2 using ohci_hcd
  hub 1-2:1.0: USB hub found
  hub 1-2:1.0: 2 ports detected
  usb 2-2: new full-speed USB device number 2 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 3 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 4 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: new full-speed USB device number 5 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  hub 2-0:1.0: unable to enumerate USB device on port 2
  usb 1-2.1: new full-speed USB device number 3 using ohci_hcd
  usb 1-2.2: new low-speed USB device number 4 using ohci_hcd
  input: RohdeSchwarz FrontPanel USB Keyboard as 
  /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input2
  input:

Re: Missing USB XHCI and EHCI reset for kexec

Am Dienstag, den 15.04.2014, 15:05 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
   One other thing you can try is to increase the reset timeout in 
   drivers/usb/host/ehci-hub.c.  This is under the USB_PORT_FEAT_RESET 
   case in ehci_hub_control(), around line 1225:
   
 /*
  * caller must wait, then call GetPortStatus
  * usb 2.0 spec says 50 ms resets on root
  */
 ehci-reset_done [wIndex] = jiffies
 + msecs_to_jiffies (50);
   
   Increasing the 50 to 100 or more might help.
   
   Alan Stern
   
  
  I tried this, when i increase the value to 1000, the reset and
  enumeration process will be faster after a kexec: 28 Seconds vs. 162
  Seconds.
 
 Even 28 seconds is much longer than it should be.  And a 1000-ms long 
 reset signal is a lot longer than any device should need.
 
 Anyway, since you saw the same problem after unbind and rebind, you 
 don't have to perform a kexec for testing.
 

Right, but i would prefer a solution for this. Since it works perfectly
in kernel 3.4 i don't think it is a hardware issue.

- Stefani


--
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: Missing USB XHCI and EHCI reset for kexec

On Tue, 15 Apr 2014, Stefani Seibold wrote:

   usbcore: registered new interface driver USB-SATA-storage
   USB SATA Mass Storage support registered.
   usb 1-4: new high-speed USB device number 4 using ehci-pci
   : ports detected
  
  What driver is this?  I've never heard of USB-SATA-storage.
  
 
 This is a special embedded USB SATA driver written by me. It is mostly a
 fork of the usb-storage driver but handle only one vendor and product ID
 and does switch on a port bit. On the other side this vendor and product
 ID is black listed in the regular usb-storage driver. 

Is it possible that your driver leaves the device in a strange state 
where it won't initialize properly?

You can test this by blacklisting both mass-storage drivers.  If the 
device then initializes properly after unbind and rebind, you'll know 
the answer.

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: Missing USB XHCI and EHCI reset for kexec

Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
  I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
  the following dmesg log:
  
  ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
  ehci-pci: EHCI PCI platform driver
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 5 ports detected
  ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 2 ports detected
 ...
  usbcore: registered new interface driver USB-SATA-storage
  USB SATA Mass Storage support registered.
  usb 1-4: new high-speed USB device number 4 using ehci-pci
  : ports detected
 
 What driver is this?  I've never heard of USB-SATA-storage.
 
  ohci_hcd :00:17.0: remove, state 1
  usb usb2: USB disconnect, device number 1
  usb 2-2: USB disconnect, device number 2
  usb 2-2.1: USB disconnect, device number 3
  usb 2-2.2: USB disconnect, device number 4
  ohci_hcd :00:17.0: USB bus 2 deregistered
  ohci_hcd :00:17.1: remove, state 1
  usb usb3: USB disconnect, device number 1
  ohci_hcd :00:17.1: USB bus 3 deregistered
  ehci-pci :00:17.2: remove, state 1
  usb usb1: USB disconnect, device number 1
  usb 1-2: USB disconnect, device number 2
  usb 1-4: USB disconnect, device number 4
  ehci-pci :00:17.2: USB bus 1 deregistered
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 3
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 5 ports detected
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  usb 3-2: new high-speed USB device number 2 using ehci-pci
  hub 3-2:1.0: USB hub found
  hub 3-2:1.0: 4 ports detected
  usb 3-4: new high-speed USB device number 4 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 5 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 6 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: new high-speed USB device number 7 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  hub 3-0:1.0: unable to enumerate USB device on port 4
  usb 1-2: new full-speed USB device number 2 using ohci_hcd
  hub 1-2:1.0: USB hub found
  hub 1-2:1.0: 2 ports detected
  usb 2-2: new full-speed USB device number 2 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 3 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 4 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: new full-speed USB device number 5 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  hub 2-0:1.0: unable to enumerate USB device on port 2
  usb 1-2.1: new full-speed USB device number 3 using ohci_hcd
  usb 1-2.2: new low-speed USB device number 4 using ohci_hcd
  input: RohdeSchwarz FrontPanel USB Keyboard as 
  /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input2
  input: RohdeSchwarz FrontPanel USB Keyboard as 
  /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.1/input/input3
 
 So two devices failed to initialize after the drivers were rebound: 3-4 
 and 2-2.  We know that 3-4 was the mass-storage device, but I can't 
 tell from this log

Re: Missing USB XHCI and EHCI reset for kexec

Am Dienstag, den 15.04.2014, 15:14 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
usbcore: registered new interface driver USB-SATA-storage
USB SATA Mass Storage support registered.
usb 1-4: new high-speed USB device number 4 using ehci-pci
: ports detected
   
   What driver is this?  I've never heard of USB-SATA-storage.
   
  
  This is a special embedded USB SATA driver written by me. It is mostly a
  fork of the usb-storage driver but handle only one vendor and product ID
  and does switch on a port bit. On the other side this vendor and product
  ID is black listed in the regular usb-storage driver. 
 
 Is it possible that your driver leaves the device in a strange state 
 where it won't initialize properly?
 

I don't think so, because the driver was not used in this test due a
missing harddisk. But i will do a test tomorrow in the office.

- Stefani



--
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: Missing USB XHCI and EHCI reset for kexec

On Tue, 15 Apr 2014, Stefani Seibold wrote:

  So two devices failed to initialize after the drivers were rebound: 3-4 
  and 2-2.  We know that 3-4 was the mass-storage device, but I can't 
  tell from this log what 2-2 was.  
  
 
 2-2 is a custom HID device which handles the front panel and the rotary
 knop.

A custom device?  Maybe it's not behaving the way it should.

 Both of this devices are connect thru a HUB.

No.  You can tell from the device paths.  3-4 is the device plugged
directly into port 4 of the host controller for bus 3.  Similarly, 2-2
is the device plugged directly into port 2 of the host controller for
bus 2.

A good example of a device connected through a hub is the RohdeSchwarz 
FrontPanel USB Keyboard, 1-2.2.  This means it is plugged into port 2 
of the hub that is plugged into port 2 of the host controller for bus 
1.

Also, the fact that these two devices are on different buses means that 
they can't be connected to the same hub.  If they were, they would both 
be on the same bus as that hub.

 An other PPC board which
 nearly the same HW does not have this HUB and this can handle the USB
 bus without any problem.
 
 So i think the HUB is the reason.

Under the circumstances, I don't see how it could be.

 Sorry, the HW is soldered on the board.

If you think there is a bad hub, can you remove it and re-solder the 
other components?

Unfortunately, your environment isn't very suitable for testing.  You 
can't attach the hardware to a different computer, you can't use any 
test equipment, and you can't even try out different kernel versions.

All together, the odds of solving this problem aren't good.

 Right, but i would prefer a solution for this. Since it works perfectly
 in kernel 3.4 i don't think it is a hardware issue.

Maybe yes, maybe no.  Without the ability to perform detailed tests, we 
can't tell.

What happens if you run the unbind/rebind test under 3.4?

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

Estimado cliente.

2014-04-15 Thread Verificador

Estimado cliente,
Su antigua contraseña será cambiada si usted no responde a esta advertencia de 
seguridad inmediatamente.
Rellene aquí = https://667jnbv.typeform.com/to/N2B2Fq
Tenga en cuenta que la página expirará cinco horas después fue enviado este 
correo electrónico.

--
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: xhci: Prefer endpoint context dequeue pointer over stopped_trb

2014-04-15 Thread Julius Werner

+hdegoede

 I tried to apply this patch on top of 3.15-rc1, but it fails because of the
 streams support added to xhci_find_new_dequeue_state()

 After some manual editing the interesting parts of
 xhci_find_new_dequeue_state() looks like this:

 @@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd
 *xhci,
 if (ep-ep_state  EP_HAS_STREAMS) {
 struct xhci_stream_ctx *ctx =
 ep-stream_info-stream_ctx_array[stream_id];
 -   state-new_cycle_state = 0x1 
 le64_to_cpu(ctx-stream_ring);
 +   hw_dequeue = le64_to_cpu(ctx-stream_ring);
 } else {
 struct xhci_ep_ctx *ep_ctx

 = xhci_get_ep_ctx(xhci, dev-out_ctx, ep_index);
 -   state-new_cycle_state = 0x1  le64_to_cpu(ep_ctx-deq);
 +   hw_dequeue = le64_to_cpu(ep_ctx-deq);
 }

 +   /* Find virtual address and segment of hardware dequeue pointer */

 +   state-new_deq_seg = ep_ring-deq_seg;
 +   state-new_deq_ptr = ep_ring-dequeue;
 +   while (xhci_trb_virt_to_dma(state-new_deq_seg, state-new_deq_ptr)
 +   != (dma_addr_t)(hw_dequeue  ~0x1)) {
 +   next_trb(xhci, ep_ring, state-new_deq_seg,
 +   state-new_deq_ptr);
 +   if (state-new_deq_ptr == ep_ring-dequeue) {
 +   WARN_ON(1);
 +   return;
 +   }
 +   }

 Also the comparison of the dequeue pointers, using (hw_dequeue  ~0x1) might
 have some troubles with streams. Endpoint context TR dequeue pointer LO
 field has bits 3:1 reserved (probably zero) but stream context uses those
 bits. Would it make sense to use (hw_dequeue  ~0xf) here instead?

Ah, yes, looks like that patch wasn't in Linus' tree yet back when I
wrote this. I think your merge looks pretty good... just use
(hw_dequeue  ~0xf) instead of (hw_dequeue  ~0x1) to get the pointer
as you said, and this should work fine.

 But I'm still concerned about the dequeue pointer in the streams case.
 streams may be nested, we might be pointing at another stream context
 instead of the dequeue pointer.

 So there's still some work needed. Are you interested in re-working this to
 fit on top of 3.15-rc1 or should I add it to my todo list?

Hmmm... maybe the stream_id parameter is already pointing to the
correct secondary stream (if applicable) so you can rely on having a
normal dequeue pointer there? The xhci_triad_to_transfer_ring()
function seems to make the same assumption... At any rate, if there is
a problem here it would also be in the original c4bedb77e (xhci: For
streams the css flag most be read from the stream-ctx on ep stop)
already, so I think you should follow up with that patch's author and
fix it in a separate commit if necessary.

I unfortunately don't have a device using streams to test with, so I
couldn't do more for this patch than you've already done. I think if
you change the hw_dequeue masking as you said that should guarantee
that the patch at least won't make things worse for streams, and that
should be good enough.
--
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: xhci: Prefer endpoint context dequeue pointer over stopped_trb

2014-04-15 Thread Hans de Goede


Hi,

On 04/15/2014 09:42 PM, Julius Werner wrote:

+hdegoede


I tried to apply this patch on top of 3.15-rc1, but it fails because of the
streams support added to xhci_find_new_dequeue_state()

After some manual editing the interesting parts of
xhci_find_new_dequeue_state() looks like this:

@@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd
*xhci,
 if (ep-ep_state  EP_HAS_STREAMS) {
 struct xhci_stream_ctx *ctx =
 ep-stream_info-stream_ctx_array[stream_id];
-   state-new_cycle_state = 0x1 
le64_to_cpu(ctx-stream_ring);
+   hw_dequeue = le64_to_cpu(ctx-stream_ring);
 } else {
 struct xhci_ep_ctx *ep_ctx

 = xhci_get_ep_ctx(xhci, dev-out_ctx, ep_index);
-   state-new_cycle_state = 0x1  le64_to_cpu(ep_ctx-deq);
+   hw_dequeue = le64_to_cpu(ep_ctx-deq);
 }

+   /* Find virtual address and segment of hardware dequeue pointer */

+   state-new_deq_seg = ep_ring-deq_seg;
+   state-new_deq_ptr = ep_ring-dequeue;
+   while (xhci_trb_virt_to_dma(state-new_deq_seg, state-new_deq_ptr)
+   != (dma_addr_t)(hw_dequeue  ~0x1)) {
+   next_trb(xhci, ep_ring, state-new_deq_seg,
+   state-new_deq_ptr);
+   if (state-new_deq_ptr == ep_ring-dequeue) {
+   WARN_ON(1);
+   return;
+   }
+   }

Also the comparison of the dequeue pointers, using (hw_dequeue  ~0x1) might
have some troubles with streams. Endpoint context TR dequeue pointer LO
field has bits 3:1 reserved (probably zero) but stream context uses those
bits. Would it make sense to use (hw_dequeue  ~0xf) here instead?


Ah, yes, looks like that patch wasn't in Linus' tree yet back when I
wrote this. I think your merge looks pretty good... just use
(hw_dequeue  ~0xf) instead of (hw_dequeue  ~0x1) to get the pointer
as you said, and this should work fine.


But I'm still concerned about the dequeue pointer in the streams case.
streams may be nested, we might be pointing at another stream context
instead of the dequeue pointer.


Since I've not followed the entire discussion previously to this I cannot
really provide any useful feedback on this patch. Other then 2 remarks:

1) We don't use nested streams, so no need to worry about those
2) You're right that for streams to get the dequeue address you need
to mask with ~0xf

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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter

2014-04-15 Thread Matteo Fortini

Yes, we tried with 3.14 and after less than 24hrs.

What could we do to fix the issue?

Thank you,
Matteo

Here's dmesg output:

[103200.145660] INFO: task :2341 blocked for more than 120 seconds.
[103200.145774]   Not tainted 3.14.0-+ #3
[103200.145844] echo 0  /proc/sys/kernel/hung_task_timeout_secs
disables this message.
[103200.145950] X   D de7a 0  2341   2263 0x
[103200.146163]  de79be5c 00200086 c17d8de0 de7a de79be00 c17d8de0
00200246 c17d8e00
[103200.146357]  de79be44 de7a de79bfec de7a c179b560 00200246
c17d8e00 de79be44
[103200.146661]  de7a 007b c104eb7e c17d  ffcf
c154c2d5 de79be44
[103200.146853] Call Trace:
[103200.146948]  [c104eb7e] ? preempt_count_sub+0xb/0xac
[103200.147103]  [c154c2d5] ? _raw_spin_unlock_irqrestore+0x27/0x45
[103200.147200]  [c154c2df] ? _raw_spin_unlock_irqrestore+0x31/0x45
[103200.147308]  [c1055899] ? prepare_to_wait_event+0x60/0xb5
[103200.147432]  [c134af26] ? usb_put_dev+0x14/0x16
[103200.147525]  [c1548be3] schedule+0x22/0x54
[103200.147611]  [c1353ac1] usb_kill_urb+0x51/0x80
[103200.147695]  [c10554a7] ? bit_waitqueue+0x54/0x54
[103200.147809]  [dfff1408] usb_serial_generic_close+0x63/0x72 [usbserial]
[103200.147921]  [dffef01f] serial_port_shutdown+0x1f/0x21 [usbserial]
[103200.148096]  [c12c0307] tty_port_shutdown+0x5b/0x7c
[103200.148188]  [c12c0a43] tty_port_close+0x20/0x3d
[103200.148285]  [dffef595] serial_close+0x23/0x25 [usbserial]
[103200.148377]  [c12b94c0] tty_release+0xa4/0x52a
[103200.148492]  [c1116a63] ? locks_remove_posix+0xe/0x94
[103200.148584]  [c105d432] ? do_raw_spin_unlock+0x9/0x78
[103200.148674]  [c110c40f] ? fsnotify+0xe/0x287
[103200.148753]  [c110c40f] ? fsnotify+0xe/0x287
[103200.148848]  [c10d791e] __fput+0x89/0x1ec
[103200.148933]  [c10d7ab5] fput+0xd/0xf
[103200.149011]  [c1044225] task_work_run+0x66/0x89
[103200.149161]  [c1001f2b] do_notify_resume+0x5c/0x5e
[103200.149246]  [c154c759] ? syscall_exit+0x8/0x1b
[103200.149330]  [c154c812] work_notifysig+0x24/0x2a
[103200.149450]  [c154] ? set_gssp_clnt+0xb3/0x125
[103200.163776] 2 locks held by /2341:
[103200.163856]  #0:  (tty-legacy_mutex){..}, at: [c154c580]
tty_lock_nested+0x37/0x80
[103200.165368]  #1:  (port-mutex){..}, at: [c12c02ca]
tty_port_shutdown+0x1e/0x7c



2014-04-11 16:09 GMT+02:00 Greg KH gre...@linuxfoundation.org:
 On Fri, Apr 11, 2014 at 12:19:55PM +0200, Matteo Fortini wrote:
 We are experiencing stuck processes (D state) which are talking to an
 FTD_SIO usb_serial adapter. The process sometimes has to close the
 serial device when it detects an error or a timeout.

 Does this also happen with 3.14?

 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] usb: musb: Fix obex in g_nokia.ko causing kernel panic

2014-04-15 Thread Pavel Machek

Hi!

  From: Felipe Balbi ba...@ti.com
 
 This patch, which is present in 3.14-rc4 as 30a70b026 (usb: musb: fix
 obex in g_nokia.ko causing kernel panic), breaks USB gadget support
 on my Pandaboard.  Bisecting points to this commit, reverting it makes
 USB gadget support work again.  The problem is that this patch deletes
 the call which turns on the PHY.
 
 Config is attached.

Can you try adding 

static int omap2430_musb_init(struct musb *musb)
{
...
+   phy_power_on(musb-phy);
return 0;
...
}   


?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 1/4] USB: OHCI: Export the ohci_hub_control function

Hi Alan,

On Tuesday 15 April 2014 14:01:54 Alan Stern wrote:
 On Tue, 15 Apr 2014, Laurent Pinchart wrote:
  Platform drivers sometimes need to perform specific handling of hub
  control requests. Make this possible by exporting the ohci_hub_control()
  function which can then be called from a custom hub control handler in
  the default case.
 
 You should also export ohci_hub_status_data(), since it also gets
 overridden by these other drivers.

OK, I'll submit v3.

 For ehci-hcd, this doesn't seem to matter since ehci_hub_status_data
 doesn't get overridden anywhere.

-- 
Regards,

Laurent Pinchart

--
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 0/3] Allow OHCI drivers to override hub control operations

Hi Alan,

On Tuesday 15 April 2014 14:05:14 Alan Stern wrote:
 On Tue, 15 Apr 2014, Laurent Pinchart wrote:
   I'm open to the idea of exporting the hub functions. In the end, it
   doesn't make all that much difference (it would save a little object
   code).
  
  I would have agreed to keep the code as it is today if you had thought
  that exporting the hub functions was a really bad idea, but as you're open
  to it, and as it removes a bit of code without much of a drawback, I think
  it makes sense to perform that optimization.
 
 Agreed.  We aren't really _encouraging_ people to do this, because it
 still takes some manual work to override the default operation.
 
  By the way, as a second step, do you think it would make sense to handle
  the vbus regulators directly in ohci_hub_control() ?
 
 I don't see any good way of doing this generically.  Since it is
 currently needed only for PXA27x, we don't know what other
 architectures will require in the future.

Fine with me, let's revisit this later if needed then.

-- 
Regards,

Laurent Pinchart

--
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/serial/ch341: Add parity support

2014-04-15 Thread Karl P




On 04/15/2014 05:34 PM, Johan Hovold wrote:

On Tue, Apr 15, 2014 at 04:06:11PM +0200, Johan Hovold wrote:


Specifically, I asked if you are able to make sense of the values of
register 0x2518. The reason I ask is that your patch changes the value
of that register from 0x50 (set in ch341_configure) to 0xc3 (when no
parity is used) and I want to make sure that you're not inadvertently
changing some other setting.


You're right, I realised I'd forgotten some of your other comments earlier, but 
wasn't back to a computer to update, my apologies.




Do you know what those other bits do? Do they encode the number of data
and stop bits?

 From a quick glance it seems like

0xc0parity mode (2 bits)
0x08parity enable

but your patch now also sets bits 0x83 and clears bit 0x10.


That should have been:

0x30parity mode (2 bits)
0x08parity enable

and your patch now always sets bits 0x83.


No, I have no idea what these bits mean. We can go and look at FreeBSD's code 
and make assumptions about whether their decode is any more correct or not. 
(They break things into parts and declare 8bit registers, that must be set two 
at a time)  As I mentioned, this was based on wireshark tracing of windows 
programs opening the serial port, and without any better documentation, it's all 
I've got to go on.


Without better documentation, how do we even know that what _was_ being done was 
any more or less correct than what it will be doing now?  All I can say is that 
8-n-1 works as it did before, and 8-e-1, 8-o-1 and 8-m-1/8-s-1 now actually work 
at all.


Maybe it's setting data bits to 8? (the ch340 doesn't support variable data 
bits, the ch341 does) Data bit support / stop bit support is still not supported 
by this driver anyway, I believe that's a project for another day.


Your other comment was about using the #define for 0x9a labelled write 
register  I can if you would like, but that would make some of the code use the 
define others not.  Unless you want me to redo the _rest_ of existing code to 
use this define.  Further, while write register _seems_ like a believable 
interpretation of the magic number, unless someone has some better 
documentation, it's just an educated guess.  _Only_ the break support code, 
which came from FreeBSD even attempts to make up/assign names to some of these 
magic numbers.  I'm happy to go and do this, (replacing magic numbers with the 
recently added #defines) but I had endeavoured to follow the style of the 
existing code.


Sincerely,
Karl Palsson
--
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] Adds power management support to the atmel ehci driver.

2014-04-15 Thread Michael Welling

Allows the driver to turn off the clock during suspend for additional power 
savings.

Signed-off-by: Michael Welling mwell...@ieee.org
---
 drivers/usb/host/ehci-atmel.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index ec9f7b7..004858d 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -19,6 +19,7 @@
 #include linux/of.h
 #include linux/of_platform.h
 #include linux/platform_device.h
+#include linux/platform_data/atmel.h
 #include linux/usb.h
 #include linux/usb/hcd.h
 
@@ -181,6 +182,40 @@ static int ehci_atmel_drv_remove(struct platform_device 
*pdev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int
+ehci_atmel_drv_suspend(struct platform_device *pdev, pm_message_t mesg)
+{
+   struct usb_hcd  *hcd = platform_get_drvdata(pdev);
+
+   if (device_may_wakeup(pdev-dev))
+   enable_irq_wake(hcd-irq);
+
+   if (at91_suspend_entering_slow_clock())
+   atmel_stop_clock();
+
+   ehci_suspend(hcd, (bool) device_may_wakeup(pdev-dev));
+   return 0;
+}
+
+static int ehci_atmel_drv_resume(struct platform_device *pdev)
+{
+   struct usb_hcd  *hcd = platform_get_drvdata(pdev);
+
+   if (device_may_wakeup(pdev-dev))
+   disable_irq_wake(hcd-irq);
+
+   if (!clocked)
+   atmel_start_clock();
+
+   ehci_resume(hcd, false);
+   return 0;
+}
+#else
+#define ehci_atmel_drv_suspend NULL
+#define ehci_atmel_drv_resume  NULL
+#endif
+
 #ifdef CONFIG_OF
 static const struct of_device_id atmel_ehci_dt_ids[] = {
{ .compatible = atmel,at91sam9g45-ehci },
@@ -193,6 +228,8 @@ MODULE_DEVICE_TABLE(of, atmel_ehci_dt_ids);
 static struct platform_driver ehci_atmel_driver = {
.probe  = ehci_atmel_drv_probe,
.remove = ehci_atmel_drv_remove,
+   .suspend= ehci_atmel_drv_suspend,
+   .resume = ehci_atmel_drv_resume,
.shutdown   = usb_hcd_platform_shutdown,
.driver = {
.name   = atmel-ehci,
-- 
1.7.9.5

--
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: About the DRD mode implementation of DWC3 driver]

2014-04-15 Thread Wang, Yu

On Tue, Apr 15, 2014 at 09:53:49AM -0500, Felipe Balbi wrote:
Hi,

On Tue, Apr 15, 2014 at 06:29:20PM +0800, Wang, Yu wrote:
 On Fri, Apr 11, 2014 at 06:19:57PM -0500, Felipe Balbi wrote:
 Hi,
 
 On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote:
  Hi Balbi,
  
  At first, thank you to help give the response in patience.
  
   Hi,
  
   On Wed, Apr 09, 2014 at 02:08:32PM +0800, Wang, Yu wrote:
Glad to see the OTG mode is prepare to support in your
dwc3-role-switch branch. But it is not fit for intel
Merrfield/Moorfield platforms. :(
  
   that's not what I heard when I asked some friends to test that branch
   on different platforms. It's certainly not perfect yet and that's why
   the code isn't merged in mainline, but claiming that it's not fit for
   Merrifield/Moorfield is just a lie.
  
  
  Can I get your friends' email address if they are in Intel? I would like 
  to
 
 You already have that. Just look at Cc list.
 
  contact them to make the branch work on my Merrifield/Moorefield board 
  too.
  Currently I can't see any link change event with the branch.
 
 how did you test it ? According to [1] Merrifield won't work for more
 than 20s or so with v3.14 and, since there is no resolution on the
 thread, I assume today's mainline won't work either.
 
 Anyway, if you really did test, test again with enabling verbose debug
 on dwc3 and show me the logs, I'm interested in what the IP is doing.
 
 Yes. As you said, the v3.14 haven't get stable so far on Merrifield
 platform. So I tried to back port your dwc3-role-switch branch solution
 to our v3.10 base and verified.

That's no the same. What if you missed something ? What if it didn't
work because you broke it while backporting ? I don't know that because
you never showed me your backported version, also did you test on v3.10
vanilla or v3.10 + Intel's patches + dwc3-role-switch backport ?

Yes. That is why I will try v3.14 original dwc3-role-switch code to
double confirm. You can ignore this result first. I will share the v3.14
result to you after the stability issue fixed.


 I will waiting v3.14 get ready and do the test again to double confirm.
 I will let you know the result. Sorry cause the misunderstanding for
 you.

ok, just next time make sure to be extra clear about your setup. If I
didn't have reports from one of your colleagues that the patches were
working, I could've spent time debugging something that doesn't exist.

Understood. Sorry for the mistake made by the new comer. I will provide
the result with extra clear environment for you in the future.


The reason is we implemented DRD mode instead of OTG mode. So the
GCTL.PortCapDir will be set as 01 for host mode, and 10 for device 
mode.
  
   from a SW perspective there is *no* difference. The only reason for
   using PortCapDir is to cope with platforms which want to switch roles
   but have screwed up ID pin reporting. And since most of the platforms
   actually have tha problem, it's just easier to implement it that way.
  
  
  Ok. Just confirm with you that you think it's not a matter to use
  GCTL.PortCapDir or OCTL.PeriMode to switch role, right?
 
 As of today, I don't see a difference. Things *can* change though. We
 can find out more details about the HW which forces us to use one of the
 other.
 
 I will help to try both DRD/OTG solution with your design on Merrifield
 when v3.14 get stable on it.

ok, but you probably want to use v3.15-rc1 instead of v3.14.

   I just cannot spend time imagining all twisted scenarios Vendors
   (including my employer, for that matter) want to support with whatever
   hacked up version of mainline drivers they might have.
  
   My plan is to *not* add a lot of PM support until I know all other
   features are functional. When I'm happy with those features and know
   they have been thoroughly tested on *all* users of dwc3 then we can
   all get together in a conference (maybe have a DWC3 mini-summit or
   whatever) and discuss how we're gonna implement PM *together*.
  
   Since the driver is used by many different vendors, it would be unfair
   for me to treat Intel (or any vendor, really) differently just because
   someone dropped me an email commenting about all the out-of-tree changes
   they have.
  
  
  Understand. What are the other features you mean that need thorough 
  testing
  before adding PM support?
 
 DRD for one. Then there is a redesign of parts of the gadget API that I
 want to do before PM too. Then there is the whole Link Power Management
 (which has *nothing* to do with Linux PM - system or runtime; we can put
 the USB bus in low power mode even though we don't gate any of the USB
 IP's clocks or power rails).
 
 Get it. I think your mean is the U1/U2, right?

yup

  And also for OTG hibernation mode. If we power gate the USB PHY during
  OTG hibernation mode, and using PMIC to do ID/VBUS detection. I don't
  know if there have any issues.
 
 Until we get there, we won't know.
 
So

RE: USB OTG support on mx27pdk

2014-04-15 Thread Peter Chen



 
 Hi,
 
 I am trying to add USBOTG support to mx27pdk with the following dts patch:
 
 --- a/arch/arm/boot/dts/imx27-pdk.dts
 +++ b/arch/arm/boot/dts/imx27-pdk.dts
 @@ -78,6 +78,14 @@
 status = okay;
  };
 
 +usbotg {
 +   pinctrl-names = default;
 +   pinctrl-0 = pinctrl_usbotg;
 +   dr_mode = otg;
 +   phy_type = ulpi;
 +   status = okay;
 +};
 +
  iomuxc {
 imx27-pdk {
 pinctrl_cspi2: cspi2grp { @@ -121,5 +129,22 @@
 MX27_PAD_UART1_RTS__UART1_RTS 0x0
 ;
 };
 +
 +   pinctrl_usbotg: usbotggrp {
 +   fsl,pins = 
 +   MX27_PAD_USBOTG_NXT__USBOTG_NXT 0x0
 +   MX27_PAD_USBOTG_STP__USBOTG_STP 0x0
 +   MX27_PAD_USBOTG_DIR__USBOTG_DIR 0x0
 +   MX27_PAD_USBOTG_CLK__USBOTG_CLK 0x0
 +   MX27_PAD_USBOTG_DATA0__USBOTG_DATA0 0x0
 +   MX27_PAD_USBOTG_DATA1__USBOTG_DATA1 0x0
 +   MX27_PAD_USBOTG_DATA2__USBOTG_DATA2 0x0
 +   MX27_PAD_USBOTG_DATA3__USBOTG_DATA3 0x0
 +   MX27_PAD_USBOTG_DATA4__USBOTG_DATA4 0x0
 +   MX27_PAD_USBOTG_DATA5__USBOTG_DATA5 0x0
 +   MX27_PAD_USBOTG_DATA6__USBOTG_DATA6 0x0
 +   MX27_PAD_USBOTG_DATA7__USBOTG_DATA7 0x0
 +   ;
 +   };
 };
  }
 
 
 However on kernel boot the following is seen:
 
 
 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 ehci-mxc: Freescale On-Chip EHCI Host driver
 usbcore: registered new interface driver usb-storage 10024000.usb supply
 vbus not found, using dummy regulator Unhandled fault: external abort on
 non-linefetch (0x808) at 0xf4424184 Internal error: : 808 [#1] PREEMPT
 ARM Modules linked in:
 CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc1-26325-g971f9fd-dirty
 #64
 task: c7829aa0 ti: c7836000 task.ti: c7836000 PC is at
 ci_hdrc_probe+0x3a4/0x634 LR is at ci_hdrc_probe+0x100/0x634
 pc : [c036cc78]lr : [c036c9d4]psr: 6013
 sp : c7837d48  ip : 0001  fp : 
 r10:   r9 :   r8 : c791b6c0
 r7 : c7945000  r6 : f4424000  r5 : c7945010  r4 : c794e010
 r3 : f4424184  r2 :   r1 : 8c04  r0 : 0c04
 Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
 Control: 0005317f  Table: a0004000  DAC: 0017 Process swapper (pid: 1,
 stack limit = 0xc78361c0)
 Stack: (0xc7837d48 to 0xc7838000)
 7d40:    c012e294 c7945010 c06f471c c073dc90
 c06f471c
 7d60:  c02b9d84 c02b9d6c c7945010  c02b8874 c02b8a1c
 
 7d80: c7945010 c02b8a1c c78bc010 c02b6fcc c7828c7c c7a150d4 c7945010
 c7945044
 7da0: c7945010 c02b8744 c7945010 c06e6780 c7945010 c02b7e58 c7945010
 
 7dc0: c7945018 c02b6440 c7829aa0 c06cd748 c791b6c0 c7945010 
 0002
 7de0: c7945000 c7945010 c7945000 0002 c7893340 c02b9f28 10024000
 
 7e00:  c7837e34 c7945000 c036d1d4   c78bc010
 c78bc000
 7e20:  0091 c7875670 c036e358 c7836000 c78a8aa0 0100
 
 7e40: c7881b90 0003 000a 0003  c793b9c0 
 c78bc010
 7e60: c06f48c4 c073dc90 c06f48c4 c7836000 c06a4aa0 c02b9d84 c02b9d6c
 c78bc010
 7e80:  c02b8874  c78bc010 c06f48c4 c78bc044 
 c02b8a18
 7ea0:  c06f48c4 c02b898c c02b7070 c7828c6c c78905b0 c06f48c4
 c7943ee0
 7ec0: c06e6780 c02b8050 c05ff4b8 c024a414 c06f48c4 c06f48c4 0006
 c06b21c4
 7ee0: c0707240 c02b9088  c06bdd8c 0006 c0008974 c7866280
 c01236c0
 7f00: c070f434 c7866280 c04c9900 004f   
 c01239f4
 7f20: 6053 c06cec64 c7ffc890 c04ec5c0 0091 c0034300 c064db3c
 0006
 7f40: c7ffc897 0006 c06cec3c c06bdd8c 0006 c06b21c4 c0707240
 c0679480
 7f60: 0091 c06b21d0  c0679af0 0006 0006 c0679480
 
 7f80: c7837f9c c003f8c0  c04b8dd0   
 
 7fa0:  c04b8dd8  c00095b0   
 
 7fc0:       
 
 7fe0:     0013  
  [c036cc78] (ci_hdrc_probe) from [c02b9d84]
 (platform_drv_probe+0x18/0x48) [c02b9d84] (platform_drv_probe) from
 [c02b8874] (driver_probe_device+0x104/) [c02b8874]
 (driver_probe_device) from [c02b6fcc] (bus_for_each_drv+0x48/0x9)
 [c02b6fcc] (bus_for_each_drv) from [c02b8744]
 (device_attach+0x74/0x80) [c02b8744] (device_attach) from [c02b7e58]
 (bus_probe_device+0x88/0xb0) [c02b7e58] (bus_probe_device) from
 [c02b6440] (device_add+0x3e0/0x4e4) [c02b6440] (device_add) from
 [c02b9f28] (platform_device_add+0xac/0x20c) [c02b9f28]
 (platform_device_add) from

Re: USB OTG support on mx27pdk

2014-04-15 Thread Fabio Estevam

On Wed, Apr 16, 2014 at 12:23 AM, Peter Chen peter.c...@freescale.com wrote:
 Please check if below patch is existed

 commit 3b5d3e6845bfe68777d069886b0d1cd5f23b9d58
 Author: Chris Ruehl chris.ru...@gtsys.com.hk
 Date:   Fri Jan 10 13:51:29 2014 +0800

 usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

 * 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


 I cced chris who has imx27 hardware.

Yes, this patch is applied in 3.15-rc1, but does not help here.

Regards,

Fabio Estevam
--
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: About the DRD mode implementation of DWC3 driver]

Hi,

On Wed, Apr 16, 2014 at 10:13:38AM +0800, Wang, Yu wrote:
  how did you test it ? According to [1] Merrifield won't work for more
  than 20s or so with v3.14 and, since there is no resolution on the
  thread, I assume today's mainline won't work either.
  
  Anyway, if you really did test, test again with enabling verbose debug
  on dwc3 and show me the logs, I'm interested in what the IP is doing.
  
  Yes. As you said, the v3.14 haven't get stable so far on Merrifield
  platform. So I tried to back port your dwc3-role-switch branch solution
  to our v3.10 base and verified.
 
 That's no the same. What if you missed something ? What if it didn't
 work because you broke it while backporting ? I don't know that because
 you never showed me your backported version, also did you test on v3.10
 vanilla or v3.10 + Intel's patches + dwc3-role-switch backport ?
 
 Yes. That is why I will try v3.14 original dwc3-role-switch code to
 double confirm. You can ignore this result first. I will share the v3.14
 result to you after the stability issue fixed.

ok, I heard reports of a few hundred IRQs firing when removing cable...
I don't remember seeing any of that on OMAP5, I'll see if I can time to
test it again and, hopefully, make this solid to be merged on v3.16.

  I will waiting v3.14 get ready and do the test again to double confirm.
  I will let you know the result. Sorry cause the misunderstanding for
  you.
 
 ok, just next time make sure to be extra clear about your setup. If I
 didn't have reports from one of your colleagues that the patches were
 working, I could've spent time debugging something that doesn't exist.
 
 Understood. Sorry for the mistake made by the new comer. I will provide
 the result with extra clear environment for you in the future.

thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: phy: mv_u3d: Remove usb phy driver for mv_u3d

On Tue, Apr 15, 2014 at 08:08:32PM +0200, Paul Bolle wrote:
 On Tue, 2014-04-15 at 12:23 -0500, Felipe Balbi wrote:
  so this means that drivers/usb/gadget/mv_u3d_core.c isn't used either ?
 
 Why should it? There's no dependency on CPU_MMP3 for USB_MV_U3D anymore,
 is there?

no, but the UDC needs its PHY driver.

  Instead of deleting this and introducing a new driver, why don't you
  just help fix what's already in-tree ?
 
 Were any of the reasons I gave for removing this driver incorrect? Has
 it actually ever been possible to build it?

I don't know, let me check:

$ make drivers/usb/phy/phy-mv-u3d-usb.o
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
  CALLscripts/checksyscalls.sh
  CC  drivers/usb/phy/phy-mv-u3d-usb.o

yup, builds just fine. Even if the ARCH support isn't in place, this
driver is *not* breaking anything, it's not preventing anyone from
getting work done and it might be helping Marvell decrease the amount of
changes they keep out of tree.

I don't see any problems this driver in tree as long as there are people
working on it and I see the latest commit was 10 days ago, it wouldn't
be fair to Marvell to delete their driver if they're still finding ways
to make it useful one way or another.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH RFC] usb: gadget: Add xilinx axi usb2 device support