Re: [PATCH v2 13/17] phy: qcom-qmp: Add support for QMP V3 USB3 PHY

[Manu Gautam]

On 9/27/2017 11:29 PM, Jack Pham wrote:
> On Wed, Sep 27, 2017 at 02:29:09PM +0530, Manu Gautam wrote:
>> QMP V3 USB3 PHY is a DP USB combo PHY with
>> dual RX/TX lanes to support type-c. There is a
>> separate block DP_COM for configuration related
>> to type-c or DP. Add support for dp_com region
>> and secondary rx/tx lanes initialization.
> Clarify "DP" as DisplayPort here?

Yes, DP implies DisplayPort. I will update commit text.

> Jack

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: Issue with Gadget UVC and dummy_hcd

[David Tulloh]

On 26 September 2017 at 06:28, Alan Stern  wrote:
>
> On Mon, 25 Sep 2017, David Tulloh wrote:
>
> > Hi,
> >
> > I have been trying to get a UVC gadget running through configfs and
> > wired in to dummy_hcd.
> > ...
>
> Does uvc use isochronous transfers?  I assume it would, since it's a
> video protocol.
>
> dummy-hcd does not support isochronous.  I don't know what would happen
> if you tried it, but one way or another it would not work the way you
> want.
>
> Of course, you might be facing a different problem.
>
> Alan Stern


Thanks Alan,

I was facing a different problem but your suggestion put me on the right path.

Sorry it took me so long to update the thread, it has taken me a while
to get a basic understanding of the debugging tools and processes
built into the kernel.

My issue was the rare beast, a consistently repeatable lock contention.
The wonderful LOCK_DEP output summarises it better than I could.

Unfortunately I don't understand the locking requirements nearly well
enough to craft a patch.


Now I have solved this issue (turn off SMP) I'm looking forward to see
if the isochronous problem bites me too.


David


[   88.361471] 
[   88.362014] WARNING: possible recursive locking detected
[   88.362580] 4.14.0-rc2+ #9 Not tainted
[   88.363010] 
[   88.363561] v4l_id/526 is trying to acquire lock:
[   88.364062]  (&(>lock)->rlock){}, at:
[] composite_disconnect+0x43/0x100 [libcomposite]
[   88.365051]
[   88.365051] but task is already holding lock:
[   88.365826]  (&(>lock)->rlock){}, at:
[] usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.366858]
[   88.366858] other info that might help us debug this:
[   88.368301]  Possible unsafe locking scenario:
[   88.368301]
[   88.369304]CPU0
[   88.369701]
[   88.370101]   lock(&(>lock)->rlock);
[   88.370623]   lock(&(>lock)->rlock);
[   88.371145]
[   88.371145]  *** DEADLOCK ***
[   88.371145]
[   88.372211]  May be due to missing lock nesting notation
[   88.372211]
[   88.373191] 2 locks held by v4l_id/526:
[   88.373715]  #0:  (&(>lock)->rlock){}, at:
[] usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.374814]  #1:  (&(_hcd->dum->lock)->rlock){}, at:
[] dummy_pullup+0x7d/0xf0 [dummy_hcd]
[   88.376289]
[   88.376289] stack backtrace:
[   88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
[   88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[   88.379504] Call Trace:
[   88.380019]  dump_stack+0x86/0xc7
[   88.380605]  __lock_acquire+0x841/0x1120
[   88.381252]  lock_acquire+0xd5/0x1c0
[   88.381865]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.382668]  _raw_spin_lock_irqsave+0x40/0x54
[   88.383357]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.384290]  composite_disconnect+0x43/0x100 [libcomposite]
[   88.385490]  set_link_state+0x2d4/0x3c0 [dummy_hcd]
[   88.386436]  dummy_pullup+0xa7/0xf0 [dummy_hcd]
[   88.387195]  usb_gadget_disconnect+0xd8/0x160 [udc_core]
[   88.387990]  usb_gadget_deactivate+0xd3/0x160 [udc_core]
[   88.388793]  usb_function_deactivate+0x64/0x80 [libcomposite]
[   88.389628]  uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]
[   88.390445]  uvc_v4l2_release+0x33/0x90 [usb_f_uvc]
[   88.391224]  v4l2_release+0x38/0x80 [videodev]
[   88.392003]  __fput+0xed/0x230
[   88.392776]  fput+0xe/0x10
[   88.393515]  task_work_run+0x85/0xb0
[   88.394286]  exit_to_usermode_loop+0xce/0xd0
[   88.395066]  do_syscall_64+0x128/0x1a0
[   88.395775]  entry_SYSCALL64_slow_path+0x25/0x25
[   88.396534] RIP: 0033:0x7ff57e33b250
[   88.397217] RSP: 002b:7ffd1590d6e8 EFLAGS: 0246 ORIG_RAX:
0003
[   88.398187] RAX:  RBX: 0003 RCX: 7ff57e33b250
[   88.399113] RDX: 000a RSI: 7ff57e327760 RDI: 0003
[   88.400035] RBP: 7ff57e969698 R08: 7ff57e327760 R09: 7ff57e969700
[   88.401154] R10: 55d4a53e3ecc R11: 0246 R12: 
[   88.402518] R13: 7ffd1590d870 R14:  R15: 
--
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: [PATCHv2 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[kbuild test robot]

Hi Vivek,

[auto build test ERROR on phy/next]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrzej-Pietrasiewicz/drivers-phy-add-calibrate-method/20171005-144320
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
next
config: x86_64-randconfig-b0-10051313 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "phy_calibrate" [drivers/usb/dwc3/dwc3.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

RE: [PATCH] usb: renesas_usbhs: Use of_device_get_match_data() helper

[Yoshihiro Shimoda]

Hi,

> From: Geert Uytterhoeven, Sent: Wednesday, October 4, 2017 9:27 PM
> 
> Use the of_device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Geert Uytterhoeven 

Thank you for the patch!

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

--
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 11/13] xhci: allow TRACE to work with EVENT ring dequeue

[Mathias Nyman]

From: Adam Wallis 

inc_deq() currently bails earlier for EVENT rings than the common return
point of the function, due to the fact that EVENT rings do not have
link TRBs. The unfortunate side effect of this is that the very useful
trace_xhci_inc_deq() function is not called/usable for EVENT ring
debug.

This patch provides a refactor by removing the multiple return exit
points into a single return which additionally allows for all rings to
use the trace function.

Signed-off-by: Adam Wallis 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 15afe1e..4764121 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -171,13 +171,13 @@ static void inc_deq(struct xhci_hcd *xhci, struct 
xhci_ring *ring)
if (ring->type == TYPE_EVENT) {
if (!last_trb_on_seg(ring->deq_seg, ring->dequeue)) {
ring->dequeue++;
-   return;
+   goto out;
}
if (last_trb_on_ring(ring, ring->deq_seg, ring->dequeue))
ring->cycle_state ^= 1;
ring->deq_seg = ring->deq_seg->next;
ring->dequeue = ring->deq_seg->trbs;
-   return;
+   goto out;
}
 
/* All other rings have link trbs */
@@ -190,6 +190,7 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring 
*ring)
ring->dequeue = ring->deq_seg->trbs;
}
 
+out:
trace_xhci_inc_deq(ring);
 
return;
-- 
2.7.4

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

[PATCH 07/13] usb: xhci: Return error when host is dead in xhci_disable_slot()

[Mathias Nyman]

From: Lu Baolu 

xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it returns
success when it sees a dead host. This is not the right way to go.
It should return error and let the invoker know that disable slot
command was failed due to a dead host.

Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 23378f3..cf10d7b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3582,10 +3582,9 @@ int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
state = readl(>op_regs->status);
if (state == 0x || (xhci->xhc_state & XHCI_STATE_DYING) ||
(xhci->xhc_state & XHCI_STATE_HALTED)) {
-   xhci_free_virt_device(xhci, slot_id);
spin_unlock_irqrestore(>lock, flags);
kfree(command);
-   return ret;
+   return -ENODEV;
}
 
ret = xhci_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
-- 
2.7.4

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

[PATCH 08/13] usb: xhci: Remove xhci->mutex from xhci_alloc_dev()

[Mathias Nyman]

From: Lu Baolu 

xhci->mutex was added in xhci_alloc_dev()  to protect two race sources
(xhci->slot_id and xhci->addr_dev) by commit a00918d0521d ("usb: host:
xhci: add mutex for non-thread-safe data").

While xhci->slot_id has been discarded in commit c2d3d49bba08 ("usb:
xhci: move slot_id from xhci_hcd to xhci_command structure"), and
xhci->addr_dev has been removed in commit 87e44f2aac8d ("usb: xhci:
remove the use of xhci->addr_dev"), it's now safe to remove the use of
xhci->mutex in xhci_alloc_dev().

Link: https://marc.info/?l=linux-usb=150306294725821=2

Suggested-by: Mathias Nyman 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index cf10d7b..339ff9f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3639,13 +3639,10 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
if (!command)
return 0;
 
-   /* xhci->slot_id and xhci->addr_dev are not thread-safe */
-   mutex_lock(>mutex);
spin_lock_irqsave(>lock, flags);
ret = xhci_queue_slot_control(xhci, command, TRB_ENABLE_SLOT, 0);
if (ret) {
spin_unlock_irqrestore(>lock, flags);
-   mutex_unlock(>mutex);
xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
xhci_free_command(xhci, command);
return 0;
@@ -3655,7 +3652,6 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 
wait_for_completion(command->completion);
slot_id = command->slot_id;
-   mutex_unlock(>mutex);
 
if (!slot_id || command->status != COMP_SUCCESS) {
xhci_err(xhci, "Error while assigning device slot ID\n");
-- 
2.7.4

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

[PATCH 05/13] usb: xhci: Fix potential memory leak in xhci_disable_slot()

[Mathias Nyman]

From: Lu Baolu 

xhci_disable_slot() allows the invoker to pass a command pointer
as paramenter. Otherwise, it will allocate one. This will cause
memory leak when a command structure was allocated inside of this
function while queuing command trb fails. Another problem comes up
when the invoker passed a command pointer, but xhci_disable_slot()
frees it when it detects a dead host.

This patch fixes these two problems by removing the command parameter
from xhci_disable_slot().

Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c |  2 +-
 drivers/usb/host/xhci.c | 30 +-
 drivers/usb/host/xhci.h |  3 +--
 3 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index f0ae9df..e35903d 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -615,7 +615,7 @@ static int xhci_enter_test_mode(struct xhci_hcd *xhci,
if (!xhci->devs[i])
continue;
 
-   retval = xhci_disable_slot(xhci, NULL, i);
+   retval = xhci_disable_slot(xhci, i);
if (retval)
xhci_err(xhci, "Failed to disable slot %d, %d. Enter 
test mode anyway\n",
 i, retval);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5cb7c5c..d9dabb7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3531,14 +3531,9 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
struct xhci_virt_device *virt_dev;
struct xhci_slot_ctx *slot_ctx;
int i, ret;
-   struct xhci_command *command;
 
xhci_debugfs_remove_slot(xhci, udev->slot_id);
 
-   command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
-   if (!command)
-   return;
-
 #ifndef CONFIG_USB_DEFAULT_PERSIST
/*
 * We called pm_runtime_get_noresume when the device was attached.
@@ -3553,10 +3548,8 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
/* If the host is halted due to driver unload, we still need to free the
 * device.
 */
-   if (ret <= 0 && ret != -ENODEV) {
-   kfree(command);
+   if (ret <= 0 && ret != -ENODEV)
return;
-   }
 
virt_dev = xhci->devs[udev->slot_id];
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
@@ -3568,22 +3561,21 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
del_timer_sync(_dev->eps[i].stop_cmd_timer);
}
 
-   xhci_disable_slot(xhci, command, udev->slot_id);
+   xhci_disable_slot(xhci, udev->slot_id);
/*
 * Event command completion handler will free any data structures
 * associated with the slot.  XXX Can free sleep?
 */
 }
 
-int xhci_disable_slot(struct xhci_hcd *xhci, struct xhci_command *command,
-   u32 slot_id)
+int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
 {
+   struct xhci_command *command;
unsigned long flags;
u32 state;
int ret = 0;
 
-   if (!command)
-   command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
+   command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
return -ENOMEM;
 
@@ -3602,7 +3594,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, struct 
xhci_command *command,
slot_id);
if (ret) {
spin_unlock_irqrestore(>lock, flags);
-   xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
+   kfree(command);
return ret;
}
xhci_ring_cmd_db(xhci);
@@ -3677,6 +3669,8 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
return 0;
}
 
+   xhci_free_command(xhci, command);
+
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK)) {
spin_lock_irqsave(>lock, flags);
ret = xhci_reserve_host_control_ep_resources(xhci);
@@ -3714,18 +3708,12 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
pm_runtime_get_noresume(hcd->self.controller);
 #endif
 
-
-   xhci_free_command(xhci, command);
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
 
 disable_slot:
-   /* Disable slot, if we can do it without mem alloc */
-   kfree(command->completion);
-   command->completion = NULL;
-   command->status = 0;
-   return xhci_disable_slot(xhci, command, udev->slot_id);
+   return xhci_disable_slot(xhci, udev->slot_id);
 }
 
 /*
diff 

[PATCH 12/13] xhci: trace slot context when calling xhci_configure_endpoint()

[Mathias Nyman]

Add trace showing content of input slot context for
configure endpoint and evaluate context commands

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-trace.h | 5 +
 drivers/usb/host/xhci.c   | 4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
index f20753b..754dfb0 100644
--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -388,6 +388,11 @@ DEFINE_EVENT(xhci_log_slot_ctx, xhci_handle_cmd_set_deq,
TP_ARGS(ctx)
 );
 
+DEFINE_EVENT(xhci_log_slot_ctx, xhci_configure_endpoint,
+   TP_PROTO(struct xhci_slot_ctx *ctx),
+   TP_ARGS(ctx)
+);
+
 DECLARE_EVENT_CLASS(xhci_log_ring,
TP_PROTO(struct xhci_ring *ring),
TP_ARGS(ring),
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 870093a..9c1f1ad 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2564,6 +2564,7 @@ static int xhci_configure_endpoint(struct xhci_hcd *xhci,
unsigned long flags;
struct xhci_input_control_ctx *ctrl_ctx;
struct xhci_virt_device *virt_dev;
+   struct xhci_slot_ctx *slot_ctx;
 
if (!command)
return -EINVAL;
@@ -2602,6 +2603,9 @@ static int xhci_configure_endpoint(struct xhci_hcd *xhci,
return -ENOMEM;
}
 
+   slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx);
+   trace_xhci_configure_endpoint(slot_ctx);
+
if (!ctx_change)
ret = xhci_queue_configure_endpoint(xhci, command,
command->in_ctx->dma,
-- 
2.7.4

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

[PATCH 10/13] usb: xhci: reduce device initiated resume time variance.

[Mathias Nyman]

From: Anshuman Gupta 

This patch will improve the variable auto-resume latency of an usb-port.

The attempt to sync the start of root hub polling with resume time
signaling finish was ruined by a later request to start immediate
root hub polling.

When xhci gets a port status change event interrupt due to PORT_PLC
(port link state transition), linux Host controller driver drives the
resume signalling on the bus for the amount of time defined by
USB_REUME_TIMEOUT(40ms) macro.

This 40ms delay for resume signalling is in acceptable limit, but
it get worse when xhci goes for polling mode in order to detect other
events on its ports and modify rh_timer timer with a variable time out of
1ms to (HZ/4)ms.

drivers/usb/core/hcd.c line 799
mod_timer (>rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)).

Due to above variable timeout usb auto-resume latency varies from
40ms to ~300ms.

Log Snippet:
~128ms latency
[   53.112049] hub 1-0:1.0: state 7 ports 12 chg  evt 
[   53.229200] hub 1-0:1.0: state 7 ports 12 chg  evt 0004
[   53.240177] usb 1-2: usb wakeup-resume
[   53.240195] usb 1-2: finish resume
[   53.240357] usb usb1-port2: resume, status 0
-
~300ms latency
[   59.946620] hub 1-0:1.0: state 7 ports 12 chg  evt 
[   59.979341] hub 1-0:1.0: state 7 ports 12 chg  evt 
[   60.229342] hub 1-0:1.0: state 7 ports 12 chg  evt 0004
[   60.251321] usb 1-2: usb wakeup-resume
[   60.251335] usb 1-2: finish resume
[   60.251539] usb usb1-port2: resume, status 0

This variable resume latency can be optimized, as in case of PORT_PLC
change event rh_timer has already been modified with USB_RESUME_TIMEOUT
(40ms) delay,leaving the rest to GetPortStatus and started polling for
root hub status (invoking usb_hcd_poll_rh_status).
We can avoid polling as we have already modified rh_timer with
delay of 40ms.

This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of
rh_timer, and avoids polling of root hub status. so rh_timer can fire
after 40ms and usb device auto-resuem latency will be around 40ms.

[topic and first two senctences of commit message changed -Mathias]
Signed-off-by: Anshuman Gupta 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index a944365..15afe1e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1679,9 +1679,14 @@ static void handle_port_status(struct xhci_hcd *xhci,
bus_state->resume_done[faked_port_index] = jiffies +
msecs_to_jiffies(USB_RESUME_TIMEOUT);
set_bit(faked_port_index, _state->resuming_ports);
+   /* Do the rest in GetPortStatus after resume time delay.
+* Avoid polling roothub status before that so that a
+* usb device auto-resume latency around ~40ms.
+*/
+   set_bit(HCD_FLAG_POLL_RH, >flags);
mod_timer(>rh_timer,
  bus_state->resume_done[faked_port_index]);
-   /* Do the rest in GetPortStatus */
+   bogus_port_status = true;
}
}
 
-- 
2.7.4

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

[PATCH 13/13] usb: host: xhci-plat: Use of_device_get_match_data() helper

[Mathias Nyman]

From: Geert Uytterhoeven 

Use the of_device_get_match_data() helper instead of open coding.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-plat.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d0625fa..6804cd4 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -152,7 +153,7 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
 
 static int xhci_plat_probe(struct platform_device *pdev)
 {
-   const struct of_device_id *match;
+   const struct xhci_plat_priv *priv_match;
const struct hc_driver  *driver;
struct device   *sysdev;
struct xhci_hcd *xhci;
@@ -238,9 +239,8 @@ static int xhci_plat_probe(struct platform_device *pdev)
}
 
xhci = hcd_to_xhci(hcd);
-   match = of_match_node(usb_xhci_of_match, pdev->dev.of_node);
-   if (match) {
-   const struct xhci_plat_priv *priv_match = match->data;
+   priv_match = of_device_get_match_data(>dev);
+   if (priv_match) {
struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
 
/* Just copy data for now */
-- 
2.7.4

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

[PATCH 06/13] usb: xhci: Fix memory leak when xhci_disable_slot() returns error

[Mathias Nyman]

From: Lu Baolu 

If xhci_disable_slot() returns success, a disable slot command
trb was queued in the command ring. The command completion
handler will free the virtual device data structure associated
with the slot. On the other hand, when xhci_disable_slot()
returns error, the invokers should take the responsibilities to
free the slot related data structure. Otherwise, memory leakage
happens.

Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d9dabb7..23378f3 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3561,11 +3561,9 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
del_timer_sync(_dev->eps[i].stop_cmd_timer);
}
 
-   xhci_disable_slot(xhci, udev->slot_id);
-   /*
-* Event command completion handler will free any data structures
-* associated with the slot.  XXX Can free sleep?
-*/
+   ret = xhci_disable_slot(xhci, udev->slot_id);
+   if (ret)
+   xhci_free_virt_device(xhci, udev->slot_id);
 }
 
 int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
@@ -3713,7 +3711,11 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
return 1;
 
 disable_slot:
-   return xhci_disable_slot(xhci, udev->slot_id);
+   ret = xhci_disable_slot(xhci, udev->slot_id);
+   if (ret)
+   xhci_free_virt_device(xhci, udev->slot_id);
+
+   return 0;
 }
 
 /*
-- 
2.7.4

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

[PATCH 09/13] usb: xhci: Handle USB transaction error on address command

[Mathias Nyman]

From: Lu Baolu 

Xhci driver handles USB transaction errors on transfer events,
but transaction errors are possible on address device command
completion events as well.

The xHCI specification (section 4.6.5) says: A USB Transaction
Error Completion Code for an Address Device Command may be due
to a Stall response from a device. Software should issue a Disable
Slot Command for the Device Slot then an Enable Slot Command to
recover from this error.

This patch handles USB transaction errors on address command
completion events. The related discussion threads can be found
through below links.

http://marc.info/?l=linux-usb=149362010728921=2
http://marc.info/?l=linux-usb=149252752825755=2

Suggested-by: Mathias Nyman 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 339ff9f..870093a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3834,8 +3834,14 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct 
usb_device *udev,
break;
case COMP_USB_TRANSACTION_ERROR:
dev_warn(>dev, "Device not responding to setup %s.\n", 
act);
-   ret = -EPROTO;
-   break;
+
+   mutex_unlock(>mutex);
+   ret = xhci_disable_slot(xhci, udev->slot_id);
+   if (!ret)
+   xhci_alloc_dev(hcd, udev);
+   kfree(command->completion);
+   kfree(command);
+   return -EPROTO;
case COMP_INCOMPATIBLE_DEVICE_ERROR:
dev_warn(>dev,
 "ERROR: Incompatible device for setup %s command\n", 
act);
-- 
2.7.4

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

[PATCH 00/13] xhci features for usb-next

[Mathias Nyman]

Hi Greg

Some xhci features for 4.15.
Adds debugfs and more tracing for xhci, improves resume time
among other changes.

-Mathias

Adam Wallis (1):
  xhci: allow TRACE to work with EVENT ring dequeue

Anshuman Gupta (1):
  usb: xhci: reduce device initiated resume time variance.

Geert Uytterhoeven (1):
  usb: host: xhci-plat: Use of_device_get_match_data() helper

Lu Baolu (7):
  usb: xhci: Add debugfs interface for xHCI driver
  usb: xhci: Disable slot even when virt-dev is null
  usb: xhci: Fix potential memory leak in xhci_disable_slot()
  usb: xhci: Fix memory leak when xhci_disable_slot() returns error
  usb: xhci: Return error when host is dead in xhci_disable_slot()
  usb: xhci: Remove xhci->mutex from xhci_alloc_dev()
  usb: xhci: Handle USB transaction error on address command

Mathias Nyman (2):
  xhci: add port speed ID to portsc tracing
  xhci: trace slot context when calling xhci_configure_endpoint()

Thang Q. Nguyen (1):
  usb: host: xhci support option to disable the xHCI USB2 HW LPM

 Documentation/devicetree/bindings/usb/usb-xhci.txt |   1 +
 drivers/usb/host/Makefile  |   4 +
 drivers/usb/host/xhci-debugfs.c| 526 +
 drivers/usb/host/xhci-debugfs.h| 137 ++
 drivers/usb/host/xhci-hub.c|   5 +-
 drivers/usb/host/xhci-mem.c|   5 +-
 drivers/usb/host/xhci-plat.c   |  11 +-
 drivers/usb/host/xhci-ring.c   |  12 +-
 drivers/usb/host/xhci-trace.h  |   5 +
 drivers/usb/host/xhci.c|  88 ++--
 drivers/usb/host/xhci.h|  18 +-
 11 files changed, 759 insertions(+), 53 deletions(-)
 create mode 100644 drivers/usb/host/xhci-debugfs.c
 create mode 100644 drivers/usb/host/xhci-debugfs.h

-- 
2.7.4

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

Re: [PATCH v2 14/17] phy: qcom-qusb2: Set vbus sw-override signal in device mode

[Manu Gautam]

Hi Jack,

On 9/28/2017 10:23 PM, Jack Pham wrote:
> Hi Manu,
>
> On Thu, Sep 28, 2017 at 09:30:38AM +0530, Manu Gautam wrote:
>> On 9/28/2017 12:46 AM, Jack Pham wrote:
>>> On Wed, Sep 27, 2017 at 10:57:41AM -0700, Jack Pham wrote:
 On Wed, Sep 27, 2017 at 02:29:10PM +0530, Manu Gautam wrote:
> VBUS signal coming from PHY must be asserted in device for
> controller to start operation or assert pull-up. For some
> platforms where VBUS line is not connected to PHY there is
> HS_PHY_CTRL register in QSCRATCH wrapper that can be used
> by software to override VBUS signal going to controller.
>
> Signed-off-by: Manu Gautam 
> ---
>  
> +static int qusb2_phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct qusb2_phy *qphy = phy_get_drvdata(phy);
> +
> + qphy->mode = mode;
> +
> + /* Update VBUS override in qscratch register */
> + if (qphy->qscratch_base) {
> + if (mode == PHY_MODE_USB_DEVICE)
> + qusb2_setbits(qphy->qscratch_base, QSCRATCH_HS_PHY_CTRL,
> +   UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
> + else
> + qusb2_clrbits(qphy->qscratch_base, QSCRATCH_HS_PHY_CTRL,
> +   UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
 Wouldn't this be better off handled in the controller glue driver? Two
 reasons I think this patch is unattractive:

 - qscratch_base is part of the controller's register space. Your later
   patch 16/17 ("phy: qcom-qmp: Override lane0_power_present signal in
   device mode") does a similar thing and hence both drivers have to
   ioremap() the same register resource while at the same time avoiding
   request_mem_region() (called by devm_ioremap_resource) to allow it to
   be mapped in both places.
>> Right. There is one more reason why qusb2 driver needs qscratch:
>> - During runtime suspend, it has to check linestate to set correct  polarity 
>> for dp/dm
>>   wakeup interrupt in order to detect disconnect/resume ion LS and FS/HS 
>> modes.
> Ugh, oh yeah. The way I understand we did it in our downstream driver
> is still to have the controller driver read the linestate but then pass
> the information via additional set_mode() flags which the PHY driver
> could use to correctly arm the interrupt trigger polarity.
>
> An alternative would be to access a couple of the debug QUSB2PHY
> registers that also provide a reading of the current UTMI linestate. The
> HPG mentions them vaguely, and I can't remember if we tested that
> interface or not. Assuming it works, would that be preferable to reading
> a non-PHY register here?

it looks like newer QUSB2 PHY doesn't have a register to read linestate.
QSCRATCH is the only option.
However, setting dp/dm wakeup interrupt polarity based on current linestate
isn't perfect either. It could race with any change in linestate while it was 
being
read, resulting in missed wakeup interrupt.
Same is the case with QMP PHY when trying to check for RX terminations on
suspend.
IMO PHY driver should get this info from platform glue or controller driver.
E.g. current speed -> SS, HS/FS, LS or NONE (if not in session).

Kishon,
What would you suggest here?
Should we add new calls e.g. phy_get/set_current_speed like::

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 78bb0d7..41d9ec2 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -29,6 +29,14 @@ enum phy_mode {
    PHY_MODE_USB_OTG,
 };

+enum phy_speed {
+   PHY_SPEED_INVALID,
+   PHY_SPEED_USB_LS,
+   PHY_SPEED_USB_FS_HS,
+   PHY_SPEED_USB_SS,
+};
+
 /**
  * struct phy_ops - set of function pointers for performing phy operations
  * @init: operation to be performed for initializing phy
@@ -45,6 +53,7 @@ struct phy_ops {
    int (*power_on)(struct phy *phy);
    int (*power_off)(struct phy *phy);
    int (*set_mode)(struct phy *phy, enum phy_mode mode);
+   int (*set_speed)(struct phy *phy, enum phy_speed speed);
    int (*reset)(struct phy *phy);
    struct module *owner;
 };


 - VBUS override bit becomes asserted simply because the mode is changed
   to device mode but this is irrespective of the actual VBUS state. This
   could break some test setups which perform a logical disconnect by
   switching off/on VBUS while leaving data lines connected. Controller
   would go merrily along thinking it is still attached to the host.

 Instead maybe this could be tied to EXTCON_USB handling in the glue
 driver; though it would need to be an additional notifier on top of
 dwc3/drd.c which already handles extcon for host/device mode.
>> Yes, dwc3/drd.c currently deals with only EXTCON_USB_HOST. So, for platforms
>> where role swap happens using only Vbus or single GPIO this should take care 
>> of.
>>
>>
>>> That is to say, 

Re: [PATCH] usb: host: xhci-plat: Use of_device_get_match_data() helper

[Simon Horman]

On Wed, Oct 04, 2017 at 02:25:03PM +0200, Geert Uytterhoeven wrote:
> Use the of_device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 


--
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: Random xHCI HC died on device disconnect

[Kristian Evensen]

Hi,

On Wed, Oct 4, 2017 at 12:16 PM, Mathias Nyman
 wrote:
> This is the xhci->cmd_timer (delayed work) that has a five second timeout
> for the currently processing command on the command ring.
> When triggered it will abort the current command by stopping the command
> ring
> and remove/move past the current command.
>
> Logs shows the command first timed out, and xhci then failing to stop the
> command ring.
> when trying to abort the command.
>
> To me it looks like xHC ends up in a state that we can't recover from
> without resetting xHC.
> xhci Module reload or rebinding device and driver is needed

I thought I had scared the error away, but it just happened. I figured
out how to build xhci as a module for my board and reloading
(rmmod/modprobe) the module recovers the host controller. So while not
very elegant, a script which checks dmesg for this error message and
reloads xhci in case error happens is good enough in my case.

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

RE: [PATCH] usb: gadget: udc: renesas_usb3: Use of_device_get_match_data() helper

[Yoshihiro Shimoda]

Hi,

> From: Geert Uytterhoeven, Sent: Wednesday, October 4, 2017 9:24 PM
> 
> Use the of_device_get_match_data() helper instead of open coding,
> postponing the matching until when it's really needed.
> Note that the renesas_usb3 driver is used with DT only, so there's
> always a valid match.
> 
> Signed-off-by: Geert Uytterhoeven 

Thank you for the patch!

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

--
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: host: xhci-plat: Use of_device_get_match_data() helper

[Mathias Nyman]

On 05.10.2017 12:19, Simon Horman wrote:

On Wed, Oct 04, 2017 at 02:25:03PM +0200, Geert Uytterhoeven wrote:

Use the of_device_get_match_data() helper instead of open coding.

Signed-off-by: Geert Uytterhoeven 


Reviewed-by: Simon Horman 




Thanks, I already applied and sent forward before this new reviewed-by tag

-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 v4 4/8] mtd: nand: atmel: Avoid ECC errors when leaving backup mode

[Boris Brezillon]

On Thu, 28 Sep 2017 11:46:23 +0200
Romain Izard  wrote:

> During backup mode, the contents of all registers will be cleared as the
> SoC will be completely powered down. For a product that boots on NAND
> Flash memory, the bootloader will obviously use the related controller
> to read the Flash and correct any detected error in the memory, before
> handling back control to the kernel's resuming entry point.
> 
> But it does not clean the NAND controller registers after use and on its
> side the kernel driver expects the error locator to be powered down and
> in a clean state. Add a resume hook for the PMECC error locator, and
> reset its registers.
> 
> Signed-off-by: Romain Izard 

Applied.

Thanks,

Boris

> ---
> Changes in v3:
> * keep the PMECC disabled when not in use, and use atmel_pmecc_resume to
>   reset the controller after the bootloader has left it enabled.
> 
> Changes in v4:
> * export atmel_pmecc_reset instead of atmel_pmecc_resume
> * use the correct pointer in atmel_nand_controller_resume
> 
>  drivers/mtd/nand/atmel/nand-controller.c |  3 +++
>  drivers/mtd/nand/atmel/pmecc.c   | 17 +
>  drivers/mtd/nand/atmel/pmecc.h   |  1 +
>  3 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mtd/nand/atmel/nand-controller.c 
> b/drivers/mtd/nand/atmel/nand-controller.c
> index f25eca79f4e5..8afcff9a66ea 100644
> --- a/drivers/mtd/nand/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/atmel/nand-controller.c
> @@ -2530,6 +2530,9 @@ static __maybe_unused int 
> atmel_nand_controller_resume(struct device *dev)
>   struct atmel_nand_controller *nc = dev_get_drvdata(dev);
>   struct atmel_nand *nand;
>  
> + if (nc->pmecc)
> + atmel_pmecc_reset(nc->pmecc);
> +
>   list_for_each_entry(nand, >chips, node) {
>   int i;
>  
> diff --git a/drivers/mtd/nand/atmel/pmecc.c b/drivers/mtd/nand/atmel/pmecc.c
> index 146af8218314..0a3f12141c45 100644
> --- a/drivers/mtd/nand/atmel/pmecc.c
> +++ b/drivers/mtd/nand/atmel/pmecc.c
> @@ -765,6 +765,13 @@ void atmel_pmecc_get_generated_eccbytes(struct 
> atmel_pmecc_user *user,
>  }
>  EXPORT_SYMBOL_GPL(atmel_pmecc_get_generated_eccbytes);
>  
> +void atmel_pmecc_reset(struct atmel_pmecc *pmecc)
> +{
> + writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> + writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> +}
> +EXPORT_SYMBOL_GPL(atmel_pmecc_reset);
> +
>  int atmel_pmecc_enable(struct atmel_pmecc_user *user, int op)
>  {
>   struct atmel_pmecc *pmecc = user->pmecc;
> @@ -797,10 +804,7 @@ EXPORT_SYMBOL_GPL(atmel_pmecc_enable);
>  
>  void atmel_pmecc_disable(struct atmel_pmecc_user *user)
>  {
> - struct atmel_pmecc *pmecc = user->pmecc;
> -
> - writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> - writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> + atmel_pmecc_reset(user->pmecc);
>   mutex_unlock(>pmecc->lock);
>  }
>  EXPORT_SYMBOL_GPL(atmel_pmecc_disable);
> @@ -855,10 +859,7 @@ static struct atmel_pmecc *atmel_pmecc_create(struct 
> platform_device *pdev,
>  
>   /* Disable all interrupts before registering the PMECC handler. */
>   writel(0x, pmecc->regs.base + ATMEL_PMECC_IDR);
> -
> - /* Reset the ECC engine */
> - writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> - writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> + atmel_pmecc_reset(pmecc);
>  
>   return pmecc;
>  }
> diff --git a/drivers/mtd/nand/atmel/pmecc.h b/drivers/mtd/nand/atmel/pmecc.h
> index a8ddbfca2ea5..817e0dd9fd15 100644
> --- a/drivers/mtd/nand/atmel/pmecc.h
> +++ b/drivers/mtd/nand/atmel/pmecc.h
> @@ -61,6 +61,7 @@ atmel_pmecc_create_user(struct atmel_pmecc *pmecc,
>   struct atmel_pmecc_user_req *req);
>  void atmel_pmecc_destroy_user(struct atmel_pmecc_user *user);
>  
> +void atmel_pmecc_reset(struct atmel_pmecc *pmecc);
>  int atmel_pmecc_enable(struct atmel_pmecc_user *user, int op);
>  void atmel_pmecc_disable(struct atmel_pmecc_user *user);
>  int atmel_pmecc_wait_rdy(struct atmel_pmecc_user *user);

--
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: Random xHCI HC died on device disconnect

[Manu Gautam]

Hi Mathias,


On 10/4/2017 3:46 PM, Mathias Nyman wrote:
> On 03.10.2017 18:27, Kristian Evensen wrote:
>> On Tue, Oct 3, 2017 at 4:51 PM, Kristian Evensen
>>  wrote:
> This is the xhci->cmd_timer (delayed work) that has a five second timeout
> for the currently processing command on the command ring.
> When triggered it will abort the current command by stopping the command ring
> and remove/move past the current command.
>
> Logs shows the command first timed out, and xhci then failing to stop the 
> command ring.
> when trying to abort the command.
>
> To me it looks like xHC ends up in a state that we can't recover from without 
> resetting xHC.
> xhci Module reload or rebinding device and driver is needed
>
> -Mathias
>

Should we register an atomic_notifier chain to notify on usb_hc_died?
This will allow platform glue drivers to recover from this state by
re-initializing the xHC/PHYs.

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

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 02/13] xhci: add port speed ID to portsc tracing

[Mathias Nyman]

Shows the port speed protocol speed ID (PSID) in use.
speed ID may map to custom speeds, but in most cases it uses default

1 = Full-Speed12 MB/s
2 = Low-Speed 1.5 Mb/s
3 = High-speed480 Mb/s
4 = SuperSpeed5 Gb/s
5 = SuperSpeedPlus10 Gb/s

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index dc22392..ea176da 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -2441,11 +2441,12 @@ static inline const char *xhci_decode_portsc(u32 portsc)
static char str[256];
int ret;
 
-   ret = sprintf(str, "%s %s %s Link:%s ",
+   ret = sprintf(str, "%s %s %s Link:%s PortSpeed:%d ",
  portsc & PORT_POWER   ? "Powered" : "Powered-off",
  portsc & PORT_CONNECT ? "Connected" : "Not-connected",
  portsc & PORT_PE  ? "Enabled" : "Disabled",
- xhci_portsc_link_state_string(portsc));
+ xhci_portsc_link_state_string(portsc),
+ DEV_PORT_SPEED(portsc));
 
if (portsc & PORT_OC)
ret += sprintf(str + ret, "OverCurrent ");
-- 
2.7.4

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

[PATCH 01/13] usb: host: xhci support option to disable the xHCI USB2 HW LPM

[Mathias Nyman]

From: "Thang Q. Nguyen" 

XHCI specification 1.1 does not require xHCI-compliant controllers
to always enable hardware USB2 LPM. However, the current xHCI
driver always enable it when seeing HLC=1.
This patch supports an option for users to control disabling
USB2 Hardware LPM via DT/ACPI attribute.
This option is needed in case user would like to disable this
feature. For example, their xHCI controller has its USB2 HW LPM
broken.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
Acked-by: Rob Herring 
Signed-off-by: Mathias Nyman 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
 drivers/usb/host/xhci-plat.c   | 3 +++
 drivers/usb/host/xhci.c| 2 +-
 drivers/usb/host/xhci.h| 1 +
 4 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 2d80b60..ae6e484 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -26,6 +26,7 @@ Required properties:
 
 Optional properties:
   - clocks: reference to a clock
+  - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
   - usb3-lpm-capable: determines if platform is USB3 LPM capable
   - quirk-broken-port-ped: set if the controller has broken port disable 
mechanism
 
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 163bafd..d0625fa 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -259,6 +259,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto disable_clk;
}
 
+   if (device_property_read_bool(sysdev, "usb2-lpm-disable"))
+   xhci->quirks |= XHCI_HW_LPM_DISABLE;
+
if (device_property_read_bool(sysdev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
 
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b2ff1ff..3a8e75f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4087,7 +4087,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
 
-   if (enable) {
+   if (enable && !(xhci->quirks & XHCI_HW_LPM_DISABLE)) {
/* Host supports BESL timeout instead of HIRD */
if (udev->usb2_hw_lpm_besl_capable) {
/* if device doesn't have a preferred BESL value use a
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 2abaa4d..dc22392 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1828,6 +1828,7 @@ struct xhci_hcd {
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
 #define XHCI_U2_DISABLE_WAKE   (1 << 27)
 #define XHCI_ASMEDIA_MODIFY_FLOWCONTROL(1 << 28)
+#define XHCI_HW_LPM_DISABLE(1 << 29)
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
2.7.4

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

[PATCH 04/13] usb: xhci: Disable slot even when virt-dev is null

[Mathias Nyman]

From: Lu Baolu 

xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it checks
the corespoding virt-dev pointer and returns directly (w/o issuing
disable slot command) if it's null.

This is unnecessary and will cause problems in case where virt-dev
allocation fails and xhci_disable_slot() is called to roll back the
hardware state. Refer to the implementation of xhci_alloc_dev().

This patch removes lines to check virt-dev in xhci_disable_slot().

Fixes: f9e609b82479 ("usb: xhci: Add helper function xhci_disable_slot().")
Cc: Guoqing Zhang 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c | 3 +++
 drivers/usb/host/xhci.c | 4 
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index ad89a6d..f0ae9df 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -612,6 +612,9 @@ static int xhci_enter_test_mode(struct xhci_hcd *xhci,
xhci_dbg(xhci, "Disable all slots\n");
spin_unlock_irqrestore(>lock, *flags);
for (i = 1; i <= HCS_MAX_SLOTS(xhci->hcs_params1); i++) {
+   if (!xhci->devs[i])
+   continue;
+
retval = xhci_disable_slot(xhci, NULL, i);
if (retval)
xhci_err(xhci, "Failed to disable slot %d, %d. Enter 
test mode anyway\n",
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e20b2c2..5cb7c5c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3581,11 +3581,7 @@ int xhci_disable_slot(struct xhci_hcd *xhci, struct 
xhci_command *command,
unsigned long flags;
u32 state;
int ret = 0;
-   struct xhci_virt_device *virt_dev;
 
-   virt_dev = xhci->devs[slot_id];
-   if (!virt_dev)
-   return -EINVAL;
if (!command)
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
-- 
2.7.4

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

[PATCH 03/13] usb: xhci: Add debugfs interface for xHCI driver

[Mathias Nyman]

From: Lu Baolu 

This adds debugfs consumer for xHCI driver. The debugfs entries
read all host registers, device/endpoint contexts, command ring,
event ring and various endpoint rings. With these entries, users
can check the registers and memory spaces used by a host during
run time, or save all the information with a simple 'cp -r' for
post-mortem programs.

The file hierarchy looks like this.

[root of debugfs]
|__usb
|[e,u,o]hci <-[root for other HCIs]
|xhci   <---[root for xHCI]
|__:00:14.0 <--[xHCI host name]
|reg-cap<[capability registers]
|reg-op <---[operational registers]
|reg-runtime<---[runtime registers]
|reg-ext-#cap_name  <[extended capability regs]
|command-ring   <---[root for command ring]
|__cycle<--[ring cycle]
|__dequeue  <[ring dequeue pointer]
|__enqueue  <[ring enqueue pointer]
|__trbs <---[ring trbs]
|event-ring <-[root for event ring]
|__cycle<--[ring cycle]
|__dequeue  <[ring dequeue pointer]
|__enqueue  <[ring enqueue pointer]
|__trbs <---[ring trbs]
|devices<[root for devices]
|__#slot_id <---[root for a device]
|name   <-[device name]
|slot-context   <[slot context]
|ep-context <---[endpoint contexts]
|ep#ep_index<[root for an endpoint]
|__cycle<--[ring cycle]
|__dequeue  <[ring dequeue pointer]
|__enqueue  <[ring enqueue pointer]
|__trbs <---[ring trbs]

Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/Makefile   |   4 +
 drivers/usb/host/xhci-debugfs.c | 526 
 drivers/usb/host/xhci-debugfs.h | 137 +++
 drivers/usb/host/xhci-mem.c |   5 +-
 drivers/usb/host/xhci.c |  23 +-
 drivers/usb/host/xhci.h |   9 +
 6 files changed, 700 insertions(+), 4 deletions(-)
 create mode 100644 drivers/usb/host/xhci-debugfs.c
 create mode 100644 drivers/usb/host/xhci-debugfs.h

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691f..b2a7f05 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -25,6 +25,10 @@ ifneq ($(CONFIG_USB_XHCI_RCAR), )
xhci-plat-hcd-y += xhci-rcar.o
 endif
 
+ifneq ($(CONFIG_DEBUG_FS),)
+   xhci-hcd-y  += xhci-debugfs.o
+endif
+
 obj-$(CONFIG_USB_WHCI_HCD) += whci/
 
 obj-$(CONFIG_USB_PCI)  += pci-quirks.o
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
new file mode 100644
index 000..6772ee9
--- /dev/null
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -0,0 +1,526 @@
+/*
+ * xhci-debugfs.c - xHCI debugfs interface
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+
+#include "xhci.h"
+#include "xhci-debugfs.h"
+
+static const struct debugfs_reg32 xhci_cap_regs[] = {
+   dump_register(CAPLENGTH),
+   dump_register(HCSPARAMS1),
+   dump_register(HCSPARAMS2),
+   dump_register(HCSPARAMS3),
+   dump_register(HCCPARAMS1),
+   dump_register(DOORBELLOFF),
+   dump_register(RUNTIMEOFF),
+   dump_register(HCCPARAMS2),
+};
+
+static const struct debugfs_reg32 xhci_op_regs[] = {
+   dump_register(USBCMD),
+   dump_register(USBSTS),
+   dump_register(PAGESIZE),
+   dump_register(DNCTRL),
+   dump_register(CRCR),
+   dump_register(DCBAAP_LOW),
+   dump_register(DCBAAP_HIGH),
+   dump_register(CONFIG),
+};
+
+static const struct debugfs_reg32 xhci_runtime_regs[] = {
+   dump_register(MFINDEX),
+   dump_register(IR0_IMAN),
+   dump_register(IR0_IMOD),
+   dump_register(IR0_ERSTSZ),
+   dump_register(IR0_ERSTBA_LOW),
+   dump_register(IR0_ERSTBA_HIGH),
+   dump_register(IR0_ERDP_LOW),
+   dump_register(IR0_ERDP_HIGH),
+};
+
+static const struct debugfs_reg32 xhci_extcap_legsup[] = {
+   dump_register(EXTCAP_USBLEGSUP),
+   dump_register(EXTCAP_USBLEGCTLSTS),
+};
+
+static const struct debugfs_reg32 

Re: [PATCH v2 0/2] USB: musb: PM fixes

[Johan Hovold]

On Thu, Sep 07, 2017 at 03:37:46PM +0200, Johan Hovold wrote:
> These patches fix a couple of bugs introduced by the recent runtime-PM
> work (details in the individual commit messages).
> 
> Note that the external abort was due to the irq work never being flushed
> on suspend, and that we may need similar fixes for the delayed reset and
> resume work which are likewise never cancelled on suspend.
> 
> As I just mentioned in the v1 thread, there are a number of further issues 
> with
> musb suspend (e.g. on BBB):
> 
>  1. System suspend appears to break any active gadget (which then can be
> restarted manually).
> 
>  2. The early_tx polling in musb_cppi41 lacks a timeout, something which can
> lead to the hrtimer rescheduling itself indefinitely if the fifo never
> empties (e.g. if a transfer is is initiated post suspend due to issue 1).
> 
> See commit a655f481d83d ("usb: musb: musb_cppi41: handle pre-mature TX
> complete interrupt").
> 
>  3. In host mode, if a device is disconnected while the system is suspended,
> this will keep the controller runtime active after resume as the session
> bit is always set.

Bin and Tony, any comments to this series?

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: [PATCH] usb: renesas_usbhs: Use of_device_get_match_data() helper

[Simon Horman]

On Wed, Oct 04, 2017 at 02:26:48PM +0200, Geert Uytterhoeven wrote:
> Use the of_device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

--
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: host: xhci-plat: Use of_device_get_match_data() helper

[Yoshihiro Shimoda]

Hi,

> From: Geert Uytterhoeven, Sent: Wednesday, October 4, 2017 9:25 PM
> 
> Use the of_device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Geert Uytterhoeven 

Thank you for the patch!

Reviewed-by: Yoshihiro Shimoda 

But, it seems too late about this Reviewed-by though...
https://marc.info/?l=linux-usb=150719811907415=2

Best regards,
Yoshihiro Shimoda

--
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: Random xHCI HC died on device disconnect

[Greg KH]

On Thu, Oct 05, 2017 at 01:50:35PM +0530, Manu Gautam wrote:
> Hi Mathias,
> 
> 
> On 10/4/2017 3:46 PM, Mathias Nyman wrote:
> > On 03.10.2017 18:27, Kristian Evensen wrote:
> >> On Tue, Oct 3, 2017 at 4:51 PM, Kristian Evensen
> >>  wrote:
> > This is the xhci->cmd_timer (delayed work) that has a five second timeout
> > for the currently processing command on the command ring.
> > When triggered it will abort the current command by stopping the command 
> > ring
> > and remove/move past the current command.
> >
> > Logs shows the command first timed out, and xhci then failing to stop the 
> > command ring.
> > when trying to abort the command.
> >
> > To me it looks like xHC ends up in a state that we can't recover from 
> > without resetting xHC.
> > xhci Module reload or rebinding device and driver is needed
> >
> > -Mathias
> >
> 
> Should we register an atomic_notifier chain to notify on usb_hc_died?
> This will allow platform glue drivers to recover from this state by
> re-initializing the xHC/PHYs.

Ugh, notifier chains are horrid, please use almost anything other than
that...

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

Re: [PATCH] usb: gadget: udc: renesas_usb3: Use of_device_get_match_data() helper

[Simon Horman]

On Wed, Oct 04, 2017 at 02:23:31PM +0200, Geert Uytterhoeven wrote:
> Use the of_device_get_match_data() helper instead of open coding,
> postponing the matching until when it's really needed.
> Note that the renesas_usb3 driver is used with DT only, so there's
> always a valid match.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

--
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 v3][for 4.14] xhci: allow TRACE to work with EVENT ring dequeue

[Mathias Nyman]

On 04.10.2017 19:07, Adam Wallis wrote:

On 9/26/2017 2:44 AM, Mathias Nyman wrote:

On 25.09.2017 19:09, David Laight wrote:

From: Adam Wallis

Sent: 25 September 2017 13:26
inc_deq() currently bails earlier for EVENT rings than the common return
point of the function, due to the fact that EVENT rings do not have
link TRBs. The unfortunate side effect of this is that the very useful
trace_xhci_inc_deq() function is not called/usable for EVENT ring
debug.


Is it actually worth using different functions for the different
ring types?
  From what I remember there are conditionals in a lot of the functions
but they are fixed for most of the call sites.



There's some restructuring and refactoring that could be done in xhci,
but that's not part of this patch.

This will just enable better debugging.

Applying this patch

Sounds great, thanks! Will this be going in on 4.14 sometime shortly? I hadn't
seen it in your tree and was curious since we are tracking internally. Thanks!



Now pushed to my for-usb-next branch and sent forward to Greg.
On its way to 4.15

-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 12/12] dt-bindings: usb: mtu3: remove optional pinctrls

[Rob Herring]

On Thu, Sep 28, 2017 at 08:17:20AM +0800, Chunfeng Yun wrote:
> Remove optional pinctrls due to using FORCE/RG_IDDIG to implement
> manual switch function.

Another not backwards compatible change. Please explain why that is 
okay.

> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mediatek,mtu3.txt  |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt 
> b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> index 49c982b..b2271d8 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> @@ -30,9 +30,10 @@ Optional properties:
>   when supports dual-role mode.
>   - vbus-supply : reference to the VBUS regulator, needed when supports
>   dual-role mode.
> - - pinctl-names : a pinctrl state named "default" must be defined,
> - "id_float" and "id_ground" are optinal which depends on
> - "mediatek,enable-manual-drd"
> + - pinctrl-names : a pinctrl state named "default" is optional, and need be
> + defined if auto drd switch is enabled, that means the property dr_mode
> + is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
> + is not set.
>   - pinctrl-0 : pin control group
>   See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>  
> -- 
> 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: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
> These bindings allows to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.

Yay!

> Signed-off-by: Andrzej Hajda 
> ---
> There are few things for discussion (IMO):
> 1. vendor specific connectors, I have added them here, but maybe better is
>to place them in separate files.

I'd worry about the standard connectors first, but probably good to have 
an idea of how vendor connectors need to be extended.

> 2. physical connector description - I have split it to three properties:
>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>This tripled is able to describe all USB-standard connectors, but there
>are also impossible combinations, for example(c, *, micro). Maybe better
>would be to just enumerate all possible connectors in include file.

We did "type" for hdmi-connector, but I think I'd really prefer 
compatible be used to distinguish as least where it may matter to s/w. 
In the HDMI case, they all are pretty much the same, just different 
physical size.

> 3. Numbering of port/remote nodes, currently only 0 is assigned for Interface
>Controller. Maybe other functions should be also assigned:
>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>as an additional property of remote node?

child of the controller is also an option. There's already prec

> ...
> 
> Regards
> Andrzej
> ---
>  .../bindings/connector/usb-connector.txt   | 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> new file mode 100644
> index ..f3a4e85122d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -0,0 +1,49 @@
> +USB Connector
> +=
> +
> +Required properties:
> +- compatible: "usb-connector"
> +  connectors with vendor specific extensions can add one of additional
> +  compatibles:
> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
> +- type: the USB connector type: "a", "b", "ab", "c"
> +- max-mode: max USB speed mode supported by the connector:
> +  "ls", "fs", "hs", "ss", "ss+"

Do we really see cases where the connector is slower than the 
controller? Plus things like "ls" with an type A connector are not 
valid.

> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +- size: size of the connector, should be specified in case of
> +  non-standard USB connectors: "mini", "micro", "powered"

What does powered mean?

This is really "type" if you compare to HDMI.

> +
> +Required nodes:
> +- any data bus to the connector should be modeled using the
> +  OF graph bindings specified in bindings/graph.txt.
> +  There should be exactly one port with at least one endpoint to
> +  different device nodes. The first endpoint (reg = <0>) should
> +  point to USB Interface Controller.
> +
> +Example
> +---
> +
> +musb_con: connector {
> + compatible = "samsung,usb-connector-11pin", "usb-connector";
> + label = "usb";

> + type = "b";
> + size = "micro";
> + max-mode = "hs";

These all are implied by "samsung,usb-connector-11pin".

> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + musb_con_usb_in: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_usb_out>;
> + };
> +
> + musb_con_mhl_in: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_out>;
> + };

I think this should be 2 ports, not 2 endpoints. Think of ports as 
different data streams and endpoints are either the same data stream 
muxed or fanned out depending on direction. Now for Type-C, 1 port for 
USB and alternate modes is probably correct.

Rob
--
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: renesas_usbhs: Add compatible string for r8a7743/5

[Yoshihiro Shimoda]

Hi Biju-san,
(+ Felipe-san)

Thank you for the patch!

> From: Biju Das, Sent: Friday, October 6, 2017 12:13 AM
> 
> This patch adds support for r8a7743/5 SoC.  The Renesas RZ/G1[ME]
> (R8A7743/5) usbhs is identical to the R-Car Gen2 family.
> 
> This doesn't change the driver, so it does nothing by itself.  But it does
> mean that checkpatch won't complain about a future patch that adds
> "renesas,usbhs-r8a7743" or "renesas,usbhs-r8a7745" to a DT, which helps
> ensure that shipped DTs use documented compatibility strings.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is tested against Linux next tag next-20170929
> 
>  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> index 9e18e00..479215b 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -3,6 +3,8 @@ Renesas Electronics USBHS driver
>  Required properties:
>- compatible: Must contain one or more of the following:
> 
> + - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device
> + - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device
>   - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
>   - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
>   - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
> @@ -10,7 +12,7 @@ Required properties:
>   - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
>   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
>   - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device
> - - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
> + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible device
>   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device

This will be conflict with my R-Car D3 support patch.
https://patchwork.kernel.org/patch/9982267/
The R-Car D3 patch is not applied into usb.git yet though...

Hi Felipe-san,

Could you resolve this conflict on your side?
Or, should this r8a7743/5 patch be rebased on the R-Car D3 patch?

When after resolved the conflict:

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

>   When compatible with the generic version, nodes must list the
> --
> 1.9.1

--
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 08/17] dt-bindings: phy-qcom-qusb2: Update binding for QUSB2 V2 version

[Rob Herring]

On Wed, Sep 27, 2017 at 02:29:04PM +0530, Manu Gautam wrote:
> Update generic compatible string for QUSB2 V2 PHY. This will allow
> all targets using QUSB2 V2 use same string.
> 
> Signed-off-by: Manu Gautam 
> ---
>  Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 
--
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: Issue with Gadget UVC and dummy_hcd

[David Tulloh]

On 6 October 2017 at 06:55, Alan Stern  wrote:
> David, please try the patch below.  It should fix this problem.  And I
> have no idea why I didn't encounter exactly the same recursive locking
> error in my own testing...

Thanks Alan, the patch works.

Is it still possible to go down the deadlocking path under other conditions?


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

Re: [PATCH 8/9] dt-bindings: usb: mtk-xhci: add a optional property to disable u3ports

[Rob Herring]

On Wed, Sep 27, 2017 at 05:23:04PM +0800, Chunfeng Yun wrote:
> Add a new optional property to disable u3ports
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mediatek,mtk-xhci.txt  |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt 
> b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> index 5611a2e..2d9b459 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> @@ -38,6 +38,8 @@ Optional properties:
>   mode;
>   - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
>   control register, it depends on "mediatek,wakeup-src".
> + - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> + bit1 for u3port1, ... etc;

I think you should have child nodes for ports and use "status" to 
disable them (or omit them). IIRC, the common USB bus binding already 
defines ports.

>   - vbus-supply : reference to the VBUS regulator;
>   - usb3-lpm-capable : supports USB3.0 LPM
>   - pinctrl-names : a pinctrl state named "default" must be defined
> -- 
> 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: [PATCH 9/9] dt-bindings: usb: mtk-xhci: remove dummy clocks and add optional ones

[Rob Herring]

On Wed, Sep 27, 2017 at 05:23:05PM +0800, Chunfeng Yun wrote:
> Remove dummy clocks for usb wakeup and add optional ones for
> MCU_BUS_CK and DMA_BUS_CK.
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mediatek,mtk-xhci.txt  |   18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)

Seems a bit suspicious and not a backwards compatible change, but only 
affects your platforms, so:

Acked-by: Rob Herring 
--
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 13/13] usb: host: xhci-plat: Use of_device_get_match_data() helper

[Mathias Nyman]

On 05.10.2017 16:00, Geert Uytterhoeven wrote:

Hi Greg,

On Thu, Oct 5, 2017 at 2:52 PM, Greg KH  wrote:

On Thu, Oct 05, 2017 at 11:21:49AM +0300, Mathias Nyman wrote:

From: Geert Uytterhoeven 

Use the of_device_get_match_data() helper instead of open coding.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mathias Nyman 
---
  drivers/usb/host/xhci-plat.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d0625fa..6804cd4 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -152,7 +153,7 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_match);

  static int xhci_plat_probe(struct platform_device *pdev)
  {
- const struct of_device_id *match;
+ const struct xhci_plat_priv *priv_match;
   const struct hc_driver  *driver;
   struct device   *sysdev;
   struct xhci_hcd *xhci;
@@ -238,9 +239,8 @@ static int xhci_plat_probe(struct platform_device *pdev)
   }

   xhci = hcd_to_xhci(hcd);
- match = of_match_node(usb_xhci_of_match, pdev->dev.of_node);
- if (match) {
- const struct xhci_plat_priv *priv_match = match->data;
+ priv_match = of_device_get_match_data(>dev);
+ if (priv_match) {
   struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);

   /* Just copy data for now */


kbuild just spit out the following warning for this patch:

drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702

Error ids grouped by kconfigs:

recent_errors
└── i386-allmodconfig
 └── drivers-usb-host-max3421-hcd.c:preceding-lock-on-line



I don't really know what it means, any ideas?


Me neither.

I find it hard to believe this was caused by my patch, as it doesn't change
locking behavior (of_match_node() takes a lock, but of_device_get_match_data()
calls into of_match_node(), too).

This report seems like a summary report from kbuild?
Where is the report about this particular failure?
Google found a similar warning in
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1205736.html
showing more context. Where's the context?

Finally, which version of drivers/usb/host/max3421-hcd.c in which tree
was used? There's no locking at line 1707 or 1702 in my copy...



Looking at the usb-testing branch it takes a lock at 1702 in max3421-hcd.c
and returns without releasing it at 1707.

Must be some other patch causing this

spin_lock_irqsave(_hcd->lock, flags);

pdata = spi->dev.platform_data;
if (!pdata) {
dev_err(>dev, "Device platform data is missing\n");
return -EFAULT;
}

-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

[PATCHv3 0/2] dwc3 on XU3

[Andrzej Pietrasiewicz]

Hi all,

This is the third version of patches in this thread.

The series fixes problems with enumerating of SuperSpeed devices
on an Odroid XU3. There was a patch series from Vivek Gautam in
circulation, but it got lost somehow. Please see:

https://lkml.org/lkml/2014/9/2/166
https://lkml.org/lkml/2015/2/2/257

I adapted his patch so that it does not use a hacky solution to force
additional initialization in order for calibration to happen.
With this patch enumeration happens correctly and a super speed device
is recognized as such.

Changes since v2:

- exported the "calibrate_phy" symbol

Changes since v1:

- added calibrate() callback to phy
- used calibrate() instead of reset() to trigger the calibration


Andrzej Pietrasiewicz (1):
  drivers: phy: add calibrate method

Vivek Gautam (1):
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-core.c   |  15 +++
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++
 drivers/usb/dwc3/core.c  |   7 +-
 include/linux/phy/phy.h  |  10 ++
 4 files changed, 213 insertions(+), 2 deletions(-)

-- 
1.9.1

--
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: [PATCHv3 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Sylwester Nawrocki]

On 10/05/2017 02:11 PM, Andrzej Pietrasiewicz wrote:
> +static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
> + u32 val, u32 cmd)
> +{
> + u32 usec = 100;
> + unsigned int result;
> +
> + writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> +
> + do {
> + result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> + if (result & PHYREG1_CR_ACK)
> + break;
> +
> + udelay(1);
> + } while (usec-- > 0);

It looks like you could use readl_poll_timeout_atomic() macro 
instead of these polling loops.

-- 
Regards,
Sylwester
--
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 13/13] usb: host: xhci-plat: Use of_device_get_match_data() helper

[Mathias Nyman]

On 05.10.2017 16:59, Mathias Nyman wrote:

On 05.10.2017 16:00, Geert Uytterhoeven wrote:

Hi Greg,

On Thu, Oct 5, 2017 at 2:52 PM, Greg KH  wrote:

On Thu, Oct 05, 2017 at 11:21:49AM +0300, Mathias Nyman wrote:

From: Geert Uytterhoeven 

Use the of_device_get_match_data() helper instead of open coding.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mathias Nyman 
---
  drivers/usb/host/xhci-plat.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d0625fa..6804cd4 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -152,7 +153,7 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_match);

  static int xhci_plat_probe(struct platform_device *pdev)
  {
- const struct of_device_id *match;
+ const struct xhci_plat_priv *priv_match;
   const struct hc_driver  *driver;
   struct device   *sysdev;
   struct xhci_hcd *xhci;
@@ -238,9 +239,8 @@ static int xhci_plat_probe(struct platform_device *pdev)
   }

   xhci = hcd_to_xhci(hcd);
- match = of_match_node(usb_xhci_of_match, pdev->dev.of_node);
- if (match) {
- const struct xhci_plat_priv *priv_match = match->data;
+ priv_match = of_device_get_match_data(>dev);
+ if (priv_match) {
   struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);

   /* Just copy data for now */


kbuild just spit out the following warning for this patch:

drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702

Error ids grouped by kconfigs:

recent_errors
└── i386-allmodconfig
 └── drivers-usb-host-max3421-hcd.c:preceding-lock-on-line



I don't really know what it means, any ideas?


Me neither.

I find it hard to believe this was caused by my patch, as it doesn't change
locking behavior (of_match_node() takes a lock, but of_device_get_match_data()
calls into of_match_node(), too).

This report seems like a summary report from kbuild?
Where is the report about this particular failure?
Google found a similar warning in
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1205736.html
showing more context. Where's the context?

Finally, which version of drivers/usb/host/max3421-hcd.c in which tree
was used? There's no locking at line 1707 or 1702 in my copy...



Looking at the usb-testing branch it takes a lock at 1702 in max3421-hcd.c
and returns without releasing it at 1707.

Must be some other patch causing this



It's commit 721fdc83b31b1b22c34b2d77304890877c624c6b
usb: max3421: Add devicetree support

returns without releasing the lock

-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

[PATCHv3 1/2] drivers: phy: add calibrate method

[Andrzej Pietrasiewicz]

Some quirky UDCs (like dwc3 on exynos) need to have heir phys calibrated
e.g. for using super speed.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/phy/phy-core.c  | 15 +++
 include/linux/phy/phy.h | 10 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index a268f4d..b4964b0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -372,6 +372,21 @@ int phy_reset(struct phy *phy)
 }
 EXPORT_SYMBOL_GPL(phy_reset);
 
+int phy_calibrate(struct phy *phy)
+{
+   int ret;
+
+   if (!phy || !phy->ops->calibrate)
+   return 0;
+
+   mutex_lock(>mutex);
+   ret = phy->ops->calibrate(phy);
+   mutex_unlock(>mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_calibrate);
+
 /**
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @np: device_node for which to get the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e694d40..87580c8 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -39,6 +39,7 @@ enum phy_mode {
  * @power_off: powering off the phy
  * @set_mode: set the mode of the phy
  * @reset: resetting the phy
+ * @calibrate: calibrate the phy
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -48,6 +49,7 @@ struct phy_ops {
int (*power_off)(struct phy *phy);
int (*set_mode)(struct phy *phy, enum phy_mode mode);
int (*reset)(struct phy *phy);
+   int (*calibrate)(struct phy *phy);
struct module *owner;
 };
 
@@ -141,6 +143,7 @@ static inline void *phy_get_drvdata(struct phy *phy)
 int phy_power_off(struct phy *phy);
 int phy_set_mode(struct phy *phy, enum phy_mode mode);
 int phy_reset(struct phy *phy);
+int phy_calibrate(struct phy *phy);
 static inline int phy_get_bus_width(struct phy *phy)
 {
return phy->attrs.bus_width;
@@ -262,6 +265,13 @@ static inline int phy_reset(struct phy *phy)
return -ENOSYS;
 }
 
+static inline int phy_calibrate(struct phy *phy)
+{
+   if (!phy)
+   return 0;
+   return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
return -ENOSYS;
-- 
1.9.1

--
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

[PATCHv3 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Andrzej Pietrasiewicz]

From: Vivek Gautam 

Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz.
the Loss-of-Signal (LOS) Detector Threshold Level, as well as
Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.

We are using CR_port for this purpose to send required data
to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by: Vivek Gautam 
[adapted to use phy_calibrate as entry point]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++
 drivers/usb/dwc3/core.c  |   7 +-
 2 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c 
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 22c68f5..9e83c15 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -90,7 +90,17 @@
 #define PHYCLKRST_COMMONONNBIT(0)
 
 #define EXYNOS5_DRD_PHYREG00x14
+#define PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define PHYREG0_SSC_RANGE  BIT(20)
+#define PHYREG0_CR_WRITE   BIT(19)
+#define PHYREG0_CR_READBIT(18)
+#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
+#define PHYREG0_CR_CAP_DATABIT(1)
+#define PHYREG0_CR_CAP_ADDRBIT(0)
+
 #define EXYNOS5_DRD_PHYREG10x18
+#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1)
+#define PHYREG1_CR_ACK BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0  0x1c
 
@@ -119,6 +129,25 @@
 #define EXYNOS5_DRD_PHYRESUME  0x34
 #define EXYNOS5_DRD_LINKPORT   0x44
 
+/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
+#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN (0x15)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420 (0x5 << 13)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT  (0x0 << 13)
+#define LOSLEVEL_OVRD_IN_EN(0x1 << 10)
+#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT (0x9 << 0)
+
+#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN   (0x12)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420 (0x5 << 13)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT  (0x4 << 13)
+
+#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG   (0x1010)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M(0x4 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M (0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M(0x40 << 4)
+
 #define KHZ1000
 #define MHZ(KHZ * KHZ)
 
@@ -527,6 +556,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
return 0;
 }
 
+static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+   u32 val, u32 cmd)
+{
+   u32 usec = 100;
+   unsigned int result;
+
+   writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (result & PHYREG1_CR_ACK)
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec) {
+   dev_err(phy_drd->dev,
+   "CRPORT handshake timeout1 (0x%08x)\n", val);
+   return -ETIME;
+   }
+
+   usec = 100;
+
+   writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (!(result & PHYREG1_CR_ACK))
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec) {
+   dev_err(phy_drd->dev,
+   "CRPORT handshake timeout2 (0x%08x)\n", val);
+   return -ETIME;
+   }
+
+   return 0;
+}
+
+static int crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
+   u32 addr, u32 

Re: [PATCH 13/13] usb: host: xhci-plat: Use of_device_get_match_data() helper

[Greg KH]

On Thu, Oct 05, 2017 at 11:21:49AM +0300, Mathias Nyman wrote:
> From: Geert Uytterhoeven 
> 
> Use the of_device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Geert Uytterhoeven 
> Signed-off-by: Mathias Nyman 
> ---
>  drivers/usb/host/xhci-plat.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index d0625fa..6804cd4 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -152,7 +153,7 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
>  
>  static int xhci_plat_probe(struct platform_device *pdev)
>  {
> - const struct of_device_id *match;
> + const struct xhci_plat_priv *priv_match;
>   const struct hc_driver  *driver;
>   struct device   *sysdev;
>   struct xhci_hcd *xhci;
> @@ -238,9 +239,8 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   }
>  
>   xhci = hcd_to_xhci(hcd);
> - match = of_match_node(usb_xhci_of_match, pdev->dev.of_node);
> - if (match) {
> - const struct xhci_plat_priv *priv_match = match->data;
> + priv_match = of_device_get_match_data(>dev);
> + if (priv_match) {
>   struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
>  
>   /* Just copy data for now */

kbuild just spit out the following warning for this patch:

drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702

Error ids grouped by kconfigs:

recent_errors
└── i386-allmodconfig
└── drivers-usb-host-max3421-hcd.c:preceding-lock-on-line



I don't really know what it means, any ideas?

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 v3 07/14] xhci: Add Intel cherrytrail extended cap / otg phy mux handling

[Mathias Nyman]

On 22.09.2017 21:37, Hans de Goede wrote:

The Intel cherrytrail xhci controller has an extended cap mmio-range
which contains registers to control the muxing to the xhci (host mode)
or the dwc3 (device mode) and vbus-detection for the otg usb-phy.

Having a mux driver included in the xhci code (or under drivers/usb/host)
is not desirable. So this commit adds a simple handler for this extended
capability, which creates a platform device with the caps mmio region as
resource, this allows us to write a separate platform mux driver for the
mux.

Note this commit adds a call to the new xhci_ext_cap_init() function
to xhci_pci_probe(), it is added here because xhci_ext_cap_init() must
be called only once. If in the future we also want to handle ext-caps
on non pci XHCI HCDs from xhci_ext_cap_init() a call to it should also
be added to other bus probe paths.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Check xHCI controller PCI device-id instead of only checking for the
  Intel Extended capability ID, as the Extended capability ID is used on
  other model Intel xHCI controllers too

Changes in v3:
-Add a new generic xhci_ext_cap_init() function and handle the new
  XHCI_INTEL_CHT_USB_MUX quirk there.
---


Acked-by: Mathias Nyman 

--
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 13/13] usb: host: xhci-plat: Use of_device_get_match_data() helper

[Geert Uytterhoeven]

Hi Greg,

On Thu, Oct 5, 2017 at 2:52 PM, Greg KH  wrote:
> On Thu, Oct 05, 2017 at 11:21:49AM +0300, Mathias Nyman wrote:
>> From: Geert Uytterhoeven 
>>
>> Use the of_device_get_match_data() helper instead of open coding.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> Signed-off-by: Mathias Nyman 
>> ---
>>  drivers/usb/host/xhci-plat.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index d0625fa..6804cd4 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -152,7 +153,7 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
>>
>>  static int xhci_plat_probe(struct platform_device *pdev)
>>  {
>> - const struct of_device_id *match;
>> + const struct xhci_plat_priv *priv_match;
>>   const struct hc_driver  *driver;
>>   struct device   *sysdev;
>>   struct xhci_hcd *xhci;
>> @@ -238,9 +239,8 @@ static int xhci_plat_probe(struct platform_device *pdev)
>>   }
>>
>>   xhci = hcd_to_xhci(hcd);
>> - match = of_match_node(usb_xhci_of_match, pdev->dev.of_node);
>> - if (match) {
>> - const struct xhci_plat_priv *priv_match = match->data;
>> + priv_match = of_device_get_match_data(>dev);
>> + if (priv_match) {
>>   struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
>>
>>   /* Just copy data for now */
>
> kbuild just spit out the following warning for this patch:
>
> drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702
>
> Error ids grouped by kconfigs:
>
> recent_errors
> └── i386-allmodconfig
> └── drivers-usb-host-max3421-hcd.c:preceding-lock-on-line
>
>
>
> I don't really know what it means, any ideas?

Me neither.

I find it hard to believe this was caused by my patch, as it doesn't change
locking behavior (of_match_node() takes a lock, but of_device_get_match_data()
calls into of_match_node(), too).

This report seems like a summary report from kbuild?
Where is the report about this particular failure?
Google found a similar warning in
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1205736.html
showing more context. Where's the context?

Finally, which version of drivers/usb/host/max3421-hcd.c in which tree
was used? There's no locking at line 1707 or 1702 in my copy...

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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

[usb:usb-testing 9/39] drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702 (fwd)

[Julia Lawall]

It looks like an unlock is needed before line 1707.

julia

-- Forwarded message --
Date: Thu, 5 Oct 2017 19:35:31 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: [usb:usb-testing 9/39] drivers/usb/host/max3421-hcd.c:1707:2-8:
preceding lock on line 1702

CC: kbuild-...@01.org
CC: linux-usb@vger.kernel.org
TO: Jules Maselbas 
CC: "Greg Kroah-Hartman" 

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
head:   2847d242a1e48ca734cee742efa0f70abf545d1e
commit: 721fdc83b31b1b22c34b2d77304890877c624c6b [9/39] usb: max3421: Add 
devicetree support
:: branch date: 3 hours ago
:: commit date: 28 hours ago

>> drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702

# 
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?id=721fdc83b31b1b22c34b2d77304890877c624c6b
git remote add usb 
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
git remote update usb
git checkout 721fdc83b31b1b22c34b2d77304890877c624c6b
vim +1707 drivers/usb/host/max3421-hcd.c

2d53139f David Mosberger  2014-04-28  1691
2d53139f David Mosberger  2014-04-28  1692  static int
2d53139f David Mosberger  2014-04-28  1693  max3421_hub_control(struct 
usb_hcd *hcd, u16 type_req, u16 value, u16 index,
2d53139f David Mosberger  2014-04-28  1694  char *buf, 
u16 length)
2d53139f David Mosberger  2014-04-28  1695  {
2d53139f David Mosberger  2014-04-28  1696  struct spi_device *spi 
= to_spi_device(hcd->self.controller);
2d53139f David Mosberger  2014-04-28  1697  struct max3421_hcd 
*max3421_hcd = hcd_to_max3421(hcd);
2d53139f David Mosberger  2014-04-28  1698  struct 
max3421_hcd_platform_data *pdata;
2d53139f David Mosberger  2014-04-28  1699  unsigned long flags;
2d53139f David Mosberger  2014-04-28  1700  int retval = 0;
2d53139f David Mosberger  2014-04-28  1701
2d53139f David Mosberger  2014-04-28 @1702  
spin_lock_irqsave(_hcd->lock, flags);
2d53139f David Mosberger  2014-04-28  1703
2d53139f David Mosberger  2014-04-28  1704  pdata = 
spi->dev.platform_data;
721fdc83 Jules Maselbas   2017-09-15  1705  if (!pdata) {
721fdc83 Jules Maselbas   2017-09-15  1706  
dev_err(>dev, "Device platform data is missing\n");
721fdc83 Jules Maselbas   2017-09-15 @1707  return -EFAULT;
721fdc83 Jules Maselbas   2017-09-15  1708  }
2d53139f David Mosberger  2014-04-28  1709
2d53139f David Mosberger  2014-04-28  1710  switch (type_req) {
2d53139f David Mosberger  2014-04-28  1711  case ClearHubFeature:
2d53139f David Mosberger  2014-04-28  1712  break;
2d53139f David Mosberger  2014-04-28  1713  case ClearPortFeature:
2d53139f David Mosberger  2014-04-28  1714  switch (value) {
2d53139f David Mosberger  2014-04-28  1715  case 
USB_PORT_FEAT_SUSPEND:
2d53139f David Mosberger  2014-04-28  1716  break;
2d53139f David Mosberger  2014-04-28  1717  case 
USB_PORT_FEAT_POWER:
2d53139f David Mosberger  2014-04-28  1718  
dev_dbg(hcd->self.controller, "power-off\n");
4055e5e5 David Mosberger-Tang 2014-05-29  1719  
max3421_gpout_set_value(hcd, pdata->vbus_gpout,
4055e5e5 David Mosberger-Tang 2014-05-29  1720  
!pdata->vbus_active_level);
2d53139f David Mosberger  2014-04-28  1721  /* 
FALLS THROUGH */
2d53139f David Mosberger  2014-04-28  1722  default:
2d53139f David Mosberger  2014-04-28  1723  
max3421_hcd->port_status &= ~(1 << value);
2d53139f David Mosberger  2014-04-28  1724  }
2d53139f David Mosberger  2014-04-28  1725  break;
2d53139f David Mosberger  2014-04-28  1726  case GetHubDescriptor:
2d53139f David Mosberger  2014-04-28  1727  
hub_descriptor((struct usb_hub_descriptor *) buf);
2d53139f David Mosberger  2014-04-28  1728  break;
2d53139f David Mosberger  2014-04-28  1729
2d53139f David Mosberger  2014-04-28  1730  case DeviceRequest | 
USB_REQ_GET_DESCRIPTOR:
2d53139f David Mosberger  2014-04-28  1731  case GetPortErrorCount:
2d53139f David Mosberger  2014-04-28  1732  case SetHubDepth:
2d53139f David Mosberger  2014-04-28  1733  /* USB3 only */
2d53139f David Mosberger  2014-04-28  1734  goto error;
2d53139f David Mosberger  2014-04-28  1735
2d53139f David Mosberger  2014-04-28  1736  case GetHubStatus:
2d53139f David 

Re: [PATCH v2 0/2] USB: musb: PM fixes

[Johan Hovold]

On Thu, Oct 05, 2017 at 08:11:55AM -0700, Tony Lindgren wrote:
> * Johan Hovold  [171005 02:15]:
> > On Thu, Sep 07, 2017 at 03:37:46PM +0200, Johan Hovold wrote:
> > > These patches fix a couple of bugs introduced by the recent runtime-PM
> > > work (details in the individual commit messages).
> > > 
> > > Note that the external abort was due to the irq work never being flushed
> > > on suspend, and that we may need similar fixes for the delayed reset and
> > > resume work which are likewise never cancelled on suspend.
> > > 
> > > As I just mentioned in the v1 thread, there are a number of further 
> > > issues with
> > > musb suspend (e.g. on BBB):
> > > 
> > >  1. System suspend appears to break any active gadget (which then can be
> > > restarted manually).
> > > 
> > >  2. The early_tx polling in musb_cppi41 lacks a timeout, something which 
> > > can
> > > lead to the hrtimer rescheduling itself indefinitely if the fifo never
> > > empties (e.g. if a transfer is is initiated post suspend due to issue 
> > > 1).
> > > 
> > > See commit a655f481d83d ("usb: musb: musb_cppi41: handle pre-mature TX
> > > complete interrupt").
> > > 
> > >  3. In host mode, if a device is disconnected while the system is 
> > > suspended,
> > > this will keep the controller runtime active after resume as the 
> > > session
> > > bit is always set.
> > 
> > Bin and Tony, any comments to this series?
> 
> Oops sorry I forgot to test these after two recent conferences. I just gave
> these a try and they both behave for me. Nice fixes, for both:
> 
> Tested-by: Tony Lindgren 

Great, thanks for testing!

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 02/13] xhci: add port speed ID to portsc tracing

[David Laight]

From: Mathias Nyman
> Sent: 05 October 2017 09:22
> Shows the port speed protocol speed ID (PSID) in use.
> speed ID may map to custom speeds, but in most cases it uses default
> 
> 1 = Full-Speed12 MB/s
> 2 = Low-Speed 1.5 Mb/s
> 3 = High-speed480 Mb/s
> 4 = SuperSpeed5 Gb/s
> 5 = SuperSpeedPlus10 Gb/s
> 
> Signed-off-by: Mathias Nyman 
> ---
>  drivers/usb/host/xhci.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index dc22392..ea176da 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -2441,11 +2441,12 @@ static inline const char *xhci_decode_portsc(u32 
> portsc)
>   static char str[256];
>   int ret;
> 
> - ret = sprintf(str, "%s %s %s Link:%s ",
> + ret = sprintf(str, "%s %s %s Link:%s PortSpeed:%d ",

Shouldn't that be an snprintf() ?

I'm not sure adding "1" to "5" here is entirely useful.
It would be better is a string could be returned containing the actual speed
ie "480Mb/s" etc.

> portsc & PORT_POWER   ? "Powered" : "Powered-off",
> portsc & PORT_CONNECT ? "Connected" : "Not-connected",
> portsc & PORT_PE  ? "Enabled" : "Disabled",
> -   xhci_portsc_link_state_string(portsc));
> +   xhci_portsc_link_state_string(portsc),
> +   DEV_PORT_SPEED(portsc));
> 
>   if (portsc & PORT_OC)
>   ret += sprintf(str + ret, "OverCurrent ");

The s(n)printf() above better not have overflowed the buffer...

David

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

Re: [PATCH v2 0/2] USB: musb: PM fixes

[Tony Lindgren]

* Johan Hovold  [171005 02:15]:
> On Thu, Sep 07, 2017 at 03:37:46PM +0200, Johan Hovold wrote:
> > These patches fix a couple of bugs introduced by the recent runtime-PM
> > work (details in the individual commit messages).
> > 
> > Note that the external abort was due to the irq work never being flushed
> > on suspend, and that we may need similar fixes for the delayed reset and
> > resume work which are likewise never cancelled on suspend.
> > 
> > As I just mentioned in the v1 thread, there are a number of further issues 
> > with
> > musb suspend (e.g. on BBB):
> > 
> >  1. System suspend appears to break any active gadget (which then can be
> > restarted manually).
> > 
> >  2. The early_tx polling in musb_cppi41 lacks a timeout, something which can
> > lead to the hrtimer rescheduling itself indefinitely if the fifo never
> > empties (e.g. if a transfer is is initiated post suspend due to issue 
> > 1).
> > 
> > See commit a655f481d83d ("usb: musb: musb_cppi41: handle pre-mature TX
> > complete interrupt").
> > 
> >  3. In host mode, if a device is disconnected while the system is suspended,
> > this will keep the controller runtime active after resume as the session
> > bit is always set.
> 
> Bin and Tony, any comments to this series?

Oops sorry I forgot to test these after two recent conferences. I just gave
these a try and they both behave for me. Nice fixes, for both:

Tested-by: Tony Lindgren 
--
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: renesas_usbhs: Add compatible string for r8a7743/5

[Biju Das]

This patch adds support for r8a7743/5 SoC.  The Renesas RZ/G1[ME]
(R8A7743/5) usbhs is identical to the R-Car Gen2 family.

This doesn't change the driver, so it does nothing by itself.  But it does
mean that checkpatch won't complain about a future patch that adds
"renesas,usbhs-r8a7743" or "renesas,usbhs-r8a7745" to a DT, which helps
ensure that shipped DTs use documented compatibility strings.

Signed-off-by: Biju Das 
---
This patch is tested against Linux next tag next-20170929

 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 9e18e00..479215b 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -3,6 +3,8 @@ Renesas Electronics USBHS driver
 Required properties:
   - compatible: Must contain one or more of the following:
 
+   - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device
+   - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
@@ -10,7 +12,7 @@ Required properties:
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
- "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device
-   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible device
- "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
 
When compatible with the generic version, nodes must list the
-- 
1.9.1

--
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 13/13] usb: host: xhci-plat: Use of_device_get_match_data() helper

[Greg KH]

On Thu, Oct 05, 2017 at 05:03:36PM +0300, Mathias Nyman wrote:
> On 05.10.2017 16:59, Mathias Nyman wrote:
> > On 05.10.2017 16:00, Geert Uytterhoeven wrote:
> > > Hi Greg,
> > > 
> > > On Thu, Oct 5, 2017 at 2:52 PM, Greg KH  
> > > wrote:
> > > > On Thu, Oct 05, 2017 at 11:21:49AM +0300, Mathias Nyman wrote:
> > > > > From: Geert Uytterhoeven 
> > > > > 
> > > > > Use the of_device_get_match_data() helper instead of open coding.
> > > > > 
> > > > > Signed-off-by: Geert Uytterhoeven 
> > > > > Signed-off-by: Mathias Nyman 
> > > > > ---
> > > > >   drivers/usb/host/xhci-plat.c | 8 
> > > > >   1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/usb/host/xhci-plat.c 
> > > > > b/drivers/usb/host/xhci-plat.c
> > > > > index d0625fa..6804cd4 100644
> > > > > --- a/drivers/usb/host/xhci-plat.c
> > > > > +++ b/drivers/usb/host/xhci-plat.c
> > > > > @@ -16,6 +16,7 @@
> > > > >   #include 
> > > > >   #include 
> > > > >   #include 
> > > > > +#include 
> > > > >   #include 
> > > > >   #include 
> > > > >   #include 
> > > > > @@ -152,7 +153,7 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
> > > > > 
> > > > >   static int xhci_plat_probe(struct platform_device *pdev)
> > > > >   {
> > > > > - const struct of_device_id *match;
> > > > > + const struct xhci_plat_priv *priv_match;
> > > > >const struct hc_driver  *driver;
> > > > >struct device   *sysdev;
> > > > >struct xhci_hcd *xhci;
> > > > > @@ -238,9 +239,8 @@ static int xhci_plat_probe(struct platform_device 
> > > > > *pdev)
> > > > >}
> > > > > 
> > > > >xhci = hcd_to_xhci(hcd);
> > > > > - match = of_match_node(usb_xhci_of_match, pdev->dev.of_node);
> > > > > - if (match) {
> > > > > - const struct xhci_plat_priv *priv_match = match->data;
> > > > > + priv_match = of_device_get_match_data(>dev);
> > > > > + if (priv_match) {
> > > > >struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> > > > > 
> > > > >/* Just copy data for now */
> > > > 
> > > > kbuild just spit out the following warning for this patch:
> > > > 
> > > > drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702
> > > > 
> > > > Error ids grouped by kconfigs:
> > > > 
> > > > recent_errors
> > > > └── i386-allmodconfig
> > > >  └── drivers-usb-host-max3421-hcd.c:preceding-lock-on-line
> > > > 
> > > > 
> > > > 
> > > > I don't really know what it means, any ideas?
> > > 
> > > Me neither.
> > > 
> > > I find it hard to believe this was caused by my patch, as it doesn't 
> > > change
> > > locking behavior (of_match_node() takes a lock, but 
> > > of_device_get_match_data()
> > > calls into of_match_node(), too).
> > > 
> > > This report seems like a summary report from kbuild?
> > > Where is the report about this particular failure?
> > > Google found a similar warning in
> > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1205736.html
> > > showing more context. Where's the context?
> > > 
> > > Finally, which version of drivers/usb/host/max3421-hcd.c in which tree
> > > was used? There's no locking at line 1707 or 1702 in my copy...
> > > 
> > 
> > Looking at the usb-testing branch it takes a lock at 1702 in max3421-hcd.c
> > and returns without releasing it at 1707.
> > 
> > Must be some other patch causing this
> > 
> 
> It's commit 721fdc83b31b1b22c34b2d77304890877c624c6b
> usb: max3421: Add devicetree support
> 
> returns without releasing the lock

Ah, nice digging.  Ok, this wasn't due to this patch, I'll merge this
into my usb-next branch and then go poke the author of that patch to fix
it :)

thanks,

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

Re: [PATCH 10/12] dt-bindings: usb: mtu3: add a optional property to disable u3ports

[Rob Herring]

On Thu, Sep 28, 2017 at 08:17:18AM +0800, Chunfeng Yun wrote:
> Add a new optional property to disable u3ports
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mediatek,mtu3.txt  |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt 
> b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> index 49f5476..7c611d1 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> @@ -44,6 +44,8 @@ Optional properties:
>   - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
>   - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
>   control register, it depends on "mediatek,enable-wakeup".
> + - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> + bit1 for u3port1, ... etc;

How does this relate to the XHCI change? Same comment applies.
--
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: the imfamous asix ax88179 iommu error

[Will Trives]

Hello,

Just reporting that it looks like this patch may fix the error (so
people having issues with VIA controller hosts may also want to try it):

https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html

It appears that my ax88179 is working just fine now with the vendor
driver. So perhaps it's possible to revert the old commit in the linux
kernel and allow the use of scatter gather ? (perhaps for non-intel
hosts ? I'm not sure if this device is effected by intel xhci errata)

commit: e2ed511400d41e0d136089d5a55ceab57c6a2426

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2ed511400d41e0d136089d5a55ceab57c6a2426


ethtool -k enp2s0u1u4
Features for enp2s0u1u4:
Cannot get device udp-fragmentation-offload settings: Operation not supported
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]


Regards,


Will 

On Fri, 29 Sep 2017 09:58:07 +1000
Will Trives  wrote:

> Hello,
> 
> I just saw a post about VIA controllers triggering IOMMU errors.
> 
> 
> Just want to also point out that the ax88179 will also trigger PTE
> read errors when using the vendor's driver.
> 
> I'm nowhere near an expert but I remember seeing that 'TD fragment' is
> supported now or some such, which I take to mean that sg/tso should be
> supported with usbnet ?
> 
> I'm unclear on whether it can ever work with intel hosts because of an
> errata ?
> 
> Anyway for anyone that wants to see the error you can grab the vendor
> driver:
> 
> http://www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE.tar.bz2
> 
> 
> This driver was working recently-ish perhaps around the same time the
> VIA controllers starting having iommu issues.
> 
> 
> Regards,
> 
> 
> Will
> 
> 

--
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: the imfamous asix ax88179 iommu error

[Will Trives]

sorry, I mean this commit:

commit  469d417b68958a064c09e7875646c97c6e783dfc

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=469d417b68958a064c09e7875646c97c6e783dfc
--
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: the imfamous asix ax88179 iommu error

[Greg KH]

On Fri, Oct 06, 2017 at 11:29:19AM +1100, Will Trives wrote:
> sorry, I mean this commit:
> 
> commit469d417b68958a064c09e7875646c97c6e783dfc
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=469d417b68958a064c09e7875646c97c6e783dfc

revert the revert?

Please just send a patch, that makes things much easier to understand...

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 00/18] use ARRAY_SIZE macro

[J. Bruce Fields]

On Mon, Oct 02, 2017 at 09:33:12PM -0400, Jérémy Lefaure wrote:
> On Mon, 2 Oct 2017 15:22:24 -0400
> bfie...@fieldses.org (J. Bruce Fields) wrote:
> 
> > Mainly I'd just like to know which you're asking for.  Do you want me to
> > apply this, or to ACK it so someone else can?  If it's sent as a series
> > I tend to assume the latter.
> > 
> > But in this case I'm assuming it's the former, so I'll pick up the nfsd
> > one
> Could you to apply the NFSD patch ("nfsd: use ARRAY_SIZE") with the
> Reviewed-by: Jeff Layton ) tag please ?
> 
> This patch is an individual patch and it should not have been sent in a
> series (sorry about that).

Applying for 4.15, thanks.--b.
--
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: xhci: Handle error condition in xhci_stop_device()

[Jack Pham]

From: Mayank Rana 

xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Signed-off-by: Mayank Rana 
Signed-off-by: Jack Pham 
---
 drivers/usb/host/xhci-hub.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index ad89a6d..eed2f8b 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -411,14 +411,25 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
 GFP_NOWAIT);
if (!command) {
spin_unlock_irqrestore(>lock, flags);
-   xhci_free_command(xhci, cmd);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto cmd_cleanup;
+   }
+
+   ret = xhci_queue_stop_endpoint(xhci, command, slot_id,
+  i, suspend);
+   if (ret) {
+   spin_unlock_irqrestore(>lock, flags);
+   xhci_free_command(xhci, command);
+   goto cmd_cleanup;
}
-   xhci_queue_stop_endpoint(xhci, command, slot_id, i,
-suspend);
}
}
-   xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
+   ret = xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
+   if (ret) {
+   spin_unlock_irqrestore(>lock, flags);
+   goto cmd_cleanup;
+   }
+
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
 
@@ -430,6 +441,8 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
xhci_warn(xhci, "Timeout while waiting for stop endpoint 
command\n");
ret = -ETIME;
}
+
+cmd_cleanup:
xhci_free_command(xhci, cmd);
return ret;
 }
-- 
2.9.1.200.gb1ec08f

--
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: [usb:usb-testing 9/39] drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702 (fwd)

[Greg Kroah-Hartman]

On Thu, Oct 05, 2017 at 06:08:19PM +0200, Julia Lawall wrote:
> It looks like an unlock is needed before line 1707.
> 
> julia
> 
> -- Forwarded message --
> Date: Thu, 5 Oct 2017 19:35:31 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: [usb:usb-testing 9/39] drivers/usb/host/max3421-hcd.c:1707:2-8:
> preceding lock on line 1702
> 
> CC: kbuild-...@01.org
> CC: linux-usb@vger.kernel.org
> TO: Jules Maselbas 
> CC: "Greg Kroah-Hartman" 
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
> usb-testing
> head:   2847d242a1e48ca734cee742efa0f70abf545d1e
> commit: 721fdc83b31b1b22c34b2d77304890877c624c6b [9/39] usb: max3421: Add 
> devicetree support
> :: branch date: 3 hours ago
> :: commit date: 28 hours ago
> 
> >> drivers/usb/host/max3421-hcd.c:1707:2-8: preceding lock on line 1702
> 
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?id=721fdc83b31b1b22c34b2d77304890877c624c6b
> git remote add usb 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> git remote update usb
> git checkout 721fdc83b31b1b22c34b2d77304890877c624c6b
> vim +1707 drivers/usb/host/max3421-hcd.c
> 
> 2d53139f David Mosberger  2014-04-28  1691
> 2d53139f David Mosberger  2014-04-28  1692  static int
> 2d53139f David Mosberger  2014-04-28  1693  max3421_hub_control(struct 
> usb_hcd *hcd, u16 type_req, u16 value, u16 index,
> 2d53139f David Mosberger  2014-04-28  1694char *buf, 
> u16 length)
> 2d53139f David Mosberger  2014-04-28  1695  {
> 2d53139f David Mosberger  2014-04-28  1696struct spi_device *spi 
> = to_spi_device(hcd->self.controller);
> 2d53139f David Mosberger  2014-04-28  1697struct max3421_hcd 
> *max3421_hcd = hcd_to_max3421(hcd);
> 2d53139f David Mosberger  2014-04-28  1698struct 
> max3421_hcd_platform_data *pdata;
> 2d53139f David Mosberger  2014-04-28  1699unsigned long flags;
> 2d53139f David Mosberger  2014-04-28  1700int retval = 0;
> 2d53139f David Mosberger  2014-04-28  1701
> 2d53139f David Mosberger  2014-04-28 @1702
> spin_lock_irqsave(_hcd->lock, flags);
> 2d53139f David Mosberger  2014-04-28  1703
> 2d53139f David Mosberger  2014-04-28  1704pdata = 
> spi->dev.platform_data;
> 721fdc83 Jules Maselbas   2017-09-15  1705if (!pdata) {
> 721fdc83 Jules Maselbas   2017-09-15  1706
> dev_err(>dev, "Device platform data is missing\n");
> 721fdc83 Jules Maselbas   2017-09-15 @1707return -EFAULT;
> 721fdc83 Jules Maselbas   2017-09-15  1708}
> 2d53139f David Mosberger  2014-04-28  1709
> 2d53139f David Mosberger  2014-04-28  1710switch (type_req) {
> 2d53139f David Mosberger  2014-04-28  1711case ClearHubFeature:
> 2d53139f David Mosberger  2014-04-28  1712break;
> 2d53139f David Mosberger  2014-04-28  1713case ClearPortFeature:
> 2d53139f David Mosberger  2014-04-28  1714switch (value) {
> 2d53139f David Mosberger  2014-04-28  1715case 
> USB_PORT_FEAT_SUSPEND:
> 2d53139f David Mosberger  2014-04-28  1716break;
> 2d53139f David Mosberger  2014-04-28  1717case 
> USB_PORT_FEAT_POWER:
> 2d53139f David Mosberger  2014-04-28  1718
> dev_dbg(hcd->self.controller, "power-off\n");
> 4055e5e5 David Mosberger-Tang 2014-05-29  1719
> max3421_gpout_set_value(hcd, pdata->vbus_gpout,
> 4055e5e5 David Mosberger-Tang 2014-05-29  1720
> !pdata->vbus_active_level);
> 2d53139f David Mosberger  2014-04-28  1721/* 
> FALLS THROUGH */
> 2d53139f David Mosberger  2014-04-28  1722default:
> 2d53139f David Mosberger  2014-04-28  1723
> max3421_hcd->port_status &= ~(1 << value);
> 2d53139f David Mosberger  2014-04-28  1724}
> 2d53139f David Mosberger  2014-04-28  1725break;
> 2d53139f David Mosberger  2014-04-28  1726case GetHubDescriptor:
> 2d53139f David Mosberger  2014-04-28  1727
> hub_descriptor((struct usb_hub_descriptor *) buf);
> 2d53139f David Mosberger  2014-04-28  1728break;
> 2d53139f David Mosberger  2014-04-28  1729
> 2d53139f David Mosberger  2014-04-28  1730case DeviceRequest | 
> USB_REQ_GET_DESCRIPTOR:
> 2d53139f David Mosberger  2014-04-28  1731case GetPortErrorCount:
> 2d53139f David Mosberger  2014-04-28  1732case SetHubDepth:
> 2d53139f David Mosberger  2014-04-28  1733/* USB3 only */
> 2d53139f David Mosberger  

Re: [PATCH] usb: isp1301-omap: Convert timers to use timer_setup()

[Tony Lindgren]

* Kees Cook  [171004 17:57]:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: linux-usb@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: Thomas Gleixner 
> Signed-off-by: Kees Cook 
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.

Acked-by: Tony Lindgren 
--
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: Issue with Gadget UVC and dummy_hcd

[Alan Stern]

On Thu, 5 Oct 2017, David Tulloh wrote:

> Thanks Alan,
> 
> I was facing a different problem but your suggestion put me on the right path.
> 
> Sorry it took me so long to update the thread, it has taken me a while
> to get a basic understanding of the debugging tools and processes
> built into the kernel.
> 
> My issue was the rare beast, a consistently repeatable lock contention.
> The wonderful LOCK_DEP output summarises it better than I could.
> 
> Unfortunately I don't understand the locking requirements nearly well
> enough to craft a patch.
> 
> 
> Now I have solved this issue (turn off SMP) I'm looking forward to see
> if the isochronous problem bites me too.
> 
> 
> David
> 
> 
> [   88.361471] 
> [   88.362014] WARNING: possible recursive locking detected
> [   88.362580] 4.14.0-rc2+ #9 Not tainted
> [   88.363010] 
> [   88.363561] v4l_id/526 is trying to acquire lock:
> [   88.364062]  (&(>lock)->rlock){}, at:
> [] composite_disconnect+0x43/0x100 [libcomposite]
> [   88.365051]
> [   88.365051] but task is already holding lock:
> [   88.365826]  (&(>lock)->rlock){}, at:
> [] usb_function_deactivate+0x29/0x80 [libcomposite]
> [   88.366858]
> [   88.366858] other info that might help us debug this:
> [   88.368301]  Possible unsafe locking scenario:
> [   88.368301]
> [   88.369304]CPU0
> [   88.369701]
> [   88.370101]   lock(&(>lock)->rlock);
> [   88.370623]   lock(&(>lock)->rlock);
> [   88.371145]
> [   88.371145]  *** DEADLOCK ***
> [   88.371145]
> [   88.372211]  May be due to missing lock nesting notation
> [   88.372211]
> [   88.373191] 2 locks held by v4l_id/526:
> [   88.373715]  #0:  (&(>lock)->rlock){}, at:
> [] usb_function_deactivate+0x29/0x80 [libcomposite]
> [   88.374814]  #1:  (&(_hcd->dum->lock)->rlock){}, at:
> [] dummy_pullup+0x7d/0xf0 [dummy_hcd]
> [   88.376289]
> [   88.376289] stack backtrace:
> [   88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
> [   88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.10.2-1 04/01/2014
> [   88.379504] Call Trace:
> [   88.380019]  dump_stack+0x86/0xc7
> [   88.380605]  __lock_acquire+0x841/0x1120
> [   88.381252]  lock_acquire+0xd5/0x1c0
> [   88.381865]  ? composite_disconnect+0x43/0x100 [libcomposite]
> [   88.382668]  _raw_spin_lock_irqsave+0x40/0x54
> [   88.383357]  ? composite_disconnect+0x43/0x100 [libcomposite]
> [   88.384290]  composite_disconnect+0x43/0x100 [libcomposite]
> [   88.385490]  set_link_state+0x2d4/0x3c0 [dummy_hcd]
> [   88.386436]  dummy_pullup+0xa7/0xf0 [dummy_hcd]
> [   88.387195]  usb_gadget_disconnect+0xd8/0x160 [udc_core]
> [   88.387990]  usb_gadget_deactivate+0xd3/0x160 [udc_core]
> [   88.388793]  usb_function_deactivate+0x64/0x80 [libcomposite]
> [   88.389628]  uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]
> [   88.390445]  uvc_v4l2_release+0x33/0x90 [usb_f_uvc]

This looks like a bug in dummy-hcd.  It calls the gadget driver's
disconnect callback when the D+ pullup is turned off rather than when
Vbus power is turned off.

Felipe, can you confirm my understanding of how a UDC driver is 
supposed to behave?

David, please try the patch below.  It should fix this problem.  And I
have no idea why I didn't encounter exactly the same recursive locking
error in my own testing...

Alan Stern



Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
===
--- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
+++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
@@ -433,6 +433,7 @@ static void set_link_state_by_speed(stru
 static void set_link_state(struct dummy_hcd *dum_hcd)
 {
struct dummy *dum = dum_hcd->dum;
+   unsigned int power_bit;
 
dum_hcd->active = 0;
if (dum->pullup)
@@ -443,15 +444,17 @@ static void set_link_state(struct dummy_
return;
 
set_link_state_by_speed(dum_hcd);
+   power_bit = (dummy_hcd_to_hcd(dum_hcd)->speed == HCD_USB3 ?
+   USB_SS_PORT_STAT_POWER : USB_PORT_STAT_POWER);
 
if ((dum_hcd->port_status & USB_PORT_STAT_ENABLE) == 0 ||
 dum_hcd->active)
dum_hcd->resuming = 0;
 
/* Currently !connected or in reset */
-   if ((dum_hcd->port_status & USB_PORT_STAT_CONNECTION) == 0 ||
+   if ((dum_hcd->port_status & power_bit) == 0 ||
(dum_hcd->port_status & USB_PORT_STAT_RESET) != 0) {
-   unsigned disconnect = USB_PORT_STAT_CONNECTION &
+   unsigned disconnect = power_bit &
dum_hcd->old_status & (~dum_hcd->port_status);
unsigned reset = USB_PORT_STAT_RESET &
(~dum_hcd->old_status) & dum_hcd->port_status;

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to 

Re: [PATCH resend 02/12] usb: typec: add basic typec properties

[Rob Herring]

On Tue, Sep 26, 2017 at 12:05:13PM +0800, Li Jun wrote:
> port-type is required for any typec port; default-role is only required
> for drp; power source capable needs src-pdos; power sink capable needs
> snk-pdos, max-snk-mv, max-snk-ma, op-snk-mw.

"dt-bindings: usb: ..." for the subject prefix.

> 
> Signed-off-by: Li Jun 
> ---
>  Documentation/devicetree/bindings/usb/typec.txt | 46 
> +
>  1 file changed, 46 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/typec.txt 
> b/Documentation/devicetree/bindings/usb/typec.txt
> new file mode 100644
> index 000..36d4467
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/typec.txt
> @@ -0,0 +1,46 @@
> +Generic typec and power delivery properties
> +---

What node do these apply to? A type C connector node? The PD 
microcontroller?

I'm reluctant to accept just a random list of properties without a more 
complete Type-C binding which I'd expect to have a connector node, OF 
graph ports to connect to video outputs, connection to USB controller, 
and connection to the PD controller.

> +
> +Required properties:
> +- port-type:should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if drp, should be "sink" or "source".
> +- src-pdos: An array of u32 with each entry providing supported power
> +source data object(PDO), the detailed bit definitions of
> +PDO can be found in "Universal Serial Bus Power Delivery
> +Specification" chapter 6.4.1.2 Source_Capabilities Message,
> +the order of each entry(PDO) should follow the PD spec 
> chapter
> +6.4.1. Required only for power source and power dual role 
> with
> +power delivery support.
> +- snk-pdos: An array of u32 with each entry providing supported power
> +sink data object(PDO), the detailed bit definitions of PDO
> +can be found in "Universal Serial Bus Power Delivery
> +Specification" chapter 6.4.1.3 Sink Capabilities Message,
> +the order of each entry(PDO) should follow the PD spec 
> chapter
> +6.4.1. Required only for power sink and power dual role with
> +power delivery support.

> +- max-snk-mv:   The max voltage the sink can support in millivoltage, 
> required
> +only for power sink and power dual role with power delivery
> +support.
> +- max-snk-ma:   The max current the sink can support in milliampere, required
> +only for power sink and power dual role with power delivery
> +support.
> +- op-snk-mw:Sink required operating power in milliwatts, if source 
> offered
> +power is less then it, Capability Mismatch is set, required
> +only for power sink and power dual role with power delivery
> +support.

Use the standard unit suffixes as defined in property-units.txt

> +
> +Example:
> +
> +ptn5110@50 {
> + compatible = "usb,tcpci";
> + reg = <0x50>;
> + interrupt-parent = <>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> + port-type = "dual";
> + default-role = "sink";
> + src-pdos = <0x380190c8>;
> + snk-pdos = <0x380190c8 0x3802d0c8>;
> + max-snk-mv = <9000>;
> + max-snk-ma = <1000>;
> + op-snk-mw = <9000>;
> +};
> -- 
> 2.6.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 12/17] dt-bindings: phy-qcom-qmp: Update bindings for QMP V3 USB PHY

[Rob Herring]

On Wed, Sep 27, 2017 at 02:29:08PM +0530, Manu Gautam wrote:
> Update compatible string and clock names for QMP version V3
> USB PHY.
> 
> Signed-off-by: Manu Gautam 
> ---
>  Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
> b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> index b6a9f2b..dcf1b8f 100644
> --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> @@ -8,7 +8,8 @@ Required properties:
>   - compatible: compatible list, contains:
>  "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074
>  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
> -"qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
> +"qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
> +"qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy.

This is fine, but you will still need an SoC specific compatible in 
addition to this.

Acked-by: Rob Herring 

Rob
--
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