date:20170115

Re: [PATCH 2/2] usb: gadget: uac2: add req_number as parameter

2017-01-15 Thread Peter Chen

On Wed, Jan 04, 2017 at 10:19:23AM +0800, Peter Chen wrote:
> There are only two requests for uac2, it may not be enough at high
> loading system which usb interrupt handler can't be serviced on
> time, then the data will be lost since it is isoc transfer for audio.
> 
> In this patch, we introduce a parameter for the number for usb request,
> and the user can override it if current number for request is not enough
> for his/her use case.
> 
> Besides, update this parameter for legacy audio gadget and documentation.
> 
> Signed-off-by: Peter Chen 
> ---
>  Documentation/usb/gadget-testing.txt |  2 ++
>  drivers/usb/gadget/function/f_uac2.c | 39 
> +++-
>  drivers/usb/gadget/function/u_uac2.h |  2 ++
>  drivers/usb/gadget/legacy/audio.c|  1 +
>  4 files changed, 34 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/usb/gadget-testing.txt 
> b/Documentation/usb/gadget-testing.txt
> index 5819605..fb0cc4d 100644
> --- a/Documentation/usb/gadget-testing.txt
> +++ b/Documentation/usb/gadget-testing.txt
> @@ -632,6 +632,8 @@ The uac2 function provides these attributes in its 
> function directory:
>   p_chmask - playback channel mask
>   p_srate - playback sampling rate
>   p_ssize - playback sample size (bytes)
> + req_number - the number of pre-allocated request for both capture
> +  and playback
>  
>  The attributes have sane default values.
>  
> diff --git a/drivers/usb/gadget/function/f_uac2.c 
> b/drivers/usb/gadget/function/f_uac2.c
> index 3f4e478..f6a0d3a 100644
> --- a/drivers/usb/gadget/function/f_uac2.c
> +++ b/drivers/usb/gadget/function/f_uac2.c
> @@ -22,9 +22,6 @@
>  
>  #include "u_uac2.h"
>  
> -/* Keep everyone on toes */
> -#define USB_XFERS2
> -
>  /*
>   * The driver implements a simple UAC_2 topology.
>   * USB-OUT -> IT_1 -> OT_3 -> ALSA_Capture
> @@ -78,7 +75,7 @@ struct uac2_rtd_params {
>   size_t period_size;
>  
>   unsigned max_psize;
> - struct uac2_req ureq[USB_XFERS];
> + struct uac2_req *ureq;
>  
>   spinlock_t lock;
>  };
> @@ -269,6 +266,8 @@ static int
>  uac2_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
>  {
>   struct snd_uac2_chip *uac2 = snd_pcm_substream_chip(substream);
> + struct audio_dev *agdev = uac2_to_agdev(uac2);
> + struct f_uac2_opts *uac2_opts = agdev_to_uac2_opts(agdev);
>   struct uac2_rtd_params *prm;
>   unsigned long flags;
>   int err = 0;
> @@ -300,7 +299,7 @@ uac2_pcm_trigger(struct snd_pcm_substream *substream, int 
> cmd)
>  
>   /* Clear buffer after Play stops */
>   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK && !prm->ss)
> - memset(prm->rbuf, 0, prm->max_psize * USB_XFERS);
> + memset(prm->rbuf, 0, prm->max_psize * uac2_opts->req_number);
>  
>   return err;
>  }
> @@ -943,6 +942,8 @@ static inline void
>  free_ep(struct uac2_rtd_params *prm, struct usb_ep *ep)
>  {
>   struct snd_uac2_chip *uac2 = prm->uac2;
> + struct audio_dev *agdev = uac2_to_agdev(uac2);
> + struct f_uac2_opts *uac2_opts = agdev_to_uac2_opts(agdev);
>   int i;
>  
>   if (!prm->ep_enabled)
> @@ -950,7 +951,7 @@ free_ep(struct uac2_rtd_params *prm, struct usb_ep *ep)
>  
>   prm->ep_enabled = false;
>  
> - for (i = 0; i < USB_XFERS; i++) {
> + for (i = 0; i < uac2_opts->req_number; i++) {
>   if (prm->ureq[i].req) {
>   usb_ep_dequeue(ep, prm->ureq[i].req);
>   usb_ep_free_request(ep, prm->ureq[i].req);
> @@ -1095,7 +1096,13 @@ afunc_bind(struct usb_configuration *cfg, struct 
> usb_function *fn)
>  
>   prm = &agdev->uac2.c_prm;
>   prm->max_psize = hs_epout_desc.wMaxPacketSize;
> - prm->rbuf = kzalloc(prm->max_psize * USB_XFERS, GFP_KERNEL);
> + prm->ureq = kcalloc(uac2_opts->req_number, sizeof(struct uac2_req),
> + GFP_KERNEL);
> + if (!prm->ureq) {
> + ret = -ENOMEM;
> + goto err_free_descs;
> + }
> + prm->rbuf = kcalloc(uac2_opts->req_number, prm->max_psize, GFP_KERNEL);
>   if (!prm->rbuf) {
>   prm->max_psize = 0;
>   ret = -ENOMEM;
> @@ -1104,7 +,13 @@ afunc_bind(struct usb_configuration *cfg, struct 
> usb_function *fn)
>  
>   prm = &agdev->uac2.p_prm;
>   prm->max_psize = hs_epin_desc.wMaxPacketSize;
> - prm->rbuf = kzalloc(prm->max_psize * USB_XFERS, GFP_KERNEL);
> + prm->ureq = kcalloc(uac2_opts->req_number, sizeof(struct uac2_req),
> + GFP_KERNEL);
> + if (!prm->ureq) {
> + ret = -ENOMEM;
> + goto err_free_descs;
> + }
> + prm->rbuf = kcalloc(uac2_opts->req_number, prm->max_psize, GFP_KERNEL);
>   if (!prm->rbuf) {
>   prm->max_psize = 0;
>   ret = -ENOMEM;
> @@ -1117,6 +1130,8 @@ afunc_bind(struct usb_configuration *cfg, struct 
> usb_function *fn)
>   return 0;
>  
>  err_no_memory:
> +

Re: [PATCH 1/2] usb: gadget: f_uac2: improve error handling

2017-01-15 Thread Peter Chen

On Wed, Jan 04, 2017 at 10:19:22AM +0800, Peter Chen wrote:
> If it is out of memory, we should return -ENOMEM;
> 
> Signed-off-by: Peter Chen 
> ---
>  drivers/usb/gadget/function/f_uac2.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_uac2.c 
> b/drivers/usb/gadget/function/f_uac2.c
> index 969cfe7..3f4e478 100644
> --- a/drivers/usb/gadget/function/f_uac2.c
> +++ b/drivers/usb/gadget/function/f_uac2.c
> @@ -1098,6 +1098,7 @@ afunc_bind(struct usb_configuration *cfg, struct 
> usb_function *fn)
>   prm->rbuf = kzalloc(prm->max_psize * USB_XFERS, GFP_KERNEL);
>   if (!prm->rbuf) {
>   prm->max_psize = 0;
> + ret = -ENOMEM;
>   goto err_free_descs;
>   }
>  
> @@ -1106,20 +1107,21 @@ afunc_bind(struct usb_configuration *cfg, struct 
> usb_function *fn)
>   prm->rbuf = kzalloc(prm->max_psize * USB_XFERS, GFP_KERNEL);
>   if (!prm->rbuf) {
>   prm->max_psize = 0;
> - goto err;
> + ret = -ENOMEM;
> + goto err_no_memory;
>   }
>  
>   ret = alsa_uac2_init(agdev);
>   if (ret)
> - goto err;
> + goto err_no_memory;
>   return 0;
>  
> -err:
> +err_no_memory:
>   kfree(agdev->uac2.p_prm.rbuf);
>   kfree(agdev->uac2.c_prm.rbuf);
>  err_free_descs:
>   usb_free_all_descriptors(fn);
> - return -EINVAL;
> + return ret;
>  }
>  
>  static int
> -- 

A nice ping...

-- 

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

Re: [PATCH 35/37] usb: host: xhci: remove newline from tracer

2017-01-15 Thread Lu Baolu

Hi,

On 12/29/2016 07:01 PM, Felipe Balbi wrote:
> If we add that newline, the output will like like the following:
>
>  kworker/2:1-42[002]    169.811435: xhci_address_ctx:
> ctx_64=0, ctx_type=2, ctx_dma=@153fbd000, ctx_va=@880153fbd000
>
> We would rather have that in a single line.
>
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/host/xhci-trace.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
> index 4bad0d6d2c8a..08bed2f07e50 100644
> --- a/drivers/usb/host/xhci-trace.h
> +++ b/drivers/usb/host/xhci-trace.h
> @@ -103,7 +103,7 @@ DECLARE_EVENT_CLASS(xhci_log_ctx,
>   ((HCC_64BYTE_CONTEXT(xhci->hcc_params) + 1) * 32) *
>   ((ctx->type == XHCI_CTX_TYPE_INPUT) + ep_num + 1));
>   ),
> - TP_printk("\nctx_64=%d, ctx_type=%u, ctx_dma=@%llx, ctx_va=@%p",
> + TP_printk("ctx_64=%d, ctx_type=%u, ctx_dma=@%llx, ctx_va=@%p",
>   __entry->ctx_64, __entry->ctx_type,
>   (unsigned long long) __entry->ctx_dma, __entry->ctx_va
>   )

This patch looks good to me.

Best regards,
Lu Baolu
--
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 v3] usb: gadget: udc-core: Rescan pending list on driver unbind

2017-01-15 Thread Krzysztof Opasiak

Since:

commit 855ed04a3758 ("usb: gadget: udc-core: independent registration
of gadgets and gadget drivers")

if we load gadget module but there is no free udc available
then it will be stored on a pending gadgets list.

$ modprobe g_zero.ko
$ modprobe g_ether.ko
[] udc-core: couldn't find an available UDC - added [g_ether] to list
of pending drivers

We scan this list each time when new UDC appears in system.
But we can get a free UDC each time after gadget unbind.
This commit add scanning of that list directly after unbinding
gadget from udc.

Thanks to this, when we unload first gadget:

$ rmmod g_zero.ko

gadget which is pending is automatically
attached to that UDC (if name matches).

Fixes: 855ed04a3758  ("usb: gadget: udc-core: independent registration of 
gadgets and gadget drivers")
Cc: stable 
Signed-off-by: Krzysztof Opasiak 
---
Changes since v2:
- cc stable
Changes since v1:
- remove unused variable driver
---
 drivers/usb/gadget/udc/core.c | 45 +--
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 9483489080f6..73292459acd6 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1080,6 +1080,24 @@ static void usb_udc_nop_release(struct device *dev)
dev_vdbg(dev, "%s\n", __func__);
 }
 
+/* should be called with udc_lock held */
+static int check_pending_gadget_drivers(struct usb_udc *udc)
+{
+   struct usb_gadget_driver *driver;
+   int ret = 0;
+
+   list_for_each_entry(driver, &gadget_driver_pending_list, pending)
+   if (!driver->udc_name || strcmp(driver->udc_name,
+   dev_name(&udc->dev)) == 0) {
+   ret = udc_bind_to_driver(udc, driver);
+   if (ret != -EPROBE_DEFER)
+   list_del(&driver->pending);
+   break;
+   }
+
+   return ret;
+}
+
 /**
  * usb_add_gadget_udc_release - adds a new gadget to the udc class driver list
  * @parent: the parent device to this udc. Usually the controller driver's
@@ -1093,7 +,6 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
void (*release)(struct device *dev))
 {
struct usb_udc  *udc;
-   struct usb_gadget_driver *driver;
int ret = -ENOMEM;
 
udc = kzalloc(sizeof(*udc), GFP_KERNEL);
@@ -1136,17 +1153,9 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
udc->vbus = true;
 
/* pick up one of pending gadget drivers */
-   list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
-   if (!driver->udc_name || strcmp(driver->udc_name,
-   dev_name(&udc->dev)) == 0) {
-   ret = udc_bind_to_driver(udc, driver);
-   if (ret != -EPROBE_DEFER)
-   list_del(&driver->pending);
-   if (ret)
-   goto err5;
-   break;
-   }
-   }
+   ret = check_pending_gadget_drivers(udc);
+   if (ret)
+   goto err5;
 
mutex_unlock(&udc_lock);
 
@@ -1352,14 +1361,22 @@ int usb_gadget_unregister_driver(struct 
usb_gadget_driver *driver)
return -EINVAL;
 
mutex_lock(&udc_lock);
-   list_for_each_entry(udc, &udc_list, list)
+   list_for_each_entry(udc, &udc_list, list) {
if (udc->driver == driver) {
usb_gadget_remove_driver(udc);
usb_gadget_set_state(udc->gadget,
-   USB_STATE_NOTATTACHED);
+USB_STATE_NOTATTACHED);
+
+   /* Maybe there is someone waiting for this UDC? */
+   check_pending_gadget_drivers(udc);
+   /*
+* For now we ignore bind errors as probably it's
+* not a valid reason to fail other's gadget unbind
+*/
ret = 0;
break;
}
+   }
 
if (ret) {
list_del(&driver->pending);
-- 
2.9.3

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

RE: [PATCH v1 1/1] usbip: auto retry for concurrent attach

2017-01-15 Thread fx IWATA NOBUO

> copy-paste in error path. Could you please fix this to use goto as only
> for this single function usbip_vhci_driver_close() is called in 3
> different places.

OK. I will fix in next version.

Sorry for making you to wite same kind of comment,

Nobuo Iwata
//
> -Original Message-
> From: Krzysztof Opasiak [mailto:k.opas...@samsung.com]
> Sent: Thursday, January 12, 2017 8:02 PM
> To: fx IWATA NOBUO ;
> valentina.mane...@gmail.com; sh...@kernel.org;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
> Cc: fx MICHIMURA TADAO 
> Subject: Re: [PATCH v1 1/1] usbip: auto retry for concurrent attach
> 
> Hi,
> 
> On 12/26/2016 05:53 AM, Nobuo Iwata wrote:
> > This patch adds recovery from false busy state on concurrent attach
> > operation.
> >
> > The procedure of attach operation is as below.
> >
> > 1) Find an unused port in /sys/devices/platform/vhci_hcd/status.
> > (userspace)
> >
> > 2) Request attach found port to driver through
> > /sys/devices/platform/vhci_hcd/attach. (userspace)
> >
> > 3) Lock table, reserve requested port and unlock table. (vhci driver)
> >
> > Attaching more than one remote devices concurrently, same unused port
> > number will be found in step-1. Then one request will succeed and
> > others will fail even though there are some unused ports.
> >
> > It is possible to avoid this fail by introdocing userspace exclusive
> > control. But it's exaggerated for this special condition. The locking
> > itself is done in driver.
> >
> > With this patch, driver returns EBUSY when requested port has already
> > been used. In this case, attach command retries from step-1: finding
> > another unused port. If there's no unused port, the attach operation
> > will fail. Othrwise it retries automatically using new free port.
> >
> > Currunt userspace src/usbip_attach.c:import_device() doesn't use the
> > errno.
> >
> > vhci-hcd's interface (only errno) is changed as following.
> >
> > Current errno   New errno   Condition
> > EINVAL  same as leftspecified port numbre is in
> invalid
> > range
> > EAGAIN  same as leftplatform_get_drvdata() failed
> > EINVAL  same as leftspecified socket fd is not valid
> > EINVAL  EBUSY   specified port status is not free
> >
> > Signed-off-by: Nobuo Iwata 
> > ---
> >  drivers/usb/usbip/vhci_sysfs.c |  8 ++--
> >  tools/usb/usbip/src/usbip_attach.c | 28
> +++-
> >  2 files changed, 21 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/usb/usbip/vhci_sysfs.c
> b/drivers/usb/usbip/vhci_sysfs.c
> > index b96e5b1..5d4be4b 100644
> > --- a/drivers/usb/usbip/vhci_sysfs.c
> > +++ b/drivers/usb/usbip/vhci_sysfs.c
> > @@ -214,7 +214,7 @@ static ssize_t store_detach(struct device *dev,
> struct device_attribute *attr,
> >
> > ret = vhci_port_disconnect(hcd_to_vhci(hcd), rhport);
> > if (ret < 0)
> > -   return -EINVAL;
> > +   return ret;
> >
> > usbip_dbg_vhci_sysfs("Leave\n");
> >
> > @@ -314,7 +314,11 @@ static ssize_t store_attach(struct device *dev,
> struct device_attribute *attr,
> > sockfd_put(socket);
> >
> > dev_err(dev, "port %d already used\n", rhport);
> > -   return -EINVAL;
> > +   /*
> > +* Will be retried from userspace
> > +* if there's another free port.
> > +*/
> > +   return -EBUSY;
> > }
> >
> > dev_info(dev, "pdev(%u) rhport(%u) sockfd(%d)\n",
> > diff --git a/tools/usb/usbip/src/usbip_attach.c
> b/tools/usb/usbip/src/usbip_attach.c
> > index 70a6b50..695b2e5 100644
> > --- a/tools/usb/usbip/src/usbip_attach.c
> > +++ b/tools/usb/usbip/src/usbip_attach.c
> > @@ -101,20 +101,22 @@ static int import_device(int sockfd, struct
> usbip_usb_device *udev)
> > return -1;
> > }
> >
> > -   port = usbip_vhci_get_free_port();
> > -   if (port < 0) {
> > -   err("no free port");
> > -   usbip_vhci_driver_close();
> > -   return -1;
> > -   }
> > +   do {
> > +   port = usbip_vhci_get_free_port();
> > +   if (port < 0) {
> > +   err("no free port");
> > +   usbip_vhci_driver_close();
> > +   return -1;
> > +   }
> >
> > -   rc = usbip_vhci_attach_device(port, sockfd, udev->busnum,
> > - udev->devnum, udev->speed);
> > -   if (rc < 0) {
> > -   err("import device");
> > -   usbip_vhci_driver_close();
> > -   return -1;
> > -   }
> > +   rc = usbip_vhci_attach_device(port, sockfd,
> udev->busnum,
> > + udev->devnum,
> udev->speed);
> > +   if (rc < 0 && errno != EBUSY) {
> > +   err("import device");
> > +   usbip_vhci_driver_close();
> > +   return -1;
> > +   }
> 
> copy-paste in error path. Could you please fix this to use goto as only
> for t

Re: [PATCH 30/37] usb: host: xhci: make a generic TRB tracer

2017-01-15 Thread Lu Baolu

Hi,

On 01/16/2017 03:03 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu  writes:
>> On 12/29/2016 07:01 PM, Felipe Balbi wrote:
>>> instead of having a tracer that can only trace command completions,
>>> let's promote this tracer so it can trace and decode any TRB.
>>>
>>> With that, it will be easier to extrapolate the lifetime of any TRB
>>> which might help debugging certain issues.
>>>
>>> Signed-off-by: Felipe Balbi 
>>> ---
>>>  drivers/usb/host/xhci-ring.c  |  14 +-
>>>  drivers/usb/host/xhci-trace.h |  55 +---
>>>  drivers/usb/host/xhci.h   | 311 
>>> ++
>>>  3 files changed, 357 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>>> index 393c64f8acef..0ee7d358b812 100644
>>> --- a/drivers/usb/host/xhci-ring.c
>>> +++ b/drivers/usb/host/xhci-ring.c
>>> @@ -1346,6 +1346,9 @@ static void handle_cmd_completion(struct xhci_hcd 
>>> *xhci,
>>>  
>>> cmd_dma = le64_to_cpu(event->cmd_trb);
>>> cmd_trb = xhci->cmd_ring->dequeue;
>>> +
>>> +   trace_xhci_handle_command(xhci->cmd_ring, &cmd_trb->generic);
>>> +
>> This is duplicated with trace_xhci_handle_event().
> no it's not. They separate events from the same event class, but they're
> different things.

Comments below.

>
>>> @@ -2407,6 +2408,10 @@ static int handle_tx_event(struct xhci_hcd *xhci,
>>>  
>>> ep_trb = &ep_seg->trbs[(ep_trb_dma - ep_seg->dma) /
>>> sizeof(*ep_trb)];
>>> +
>>> +   trace_xhci_handle_transfer(ep_ring,
>>> +   (struct xhci_generic_trb *) ep_trb);
>>> +
>> This is duplicated with trace_xhci_handle_event().
> ditto
>
>>> +   __entry->type = ring->type;
>>> +   __entry->field0 = le32_to_cpu(trb->field[0]);
>>> +   __entry->field1 = le32_to_cpu(trb->field[1]);
>>> +   __entry->field2 = le32_to_cpu(trb->field[2]);
>>> +   __entry->field3 = le32_to_cpu(trb->field[3]);
>>> ),
>>> -   TP_printk("\ntrb_dma=@%llx, trb_va=@%p, status=%08x, flags=%08x",
>>> -   (unsigned long long) __entry->dma, __entry->va,
>>> -   __entry->status, __entry->flags
>>> +   TP_printk("%s: %s", xhci_ring_type_string(__entry->type),
>> How about moving the common fields of a TRB (like TRB type and
>> the cycle bit) to the place between ring type and trb decoding string?
>> And remove type and cycle decoding in xhci_decode_trb() as well.
>>
>> Something like:
>>
>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>> index d01524b..f8ef7b8 100644
>> --- a/drivers/usb/host/xhci-trace.h
>> +++ b/drivers/usb/host/xhci-trace.h
>> @@ -132,9 +132,11 @@ DECLARE_EVENT_CLASS(xhci_log_trb,
>> __entry->field2 = le32_to_cpu(trb->field[2]);
>> __entry->field3 = le32_to_cpu(trb->field[3]);
>> ),
>> -   TP_printk("%s: %s", xhci_ring_type_string(__entry->type),
>> -   xhci_decode_trb(__entry->field0, __entry->field1,
>> -   __entry->field2, __entry->field3)
>> +   TP_printk("%s: %s: %c: %s", xhci_ring_type_string(__entry->type),
>> + xhci_trb_type_string(TRB_FIELD_TO_TYPE(__entry->field3)),
>> + __entry->field3 & TRB_CYCLE ? 'C' : 'c',
>> + xhci_decode_trb(__entry->field0, __entry->field1,
>> + __entry->field2, __entry->field3)
> and what do I get with that? What's the actual benefit?

I thought that it could make xhci_decode_trb() a bit simpler.

>
>> )
>>  );
>>
>>
>>> +   xhci_decode_trb(__entry->field0, __entry->field1,
>>> +   __entry->field2, __entry->field3)
>>> )
>>>  );
>>>  
>>> -DEFINE_EVENT(xhci_log_event, xhci_cmd_completion,
>>> -   TP_PROTO(void *trb_va, struct xhci_generic_trb *ev),
>>> -   TP_ARGS(trb_va, ev)
>>> +DEFINE_EVENT(xhci_log_trb, xhci_handle_event,
>>> +   TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>>> +   TP_ARGS(ring, trb)
>>> +);
>>> +
>>> +DEFINE_EVENT(xhci_log_trb, xhci_handle_command,
>>> +   TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>>> +   TP_ARGS(ring, trb)
>>> +);
>>> +
>>> +DEFINE_EVENT(xhci_log_trb, xhci_handle_transfer,
>>> +   TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>>> +   TP_ARGS(ring, trb)
>>> +);
>>> +
>>> +DEFINE_EVENT(xhci_log_trb, xhci_queue_trb,
>>> +   TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>>> +   TP_ARGS(ring, trb)
>>>  );
>> xhci_handle_command and xhci_handle_transfer are duplications
>> of xhci_handle_event. I suggest to remove them.
> no, they are not. They give us more granularity into which events we
> want to enable. 

Fair enough.

But why not defining events for all possible event types as well
and dropping the all-in-one xhci_handle_event switch.

A single event TRB will be traced twice

Re: [PATCH v2 RESEND] usb: gadget: udc-core: Rescan pending list on driver unbind

2017-01-15 Thread Krzysztof Opasiak



On 12/27/2016 12:18 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Krzysztof Opasiak  writes:
>> Since:
>>
>> commit 855ed04a3758 ("usb: gadget: udc-core: independent registration
>> of gadgets and gadget drivers")
>>
>> if we load gadget module but there is no free udc available
>> then it will be stored on a pending gadgets list.
>>
>> $ modprobe g_zero.ko
>> $ modprobe g_ether.ko
>> [] udc-core: couldn't find an available UDC - added [g_ether] to list
>> of pending drivers
>>
>> We scan this list each time when new UDC appears in system.
>> But we can get a free UDC each time after gadget unbind.
>> This commit add scanning of that list directly after unbinding
>> gadget from udc.
>>
>> Thanks to this, when we unload first gadget:
>>
>> $ rmmod g_zero.ko
>>
>> gadget which is pending is automatically
>> attached to that UDC (if name matches).
>>
>> Signed-off-by: Krzysztof Opasiak 
> 
> Do we need to Cc stable on this?
> 

I'll resend this patch with suitable CC

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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] usb: xhci: add support for performing fake doorbell

2017-01-15 Thread Rafał Miłecki

On 21 November 2016 at 16:31, Mathias Nyman
 wrote:
> On 21.11.2016 09:57, Rafał Miłecki wrote:
>>
>> Hi Mathias,
>>
>> On 17 October 2016 at 22:30, Rafał Miłecki  wrote:
>>>
>>> From: Rafał Miłecki 
>>>
>>> Broadcom's Northstar XHCI controllers seem to need a special start
>>> procedure to work correctly. There isn't any official documentation of
>>> this, the problem is that controller doesn't detect any connected
>>> devices with default setup. Moreover connecting USB device to controller
>>> that doesn't run properly can cause SoC's watchdog issues.
>>>
>>> A workaround that was successfully tested on multiple devices is to
>>> perform a fake doorbell. This patch adds code for doing this and enables
>>> it on BCM4708 family.
>>>
>>> Signed-off-by: Rafał Miłecki 
>>> ---
>>> V2: Enable quirk for brcm,bcm4708 machines instead of adding separated
>>> binding
>>>  for it. Thanks Rob for your comment on this.
>>
>>
>> Do you think you can pick & push this one? V2 follows Rob's suggestion
>> and he has some DT knowledge for sure, so I guess it should be OK.
>> --
>
>
> Is there some more background information on this?
>
> I don't have any contacts to Broadcom myself, adding the BMC Kernel Feedback
> list to CC.
> Maybe someone over there has an errata, documentation or just general
> feedback.
>
> How was this workaround even figured out? ringing the doorbell for the first
> device doesn't seem like something found by trial and error,  especially
> when
> xhci specs state that:
>
> "Software shall not write the Doorbell of an endpoint until after it has
> issued a
> Configure Endpoint Command for the endpoint and received a successful
> Command
> Completion Event."
>
> The whole workaround is a bit intrusive, allocating a fake device, ring a
> doorbell for a
> fake device in the wrong state, clearing off HSE (host system error) which
> should only be set
> when things really go bad, some random usleeps, and possible calling
> xhci_start() twice.
>
> I can't take this as is without some more info.

Hi (ping) Broadcom guys, could you help us with this USB workaround, please?

-- 
Rafał
--
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] tools: usb usbip - update README USB/IP driver location

2017-01-15 Thread Krzysztof Opasiak



On 01/14/2017 12:38 AM, Shuah Khan wrote:
> Update USB/IP driver location in README.
> 
> Signed-off-by: Shuah Khan 

Reviewed-by: Krzysztof Opasiak 

Best regards,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Felipe Balbi


Hi,

Vincent Pelletier  writes:
>> > What happens when you run your test with dummy-hcd?  
>> 
>> this is a good idea too.
>
> Tested (on the edison, as it was the most convenient place to build
> that module and debian kernel on host does not have it), the whole
> test suite passes there. This said, dummy_hcd allocates endpoints on
> very different addresses:
>
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x86  EP 6 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
>
> Back the dwc3 I tried pushing the IN descriptor first (IN, OUT, IN
> instead of OUT, IN, IN). ep1in is still silent, so it looks like in the
> event of IN+OUT endpoint address (4 LSb), OUT wins and IN looses
> whatever the initialisation order.

this looks very similar to problem I'm debugging with ADB on Joule. I
see no errors on Joule (dwc3) side and xHCI fails transfers with "USB
Transaction Error" (hence my asking for xHCI traces).

-- 
balbi
--
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: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Felipe Balbi


Hi,

Vincent Pelletier  writes:
>> Vincent, can you compile my xhci-cleanup branch from my usb.org tree
>> (see MAINTAINERS file for the URL. Hint, it's on git.kernel.org) and run
>> it on your xHCI side and *also* capture tracepoints from xHCI?
>
> Given that the USB analyser does see traffic on the bus and it's the
> device which NAKs, I think I can skip this - unless you think there is
> more to see there.

it's actually pretty important :-)

-- 
balbi
--
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 31/37] usb: host: xhci: add urb_enqueue/dequeue/giveback tracers

2017-01-15 Thread Lu Baolu

Hi,

On 12/29/2016 07:01 PM, Felipe Balbi wrote:
> These three new tracers will help us tie TRBs into URBs by *also*
> looking into URB lifetime.

I didn't see anything related to TRBs in the patch.
Anything I missed?

>
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/host/xhci-ring.c  |  1 +
>  drivers/usb/host/xhci-trace.h | 70 
> +++
>  drivers/usb/host/xhci.c   |  5 
>  3 files changed, 76 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 0ee7d358b812..1431e0651e78 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -627,6 +627,7 @@ static void xhci_giveback_urb_in_irq(struct xhci_hcd 
> *xhci,
>   usb_hcd_unlink_urb_from_ep(hcd, urb);
>   spin_unlock(&xhci->lock);
>   usb_hcd_giveback_urb(hcd, urb, status);
> + trace_xhci_urb_giveback(urb);

There is another trace point in xhci_urb_dequeue().

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b49588f..ee46877 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1535,6 +1535,7 @@ int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb 
*urb, int status)
 
usb_hcd_unlink_urb_from_ep(hcd, urb);
spin_unlock_irqrestore(&xhci->lock, flags);
+   trace_xhci_urb_giveback(urb);
usb_hcd_giveback_urb(hcd, urb, -ESHUTDOWN);
xhci_urb_free_priv(urb_priv);
return ret;

>   spin_lock(&xhci->lock);
>  }
>  
> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
> index d01524b9fb14..4bad0d6d2c8a 100644
> --- a/drivers/usb/host/xhci-trace.h
> +++ b/drivers/usb/host/xhci-trace.h
> @@ -158,6 +158,76 @@ DEFINE_EVENT(xhci_log_trb, xhci_queue_trb,
>   TP_ARGS(ring, trb)
>  );
>  
> +DECLARE_EVENT_CLASS(xhci_log_urb,
> + TP_PROTO(struct urb *urb),
> + TP_ARGS(urb),
> + TP_STRUCT__entry(
> + __field(void *, urb)
> + __field(unsigned int, pipe)
> + __field(unsigned int, stream)
> + __field(int, status)
> + __field(unsigned int, flags)
> + __field(int, num_mapped_sgs)
> + __field(int, num_sgs)
> + __field(int, length)
> + __field(int, actual)
> + __field(int, epnum)
> + __field(int, dir_in)
> + __field(int, type)
> + ),
> + TP_fast_assign(
> + __entry->urb = urb;
> + __entry->pipe = urb->pipe;
> + __entry->stream = urb->stream_id;
> + __entry->status = urb->status;
> + __entry->flags = urb->transfer_flags;
> + __entry->num_mapped_sgs = urb->num_mapped_sgs;
> + __entry->num_sgs = urb->num_sgs;
> + __entry->length = urb->transfer_buffer_length;
> + __entry->actual = urb->actual_length;
> + __entry->epnum = usb_endpoint_num(&urb->ep->desc);
> + __entry->dir_in = usb_endpoint_dir_in(&urb->ep->desc);
> + __entry->type = usb_endpoint_type(&urb->ep->desc);
> + ),
> + TP_printk("ep%d%s-%s: urb %p pipe %u length %d/%d sgs %d/%d stream %d 
> flags %08x",
> + __entry->epnum, __entry->dir_in ? "in" : "out",
> + ({ char *s;
> + switch (__entry->type) {
> + case USB_ENDPOINT_XFER_INT:
> + s = "intr";
> + break;
> + case USB_ENDPOINT_XFER_CONTROL:
> + s = "control";
> + break;
> + case USB_ENDPOINT_XFER_BULK:
> + s = "bulk";
> + break;
> + case USB_ENDPOINT_XFER_ISOC:
> + s = "isoc";
> + break;
> + default:
> + s = "UNKNOWN";
> + } s; }), __entry->urb, __entry->pipe, __entry->actual,
> + __entry->length, __entry->num_mapped_sgs,
> + __entry->num_sgs, __entry->stream, __entry->flags
> + )
> +);
> +
> +DEFINE_EVENT(xhci_log_urb, xhci_urb_enqueue,
> + TP_PROTO(struct urb *urb),
> + TP_ARGS(urb)
> +);
> +
> +DEFINE_EVENT(xhci_log_urb, xhci_urb_giveback,
> + TP_PROTO(struct urb *urb),
> + TP_ARGS(urb)
> +);
> +
> +DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
> + TP_PROTO(struct urb *urb),
> + TP_ARGS(urb)
> +);
> +
>  #endif /* __XHCI_TRACE_H */
>  
>  /* this part must be outside header guard */
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 06d294d7e01f..c0f3670e5a51 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1383,6 +1383,8 @@ int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb 
> *urb, gfp_t mem_flags)
>   urb_priv->td_cnt

Re: [PATCH 30/37] usb: host: xhci: make a generic TRB tracer

2017-01-15 Thread Felipe Balbi


Hi,

Lu Baolu  writes:
> On 12/29/2016 07:01 PM, Felipe Balbi wrote:
>> instead of having a tracer that can only trace command completions,
>> let's promote this tracer so it can trace and decode any TRB.
>>
>> With that, it will be easier to extrapolate the lifetime of any TRB
>> which might help debugging certain issues.
>>
>> Signed-off-by: Felipe Balbi 
>> ---
>>  drivers/usb/host/xhci-ring.c  |  14 +-
>>  drivers/usb/host/xhci-trace.h |  55 +---
>>  drivers/usb/host/xhci.h   | 311 
>> ++
>>  3 files changed, 357 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index 393c64f8acef..0ee7d358b812 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -1346,6 +1346,9 @@ static void handle_cmd_completion(struct xhci_hcd 
>> *xhci,
>>  
>>  cmd_dma = le64_to_cpu(event->cmd_trb);
>>  cmd_trb = xhci->cmd_ring->dequeue;
>> +
>> +trace_xhci_handle_command(xhci->cmd_ring, &cmd_trb->generic);
>> +
>
> This is duplicated with trace_xhci_handle_event().

no it's not. They separate events from the same event class, but they're
different things.

>> @@ -2407,6 +2408,10 @@ static int handle_tx_event(struct xhci_hcd *xhci,
>>  
>>  ep_trb = &ep_seg->trbs[(ep_trb_dma - ep_seg->dma) /
>>  sizeof(*ep_trb)];
>> +
>> +trace_xhci_handle_transfer(ep_ring,
>> +(struct xhci_generic_trb *) ep_trb);
>> +
>
> This is duplicated with trace_xhci_handle_event().

ditto

>> +__entry->type = ring->type;
>> +__entry->field0 = le32_to_cpu(trb->field[0]);
>> +__entry->field1 = le32_to_cpu(trb->field[1]);
>> +__entry->field2 = le32_to_cpu(trb->field[2]);
>> +__entry->field3 = le32_to_cpu(trb->field[3]);
>>  ),
>> -TP_printk("\ntrb_dma=@%llx, trb_va=@%p, status=%08x, flags=%08x",
>> -(unsigned long long) __entry->dma, __entry->va,
>> -__entry->status, __entry->flags
>> +TP_printk("%s: %s", xhci_ring_type_string(__entry->type),
>
> How about moving the common fields of a TRB (like TRB type and
> the cycle bit) to the place between ring type and trb decoding string?
> And remove type and cycle decoding in xhci_decode_trb() as well.
>
> Something like:
>
> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
> index d01524b..f8ef7b8 100644
> --- a/drivers/usb/host/xhci-trace.h
> +++ b/drivers/usb/host/xhci-trace.h
> @@ -132,9 +132,11 @@ DECLARE_EVENT_CLASS(xhci_log_trb,
> __entry->field2 = le32_to_cpu(trb->field[2]);
> __entry->field3 = le32_to_cpu(trb->field[3]);
> ),
> -   TP_printk("%s: %s", xhci_ring_type_string(__entry->type),
> -   xhci_decode_trb(__entry->field0, __entry->field1,
> -   __entry->field2, __entry->field3)
> +   TP_printk("%s: %s: %c: %s", xhci_ring_type_string(__entry->type),
> + xhci_trb_type_string(TRB_FIELD_TO_TYPE(__entry->field3)),
> + __entry->field3 & TRB_CYCLE ? 'C' : 'c',
> + xhci_decode_trb(__entry->field0, __entry->field1,
> + __entry->field2, __entry->field3)

and what do I get with that? What's the actual benefit?

> )
>  );
>
>
>> +xhci_decode_trb(__entry->field0, __entry->field1,
>> +__entry->field2, __entry->field3)
>>  )
>>  );
>>  
>> -DEFINE_EVENT(xhci_log_event, xhci_cmd_completion,
>> -TP_PROTO(void *trb_va, struct xhci_generic_trb *ev),
>> -TP_ARGS(trb_va, ev)
>> +DEFINE_EVENT(xhci_log_trb, xhci_handle_event,
>> +TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>> +TP_ARGS(ring, trb)
>> +);
>> +
>> +DEFINE_EVENT(xhci_log_trb, xhci_handle_command,
>> +TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>> +TP_ARGS(ring, trb)
>> +);
>> +
>> +DEFINE_EVENT(xhci_log_trb, xhci_handle_transfer,
>> +TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>> +TP_ARGS(ring, trb)
>> +);
>> +
>> +DEFINE_EVENT(xhci_log_trb, xhci_queue_trb,
>> +TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
>> +TP_ARGS(ring, trb)
>>  );
>
> xhci_handle_command and xhci_handle_transfer are duplications
> of xhci_handle_event. I suggest to remove them.

no, they are not. They give us more granularity into which events we
want to enable. They also make it clear where the even is coming
from. Imagine how the trace would look like if I had a single event and
just called trace_xhci_handle_event() from all locations. How would you
differentiate from all possible call sites?

> How about adding an event for the link TRBs. Something like,
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index

Re: [PATCH] usb: host: xhci: plat: check hcc_params after add hcd

2017-01-15 Thread wlf


Hi Roger,

在 2017年01月13日 19:02, Roger Quadros 写道:

Hi,

On 13/01/17 05:18, William Wu wrote:

From: William wu 

The commit 4ac53087d6d4 ("usb: xhci: plat: Create both
HCDs before adding them") move add hcd to the end of
probe, this cause hcc_params uninitiated, because xHCI
driver sets hcc_params in xhci_gen_setup() called from
usb_add_hcd().

This patch checks the Maximum Primary Stream Array Size
in the hcc_params register after add hcd.

Signed-off-by: William wu 
---
  drivers/usb/host/xhci-plat.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ddfab30..52ce697 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -232,9 +232,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (device_property_read_bool(&pdev->dev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
  
-	if (HCC_MAX_PSA(xhci->hcc_params) >= 4)

-   xhci->shared_hcd->can_do_streams = 1;
-
hcd->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
if (IS_ERR(hcd->usb_phy)) {
ret = PTR_ERR(hcd->usb_phy);
@@ -255,6 +252,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
  
+	if (HCC_MAX_PSA(xhci->hcc_params) >= 4)

+   xhci->shared_hcd->can_do_streams = 1;
+

xhci->hcc_params is initialized after the first usb_add_hcd().
Should this bit come before the usb_add_hcd(xhci->shared_hcd,..)?

Yes, good idea！I will move it behind the first usb_add_hcd().


You will also need to copy to v4.2+ . Thanks.

OK, thank you for reminding me!



return 0;
  
  


cheers,
-roger






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

Re: [PATCH 30/37] usb: host: xhci: make a generic TRB tracer

2017-01-15 Thread Lu Baolu

Hi,

On 12/29/2016 07:01 PM, Felipe Balbi wrote:
> instead of having a tracer that can only trace command completions,
> let's promote this tracer so it can trace and decode any TRB.
>
> With that, it will be easier to extrapolate the lifetime of any TRB
> which might help debugging certain issues.
>
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/host/xhci-ring.c  |  14 +-
>  drivers/usb/host/xhci-trace.h |  55 +---
>  drivers/usb/host/xhci.h   | 311 
> ++
>  3 files changed, 357 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 393c64f8acef..0ee7d358b812 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1346,6 +1346,9 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
>  
>   cmd_dma = le64_to_cpu(event->cmd_trb);
>   cmd_trb = xhci->cmd_ring->dequeue;
> +
> + trace_xhci_handle_command(xhci->cmd_ring, &cmd_trb->generic);
> +

This is duplicated with trace_xhci_handle_event().

>   cmd_dequeue_dma = xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
>   cmd_trb);
>   /*
> @@ -1362,8 +1365,6 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
>  
>   del_timer(&xhci->cmd_timer);
>  
> - trace_xhci_cmd_completion(cmd_trb, (struct xhci_generic_trb *) event);
> -
>   cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
>  
>   /* If CMD ring stopped we own the trbs between enqueue and dequeue */
> @@ -2407,6 +2408,10 @@ static int handle_tx_event(struct xhci_hcd *xhci,
>  
>   ep_trb = &ep_seg->trbs[(ep_trb_dma - ep_seg->dma) /
>   sizeof(*ep_trb)];
> +
> + trace_xhci_handle_transfer(ep_ring,
> + (struct xhci_generic_trb *) ep_trb);
> +

This is duplicated with trace_xhci_handle_event().

>   /*
>* No-op TRB should not trigger interrupts.
>* If ep_trb is a no-op TRB, it means the
> @@ -2475,6 +2480,8 @@ static int xhci_handle_event(struct xhci_hcd *xhci)
>   xhci->event_ring->cycle_state)
>   return 0;
>  
> + trace_xhci_handle_event(xhci->event_ring, &event->generic);
> +
>   /*
>* Barrier between reading the TRB_CYCLE (valid) flag above and any
>* speculative reads of the event's flags/data below.
> @@ -2642,6 +2649,9 @@ static void queue_trb(struct xhci_hcd *xhci, struct 
> xhci_ring *ring,
>   trb->field[1] = cpu_to_le32(field2);
>   trb->field[2] = cpu_to_le32(field3);
>   trb->field[3] = cpu_to_le32(field4);
> +
> + trace_xhci_queue_trb(ring, trb);
> +
>   inc_enq(xhci, ring, more_trbs_coming);
>  }
>  
> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
> index 59c05653b2ea..d01524b9fb14 100644
> --- a/drivers/usb/host/xhci-trace.h
> +++ b/drivers/usb/host/xhci-trace.h
> @@ -115,34 +115,47 @@ DEFINE_EVENT(xhci_log_ctx, xhci_address_ctx,
>   TP_ARGS(xhci, ctx, ep_num)
>  );
>  
> -DECLARE_EVENT_CLASS(xhci_log_event,
> - TP_PROTO(void *trb_va, struct xhci_generic_trb *ev),
> - TP_ARGS(trb_va, ev),
> +DECLARE_EVENT_CLASS(xhci_log_trb,
> + TP_PROTO(struct xhci_ring *ring, struct xhci_generic_trb *trb),
> + TP_ARGS(ring, trb),
>   TP_STRUCT__entry(
> - __field(void *, va)
> - __field(u64, dma)
> - __field(u32, status)
> - __field(u32, flags)
> - __dynamic_array(u8, trb, sizeof(struct xhci_generic_trb))
> + __field(u32, type)
> + __field(u32, field0)
> + __field(u32, field1)
> + __field(u32, field2)
> + __field(u32, field3)
>   ),
>   TP_fast_assign(
> - __entry->va = trb_va;
> - __entry->dma = ((u64)le32_to_cpu(ev->field[1])) << 32 |
> - le32_to_cpu(ev->field[0]);
> - __entry->status = le32_to_cpu(ev->field[2]);
> - __entry->flags = le32_to_cpu(ev->field[3]);
> - memcpy(__get_dynamic_array(trb), trb_va,
> - sizeof(struct xhci_generic_trb));
> + __entry->type = ring->type;
> + __entry->field0 = le32_to_cpu(trb->field[0]);
> + __entry->field1 = le32_to_cpu(trb->field[1]);
> + __entry->field2 = le32_to_cpu(trb->field[2]);
> + __entry->field3 = le32_to_cpu(trb->field[3]);
>   ),
> - TP_printk("\ntrb_dma=@%llx, trb_va=@%p, status=%08x, flags=%08x",
> - (unsigned long long) __entry->dma, __entry->va,
> - __entry->status, __entry->flags
> + TP_printk("%s: %s", xhci_ring_type_string(__entry->type),

How about moving the common fields of a TRB (like TRB type and
the cycle bit) to the place between ring type and trb decoding string?
And remove type and cycle decoding in xhci_decode_trb() as well

Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs

2017-01-15 Thread Peter Chen

On Fri, Jan 13, 2017 at 12:03:00PM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-12 19:35:36)
> > On Thu, Jan 12, 2017 at 02:49:51PM -0800, Stephen Boyd wrote:
> > > 
> > > With the boards I have, vbus is not routed to the phy. Instead, there's
> > > a vbus comparator on the PMIC where the vbus line from the usb
> > > receptacle is sent. The vbus extcon driver probes the comparator on the
> > > PMIC to see if vbus is present or not and then notifies extcon users
> > > when vbus changes.
> > > 
> > > The ULPI register we write in the phy is a vendor specific register
> > > (called MISC_A) that has two bits. If you look at
> > > qcom_usb_hs_phy_set_mode() in this series you'll see that we set
> > > VBUSVLDEXTSEL and VBUSVLDEXT. VBUSVLDEXTSEL controls a mux in the phy
> > > that chooses between an internal comparator, in the case where vbus goes
> > > to the phy, or an external signal input to the phy, VBUSVLDEXT, to
> > > consider as the "session valid" signal. It looks like the session valid
> > > signal drives the D+ pullup resistor in the phy. These bits in MISC_A
> > > don't matter when the phy is in host mode.
> > > 
> > > So when the board doesn't route vbus to the phy, we have to toggle the
> > > VBUSVLDEXT bit to signal to the phy that the vbus is there or not. I
> > > also see that we're not supposed to toggle the VBUSVLDEXTSEL bit when in
> > > "normal" operating mode. So perhaps we should do everything in the
> > > qcom_usb_hs_phy_set_mode() routine during the role switch as you
> > > suggest, except toggle the VBUSVLDEXT bit. Toggling the VBUSVLDEXT bit
> > > can be done via some new phy op when the extcon triggers?
> > 
> > Why not call phy_set_mode(phy, DEVICE) directly at ci_handle_vbus_change 
> > when
> > you get extcon vbus event?
> > 
> 
> Right, I can call phy_set_mode(phy, DEVICE) there, but is that correct?
> How do we signal vbus is gone, with phy_set_mode(phy, HOST)? Mode
> doesn't seem the same as "vbus status changed" so this feels wrong.


> So when the board doesn't route vbus to the phy, we have to toggle the
> VBUSVLDEXT bit to signal to the phy that the vbus is there or not. I
> also see that we're not supposed to toggle the VBUSVLDEXTSEL bit when in
> "normal" operating mode. So perhaps we should do everything in the
> qcom_usb_hs_phy_set_mode() routine during the role switch as you
> suggest, except toggle the VBUSVLDEXT bit. Toggling the VBUSVLDEXT bit
> can be done via some new phy op when the extcon triggers?

So, you need to call phy_set_mode when switching between host and device.
Besides, you also need to toggle VBUSVLDEXT when the external vbus
is on or off at device mode (doesn't need for host mode), is it correct?

At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
to port it to generic phy framework.

-- 

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

Re: Standard USB Descriptor question

2017-01-15 Thread bruce m beach

On 1/13/17, Greg KH  wrote:
> On Fri, Jan 13, 2017 at 07:24:10PM -0800, bruce m beach wrote:
>> Hello everybody
>>
>>   I have been stuck for ages trying to figure out something
>> in the Standard USB Descriptor during the enumeration. It
>> looks like it should should be quite simple but I am not
>> getting it because maybe some mind block, maybe becuase the
>> documentation is unclear, or maybe because I'm brain-dead.
>> Here is the problem:
>>
>> I think the host starts out requesting the device descriptor
>> This is okay and works no problem. At some point the host
>> requests the configuration descriptor and I get stuck. The
>> usb 2.0 spec. says:
>>
>> "When the host requests the configuration descriptor, all
>> related interface and endpoint descriptors are returned"
>>
>> How is the host supposed to know how much data is coming in
>> or how much data to request until it reads wTotalLength?
>>
>> I would assume the host would request the 9 bytes of the
>> configuration descriptor, then make subsequent requests to
>> get the interfaces and endpoints but for instance in the
>> section on the interface descriptor the spec says
>>
>> " An interface descriptor is always returned as part of a
>> configuration descriptor.
>>
>> Again how is this supposed happen if the host is only
>> requesting 9 bytes in the configuration descriptor stage
>
> Have you looked at the data on the wire?  The host asks for 9 bytes, and
> then it uses the information there to get the "real" size of the
> descriptor and then it asks for the full descriptor with all of the
> information in it.
>
> hope this helps,
>
> greg k-h
>

  Yes it helps. Makes sense. I made some changes and can get the
  descriptors from a userland program so I know its working (i.e.
  from userland I can upload firmware and have control over the
  chip includeing the usb subsystem) but at this point after
  a reset there is no re-unumeration. It justs lists the original
  configuration.(using lsusb). Notice I am using ioctl's.

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

[v2 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

2017-01-15 Thread Bruno Herrera

This patch introduces a new parameter to activate USB OTG HS/FS core embedded 
phy transciver. The STM32F4x9 SoC uses the GGPIO register to enable the 
transciver.

Signed-off-by: Bruno Herrera 
---
 drivers/usb/dwc2/core.h   |  4 
 drivers/usb/dwc2/hcd.c| 21 ++-
 drivers/usb/dwc2/hw.h |  2 ++
 drivers/usb/dwc2/params.c | 51 +++
 4 files changed, 73 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..e3199c5 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -430,6 +430,9 @@ enum dwc2_ep0_state {
  * needed.
  * 0 - No (default)
  * 1 - Yes
+ * @activate_transceiver: Activate internal transceiver using GGPIO register.
+ * 0 - Deactivate the transceiver (default)
+ * 1 - Activate the transceiver
  * @g_dma:  Enables gadget dma usage (default: autodetect).
  * @g_dma_desc: Enables gadget descriptor DMA (default: autodetect).
  * @g_rx_fifo_size:The periodic rx fifo size for the device, in
@@ -501,6 +504,7 @@ struct dwc2_core_params {
int uframe_sched;
int external_id_pin_ctl;
int hibernation;
+   int activate_transceiver;
 
/*
 * The following parameters are *only* set via device
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 911c3b3..6bc27f1 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -118,7 +118,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg 
*hsotg)
 
 static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
 {
-   u32 usbcfg, i2cctl;
+   u32 usbcfg, ggpio, i2cctl;
int retval = 0;
 
/*
@@ -142,6 +142,17 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool 
select_phy)
return retval;
}
}
+
+   ggpio = dwc2_readl(hsotg->regs + GGPIO);
+   if (!(ggpio & GGPIO_STM32_OTG_GCCFG_PWRDWN) &&
+   (hsotg->params.activate_transceiver > 0)) {
+   dev_dbg(hsotg->dev, "Activating transceiver\n");
+   /* STM32F4xx uses the GGPIO register as general core
+* configuration register.
+*/
+   ggpio |= GGPIO_STM32_OTG_GCCFG_PWRDWN;
+   dwc2_writel(ggpio, hsotg->regs + GGPIO);
+   }
}
 
/*
@@ -941,7 +952,7 @@ static void dwc2_hc_init(struct dwc2_hsotg *hsotg, struct 
dwc2_host_chan *chan)
  *
  * In slave mode, checks for a free request queue entry, then sets the Channel
  * Enable and Channel Disable bits of the Host Channel Characteristics
- * register of the specified channel to intiate the halt. If there is no free
+ * register of the specified channel to initiate the halt. If there is no free
  * request queue entry, sets only the Channel Disable bit of the HCCHARn
  * register to flush requests for this channel. In the latter case, sets a
  * flag to indicate that the host channel needs to be halted when a request
@@ -2359,9 +2370,9 @@ static void dwc2_core_host_init(struct dwc2_hsotg *hsotg)
dwc2_flush_rx_fifo(hsotg);
 
/* Clear Host Set HNP Enable in the OTG Control Register */
-   otgctl = dwc2_readl(hsotg->regs + GOTGCTL);
-   otgctl &= ~GOTGCTL_HSTSETHNPEN;
-   dwc2_writel(otgctl, hsotg->regs + GOTGCTL);
+   //otgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+   //otgctl &= ~GOTGCTL_HSTSETHNPEN;
+   //dwc2_writel(otgctl, hsotg->regs + GOTGCTL);
 
if (hsotg->params.dma_desc_enable <= 0) {
int num_channels, i;
diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
index 5be056b..a84e93b 100644
--- a/drivers/usb/dwc2/hw.h
+++ b/drivers/usb/dwc2/hw.h
@@ -225,6 +225,8 @@
 
 #define GPVNDCTL   HSOTG_REG(0x0034)
 #define GGPIO  HSOTG_REG(0x0038)
+#define GGPIO_STM32_OTG_GCCFG_PWRDWN   (1 << 16)
+
 #define GUID   HSOTG_REG(0x003c)
 #define GSNPSIDHSOTG_REG(0x0040)
 #define GHWCFG1HSOTG_REG(0x0044)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index a786256..a8fdcfc 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -192,6 +192,37 @@ static const struct dwc2_core_params params_amlogic = {
.hibernation= -1,
 };
 
+static const struct dwc2_core_params params_stm32f4_otgfs = {
+   .otg_cap= DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE,
+   .otg_ver= -1,
+   .dma_desc_enable= 0,
+   .dma_desc_fs_enable = 0,
+   .speed  = DWC2_SPEED_PARAM_FULL,
+   .enable_dynamic_fifo= -

[v2 3/3] dt-bindings: Document the STM32 USB OTG DWC2 core binding

2017-01-15 Thread Bruno Herrera

This patch adds the documentation for STM32F4x9 USB OTG FS/HS compatible 
strings.

Signed-off-by: Bruno Herrera 
---
 Documentation/devicetree/bindings/usb/dwc2.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 6c7c2bce..637223a 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -14,6 +14,10 @@ Required properties:
   - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 
SoCs;
   - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX 
SoCs;
   - snps,dwc2: A generic DWC2 USB controller with default parameters.
+  - "st,stm32f4xx-fsotg": The DWC2 USB FS/HS controller instance in STM32F4xx 
SoCs
+  configured in FS mode;
+  - "st,stm32f4xx-hsotg": The DWC2 USB HS controller instance in STM32F4xx SoCs
+  configured in HS mode;
 - reg : Should contain 1 register range (address and length)
 - interrupts : Should contain 1 interrupt
 - clocks: clock provider specifier
-- 
2.10.1 (Apple Git-78)

--
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: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Vincent Pelletier

On Mon, 16 Jan 2017 00:07:27 +, Vincent Pelletier
 wrote:
> Sometimes, ep0 just gets stuck during SET_CONFIGURATION, but then does
> work for test's part which involves it. EP1 & above do not work.

I should mention that re-trying SET_CONFIGURATION from host.py times
out too, so the device stays unconfigured, hence EP1 & above not
working.
-- 
Vincent Pelletier
--
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: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Vincent Pelletier

On Sun, 15 Jan 2017 23:23:59 +0200, Felipe Balbi
 wrote:
> (it's always a good idea to Cc maintainers of drivers you're having
> trouble with :)

Noted, I was worried I was CC'ing you too much lately with my
patches :) .

> Alan Stern  writes:
> > The USB spec allows such things.

Thanks for your confirmation.

> > I don't know about DWC.  The host controllers drivers I maintain work 
> > okay when two endpoints have the same number but different directions.
> >
> > What sort of host controller do you test with?

Host controller is an intel xhci, managed by xhci_pci:

# lspci -vvs 00:14.0
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI 
Controller (rev 31) (prog-if 30 [XHCI])
Subsystem: ASRock Incorporation Sunrise Point-H USB 3.0 xHCI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR-  > What does usbmon show?

8x 512bytes transfers, submitted once each, 5s timeouts, whole "host.py"
trace, 3 endpoints mode:

9a1e04ad60c0 2806891189 S Ci:1:048:0 s 80 06 0300  00ff 255 <
9a1e04ad60c0 2806891773 C Ci:1:048:0 0 4 = 04030904
9a1e04ad60c0 2806891862 S Ci:1:048:0 s 80 06 0305 0409 00ff 255 <
9a1e04ad60c0 2806892148 C Ci:1:048:0 0 42 = 2a034600 75006e00 63007400 
69006f00 6e004600 53005400 65007300 74004400
9a1e04ad60c0 2806892318 S Ci:1:048:0 s 80 06 0300  00ff 255 <
9a1e04ad60c0 2806892566 C Ci:1:048:0 0 4 = 04030904
9a1e04ad60c0 2806892578 S Ci:1:048:0 s 80 06 0305 0409 00ff 255 <
9a1e04ad60c0 2806892831 C Ci:1:048:0 0 42 = 2a034600 75006e00 63007400 
69006f00 6e004600 53005400 65007300 74004400
9a1e04ad60c0 2806893000 S Ci:1:048:0 s c1 02   0001 1 <
9a1e04ad60c0 2806893778 C Ci:1:048:0 -32 0
9a1e04ad60c0 2806893870 S Co:1:048:0 s 41 02   0001 1 = 61
9a1e04ad60c0 2806894751 C Co:1:048:0 -32 0
9a1e04ad60c0 2806894843 S Ci:1:048:0 s c1 01   0001 1 <
9a1e04ad60c0 2806896079 C Ci:1:048:0 0 1 = 4e
9a1e04ad60c0 2806896284 S Ci:1:048:0 s c1 01   0002 2 <
9a1e04ad60c0 2806896949 C Ci:1:048:0 0 2 = 4e4f
9a1e04ad60c0 2806897094 S Ci:1:048:0 s c1 01   0003 3 <
9a1e04ad60c0 2806897810 C Ci:1:048:0 0 3 = 4e4f54
9a1e04ad60c0 2806897927 S Ci:1:048:0 s c1 01   0004 4 <
9a1e04ad60c0 2806898484 C Ci:1:048:0 0 4 = 4e4f5420
9a1e04ad60c0 2806898631 S Ci:1:048:0 s c1 01   0005 5 <
9a1e04ad60c0 2806899619 C Ci:1:048:0 0 5 = 4e4f5420 53
9a1e04ad60c0 2806899726 S Ci:1:048:0 s c1 01   0006 6 <
9a1e04ad60c0 2806900391 C Ci:1:048:0 0 6 = 4e4f5420 5345
9a1e04ad60c0 2806900559 S Ci:1:048:0 s c1 01   0007 7 <
9a1e04ad60c0 2806901094 C Ci:1:048:0 0 7 = 4e4f5420 534554
9a1e04ad60c0 2806901260 S Ci:1:048:0 s c1 01   0008 8 <
9a1e04ad60c0 2806901690 C Ci:1:048:0 0 7 = 4e4f5420 534554
9a1e04ad60c0 2806901787 S Co:1:048:0 s 41 01   000b 11 = 666f6f20 
62617220 62617a
9a1e04ad60c0 2806902191 C Co:1:048:0 0 11 >
9a1e04ad60c0 2806902352 S Ci:1:048:0 s c1 01   0040 64 <
9a1e04ad60c0 2806902775 C Ci:1:048:0 0 11 = 666f6f20 62617220 62617a
9a1e04ad60c0 2806902940 S Bo:1:048:1 -115 512 =    
    
9a1e04ad60c0 2806902963 C Bo:1:048:1 0 512 >
9a1e04ad63c0 2806902970 S Bo:1:048:1 -115 512 =    
    
9a1bf65103c0 2806902986 S Bo:1:048:1 -115 512 =    
    
9a1e04ad63c0 2806903013 C Bo:1:048:1 0 512 >
9a1bf65106c0 2806903015 S Bo:1:048:1 -115 512 =    
    
9a1bf65103c0 2806903018 C Bo:1:048:1 0 512 >
9a1bf6510240 2806903028 S Bo:1:048:1 -115 512 =    
    
9a1bf6510a80 2806903039 S Bo:1:048:1 -115 512 =    
    
9a1bf65106c0 2806903044 C Bo:1:048:1 0 512 >
9a1bf6510240 2806903060 C Bo:1:048:1 0 512 >
9a1bf6510a80 2806903062 C Bo:1:048:1 0 512 >
9a1bf65100c0 2806903064 S Bo:1:048:1 -115 512 =    
    
9a1bf65100c0 2806903083 C Bo:1:048:1 0 512 >
9a1bf6510e40 2806903087 S Bo:1:048:1 -115 512 =    
    
9a1bf6510e40 2806903126 C Bo:1:048:1 0 512 >
9a1bf6510e40 2806903318 S Bi:1:048:1 -115 512 <
9a1bf65100c0 2806903352 S Bi:1:048:1 -115 512 <
9a1bf6510a80 2806903367 S Bi:1:048:1 -115 512 <
9a1bf6510240 2806903383 S Bi:1:048:1 -115 512 <
9a1bf65106c0 2806903422 S Bi:1:048:1 -115 512 <
9a1bf65103c0 2806903435 S Bi:1:048:1 -115 512 <
9a1e04ad63c0 2806903446 S Bi:1:0

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Felipe Balbi


Hi,

(it's always a good idea to Cc maintainers of drivers you're having
trouble with :)

Alan Stern  writes:

> On Sun, 15 Jan 2017, Vincent Pelletier wrote:
>
>> > An endpoint can not work in both directions, that's not how USB
>> > endpoints work at all.  I think you are confusing the hardware with your
>> > configuration :)
>> 
>> I do agree that I have never noticed in the wild a device using a
>> non-zero endpoint (4 LSb) in both directions (1 MSb) - and maybe there
>> is no host OS support anywhere.
>
> I have seen such devices mentioned in the mailing list.  They work 
> fine.
>
>> On the spec level though, I am less sure. Quoting the USB (v2) spec:
> ...
>
> The USB spec allows such things.
>
>> So there is either a bug in the HCI side, or in the UDC side:
>> - either the HCI should support bidirectional-ish endpoints (same
>>   4 LSb, different 1 MSb). Would this limitation be a hardware one ?
>
> I don't know about DWC.  The host controllers drivers I maintain work 
> okay when two endpoints have the same number but different directions.
>
> What sort of host controller do you test with?
>
> What does usbmon show?

also, which kernel are you running on dwc3 side? Which platform is it?

In order to have any idea of what's going on, I need tracepoints from
dwc3.

# mkdir -p /t
# mount -t tracefs none /t
# cd /t
# echo 10240 > buffer_size_kb
# echo 1 > events/dwc3/enable
# echo 0 > events/dwc3/dwc3_readl/enable
# echo 0 > events/dwc3/dwc3_writel/enable

(run tests, cause it to fail)

# cp /t/trace /path/to/non-volatile/media/dwc3-trace.txt

compress and send me traces

> What happens when you run your test with dummy-hcd?

this is a good idea too.

>> - or the UDC endpoint auto-allocation mechanism must skip an endpoint
>>   when it is already used in the other direction
>
> This could be a bug in the UDC driver.

We don't even know which kernel he's running on dwc3 side :-) It could
also be a bug on his python functionfs lib. At this point, it could be
many things.

Vincent, can you compile my xhci-cleanup branch from my usb.org tree
(see MAINTAINERS file for the URL. Hint, it's on git.kernel.org) and run
it on your xHCI side and *also* capture tracepoints from xHCI?

# mkdir -p /t
# mount -t tracefs none /t
# cd /t
# echo 10240 > buffer_size_kb
# echo 1 > events/xhci-hcd/enable

(run tests, cause it to fail)

# cp /t/trace /path/to/non-volatile/media/xhci-trace.txt

again, compress and send me traces.

-- 
balbi
--
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: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

2017-01-15 Thread Heiner Kallweit

Set the iomem parameters in the usb_hcd to fix this misleading
message during driver load:
dwc2 c910.usb: irq 22, io mem 0x

Signed-off-by: Heiner Kallweit 
---
 drivers/usb/dwc2/core.h | 3 ++-
 drivers/usb/dwc2/hcd.c  | 5 -
 drivers/usb/dwc2/hcd.h  | 3 ++-
 drivers/usb/dwc2/platform.c | 2 +-
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e0..b66eaeea 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct dwc2_hsotg 
*hsotg) {}
 static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force) {}
 static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
 static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
-static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
+static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
+   struct resource *res)
 { return 0; }
 static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
 { return 0; }
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 911c3b36..2cfbd10e 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4964,7 +4964,7 @@ static void dwc2_hcd_release(struct dwc2_hsotg *hsotg)
  * USB bus with the core and calls the hc_driver->start() function. It returns
  * a negative error on failure.
  */
-int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
+int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq, struct resource *res)
 {
struct usb_hcd *hcd;
struct dwc2_host_chan *channel;
@@ -5021,6 +5021,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 
hcd->has_tt = 1;
 
+   hcd->rsrc_start = res->start;
+   hcd->rsrc_len = resource_size(res);
+
((struct wrapper_priv_data *) &hcd->hcd_priv)->hsotg = hsotg;
hsotg->priv = hcd;
 
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index 1ed5fa2b..2305b5fb 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -521,7 +521,8 @@ static inline u8 dwc2_hcd_is_pipe_out(struct 
dwc2_hcd_pipe_info *pipe)
return !dwc2_hcd_is_pipe_in(pipe);
 }
 
-extern int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq);
+extern int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
+struct resource *res);
 extern void dwc2_hcd_remove(struct dwc2_hsotg *hsotg);
 
 /* Transaction Execution Functions */
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4fc8c603..5ddc8860 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -445,7 +445,7 @@ static int dwc2_driver_probe(struct platform_device *dev)
}
 
if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
-   retval = dwc2_hcd_init(hsotg, hsotg->irq);
+   retval = dwc2_hcd_init(hsotg, hsotg->irq, res);
if (retval) {
if (hsotg->gadget_enabled)
dwc2_hsotg_remove(hsotg);
-- 
2.11.0

--
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: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Alan Stern

On Sun, 15 Jan 2017, Vincent Pelletier wrote:

> > An endpoint can not work in both directions, that's not how USB
> > endpoints work at all.  I think you are confusing the hardware with your
> > configuration :)
> 
> I do agree that I have never noticed in the wild a device using a
> non-zero endpoint (4 LSb) in both directions (1 MSb) - and maybe there
> is no host OS support anywhere.

I have seen such devices mentioned in the mailing list.  They work 
fine.

> On the spec level though, I am less sure. Quoting the USB (v2) spec:
...

The USB spec allows such things.

> So there is either a bug in the HCI side, or in the UDC side:
> - either the HCI should support bidirectional-ish endpoints (same
>   4 LSb, different 1 MSb). Would this limitation be a hardware one ?

I don't know about DWC.  The host controllers drivers I maintain work 
okay when two endpoints have the same number but different directions.

What sort of host controller do you test with?

What does usbmon show?

What happens when you run your test with dummy-hcd?

> - or the UDC endpoint auto-allocation mechanism must skip an endpoint
>   when it is already used in the other direction

This could be a bug in the UDC driver.

Alan Stern

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

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Vincent Pelletier

On Sun, 15 Jan 2017 12:11:08 +0100, Greg KH  wrote:
> What are you doing on the host to talk to these endpoints?

https://github.com/vpelletier/python-functionfs/tree/master/functionfs/tests

device.py is the device half and host.py the host part, of course.

The committed tests only request and test 2 endpoints.

In a nutshell:
- device declares one interface with 2 (3 in my modified version)
  endpoints, listens/writes to the functionfs-exposed files and
  discards buffer content. Note that descriptors pushed to functionfs
  cannot request a specific endpoint, they get remapped by the kernel
  (which is just fine if the remapping leads to a functional device).
- host does a few EP0 tests, then triggers usb transfers (with whatever
  in the buffer)

Currently, host just assumes IN and OUT are on endpoint 1, which is
what f_fs (and surrounding gadget machinery) actually does (here with
the OUT/IN/IN configuration):

(host)$ lsusb -vd 1d6b:0104
Bus 001 Device 040: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0104 Multifunction Composite Gadget
  bcdDevice4.10
  iManufacturer   1
  iProduct2
  iSerial 3
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0

(device)/sys/kernel/debug/dwc3.1.auto# for EP in ep*; do echo -ne "$EP\t"; cat 
$EP/transfer_type; done
ep0in   control
ep0out  control
ep10in  --
ep10out --
ep11in  --
ep11out --
ep12in  --
ep12out --
ep13in  --
ep13out --
ep14in  --
ep14out --
ep15in  --
ep15out --
ep1in   bulk
ep1out  bulk
ep2in   bulk
ep2out  --
ep3in   --
ep3out  --
ep4in   --
ep4out  --
ep5in   --
ep5out  --
ep6in   --
ep6out  --
ep7in   --
ep7out  --
ep8in   --
ep8out  --
ep9in   --
ep9out  --
(device)/sys/kernel/debug/dwc3.1.auto# diff -ru ep1in ep1out
diff -ru ep1in/descriptor_fetch_queue ep1out/descriptor_fetch_queue
--- ep1in/descriptor_fetch_queue2017-01-15 09:50:26.497903702 +
+++ ep1out/descriptor_fetch_queue   2017-01-15 09:50:26.507903702 +
@@ -1 +1 @@
-0
+32
diff -ru ep1in/rx_fifo_queue ep1out/rx_fifo_queue
--- ep1in/rx_fifo_queue 2017-01-15 09:50:26.497903702 +
+++ ep1out/rx_fifo_queue2017-01-15 09:50:26.507903702 +
@@ -1 +1 @@
-54
+50
diff -ru ep1in/trb_ring ep1out/trb_ring
--- ep1in/trb_ring  2017-01-15 09:50:26.497903702 +
+++ ep1out/trb_ring 2017-01-15 09:50:26.507903702 +
@@ -4,7 +4,7 @@
 --

 buffer_addr,size,type,ioc,isp_imi,csp,chn,lst,hwo
-3451,65536,normal,1,0,0,0,0,1
+344e,65536,normal,1,0,1,0,0,1
 ,0,UNKNOWN,0,0,0,0,0,0
 ,0,UNKNOWN,0,0,0,0,0,0
 ,0,UNKNOWN,0,0,0,0,0,0
@@ -259,4 +259,4 @@
 ,0,UNKNOWN,0,0,0,0,0,0
 ,0,UNKNOWN,0,0,0,0,0,0
 ,0,UNKNOWN,0,0,0,0,0,0
-3448d000,0,link,0,0,0,0,0,1
+36ab1000,0,link,0,0,0,0,0

[GIT PULL] USB driver fixes for 4.10-rc4

2017-01-15 Thread Greg KH

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.10-rc4

for you to fetch changes up to 97f9c5f211d1f063b1745370e6b4fd64d6adaeff:

  Merge tag 'usb-serial-4.10-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus 
(2017-01-12 18:17:38 +0100)


USB fixes for 4.10-rc4

Here are a few small USB driver fixes for 4.10-rc4 to resolve some
reported issues.  The "largest" here is a number of bugs being fixed in
the ch341 usb-serial driver, to hopefully resolve the mess of different
devices floating around that use this driver that have been having
problems with the 4.10-rc1 release.  There's also a tiny musb fix that I
missed in the last pull request, as well as the traditional xhci fix
rounding out the batch.

All have been in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Andy Lutomirski (1):
  wusbcore: Fix one more crypto-on-the-stack bug

Bin Liu (1):
  usb: musb: fix runtime PM in debugfs

Greg Kroah-Hartman (1):
  Merge tag 'usb-serial-4.10-rc4' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus

Johan Hovold (9):
  USB: serial: ch341: fix initial modem-control state
  USB: serial: ch341: fix open and resume after B0
  USB: serial: ch341: fix modem-control and B0 handling
  USB: serial: ch341: fix open error handling
  USB: serial: ch341: fix resume after reset
  USB: serial: ch341: fix line settings after reset-resume
  USB: serial: ch341: fix baud rate and line-control handling
  USB: serial: kl5kusb105: fix line-state error handling
  USB: serial: ch341: fix control-message error handling

Mathias Nyman (1):
  xhci: fix deadlock at host remove by running watchdog correctly

 drivers/usb/host/xhci-ring.c|  11 
 drivers/usb/host/xhci.c |  13 -
 drivers/usb/musb/musb_debugfs.c |  20 +++-
 drivers/usb/serial/ch341.c  | 108 +++-
 drivers/usb/serial/kl5kusb105.c |   9 ++--
 drivers/usb/wusbcore/crypto.c   |   3 +-
 6 files changed, 98 insertions(+), 66 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Documentation: usb: fix wrong documentation paths

2017-01-15 Thread Yegor Yefremov

Fixes wrong spelled "pinctrl-bindings.txt" and "qcom-dwc3-usb-phy.txt"
file names as also wrong specified "mt8173-mtu3.txt" file name.

Signed-off-by: Yegor Yefremov 
---
Changes:
v1 -> v2: add changelog text (Greg Kroah-Hartman)

 Documentation/devicetree/bindings/usb/dwc3-st.txt | 4 ++--
 Documentation/devicetree/bindings/usb/ehci-st.txt | 2 +-
 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt | 2 +-
 Documentation/devicetree/bindings/usb/mt8173-xhci.txt | 4 ++--
 Documentation/devicetree/bindings/usb/qcom,dwc3.txt   | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt 
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
index 01c71b1..50dee3b 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-st.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -20,10 +20,10 @@ See: Documentation/devicetree/bindings/reset/reset.txt
with 'reg' property
 
  - pinctl-names: A pinctrl state named "default" must be defined
-See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
  - pinctrl-0   : Pin control group
-See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
  - ranges  : allows valid 1:1 translation between child's address space and
  parent's address space
diff --git a/Documentation/devicetree/bindings/usb/ehci-st.txt 
b/Documentation/devicetree/bindings/usb/ehci-st.txt
index fb45fa5..410d922 100644
--- a/Documentation/devicetree/bindings/usb/ehci-st.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-st.txt
@@ -7,7 +7,7 @@ Required properties:
  - interrupts  : one EHCI interrupt should be described here
  - pinctrl-names   : a pinctrl state named "default" must be defined
  - pinctrl-0   : phandle referencing pin configuration of the USB 
controller
-See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
  - clocks  : phandle list of usb clocks
  - clock-names : should be "ic" for interconnect clock and "clk48"
 See: Documentation/devicetree/bindings/clock/clock-bindings.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
index e049d19..718386a 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -30,7 +30,7 @@ Optional properties:
"id_float" and "id_ground" are optinal which depends on
"mediatek,enable-manual-drd"
  - pinctrl-0 : pin control group
-   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
  - maximum-speed : valid arguments are "super-speed", "high-speed" and
"full-speed"; refer to usb/generic.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index 2a930bd..7ea3971 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -37,7 +37,7 @@ Optional properties:
  - usb3-lpm-capable : supports USB3.0 LPM
  - pinctrl-names : a pinctrl state named "default" must be defined
  - pinctrl-0 : pin control group
-   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
 Example:
 usb30: usb@1127 {
@@ -67,7 +67,7 @@ usb30: usb@1127 {
 
 In the case, xhci is added as subnode to mtu3. An example and the DT binding
 details of mtu3 can be found in:
-Documentation/devicetree/bindings/usb/mtu3.txt
+Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
 
 Required properties:
  - compatible : should contain "mediatek,mt8173-xhci"
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
index 39acb08..73cc096 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
@@ -18,7 +18,7 @@ A child node must exist to represent the core DWC3 IP block. 
The name of
 the node is not important. The content of the node is defined in dwc3.txt.
 
 Phy documentation is provided in the following places:
-Documentation/devicetree/bindings/phy/qcom,dwc3-usb-phy.txt
+Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
 
 Example device nodes:
 
-- 
2.9.3

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

Re: [PATCH] Documentation: usb: fix wrong documentation paths

2017-01-15 Thread Greg KH

On Sun, Jan 15, 2017 at 01:04:56PM +0100, Yegor Yefremov wrote:
> Signed-off-by: Yegor Yefremov 

I never take patches without any changelog text, and I doubt that other
maintainers do either :(

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

[PATCH] Documentation: usb: fix wrong documentation paths

2017-01-15 Thread Yegor Yefremov

Signed-off-by: Yegor Yefremov 
---
 Documentation/devicetree/bindings/usb/dwc3-st.txt | 4 ++--
 Documentation/devicetree/bindings/usb/ehci-st.txt | 2 +-
 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt | 2 +-
 Documentation/devicetree/bindings/usb/mt8173-xhci.txt | 4 ++--
 Documentation/devicetree/bindings/usb/qcom,dwc3.txt   | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt 
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
index 01c71b1..50dee3b 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-st.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -20,10 +20,10 @@ See: Documentation/devicetree/bindings/reset/reset.txt
with 'reg' property
 
  - pinctl-names: A pinctrl state named "default" must be defined
-See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
  - pinctrl-0   : Pin control group
-See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
  - ranges  : allows valid 1:1 translation between child's address space and
  parent's address space
diff --git a/Documentation/devicetree/bindings/usb/ehci-st.txt 
b/Documentation/devicetree/bindings/usb/ehci-st.txt
index fb45fa5..410d922 100644
--- a/Documentation/devicetree/bindings/usb/ehci-st.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-st.txt
@@ -7,7 +7,7 @@ Required properties:
  - interrupts  : one EHCI interrupt should be described here
  - pinctrl-names   : a pinctrl state named "default" must be defined
  - pinctrl-0   : phandle referencing pin configuration of the USB 
controller
-See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
  - clocks  : phandle list of usb clocks
  - clock-names : should be "ic" for interconnect clock and "clk48"
 See: Documentation/devicetree/bindings/clock/clock-bindings.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
index e049d19..718386a 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -30,7 +30,7 @@ Optional properties:
"id_float" and "id_ground" are optinal which depends on
"mediatek,enable-manual-drd"
  - pinctrl-0 : pin control group
-   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
  - maximum-speed : valid arguments are "super-speed", "high-speed" and
"full-speed"; refer to usb/generic.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index 2a930bd..7ea3971 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -37,7 +37,7 @@ Optional properties:
  - usb3-lpm-capable : supports USB3.0 LPM
  - pinctrl-names : a pinctrl state named "default" must be defined
  - pinctrl-0 : pin control group
-   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
 
 Example:
 usb30: usb@1127 {
@@ -67,7 +67,7 @@ usb30: usb@1127 {
 
 In the case, xhci is added as subnode to mtu3. An example and the DT binding
 details of mtu3 can be found in:
-Documentation/devicetree/bindings/usb/mtu3.txt
+Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
 
 Required properties:
  - compatible : should contain "mediatek,mt8173-xhci"
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
index 39acb08..73cc096 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
@@ -18,7 +18,7 @@ A child node must exist to represent the core DWC3 IP block. 
The name of
 the node is not important. The content of the node is defined in dwc3.txt.
 
 Phy documentation is provided in the following places:
-Documentation/devicetree/bindings/phy/qcom,dwc3-usb-phy.txt
+Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
 
 Example device nodes:
 
-- 
2.9.3

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

[PATCH] usb: musb: constify dev_pm_ops structures

2017-01-15 Thread Bhumika Goyal

Declare dev_pm_ops structures as const as they are only stored in the pm
field of a device_driver structure. This field is of type const, so
dev_pm_ops structures having similar properties can be declared const
too.

Size details after cross compiling the .o file for arm
architecture.

File size before: drivers/usb/musb/omap2430.o
   textdata bss dec hex filename
   4141 400   8454911c5 usb/musb/omap2430.o

File size after: drivers/usb/musb/omap2430.o
   textdata bss dec hex filename
   4333 200   8454111bd usb/musb/omap2430.o

Signed-off-by: Bhumika Goyal 
---
 drivers/usb/musb/omap2430.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 8b73214..456f3e6 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -575,7 +575,7 @@ static int omap2430_runtime_resume(struct device *dev)
return 0;
 }
 
-static struct dev_pm_ops omap2430_pm_ops = {
+static const struct dev_pm_ops omap2430_pm_ops = {
.runtime_suspend = omap2430_runtime_suspend,
.runtime_resume = omap2430_runtime_resume,
 };
-- 
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

[PATCH] usb: host: constify dev_pm_ops structures

2017-01-15 Thread Bhumika Goyal

Declare dev_pm_ops structures as const as they are only stored in the pm
field of a device_driver structure. This field is of type const, so
dev_pm_ops structures having similar properties can be declared const
too.

Size details after cross compiling the .o file for powerpc
architecture.

File size before:
   textdata bss dec hex filename
   3183 372   03555 de3 drivers/usb/host/ehci-fsl.o

File size after:
   textdata bss dec hex filename
   3275 280   03555 de3 drivers/usb/host/ehci-fsl.o

Signed-off-by: Bhumika Goyal 
---
 drivers/usb/host/ehci-fsl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 91701cc..3733aab 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -600,7 +600,7 @@ static int ehci_fsl_drv_restore(struct device *dev)
return 0;
 }
 
-static struct dev_pm_ops ehci_fsl_pm_ops = {
+static const struct dev_pm_ops ehci_fsl_pm_ops = {
.suspend = ehci_fsl_drv_suspend,
.resume = ehci_fsl_drv_resume,
.restore = ehci_fsl_drv_restore,
-- 
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: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Greg KH

On Sun, Jan 15, 2017 at 10:06:52AM +, Vincent Pelletier wrote:
> Hello,
> 
> Using configfs and functionfs I configured a 3-endpoints gadget the
> following way:
> - OUT f_fs ep: 1 real ep: 1 | OUT (0x01)
> - IN  f_fs ep: 2 real ep: 1 | IN  (0x81)
> - IN  f_fs ep: 3 real ep: 2 | IN  (0x82)
> 
> When connected to host:
> - Real ep 0x01 works.
> - Real ep 0x81 is silent (all URBs timeout).
> - Real ep 0x82 works.

What are you doing on the host to talk to these endpoints?

> Plugging my usb analyser, I see no bus activity at all for the last
> one, though I do see transactions for the others. I also see this
> message on host:
>   Jan 15 09:52:30 localhost kernel: [232403.009744] xhci_hcd :00:14.0: 
> WARN Event TRB for slot 24 ep 4 with no TDs queued?
> Would xhci_hcd (or the HCD itlsef ?) fail when a single endpoint works
> in both directions ?

An endpoint can not work in both directions, that's not how USB
endpoints work at all.  I think you are confusing the hardware with your
configuration :)

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

functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

2017-01-15 Thread Vincent Pelletier

Hello,

Using configfs and functionfs I configured a 3-endpoints gadget the
following way:
- OUT f_fs ep: 1 real ep: 1 | OUT (0x01)
- IN  f_fs ep: 2 real ep: 1 | IN  (0x81)
- IN  f_fs ep: 3 real ep: 2 | IN  (0x82)

When connected to host:
- Real ep 0x01 works.
- Real ep 0x81 is silent (all URBs timeout).
- Real ep 0x82 works.

Plugging my usb analyser, I see no bus activity at all for the last
one, though I do see transactions for the others. I also see this
message on host:
  Jan 15 09:52:30 localhost kernel: [232403.009744] xhci_hcd :00:14.0: WARN 
Event TRB for slot 24 ep 4 with no TDs queued?
Would xhci_hcd (or the HCD itlsef ?) fail when a single endpoint works
in both directions ?

"ep 4" seems to be an endpoint offset, which may be consistent with EP1
IN being the 4th endpoint:
  EP0 OUT, EP0 IN, EP1 OUT, EP1 IN

$ uname -a
Linux x2 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux

00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI 
Controller (rev 31)
Subsystem: ASRock Incorporation Sunrise Point-H USB 3.0 xHCI Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

Regards,
-- 
Vincent Pelletier
--
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 2/2] usb: gadget: uac2: add req_number as parameter

Re: [PATCH 1/2] usb: gadget: f_uac2: improve error handling

Re: [PATCH 35/37] usb: host: xhci: remove newline from tracer

[PATCH v3] usb: gadget: udc-core: Rescan pending list on driver unbind

RE: [PATCH v1 1/1] usbip: auto retry for concurrent attach

Re: [PATCH 30/37] usb: host: xhci: make a generic TRB tracer

Re: [PATCH v2 RESEND] usb: gadget: udc-core: Rescan pending list on driver unbind

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

Re: [PATCH] tools: usb usbip - update README USB/IP driver location

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

Re: [PATCH 31/37] usb: host: xhci: add urb_enqueue/dequeue/giveback tracers

Re: [PATCH 30/37] usb: host: xhci: make a generic TRB tracer

Re: [PATCH] usb: host: xhci: plat: check hcc_params after add hcd

Re: [PATCH 30/37] usb: host: xhci: make a generic TRB tracer

Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs

Re: Standard USB Descriptor question

[v2 1/3] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

[v2 3/3] dt-bindings: Document the STM32 USB OTG DWC2 core binding

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

[PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

[GIT PULL] USB driver fixes for 4.10-rc4

[PATCH v2] Documentation: usb: fix wrong documentation paths

Re: [PATCH] Documentation: usb: fix wrong documentation paths

[PATCH] Documentation: usb: fix wrong documentation paths

[PATCH] usb: musb: constify dev_pm_ops structures

[PATCH] usb: host: constify dev_pm_ops structures

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

33 matches

Site Navigation

Mail list logo

Footer information