[PATCH v4 0/3] usb: gadget: f_fs: userspace API fixes and improvements

[Robert Baldyga]

This patchset contains changes in FunctionFS making it easier and
safer to use. It fixes bug in endpoint files handling code, adds new
ioctl allowing to obtain endpoint descriptor, and introduces virtual
address mapping which allows to separate endpoint address space in
function from physical endpoint addresses, and introduces new endpoint
files naming convention.

Changelog:

v4:
- change if() sequence into switch() statement

v3: https://lkml.org/lkml/2014/7/30/115
- move fix for the redundant ep files problem into sepatare patch
- merge user space API affecting changes into single patch
- add flag switching between old and new style API

v2: https://lkml.org/lkml/2014/7/25/296
- return proper endpont address in setup request handling
- add patch usb: gadget: f_fs: add ioctl returning ep descriptor
- add patch usb: gadget: f_fs: make numbers in ep file names the same
  as ep addresses

v1: https://lkml.org/lkml/2014/7/18/1010

Robert Baldyga (3):
  usb: gadget: f_fs: fix the redundant ep files problem
  usb: gadget: f_fs: add ioctl returning ep descriptor
  usb: gadget: f_fs: virtual endpoint address mapping

 drivers/usb/gadget/function/f_fs.c  | 111 +++-
 drivers/usb/gadget/function/u_fs.h  |   4 ++
 include/uapi/linux/usb/functionfs.h |   7 +++
 3 files changed, 109 insertions(+), 13 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

[PATCH v4 3/3] usb: gadget: f_fs: virtual endpoint address mapping

[Robert Baldyga]

This patch introduces virtual endpoint address mapping. It separates
function logic form physical endpoint addresses making it more hardware
independent.

Following modifications changes user space API, so to enable them user
have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors.

Endpoints are now refered using virtual endpoint addresses chosen by
user in endpoint descpriptors. This applies to each context when endpoint
address can be used:
- when accessing endpoint files in FunctionFS filesystemi (in file name),
- in setup requests directed to specific endpoint (in wIndex field),
- in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl.

In endpoint file names the endpoint address number is formatted as
double-digit hexadecimal value ("ep%02x") which has few advantages -
it is easy to parse, allows to easly recognize endpoint direction basing
on its name (IN endpoint number starts with digit 8, and OUT with 0)
which can be useful for debugging purpose, and it makes easier to introduce
further features allowing to use each endpoint number in both directions
to have more endpoints available for function if hardware supports this
(for example we could have ep01 which is endpoint 1 with OUT direction,
and ep81 which is endpoint 1 with IN direction).

Physical endpoint address can be still obtained using ioctl named
FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle
USB transactions properly.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/function/f_fs.c  | 23 +--
 drivers/usb/gadget/function/u_fs.h  |  2 ++
 include/uapi/linux/usb/functionfs.h |  1 +
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index ac7b16d..a20ac8d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1555,7 +1555,10 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
epfile->ffs = ffs;
mutex_init(&epfile->mutex);
init_waitqueue_head(&epfile->wait);
-   sprintf(epfiles->name, "ep%u",  i);
+   if (ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
+   sprintf(epfiles->name, "ep%02x", ffs->eps_addrmap[i]);
+   else
+   sprintf(epfiles->name, "ep%u", i);
if (!unlikely(ffs_sb_create_file(ffs->sb, epfiles->name, epfile,
 &ffs_epfile_operations,
 &epfile->dentry))) {
@@ -2105,10 +2108,12 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
break;
case FUNCTIONFS_DESCRIPTORS_MAGIC_V2:
flags = get_unaligned_le32(data + 8);
+   ffs->user_flags = flags;
if (flags & ~(FUNCTIONFS_HAS_FS_DESC |
  FUNCTIONFS_HAS_HS_DESC |
  FUNCTIONFS_HAS_SS_DESC |
- FUNCTIONFS_HAS_MS_OS_DESC)) {
+ FUNCTIONFS_HAS_MS_OS_DESC |
+ FUNCTIONFS_VIRTUAL_ADDR)) {
ret = -ENOSYS;
goto error;
}
@@ -2463,7 +2468,13 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type 
type, u8 *valuep,
} else {
struct usb_request *req;
struct usb_ep *ep;
+   u8 bEndpointAddress;
 
+   /*
+* We back up bEndpointAddress because autoconfig overwrites
+* it with physical endpoint address.
+*/
+   bEndpointAddress = ds->bEndpointAddress;
pr_vdebug("autoconfig\n");
ep = usb_ep_autoconfig(func->gadget, ds);
if (unlikely(!ep))
@@ -2478,6 +2489,12 @@ static int __ffs_func_bind_do_descs(enum ffs_entity_type 
type, u8 *valuep,
ffs_ep->req = req;
func->eps_revmap[ds->bEndpointAddress &
 USB_ENDPOINT_NUMBER_MASK] = idx + 1;
+   /*
+* If we use virtual address mapping, we restore
+* original bEndpointAddress value.
+*/
+   if (func->ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
+   ds->bEndpointAddress = bEndpointAddress;
}
ffs_dump_mem(": Rewritten ep desc", ds, ds->bLength);
 
@@ -2922,6 +2939,8 @@ static int ffs_func_setup(struct usb_function *f,
ret = ffs_func_revmap_ep(func, le16_to_cpu(creq->wIndex));
if (unlikely(ret < 0))
return ret;
+   if (func->ffs->user_flags & FUNCTIONFS_VIRTUAL_ADDR)
+   ret = func->ffs->eps_addrmap[ret];
break;
 
default:
diff --git a/drivers/usb/gadget/function/u_fs.h 
b/drivers/usb/gadget/function/u_fs.h
index d48897e..cd128e3 100644
--- a/driv

[PATCH v4 2/3] usb: gadget: f_fs: add ioctl returning ep descriptor

[Robert Baldyga]

This patch introduces ioctl named FUNCTIONFS_ENDPOINT_DESC, which
returns endpoint descriptor to userspace. It works only if function
is active.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/function/f_fs.c  | 21 +
 include/uapi/linux/usb/functionfs.h |  6 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 8096f22..ac7b16d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1032,6 +1032,27 @@ static long ffs_epfile_ioctl(struct file *file, unsigned 
code,
case FUNCTIONFS_ENDPOINT_REVMAP:
ret = epfile->ep->num;
break;
+   case FUNCTIONFS_ENDPOINT_DESC:
+   {
+   int desc_idx;
+   struct usb_endpoint_descriptor *desc;
+
+   switch (epfile->ffs->gadget->speed) {
+   case USB_SPEED_SUPER:
+   desc_idx = 2;
+   break;
+   case USB_SPEED_HIGH:
+   desc_idx = 1;
+   break;
+   default:
+   desc_idx = 0;
+   }
+   desc = epfile->ep->descs[desc_idx];
+   ret = copy_to_user((void *)value, desc, sizeof(*desc));
+   if (ret)
+   ret = -EFAULT;
+   break;
+   }
default:
ret = -ENOTTY;
}
diff --git a/include/uapi/linux/usb/functionfs.h 
b/include/uapi/linux/usb/functionfs.h
index 0154b28..900896e 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -265,6 +265,12 @@ struct usb_functionfs_event {
  */
 #defineFUNCTIONFS_ENDPOINT_REVMAP  _IO('g', 129)
 
+/*
+ * Returns endpoint descriptor. In funciton is not active returns -ENODEV.
+ */
+#defineFUNCTIONFS_ENDPOINT_DESC_IOR('g', 130, \
+struct usb_endpoint_descriptor)
+
 
 
 #endif /* _UAPI__LINUX_FUNCTIONFS_H__ */
-- 
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 v4 1/3] usb: gadget: f_fs: fix the redundant ep files problem

[Robert Baldyga]

Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tryed to read/write to them. It was result of fact that maximum
endpoint address was taken as total number of endpoints in funciton.

This patch adds endpoint descriptors counting and storing their addresses
in eps_addrmap to verify their cohesion in each speed.

Endpoint address map would be also useful for further features, just like
vitual endpoint address mapping.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/function/f_fs.c | 67 +++---
 drivers/usb/gadget/function/u_fs.h |  2 ++
 2 files changed, 58 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index dc30adf..8096f22 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -155,6 +155,12 @@ struct ffs_io_data {
struct usb_request *req;
 };
 
+struct ffs_desc_helper {
+   struct ffs_data *ffs;
+   unsigned interfaces_count;
+   unsigned eps_count;
+};
+
 static int  __must_check ffs_epfiles_create(struct ffs_data *ffs);
 static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count);
 
@@ -1830,7 +1836,8 @@ static int __ffs_data_do_entity(enum ffs_entity_type type,
u8 *valuep, struct usb_descriptor_header *desc,
void *priv)
 {
-   struct ffs_data *ffs = priv;
+   struct ffs_desc_helper *helper = priv;
+   struct usb_endpoint_descriptor *d;
 
ENTER();
 
@@ -1844,8 +1851,8 @@ static int __ffs_data_do_entity(enum ffs_entity_type type,
 * encountered interface "n" then there are at least
 * "n+1" interfaces.
 */
-   if (*valuep >= ffs->interfaces_count)
-   ffs->interfaces_count = *valuep + 1;
+   if (*valuep >= helper->interfaces_count)
+   helper->interfaces_count = *valuep + 1;
break;
 
case FFS_STRING:
@@ -1853,14 +1860,23 @@ static int __ffs_data_do_entity(enum ffs_entity_type 
type,
 * Strings are indexed from 1 (0 is magic ;) reserved
 * for languages list or some such)
 */
-   if (*valuep > ffs->strings_count)
-   ffs->strings_count = *valuep;
+   if (*valuep > helper->ffs->strings_count)
+   helper->ffs->strings_count = *valuep;
break;
 
case FFS_ENDPOINT:
-   /* Endpoints are indexed from 1 as well. */
-   if ((*valuep & USB_ENDPOINT_NUMBER_MASK) > ffs->eps_count)
-   ffs->eps_count = (*valuep & USB_ENDPOINT_NUMBER_MASK);
+   d = (void *)desc;
+   helper->eps_count++;
+   if (helper->eps_count >= 15)
+   return -EINVAL;
+   if (!helper->ffs->eps_count && !helper->ffs->interfaces_count)
+   helper->ffs->eps_addrmap[helper->eps_count] =
+   d->bEndpointAddress;
+   else if (helper->ffs->eps_count < helper->eps_count)
+   return -EINVAL;
+   else if (helper->ffs->eps_addrmap[helper->eps_count] !=
+   d->bEndpointAddress)
+   return -EINVAL;
break;
}
 
@@ -2053,6 +2069,7 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
char *data = _data, *raw_descs;
unsigned os_descs_count = 0, counts[3], flags;
int ret = -EINVAL, i;
+   struct ffs_desc_helper helper;
 
ENTER();
 
@@ -2101,13 +2118,29 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
 
/* Read descriptors */
raw_descs = data;
+   helper.ffs = ffs;
for (i = 0; i < 3; ++i) {
if (!counts[i])
continue;
+   helper.interfaces_count = 0;
+   helper.eps_count = 0;
ret = ffs_do_descs(counts[i], data, len,
-  __ffs_data_do_entity, ffs);
+  __ffs_data_do_entity, &helper);
if (ret < 0)
goto error;
+   if (!ffs->eps_count && !ffs->interfaces_count) {
+   ffs->eps_count = helper.eps_count;
+   ffs->interfaces_count = helper.interfaces_count;
+   } else {
+   if (ffs->eps_count != helper.eps_count) {
+   ret = -EINVAL;
+   goto error;
+   }
+   if (ffs->interfaces_count != helper.interfaces_count) {
+   ret = -EINVAL;
+   goto error;
+   }
+ 

Re: [PATCH 02/13] usb: udc: set the udc is ready to pullup dp when it needs

[Peter Chen]

On Tue, Aug 19, 2014 at 09:02:54PM +, Paul Zimmerman wrote:
> > From: linux-usb-ow...@vger.kernel.org 
> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Peter Chen
> > Sent: Tuesday, August 19, 2014 7:26 AM
> > 
> > On Tue, Aug 19, 2014 at 01:46:17AM +, Paul Zimmerman wrote:
> > > > From: Peter Chen [mailto:peter.c...@freescale.com]
> > > > Sent: Sunday, August 17, 2014 9:14 PM
> > > >
> > > > Except for chipidea driver, all other udc drivers will tell the
> > > > gadget driver that they are ready to pullup dp at udc_start, it
> > > > is the default behaviour.
> > > >
> > > > The chipidea driver is ready to pullup dp when the vbus is there,
> > > > and isn't ready to pullup dp when the vbus is not there. Other
> > > > udc drivers which should not pull up when vbus is not there should
> > > > change like chipidea does to pass the Back-Voltage Testing at
> > > > www.usb.org/developers/docs/USB-IFTestProc1_3.pdf.
> > > >
> > > > Signed-off-by: Peter Chen 
> > > > ---
> > > >  drivers/usb/chipidea/udc.c  |9 -
> > > >  drivers/usb/dwc2/gadget.c   |2 ++
> > > >  drivers/usb/dwc3/gadget.c   |2 ++
> > > >  drivers/usb/gadget/udc/amd5536udc.c |1 +
> > > >  drivers/usb/gadget/udc/atmel_usba_udc.c |2 ++
> > > >  drivers/usb/gadget/udc/bcm63xx_udc.c|2 ++
> > > >  drivers/usb/gadget/udc/dummy_hcd.c  |1 +
> > > >  drivers/usb/gadget/udc/fotg210-udc.c|1 +
> > > >  drivers/usb/gadget/udc/fsl_qe_udc.c |1 +
> > > >  drivers/usb/gadget/udc/fsl_udc_core.c   |2 ++
> > > >  drivers/usb/gadget/udc/fusb300_udc.c|1 +
> > > >  drivers/usb/gadget/udc/gr_udc.c |2 ++
> > > >  drivers/usb/gadget/udc/lpc32xx_udc.c|2 ++
> > > >  drivers/usb/gadget/udc/m66592-udc.c |2 ++
> > > >  drivers/usb/gadget/udc/mv_u3d_core.c|1 +
> > > >  drivers/usb/gadget/udc/mv_udc_core.c|2 ++
> > > >  drivers/usb/gadget/udc/net2272.c|1 +
> > > >  drivers/usb/gadget/udc/net2280.c|1 +
> > > >  drivers/usb/gadget/udc/omap_udc.c   |1 +
> > > >  drivers/usb/gadget/udc/pch_udc.c|1 +
> > > >  drivers/usb/gadget/udc/pxa25x_udc.c |1 +
> > > >  drivers/usb/gadget/udc/pxa27x_udc.c |1 +
> > > >  drivers/usb/gadget/udc/r8a66597-udc.c   |1 +
> > > >  drivers/usb/gadget/udc/s3c-hsudc.c  |1 +
> > > >  drivers/usb/gadget/udc/s3c2410_udc.c|1 +
> > > >  drivers/usb/musb/musb_gadget.c  |2 ++
> > > >  drivers/usb/renesas_usbhs/mod_gadget.c  |7 ++-
> > > >  27 files changed, 45 insertions(+), 6 deletions(-)
> > >
> > > Instead of modifying all of the UDC drivers, how about adding a flag to
> > > 'struct usb_gadget' named 'needs_ready' or similar? If the UDC doesn't
> > > set the flag, udc-core would call usb_udc_ready_to_connect() on behalf
> > > of the UDC. If the UDC sets the flag (chipidea only?) then the UDC would
> > > be responsible for calling usb_udc_ready_to_connect().
> > >
> > 
> > USB spec requires dp is not pulled up when the vbus is not there, the dwc3 
> > is
> > the newest core, I don't think other older udc cores all has similar 
> > capability
> > that does don't draw back voltage if software pullup bit is set and vbus is
> > not there.
> > 
> > This patchset will delete the unconditional pullup dp operation at udc-core,
> > and we need to pullup dp at the end of hardware initialization (not consider
> > vbus case), then the end of .udc_start at udc driver is the old place.
> 
> I think you misunderstood my suggestion. Since you are adding a call
> to usb_udc_ready_to_connect() at the end of almost every .udc_start
> function, why not have udc-core do it instead, immediately after the
> call to .udc_start? Unless the 'needs_ready' flag is set, which would
> only be set by the udc drivers for those controllers that need it.
> 

Thanks.

Yes, we can do that, my original plan is 
usb_gadget_connect/usb_gadget_disconnect
are only called by gadget driver. If Felipe has no comment for it, I will
follow your suggestion for next revision, in fact, changing too many files
is really not a easy work:)

-- 
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 01/13] usb: gadget: introduce .connect gadget driver API

[Peter Chen]

On Tue, Aug 19, 2014 at 10:56:58AM -0400, Alan Stern wrote:
> On Tue, 19 Aug 2014, Peter Chen wrote:
> 
> > > > --- a/include/linux/usb/gadget.h
> > > > +++ b/include/linux/usb/gadget.h
> > > > @@ -873,12 +873,39 @@ struct usb_gadget_driver {
> > > > void(*disconnect)(struct usb_gadget *);
> > > > void(*suspend)(struct usb_gadget *);
> > > > void(*resume)(struct usb_gadget *);
> > > > +   int (*connect)(struct usb_gadget *, bool 
> > > > connect);
> > > >  
> > > > /* FIXME support safe rmmod */
> > > > struct device_driverdriver;
> > > >  };
> > > 
> > > This looks strange.  Why do you have the "bool connect" parameter?  
> > 
> > How can I tell the gadget driver to pull down dp after vbus is off?
> > 
> > > There's already a disconnect callback.
> > 
> > Maybe I need to use other name rather than connect, the .disconnect 
> > sometimes
> > is called at bus reset handler so I can't put dp control in it.
> 
> We could fix that.  Right now there are only about four files that 
> define a usb_gadget_driver structure.  All you have to do is make sure 
> they each contain a reset handler.
> 

Yes, it is easy to add reset handler, I am waiting Felipe's comment,
if he is no comments, I will send a patchset for adding reset handler first.

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

[PATCH 1/4] usbip: move usbip userspace code out of staging

[Valentina Manea]

At this point, USB/IP userspace code is fully functional
and can be moved out of staging.

Signed-off-by: Valentina Manea 
---
 {drivers/staging/usbip/userspace => tools/usb/usbip}/.gitignore   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/AUTHORS  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/COPYING  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/INSTALL  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/Makefile.am  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/README   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/autogen.sh   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/cleanup.sh   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/configure.ac | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbip.8  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbipd.8 | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/Makefile.am   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/list.h| 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.c   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.h   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/sysfs_utils.c | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/sysfs_utils.h | 0
 .../staging/usbip/userspace => tools/usb/usbip}/libsrc/usbip_common.c | 0
 .../staging/usbip/userspace => tools/usb/usbip}/libsrc/usbip_common.h | 0
 .../usbip/userspace => tools/usb/usbip}/libsrc/usbip_host_driver.c| 0
 .../usbip/userspace => tools/usb/usbip}/libsrc/usbip_host_driver.h| 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/vhci_driver.c | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/vhci_driver.h | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/Makefile.am  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip.c  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip.h  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_attach.c   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_bind.c | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_detach.c   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_list.c | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_network.c  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_network.h  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_port.c | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbip_unbind.c   | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/usbipd.c | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/utils.c  | 0
 {drivers/staging/usbip/userspace => tools/usb/usbip}/src/utils.h  | 0
 37 files changed, 0 insertions(+), 0 deletions(-)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/.gitignore (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/AUTHORS (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/COPYING (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/INSTALL (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/Makefile.am (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/README (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/autogen.sh (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/cleanup.sh (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/configure.ac (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbip.8 (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/doc/usbipd.8 (100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/Makefile.am 
(100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/list.h 
(100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.c 
(100%)
 rename {drivers/staging/usbip/userspace => tools/usb/usbip}/libsrc/names.h 
(100%)
 rename {drivers/staging/usbip/userspace => 
tools/usb/usbip}/libsrc/sysfs_utils.c (100%)
 rename {drivers/staging/usbip/userspace => 
tools/usb/usbip}/libsrc/sysfs_utils.h (100%)
 rename {drivers/staging/usbip/userspace => 
tools/usb/usbip}/libsrc/usbip_common.c (100%)
 rename {drivers/staging/usbip/userspace => 
tools/usb/usbip}/libsrc/usbip_common.h (100%)
 rename {drivers/staging/usbip/userspace => 
tools/usb/usbip}/libsrc/usbip_host_driver.c (100%)
 rename {drivers/staging/usbip/userspace => 
tools/usb/usbip}/libsrc/usbip_host_driver.h (100%)
 rename {drivers/staging/usbip/userspace => 
tools/usb/usbip}/libsrc/vhci_driver.c (100%)
 rename {drivers/staging/usbip/userspace => 
tools/us

[PATCH 0/4] *** SUBJECT HERE ***

[Valentina Manea]

After migrating userspace code to libudev, converting usbip-host
to a device driver and various bug fixes and enhancements, USB/IP
is fully functional and can be moved out of staging.

This patch series moves it as following:
* userspace code to tools/usb/usbip
* kernel code to drivers/usb/usbip

A warning generated in the kernel code is also solved and an entry
in MAINTAINERS file is created for this driver.

Valentina Manea (4):
  usbip: move usbip userspace code out of staging
  usbip: move usbip kernel code out of staging
  usbip: remove struct usb_device_id table
  MAINTAINERS: Add an entry for USB/IP driver

 MAINTAINERS|  8 +++
 drivers/staging/Kconfig|  2 --
 drivers/staging/Makefile   |  1 -
 drivers/usb/Kconfig|  2 ++
 drivers/usb/Makefile   |  2 ++
 drivers/{staging => usb}/usbip/Kconfig |  0
 drivers/{staging => usb}/usbip/Makefile|  0
 drivers/{staging => usb}/usbip/README  |  0
 drivers/{staging => usb}/usbip/stub.h  |  0
 drivers/{staging => usb}/usbip/stub_dev.c  | 27 --
 drivers/{staging => usb}/usbip/stub_main.c |  0
 drivers/{staging => usb}/usbip/stub_rx.c   |  0
 drivers/{staging => usb}/usbip/stub_tx.c   |  0
 drivers/{staging => usb}/usbip/usbip_common.c  |  0
 drivers/{staging => usb}/usbip/usbip_common.h  |  2 +-
 drivers/{staging => usb}/usbip/usbip_event.c   |  0
 drivers/{staging => usb}/usbip/usbip_protocol.txt  |  0
 drivers/{staging => usb}/usbip/vhci.h  |  0
 drivers/{staging => usb}/usbip/vhci_hcd.c  |  0
 drivers/{staging => usb}/usbip/vhci_rx.c   |  0
 drivers/{staging => usb}/usbip/vhci_sysfs.c|  0
 drivers/{staging => usb}/usbip/vhci_tx.c   |  0
 .../usbip/uapi => include/uapi/linux}/usbip.h  |  0
 .../usbip/userspace => tools/usb/usbip}/.gitignore |  0
 .../usbip/userspace => tools/usb/usbip}/AUTHORS|  0
 .../usbip/userspace => tools/usb/usbip}/COPYING|  0
 .../usbip/userspace => tools/usb/usbip}/INSTALL|  0
 .../userspace => tools/usb/usbip}/Makefile.am  |  0
 .../usbip/userspace => tools/usb/usbip}/README |  0
 .../usbip/userspace => tools/usb/usbip}/autogen.sh |  0
 .../usbip/userspace => tools/usb/usbip}/cleanup.sh |  0
 .../userspace => tools/usb/usbip}/configure.ac |  0
 .../userspace => tools/usb/usbip}/doc/usbip.8  |  0
 .../userspace => tools/usb/usbip}/doc/usbipd.8 |  0
 .../usb/usbip}/libsrc/Makefile.am  |  0
 .../userspace => tools/usb/usbip}/libsrc/list.h|  0
 .../userspace => tools/usb/usbip}/libsrc/names.c   |  0
 .../userspace => tools/usb/usbip}/libsrc/names.h   |  0
 .../usb/usbip}/libsrc/sysfs_utils.c|  0
 .../usb/usbip}/libsrc/sysfs_utils.h|  0
 .../usb/usbip}/libsrc/usbip_common.c   |  0
 .../usb/usbip}/libsrc/usbip_common.h   |  0
 .../usb/usbip}/libsrc/usbip_host_driver.c  |  0
 .../usb/usbip}/libsrc/usbip_host_driver.h  |  0
 .../usb/usbip}/libsrc/vhci_driver.c|  0
 .../usb/usbip}/libsrc/vhci_driver.h|  0
 .../userspace => tools/usb/usbip}/src/Makefile.am  |  0
 .../userspace => tools/usb/usbip}/src/usbip.c  |  0
 .../userspace => tools/usb/usbip}/src/usbip.h  |  0
 .../usb/usbip}/src/usbip_attach.c  |  0
 .../userspace => tools/usb/usbip}/src/usbip_bind.c |  0
 .../usb/usbip}/src/usbip_detach.c  |  0
 .../userspace => tools/usb/usbip}/src/usbip_list.c |  0
 .../usb/usbip}/src/usbip_network.c |  0
 .../usb/usbip}/src/usbip_network.h |  0
 .../userspace => tools/usb/usbip}/src/usbip_port.c |  0
 .../usb/usbip}/src/usbip_unbind.c  |  0
 .../userspace => tools/usb/usbip}/src/usbipd.c |  0
 .../userspace => tools/usb/usbip}/src/utils.c  |  0
 .../userspace => tools/usb/usbip}/src/utils.h  |  0
 60 files changed, 13 insertions(+), 31 deletions(-)
 rename drivers/{staging => usb}/usbip/Kconfig (100%)
 rename drivers/{staging => usb}/usbip/Makefile (100%)
 rename drivers/{staging => usb}/usbip/README (100%)
 rename drivers/{staging => usb}/usbip/stub.h (100%)
 rename drivers/{staging => usb}/usbip/stub_dev.c (90%)
 rename drivers/{staging => usb}/usbip/stub_main.c (100%)
 rename drivers/{staging => usb}/usbip/stub_rx.c (100%)
 rename drivers/{staging => usb}/usbip/stub_tx.c (100%)
 rename drivers/{staging => usb}/usbip/usbip_common.c (100%)
 rename drivers/{staging => usb}/usbip/usbip_common.h (99%)
 rename drivers/{staging => usb}/usbip/usbip_event.c (100%)
 rename drivers/{staging => usb}/usbip/usbip_protocol.txt (100%)
 rename drivers/{staging => usb}/usbip/vhci.h (100%)
 rename drivers/{staging => usb}/usbip/vhci_hcd.c (100%)
 rename drivers/{staging => usb}/usbip/vhci_rx.c (100%)
 renam

[PATCH 3/4] usbip: remove struct usb_device_id table

[Valentina Manea]

This was used back when usbip-host was an interface device driver;
after the conversion to device driver, the table remained unused.
Remove it in order to stop receiving a warning about it.

Signed-off-by: Valentina Manea 
---
 drivers/usb/usbip/stub_dev.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index 51d0c71..fac20e0 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -26,33 +26,6 @@
 #include "stub.h"
 
 /*
- * Define device IDs here if you want to explicitly limit exportable devices.
- * In most cases, wildcard matching will be okay because driver binding can be
- * changed dynamically by a userland program.
- */
-static struct usb_device_id stub_table[] = {
-#if 0
-   /* just an example */
-   { USB_DEVICE(0x05ac, 0x0301) },   /* Mac 1 button mouse */
-   { USB_DEVICE(0x0430, 0x0009) },   /* Plat Home Keyboard */
-   { USB_DEVICE(0x059b, 0x0001) },   /* Iomega USB Zip 100 */
-   { USB_DEVICE(0x04b3, 0x4427) },   /* IBM USB CD-ROM */
-   { USB_DEVICE(0x05a9, 0xa511) },   /* LifeView USB cam */
-   { USB_DEVICE(0x55aa, 0x0201) },   /* Imation card reader */
-   { USB_DEVICE(0x046d, 0x0870) },   /* Qcam Express(QV-30) */
-   { USB_DEVICE(0x04bb, 0x0101) },   /* IO-DATA HD 120GB */
-   { USB_DEVICE(0x04bb, 0x0904) },   /* IO-DATA USB-ET/TX */
-   { USB_DEVICE(0x04bb, 0x0201) },   /* IO-DATA USB-ET/TX */
-   { USB_DEVICE(0x08bb, 0x2702) },   /* ONKYO USB Speaker */
-   { USB_DEVICE(0x046d, 0x08b2) },   /* Logicool Qcam 4000 Pro */
-#endif
-   /* magic for wild card */
-   { .driver_info = 1 },
-   { 0, } /* Terminating entry */
-};
-MODULE_DEVICE_TABLE(usb, stub_table);
-
-/*
  * usbip_status shows the status of usbip-host as long as this driver is bound
  * to the target device.
  */
-- 
1.8.1.2

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

[PATCH 2/4] usbip: move usbip kernel code out of staging

[Valentina Manea]

At this point, USB/IP kernel code is fully functional
and can be moved out of staging.

Signed-off-by: Valentina Manea 
---
 drivers/staging/Kconfig| 2 --
 drivers/staging/Makefile   | 1 -
 drivers/usb/Kconfig| 2 ++
 drivers/usb/Makefile   | 2 ++
 drivers/{staging => usb}/usbip/Kconfig | 0
 drivers/{staging => usb}/usbip/Makefile| 0
 drivers/{staging => usb}/usbip/README  | 0
 drivers/{staging => usb}/usbip/stub.h  | 0
 drivers/{staging => usb}/usbip/stub_dev.c  | 0
 drivers/{staging => usb}/usbip/stub_main.c | 0
 drivers/{staging => usb}/usbip/stub_rx.c   | 0
 drivers/{staging => usb}/usbip/stub_tx.c   | 0
 drivers/{staging => usb}/usbip/usbip_common.c  | 0
 drivers/{staging => usb}/usbip/usbip_common.h  | 2 +-
 drivers/{staging => usb}/usbip/usbip_event.c   | 0
 drivers/{staging => usb}/usbip/usbip_protocol.txt  | 0
 drivers/{staging => usb}/usbip/vhci.h  | 0
 drivers/{staging => usb}/usbip/vhci_hcd.c  | 0
 drivers/{staging => usb}/usbip/vhci_rx.c   | 0
 drivers/{staging => usb}/usbip/vhci_sysfs.c| 0
 drivers/{staging => usb}/usbip/vhci_tx.c   | 0
 {drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h | 0
 22 files changed, 5 insertions(+), 4 deletions(-)
 rename drivers/{staging => usb}/usbip/Kconfig (100%)
 rename drivers/{staging => usb}/usbip/Makefile (100%)
 rename drivers/{staging => usb}/usbip/README (100%)
 rename drivers/{staging => usb}/usbip/stub.h (100%)
 rename drivers/{staging => usb}/usbip/stub_dev.c (100%)
 rename drivers/{staging => usb}/usbip/stub_main.c (100%)
 rename drivers/{staging => usb}/usbip/stub_rx.c (100%)
 rename drivers/{staging => usb}/usbip/stub_tx.c (100%)
 rename drivers/{staging => usb}/usbip/usbip_common.c (100%)
 rename drivers/{staging => usb}/usbip/usbip_common.h (99%)
 rename drivers/{staging => usb}/usbip/usbip_event.c (100%)
 rename drivers/{staging => usb}/usbip/usbip_protocol.txt (100%)
 rename drivers/{staging => usb}/usbip/vhci.h (100%)
 rename drivers/{staging => usb}/usbip/vhci_hcd.c (100%)
 rename drivers/{staging => usb}/usbip/vhci_rx.c (100%)
 rename drivers/{staging => usb}/usbip/vhci_sysfs.c (100%)
 rename drivers/{staging => usb}/usbip/vhci_tx.c (100%)
 rename {drivers/staging/usbip/uapi => include/uapi/linux}/usbip.h (100%)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 2c486ea..35b494f 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -28,8 +28,6 @@ source "drivers/staging/et131x/Kconfig"
 
 source "drivers/staging/slicoss/Kconfig"
 
-source "drivers/staging/usbip/Kconfig"
-
 source "drivers/staging/wlan-ng/Kconfig"
 
 source "drivers/staging/comedi/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 1e1a3a1..e66a5db 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -6,7 +6,6 @@ obj-$(CONFIG_STAGING)   += staging.o
 obj-y  += media/
 obj-$(CONFIG_ET131X)   += et131x/
 obj-$(CONFIG_SLICOSS)  += slicoss/
-obj-$(CONFIG_USBIP_CORE)   += usbip/
 obj-$(CONFIG_PRISM2_USB)   += wlan-ng/
 obj-$(CONFIG_COMEDI)   += comedi/
 obj-$(CONFIG_FB_OLPC_DCON) += olpc_dcon/
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index e0cad44..cf1b19b 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -92,6 +92,8 @@ source "drivers/usb/storage/Kconfig"
 
 source "drivers/usb/image/Kconfig"
 
+source "drivers/usb/usbip/Kconfig"
+
 endif
 
 source "drivers/usb/musb/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 3cba892..d7be717 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -60,3 +60,5 @@ obj-$(CONFIG_USB_RENESAS_USBHS)   += renesas_usbhs/
 obj-$(CONFIG_USB_GADGET)   += gadget/
 
 obj-$(CONFIG_USB_COMMON)   += common/
+
+obj-$(CONFIG_USBIP_CORE)   += usbip/
diff --git a/drivers/staging/usbip/Kconfig b/drivers/usb/usbip/Kconfig
similarity index 100%
rename from drivers/staging/usbip/Kconfig
rename to drivers/usb/usbip/Kconfig
diff --git a/drivers/staging/usbip/Makefile b/drivers/usb/usbip/Makefile
similarity index 100%
rename from drivers/staging/usbip/Makefile
rename to drivers/usb/usbip/Makefile
diff --git a/drivers/staging/usbip/README b/drivers/usb/usbip/README
similarity index 100%
rename from drivers/staging/usbip/README
rename to drivers/usb/usbip/README
diff --git a/drivers/staging/usbip/stub.h b/drivers/usb/usbip/stub.h
similarity index 100%
rename from drivers/staging/usbip/stub.h
rename to drivers/usb/usbip/stub.h
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
similarity index 100%
rename from 

[PATCH 4/4] MAINTAINERS: Add an entry for USB/IP driver

[Valentina Manea]

This patch adds an entry in MAINTAINERS file for USB/IP
driver.

Signed-off-by: Valentina Manea 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aefa948..76ac03d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9515,6 +9515,14 @@ S:   Maintained
 F: Documentation/usb/ohci.txt
 F: drivers/usb/host/ohci*
 
+USB OVER IP DRIVER
+M: Valentina Manea 
+M: Shuah Khan 
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/usbip/
+F: tools/usb/usbip/
+
 USB PEGASUS DRIVER
 M: Petko Manolov 
 L: linux-usb@vger.kernel.org
-- 
1.8.1.2

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

Re: [PATCH 2/3] usbip: move usbip kernel code out of staging

[Greg KH]

On Tue, Aug 19, 2014 at 08:21:47PM -0700, Valentina Manea wrote:
> On Tue, Aug 19, 2014 at 11:38 AM, Greg KH  wrote:
> >
> > This patch moves the code, but now it's "gone" from the build system as
> > it is not hooked up and can not be built at all.
> >
> > So while I really wanted to apply this series right now, I can't, as
> > this is a regression (working driver -> no driver).
> 
> You mean it should be in Kbuild and Makefile from drivers/, right?

Yes, in drivers/usb/

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 2/3] usbip: move usbip kernel code out of staging

[Valentina Manea]

On Tue, Aug 19, 2014 at 11:38 AM, Greg KH  wrote:
>
> This patch moves the code, but now it's "gone" from the build system as
> it is not hooked up and can not be built at all.
>
> So while I really wanted to apply this series right now, I can't, as
> this is a regression (working driver -> no driver).

You mean it should be in Kbuild and Makefile from drivers/, right?
Will resend the series again, with MAINTAINERS modified.

Thanks,
Valentina
--
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: pch_udc: USB gadget device support for Intel Quark X1000

[Felipe Balbi]

Hi,

On Wed, Aug 20, 2014 at 12:46:33AM +, Chen, Alvin wrote:
> 
> > Hi,
> > 
> > On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote:
> > > From: Bryan O'Donoghue 
> > >
> > > This patch is to enable the USB gadget device for Intel Quark X1000
> > >
> > > Signed-off-by: Bryan O'Donoghue 
> > > Signed-off-by: Bing Niu 
> > > Signed-off-by: Alvin (Weike) Chen 
> > 
> > Can someone confirm to me this is not another incarnation of chipidea ?
> 
> No, this is not another incarnation of chipidea. And its cover letter is as 
> following:
> 
> On Mon, Aug 04, 2014 at 11:00:07AM -0700, Chen, Alvin wrote:
> > From: "Alvin (Weike) Chen" 
> > 
> > Hi,
> > Intel Quark X1000 consists of one USB gadget device which can be PCI 
> > enumerated. 
> > pch_udc layer doesn't support it. Thus, we add support for Intel Quark 
> > X1000 USB gadget device as well.

hehe, right I *know* what the patch is doing. I can read the diff and
figure out that you're adding support for Quark to PCH UDC because
Quark's USB IP is the same, what I wasking was if that IP was actually
an instance of the chipidea UDC. After looking at the address space
definitions on both drivers, I see that it's not.

So tomorrow I'll look at this patch again.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb: dwc2: gadget: Set the default EP max packet value as 8 bytes

[Jingoo Han]

Set the default EP max packet value as 8 bytes, because in the case
of low-speed, 'ep_mps' is not set. Thus, the default value of 'ep_mps'
should be considered for the case of low-speed.

Signed-off-by: Jingoo Han 
---
- Based on the latest 'usb-linus' branch.

 drivers/usb/dwc2/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 2a6f76b0075e..7c9618e916e2 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1901,7 +1901,7 @@ static void s3c_hsotg_epint(struct s3c_hsotg *hsotg, 
unsigned int idx,
 static void s3c_hsotg_irq_enumdone(struct s3c_hsotg *hsotg)
 {
u32 dsts = readl(hsotg->regs + DSTS);
-   int ep0_mps = 0, ep_mps = 1023;
+   int ep0_mps = 0, ep_mps = 8;
 
/*
 * This should signal the finish of the enumeration phase
-- 
2.0.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: [PATCH v2 2/3] usb: gadget/uvc: also handle v4l2 ioctl ENUM_FMT

[Hans Verkuil]

On 08/19/2014 05:01 PM, Laurent Pinchart wrote:
> Hi Michael,
> 
> Thank you for the patch.
> 
> (CC'ing Hans Verkuil and the linux-media mailing list)
> 
> On Friday 08 August 2014 17:38:58 Michael Grzeschik wrote:
>> This patch adds ENUM_FMT as possible ioctl to the uvc v4l2 device.
>> That makes userspace applications with a generic IOCTL calling
>> convention make also use of it.
>>
>> Signed-off-by: Michael Grzeschik 
>> ---
>> v1 -> v2:
>>  - changed first switch case to simple if
>>  - added separate function
>>  - added description field
>>  - bail out on array boundaries
>>
>>  drivers/usb/gadget/uvc_v4l2.c | 30 --
>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
>> index ad48e81..58633bf 100644
>> --- a/drivers/usb/gadget/uvc_v4l2.c
>> +++ b/drivers/usb/gadget/uvc_v4l2.c
>> @@ -55,14 +55,30 @@ struct uvc_format
>>  {
>>  u8 bpp;
>>  u32 fcc;
>> +char *description;
>>  };
>>
>>  static struct uvc_format uvc_formats[] = {
>> -{ 16, V4L2_PIX_FMT_YUYV  },
>> -{ 0,  V4L2_PIX_FMT_MJPEG },
>> +{ 16, V4L2_PIX_FMT_YUYV, "YUV 4:2:2" },
>> +{ 0,  V4L2_PIX_FMT_MJPEG, "MJPEG" },
> 
> Format descriptions are currently duplicated in every driver, causing higher 
> memory usage and different descriptions for the same format depending on the 
> driver. Hans, should we try to fix this ?

Yes, we should. It's been on my todo list for ages, but at a very low priority.
I'm not planning to work on this in the near future, but if someone else wants
to work on this, then just go ahead.

Regards,

Hans

> 
>>  };
>>
>>  static int
>> +uvc_v4l2_enum_format(struct uvc_video *video, struct v4l2_fmtdesc *fmt)
>> +{
>> +
> 
> There's an extra blank line here.
> 
>> +int index = fmt->index;
> 
> You can use fmt->index directly below, there's no need for a local variable.
> 
>> +if (index >= ARRAY_SIZE(uvc_formats))
>> +return -EINVAL;
>> +
>> +strcpy(fmt->description, uvc_formats[index].description);
> 
> How about strlcpy to make sure we don't overflow the buffer ?
> 
>> +fmt->pixelformat = uvc_formats[index].fcc;
>> +
>> +return 0;
>> +}
>> +
>> +static int
>>  uvc_v4l2_get_format(struct uvc_video *video, struct v4l2_format *fmt)
>>  {
>>  fmt->fmt.pix.pixelformat = video->fcc;
>> @@ -183,6 +199,16 @@ uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd,
>> void *arg) break;
>>  }
>>
>> +case VIDIOC_ENUM_FMT:
>> +{
>> +struct v4l2_fmtdesc *fmt = arg;
>> +
>> +if (fmt->type != video->queue.queue.type)
>> +return -EINVAL;
>> +
>> +return uvc_v4l2_enum_format(video, fmt);
>> +}
>> +
>>  /* Get & Set format */
>>  case VIDIOC_G_FMT:
> 

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

RE: [PATCH 1/3] usb: dwc2: gadget: fix below build warning

[Paul Zimmerman]

> From: Jingoo Han [mailto:jg1@samsung.com]
> Sent: Tuesday, August 19, 2014 6:16 PM
> 
> On Tuesday, August 19, 2014 8:08 AM, Paul Zimmerman wrote:
> >
> > > From: Paul Zimmerman
> > > Sent: Monday, August 18, 2014 11:03 AM
> > >
> > > > From: Jingoo Han [mailto:jg1@samsung.com]
> > > > Sent: Monday, August 18, 2014 2:17 AM
> > > >
> > > > On Monday, August 18, 2014 5:32 PM, Peter Chen wrote:
> > > > >
> > > > > linux-2.6/drivers/usb/dwc2/gadget.c: In function 
> > > > > 's3c_hsotg_irq_enumdone':
> > > > > linux-2.6/drivers/usb/dwc2/gadget.c:1904: warning: 'ep_mps' may be 
> > > > > used uninitialized in this
> > function
> > > >
> > > > (+cc  Dinh Nguyen)
> > > >
> > > > I think that this warning is false.
> > > > Because, 'ep_mps' cannot be used uninitialized in 
> > > > s3c_hsotg_irq_enumdone().
> > > >
> > > > static void s3c_hsotg_irq_enumdone(struct s3c_hsotg *hsotg)
> > > > {
> > > > int ep0_mps = 0, ep_mps;
> > > >
> > > > case DSTS_ENUMSPD_FS:
> > > > case DSTS_ENUMSPD_FS48:
> > > > ep0_mps = EP0_MPS_LIMIT;
> > > > ep_mps = 1023;
> > > > break;
> > > >
> > > > case DSTS_ENUMSPD_HS:
> > > > ep0_mps = EP0_MPS_LIMIT;
> > > > ep_mps = 1024;
> > > > break;
> > > >
> > > > In the case of DSTS_ENUMSPD_FS, DSTS_ENUMSPD_FS48, and DSTS_ENUMSPD_HS,
> > > > both 'ep0_mps' and 'ep_mps' are initialized.
> > > >
> > > > case DSTS_ENUMSPD_LS:
> > > > hsotg->gadget.speed = USB_SPEED_LOW;
> > > > break;
> > > >
> > > > In the case of DSTS_ENUMSPD_LS, 'ep_mps' is uninitialized.
> > > > But, 'ep0_mps' is also '0'.
> > > >
> > > > .
> > > >
> > > > if (ep0_mps) {
> > > > int i;
> > > > s3c_hsotg_set_ep_maxpacket(hsotg, 0, ep0_mps);
> > > > for (i = 1; i < hsotg->num_of_eps; i++)
> > > > s3c_hsotg_set_ep_maxpacket(hsotg, i, ep_mps);
> > > > }
> > > >
> > > > If 'ep0_mps' is '0', 'ep_mps' will not be used.
> > > > So, uninitialized 'ep_mps' cannot be used.
> > > >
> > > > However, in the future, it is not sure that the current scheme
> > > > will not be modified. Thus, in order to make sure the code safety,
> > > > this patch may be necessary.
> > >
> > > But 0 is not a valid default value for an endpoint mps. So I think the
> > > patch serves no purpose other than to shut up the compiler. That's OK
> > > with me, but I think the usual kernel practice is not to add unnecessary
> > > initializations just to silence a compiler warning.
> >
> > Sorry, I lost the context of the original patch because Jingoo didn't
> > quote it.
> 
> Please don't blame me. It is unrelated with me.
> In addition, I did not said that 'ep_mps' is 0.

Sorry, I didn't mean to blame you. I was just stating a fact - since
the original patch wasn't in your email that I was replying to, I
mis-remembered what the change was.

> > I see the patch sets the default mps to 1024, not 0.
> >
> > However, 1024 is not a valid mps in the case of full-speed. If you change
> > the value to 1023, you can add my acked-by.
> 
> No, low-speed should be considered.
> In the case of full-speed, 'ep_mps' is set as 1023.
> However, in the case of full-speed, 'ep_mps' is not set.
> 
> The maximum data payload size allowed for low-speed devices
> is 8 bytes. So, this patch should set the default mps as '8'
> for the low-speed.

I think the patch is fine as-is. As the comment in that function says,
the driver doesn't support low-speed anyway. But if you want to change
it to 8, please submit a patch for that, since Peter's patch has
already been added to Greg's tree.

-- 
Paul

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

Re: [PATCH v2 1/3] usb: dwc2: gadget: fix below build warning

[Jingoo Han]

On Tuesday, August 19, 2014 9:56 AM, Peter Chen wrote:
> 
> linux-2.6/drivers/usb/dwc2/gadget.c: In function 's3c_hsotg_irq_enumdone':
> linux-2.6/drivers/usb/dwc2/gadget.c:1904: warning: 'ep_mps' may be used 
> uninitialized in this function
> 
> Acked-by: Paul Zimmerman 
> Signed-off-by: Peter Chen 
> ---
> Changes for v2:
> - Add Paul's suggestion and ack
> 
>  drivers/usb/dwc2/gadget.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 2421eaa..6bcc644 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -1901,7 +1901,7 @@ static void s3c_hsotg_epint(struct s3c_hsotg *hsotg, 
> unsigned int idx,
>  static void s3c_hsotg_irq_enumdone(struct s3c_hsotg *hsotg)
>  {
>   u32 dsts = readl(hsotg->regs + DSTS);
> - int ep0_mps = 0, ep_mps;
> + int ep0_mps = 0, ep_mps = 1023;

(+cc  Dinh Nguyen)

static void s3c_hsotg_irq_enumdone(struct s3c_hsotg *hsotg)
{
u32 dsts = readl(hsotg->regs + DSTS);
int ep0_mps = 0, ep_mps;

.

case DSTS_ENUMSPD_FS:
case DSTS_ENUMSPD_FS48:
ep0_mps = EP0_MPS_LIMIT;
ep_mps = 1023;
break;

case DSTS_ENUMSPD_HS:
ep0_mps = EP0_MPS_LIMIT;
ep_mps = 1024;
break;

case DSTS_ENUMSPD_LS:
hsotg->gadget.speed = USB_SPEED_LOW;
break;

Only low-speed does NOT set 'ep_mps'. Thus, the default value
of 'ep_mps' should be considered for the case of low-speed.
According to the USB2.0 spec, the maximum data payload size
allowed for low-speed devices is 8 bytes. So, this patch should set
the 'ep_mps' as '8' for the low-speed.

What I mean is as follows:

-   int ep0_mps = 0, ep_mps;
+   int ep0_mps = 0, ep_mps = 8;

Best regards,
Jingoo Han

> 
>   /*
>* This should signal the finish of the enumeration phase
> --
> 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 1/3] usb: dwc2: gadget: fix below build warning

[Jingoo Han]

On Tuesday, August 19, 2014 8:08 AM, Paul Zimmerman wrote:
> 
> > From: Paul Zimmerman
> > Sent: Monday, August 18, 2014 11:03 AM
> >
> > > From: Jingoo Han [mailto:jg1@samsung.com]
> > > Sent: Monday, August 18, 2014 2:17 AM
> > >
> > > On Monday, August 18, 2014 5:32 PM, Peter Chen wrote:
> > > >
> > > > linux-2.6/drivers/usb/dwc2/gadget.c: In function 
> > > > 's3c_hsotg_irq_enumdone':
> > > > linux-2.6/drivers/usb/dwc2/gadget.c:1904: warning: 'ep_mps' may be used 
> > > > uninitialized in this
> function
> > >
> > > (+cc  Dinh Nguyen)
> > >
> > > I think that this warning is false.
> > > Because, 'ep_mps' cannot be used uninitialized in 
> > > s3c_hsotg_irq_enumdone().
> > >
> > > static void s3c_hsotg_irq_enumdone(struct s3c_hsotg *hsotg)
> > > {
> > >   int ep0_mps = 0, ep_mps;
> > >
> > >   case DSTS_ENUMSPD_FS:
> > >   case DSTS_ENUMSPD_FS48:
> > >   ep0_mps = EP0_MPS_LIMIT;
> > >   ep_mps = 1023;
> > >   break;
> > >
> > >   case DSTS_ENUMSPD_HS:
> > >   ep0_mps = EP0_MPS_LIMIT;
> > >   ep_mps = 1024;
> > >   break;
> > >
> > > In the case of DSTS_ENUMSPD_FS, DSTS_ENUMSPD_FS48, and DSTS_ENUMSPD_HS,
> > > both 'ep0_mps' and 'ep_mps' are initialized.
> > >
> > >   case DSTS_ENUMSPD_LS:
> > >   hsotg->gadget.speed = USB_SPEED_LOW;
> > >   break;
> > >
> > > In the case of DSTS_ENUMSPD_LS, 'ep_mps' is uninitialized.
> > > But, 'ep0_mps' is also '0'.
> > >
> > >   .
> > >
> > >   if (ep0_mps) {
> > >   int i;
> > >   s3c_hsotg_set_ep_maxpacket(hsotg, 0, ep0_mps);
> > >   for (i = 1; i < hsotg->num_of_eps; i++)
> > >   s3c_hsotg_set_ep_maxpacket(hsotg, i, ep_mps);
> > >   }
> > >
> > > If 'ep0_mps' is '0', 'ep_mps' will not be used.
> > > So, uninitialized 'ep_mps' cannot be used.
> > >
> > > However, in the future, it is not sure that the current scheme
> > > will not be modified. Thus, in order to make sure the code safety,
> > > this patch may be necessary.
> >
> > But 0 is not a valid default value for an endpoint mps. So I think the
> > patch serves no purpose other than to shut up the compiler. That's OK
> > with me, but I think the usual kernel practice is not to add unnecessary
> > initializations just to silence a compiler warning.
> 
> Sorry, I lost the context of the original patch because Jingoo didn't
> quote it.

Please don't blame me. It is unrelated with me.
In addition, I did not said that 'ep_mps' is 0.

> I see the patch sets the default mps to 1024, not 0.
> 
> However, 1024 is not a valid mps in the case of full-speed. If you change
> the value to 1023, you can add my acked-by.

No, low-speed should be considered.
In the case of full-speed, 'ep_mps' is set as 1023.
However, in the case of full-speed, 'ep_mps' is not set.

The maximum data payload size allowed for low-speed devices
is 8 bytes. So, this patch should set the default mps as '8'
for the low-speed.

Best regards,
Jingoo Han

> 
> --
> Paul

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

RE: [PATCH] USB: pch_udc: USB gadget device support for Intel Quark X1000

[Chen, Alvin]

> Hi,
> 
> On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote:
> > From: Bryan O'Donoghue 
> >
> > This patch is to enable the USB gadget device for Intel Quark X1000
> >
> > Signed-off-by: Bryan O'Donoghue 
> > Signed-off-by: Bing Niu 
> > Signed-off-by: Alvin (Weike) Chen 
> 
> Can someone confirm to me this is not another incarnation of chipidea ?

No, this is not another incarnation of chipidea. And its cover letter is as 
following:

On Mon, Aug 04, 2014 at 11:00:07AM -0700, Chen, Alvin wrote:
> From: "Alvin (Weike) Chen" 
> 
> Hi,
> Intel Quark X1000 consists of one USB gadget device which can be PCI 
> enumerated. 
> pch_udc layer doesn't support it. Thus, we add support for Intel Quark 
> X1000 USB gadget device as well.
--
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: [linux-usb] USB Gadget drivers Windows 7/8 support and .bAlternateSetting in interface descriptor

[Peter Chen]

On Tue, Aug 19, 2014 at 09:36:19AM -0500, Felipe Balbi wrote:
> On Tue, Aug 19, 2014 at 10:27:39PM +0800, Peter Chen wrote:
> > On Tue, Aug 19, 2014 at 06:05:27PM +0800, Xuebing Wang wrote:
> > > 
> > > On 08/19/2014 12:58 PM, Peter Chen wrote:
> > > >>My environment is Freescale i.MX6SL EVK board (as USB peripheral 
> > > >>device),
> > > >>which is based on kernel 3.10.17. i.MX6SL uses ChipIdea dual-role
> > > >>controller.
> > > >>
> > > >>My problem is that gadget drivers g_ether and g_audio (UAC1 enabled) can
> > > >>NOT be detected by Windows 7 natively, while g_mass_storage, g_serial,
> > > >>g_hid can be detected by Windows 7 natively.
> > > >>
> > > >>1) I found that both Ether and USB Audio uses .bAlternateSetting, while
> > > >>Mass Storage, Serial and HID do NOT. I am wondering if this is related 
> > > >>to
> > > >>how Gadget framework handles USB_REQ_SET_INTERFACE request?
> > > >>
> > > >If possible, would you use Linux PC or Mac OS (macbook pro+) to test?
> > > >>From my previous experiences, g_audio works not well with windows.
> > > 
> > > Thanks Peter. g_audio is now working with Ubuntu and MacOS host, but
> > > can NOT get detected by Windows 7.
> > > 
> > > I am not sure if this Windows 7 detection issue is not specific to
> > > g_audio (UAC1), because Windows can NOT natively detect g_ether
> > > (even with RNDIS CONFIG_USB_ETH_RNDIS=y enabled).
> > > 
> > > Also, in file f_rndis.c, it says "/* Some controllers can't support
> > > RNDIS ... */", I am not sure what does this mean. Does it mean
> > > possibly controller like ChipIdea does NOT support RNDIS?
> > > 
> > 
> > RNDIS is software stuff, isn't it?
> 
> it probably means that some HW configuration doesn't have enough
> endpoints, or doesn't support a certain transfer type ;-)
> 

Thanks, so Xunbing, the imx6 hardware (chipidea core) have 8 endpoints,
and support all four transfer type, it should be no problem to support
RNDIS.


-- 
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 v2] usb: dwc3: add tracepoints to aid debugging

[Paul Zimmerman]

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, August 19, 2014 3:02 PM
> 
> I didn't have time to test this yet (other than build testing), but how
> does this one look ? Now we will print cute little strings for all
> events and we still have proper link state tracking.
> 
> 8<-
> 
> From 513ba489d66ff81eca056b41fda0cc965e6fe3ed Mon Sep 17 00:00:00 2001
> From: Felipe Balbi 
> Date: Wed, 30 Apr 2014 17:45:10 -0500
> Subject: [PATCH] usb: dwc3: add tracepoints to aid debugging
> 
> When we're debugging hard-to-reproduce and time-sensitive
> use cases, printk() poses too much overhead. That's when
> the kernel's tracing infrastructure comes into play.
> 
> This patch implements a few initial tracepoints for the
> dwc3 driver. More traces can be added as necessary in order
> to ease the task of debugging dwc3.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/dwc3/Makefile |   5 +-
>  drivers/usb/dwc3/core.h   |   2 +
>  drivers/usb/dwc3/debug.c  |  73 ++
>  drivers/usb/dwc3/debug.h  |   5 ++
>  drivers/usb/dwc3/ep0.c|   2 +
>  drivers/usb/dwc3/gadget.c |  27 +-
>  drivers/usb/dwc3/io.h |  30 +--
>  drivers/usb/dwc3/trace.c  |  19 +++
>  drivers/usb/dwc3/trace.h  | 128 
> ++
>  9 files changed, 272 insertions(+), 19 deletions(-)
>  create mode 100644 drivers/usb/dwc3/debug.c
>  create mode 100644 drivers/usb/dwc3/trace.c
>  create mode 100644 drivers/usb/dwc3/trace.h
> 
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index 10ac3e7..7793e6c 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -1,9 +1,12 @@
> +# define_trace.h needs to know how to find our header
> +CFLAGS_trace.o   := -I$(src)
> +
>  ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG
>  ccflags-$(CONFIG_USB_DWC3_VERBOSE)   += -DVERBOSE_DEBUG
> 
>  obj-$(CONFIG_USB_DWC3)   += dwc3.o
> 
> -dwc3-y   := core.o
> +dwc3-y   := core.o debug.o trace.o
> 
>  ifneq ($(filter y,$(CONFIG_USB_DWC3_HOST) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
>   dwc3-y  += host.o
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 48fb264..dbdad87 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -33,6 +33,8 @@
> 
>  #include 
> 
> +#define DWC3_MSG_MAX 500
> +
>  /* Global constants */
>  #define DWC3_EP0_BOUNCE_SIZE 512
>  #define DWC3_ENDPOINTS_NUM   32
> diff --git a/drivers/usb/dwc3/debug.c b/drivers/usb/dwc3/debug.c
> new file mode 100644
> index 000..6e109ce
> --- /dev/null
> +++ b/drivers/usb/dwc3/debug.c
> @@ -0,0 +1,73 @@
> +/**
> + * debug.c - DesignWare USB3 DRD Controller Debug/Trace Support
> + *
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * Author: Felipe Balbi 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "core.h"
> +#include "debug.h"
> +
> +static char event_str[DWC3_MSG_MAX];
> +
> +static void dwc3_endpoint_event_str(struct dwc3 *dwc,
> + const struct dwc3_event_depevt *event)
> +{
> + struct dwc3_ep *dep = dwc->eps[event->endpoint_number];
> +
> + snprintf(event_str, DWC3_MSG_MAX, "%s %s", dep->name,
> + dwc3_ep_event_string(event->endpoint_event));

Maybe you should also include the raw event data in the trace? Some
of the other bits in the event besides the event number can tell you
useful things while debugging.

> +}
> +
> +static void dwc3_gadget_event_str(struct dwc3 *dwc,
> + const struct dwc3_event_devt *devt)
> +{
> + snprintf(event_str, DWC3_MSG_MAX, "%s",
> + dwc3_gadget_event_type_string(devt->type));

Ditto here.

-- 
Paul

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

Re: [PATCH v2] usb: dwc3: add tracepoints to aid debugging

[Felipe Balbi]

Hi,

On Tue, Aug 19, 2014 at 08:14:11PM +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Tuesday, August 19, 2014 1:10 PM
> > 
> > On Tue, Aug 19, 2014 at 08:00:27PM +, Paul Zimmerman wrote:
> > > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > > Sent: Tuesday, August 19, 2014 12:09 PM
> > > >
> > > > When we're debugging hard-to-reproduce and time-sensitive
> > > > use cases, printk() poses too much overhead. That's when
> > > > the kernel's tracing infrastructure comes into play.
> > > >
> > > > This patch implements a few initial tracepoints for the
> > > > dwc3 driver. More traces can be added as necessary in order
> > > > to ease the task of debugging dwc3.
> > > >
> > > > Signed-off-by: Felipe Balbi 
> > > > ---
> > > >
> > > > Hi guys,
> > > >
> > > > here's v2 of my dwc3 tracepoints patch. Please have a look and
> > > > *CAREFULLY* consider if we want to add anything else.
> > > >
> > > > Paul, I believe you have much more experience in debugging early
> > > > HW releases with FPGA models than any of us, so tracing is likely
> > > > to help you, is there anything you'd want me to add to as a tracepoint ?
> > >
> > > What about the "unexpected" interrupt events? It would be nice to see if
> > > we receive e.g. an EVENT_OVERFLOW interrupt. Especially since you have
> > > some of those events enabled, but don't have handlers for all of them.
> > >
> > > Maybe a single tracepoint for all of the unexpected events?
> > 
> > Makes sense, I was thinking of a neater way to just pass the event
> > structure and decode it withing the trace itself. Then we can even
> > remove all the event-specific traces, would that help ?
> 
> Yeah, that's sounds even better.
> 
> > I guess with that we would have a pretty neat setup where we can trace
> > TRB lifetime, all register accesses and events.
> 
> Nice.

I didn't have time to test this yet (other than build testing), but how
does this one look ? Now we will print cute little strings for all
events and we still have proper link state tracking.

8<-

From 513ba489d66ff81eca056b41fda0cc965e6fe3ed Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Wed, 30 Apr 2014 17:45:10 -0500
Subject: [PATCH] usb: dwc3: add tracepoints to aid debugging

When we're debugging hard-to-reproduce and time-sensitive
use cases, printk() poses too much overhead. That's when
the kernel's tracing infrastructure comes into play.

This patch implements a few initial tracepoints for the
dwc3 driver. More traces can be added as necessary in order
to ease the task of debugging dwc3.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/Makefile |   5 +-
 drivers/usb/dwc3/core.h   |   2 +
 drivers/usb/dwc3/debug.c  |  73 ++
 drivers/usb/dwc3/debug.h  |   5 ++
 drivers/usb/dwc3/ep0.c|   2 +
 drivers/usb/dwc3/gadget.c |  27 +-
 drivers/usb/dwc3/io.h |  30 +--
 drivers/usb/dwc3/trace.c  |  19 +++
 drivers/usb/dwc3/trace.h  | 128 ++
 9 files changed, 272 insertions(+), 19 deletions(-)
 create mode 100644 drivers/usb/dwc3/debug.c
 create mode 100644 drivers/usb/dwc3/trace.c
 create mode 100644 drivers/usb/dwc3/trace.h

diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..7793e6c 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -1,9 +1,12 @@
+# define_trace.h needs to know how to find our header
+CFLAGS_trace.o := -I$(src)
+
 ccflags-$(CONFIG_USB_DWC3_DEBUG)   := -DDEBUG
 ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
 
 obj-$(CONFIG_USB_DWC3) += dwc3.o
 
-dwc3-y := core.o
+dwc3-y := core.o debug.o trace.o
 
 ifneq ($(filter y,$(CONFIG_USB_DWC3_HOST) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y  += host.o
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 48fb264..dbdad87 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -33,6 +33,8 @@
 
 #include 
 
+#define DWC3_MSG_MAX   500
+
 /* Global constants */
 #define DWC3_EP0_BOUNCE_SIZE   512
 #define DWC3_ENDPOINTS_NUM 32
diff --git a/drivers/usb/dwc3/debug.c b/drivers/usb/dwc3/debug.c
new file mode 100644
index 000..6e109ce
--- /dev/null
+++ b/drivers/usb/dwc3/debug.c
@@ -0,0 +1,73 @@
+/**
+ * debug.c - DesignWare USB3 DRD Controller Debug/Trace Support
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Felipe Balbi 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABI

RE: [PATCH 02/13] usb: udc: set the udc is ready to pullup dp when it needs

[Paul Zimmerman]

> From: linux-usb-ow...@vger.kernel.org 
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Peter Chen
> Sent: Tuesday, August 19, 2014 7:26 AM
> 
> On Tue, Aug 19, 2014 at 01:46:17AM +, Paul Zimmerman wrote:
> > > From: Peter Chen [mailto:peter.c...@freescale.com]
> > > Sent: Sunday, August 17, 2014 9:14 PM
> > >
> > > Except for chipidea driver, all other udc drivers will tell the
> > > gadget driver that they are ready to pullup dp at udc_start, it
> > > is the default behaviour.
> > >
> > > The chipidea driver is ready to pullup dp when the vbus is there,
> > > and isn't ready to pullup dp when the vbus is not there. Other
> > > udc drivers which should not pull up when vbus is not there should
> > > change like chipidea does to pass the Back-Voltage Testing at
> > > www.usb.org/developers/docs/USB-IFTestProc1_3.pdf.
> > >
> > > Signed-off-by: Peter Chen 
> > > ---
> > >  drivers/usb/chipidea/udc.c  |9 -
> > >  drivers/usb/dwc2/gadget.c   |2 ++
> > >  drivers/usb/dwc3/gadget.c   |2 ++
> > >  drivers/usb/gadget/udc/amd5536udc.c |1 +
> > >  drivers/usb/gadget/udc/atmel_usba_udc.c |2 ++
> > >  drivers/usb/gadget/udc/bcm63xx_udc.c|2 ++
> > >  drivers/usb/gadget/udc/dummy_hcd.c  |1 +
> > >  drivers/usb/gadget/udc/fotg210-udc.c|1 +
> > >  drivers/usb/gadget/udc/fsl_qe_udc.c |1 +
> > >  drivers/usb/gadget/udc/fsl_udc_core.c   |2 ++
> > >  drivers/usb/gadget/udc/fusb300_udc.c|1 +
> > >  drivers/usb/gadget/udc/gr_udc.c |2 ++
> > >  drivers/usb/gadget/udc/lpc32xx_udc.c|2 ++
> > >  drivers/usb/gadget/udc/m66592-udc.c |2 ++
> > >  drivers/usb/gadget/udc/mv_u3d_core.c|1 +
> > >  drivers/usb/gadget/udc/mv_udc_core.c|2 ++
> > >  drivers/usb/gadget/udc/net2272.c|1 +
> > >  drivers/usb/gadget/udc/net2280.c|1 +
> > >  drivers/usb/gadget/udc/omap_udc.c   |1 +
> > >  drivers/usb/gadget/udc/pch_udc.c|1 +
> > >  drivers/usb/gadget/udc/pxa25x_udc.c |1 +
> > >  drivers/usb/gadget/udc/pxa27x_udc.c |1 +
> > >  drivers/usb/gadget/udc/r8a66597-udc.c   |1 +
> > >  drivers/usb/gadget/udc/s3c-hsudc.c  |1 +
> > >  drivers/usb/gadget/udc/s3c2410_udc.c|1 +
> > >  drivers/usb/musb/musb_gadget.c  |2 ++
> > >  drivers/usb/renesas_usbhs/mod_gadget.c  |7 ++-
> > >  27 files changed, 45 insertions(+), 6 deletions(-)
> >
> > Instead of modifying all of the UDC drivers, how about adding a flag to
> > 'struct usb_gadget' named 'needs_ready' or similar? If the UDC doesn't
> > set the flag, udc-core would call usb_udc_ready_to_connect() on behalf
> > of the UDC. If the UDC sets the flag (chipidea only?) then the UDC would
> > be responsible for calling usb_udc_ready_to_connect().
> >
> 
> USB spec requires dp is not pulled up when the vbus is not there, the dwc3 is
> the newest core, I don't think other older udc cores all has similar 
> capability
> that does don't draw back voltage if software pullup bit is set and vbus is
> not there.
> 
> This patchset will delete the unconditional pullup dp operation at udc-core,
> and we need to pullup dp at the end of hardware initialization (not consider
> vbus case), then the end of .udc_start at udc driver is the old place.

I think you misunderstood my suggestion. Since you are adding a call
to usb_udc_ready_to_connect() at the end of almost every .udc_start
function, why not have udc-core do it instead, immediately after the
call to .udc_start? Unless the 'needs_ready' flag is set, which would
only be set by the udc drivers for those controllers that need it.

-- 
Paul

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

[PATCH] [RESEND] Newer Technology uSCSI SCSI-USB converter

[Mark]

Hi,

Re-sending as requested. I also added a couple of lines to the explanation.


The uSCSI from Newer Technology is a SCSI-USB converter with USB ID 06ca:2003.
Like several other SCSI-USB products, it's a Shuttle Technology OEM device.
Without a suitable entry in unusual-devs.h, the converter can only access the
(single) device with SCSI ID 0. Copying the entry for device 04e6:0002 allows
it to work with devices with other SCSI IDs too.

There are currently six entries for Shuttle-developed SCSI-USB devices in
unusual-devs.h (grep for euscsi):
  04e6:0002  Shuttle eUSCSI BridgeUSB_SC_DEVICE, USB_PR_DEVICE
  04e6:000b  Shuttle eUSCSI BridgeUSB_SC_SCSI, USB_PR_BULK
  04e6:000c  Shuttle eUSCSI BridgeUSB_SC_SCSI, USB_PR_BULK
  050d:0115  Belkin USB SCSI Adaptor  USB_SC_SCSI, USB_PR_BULK
  07af:0004  Microtech USB-SCSI-DB25  USB_SC_DEVICE, USB_PR_DEVICE
  07af:0005  Microtech USB-SCSI-HD50  USB_SC_DEVICE, USB_PR_DEVICE

lsusb -v output for the uSCSI lists
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk (Zip)


This patch adds an entry for the uSCSI to unusual_devs.h.

Signed-off-by: Mark Knibbs 

diff -up linux-3.16/drivers/usb/storage/unusual_devs.h.orig 
linux-3.16/drivers/usb/storage/unusual_devs.h
--- linux-3.16/drivers/usb/storage/unusual_devs.h.orig  2014-08-03 
23:25:02.0 +0100
+++ linux-3.16/drivers/usb/storage/unusual_devs.h   2014-08-15 
19:48:54.0 +0100
@@ -922,6 +922,12 @@ UNUSUAL_DEV(  0x069b, 0x3004, 0x0001, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),
 
+UNUSUAL_DEV(  0x06ca, 0x2003, 0x0100, 0x0100,
+   "Newer Technology",
+   "uSCSI",
+   USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
+   US_FL_SCM_MULT_TARG ),
+
 /* Reported by Adrian Pilchowiec  */
 UNUSUAL_DEV(  0x071b, 0x3203, 0x, 0x,
"RockChip",
--
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: serial: add Novatel Wireless GPS driver

[Kirk Madsen]

I applied your two patches to current Fedora core 20 kernel sources, built, 
remembered to remove the work-around boot-params and run grub2-mkconfig, and 
rebooted.  My Novatel GPS is recognized on plug-in to my USB2 ports and appears 
to work correctly.  

Thank you.

If you want more detail than "it appears to work" just ask.

Kirk Madsen

> -Original Message-
> From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
> Sent: Monday, August 18, 2014 10:15
> To: Kirk Madsen
> Cc: linux-usb@vger.kernel.org; Johan Hovold
> Subject: [PATCH 2/2] USB: serial: add Novatel Wireless GPS driver
> 
> Add simple driver for Novatel Wireless GPS receivers.
> 
> Reported-by: Kirk Madsen 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/Kconfig | 1 +
>  drivers/usb/serial/usb-serial-simple.c | 7 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig index
> 3ce5c74b29e4..ab05158ad03e 100644
> --- a/drivers/usb/serial/Kconfig
> +++ b/drivers/usb/serial/Kconfig
> @@ -61,6 +61,7 @@ config USB_SERIAL_SIMPLE
>   - Fundamental Software dongle.
>   - HP4x calculators
>   - a number of Motorola phones
> + - Novatel Wireless GPS receivers
>   - Siemens USB/MPI adapter.
>   - ViVOtech ViVOpay USB device.
>   - Infineon Modem Flashloader USB interface diff --git
> a/drivers/usb/serial/usb-serial-simple.c b/drivers/usb/serial/usb-serial-
> simple.c
> index 02cb77a1e79d..5565308c870c 100644
> --- a/drivers/usb/serial/usb-serial-simple.c
> +++ b/drivers/usb/serial/usb-serial-simple.c
> @@ -65,6 +65,11 @@ DEVICE(vivopay, VIVOPAY_IDS);
>   { USB_DEVICE(0x22b8, 0x2c64) }  /* Motorola V950 phone */
>  DEVICE(moto_modem, MOTO_IDS);
> 
> +/* Novatel Wireless GPS driver */
> +#define NOVATEL_IDS()\
> + { USB_DEVICE(0x09d7, 0x0100) }  /* NovAtel FlexPack GPS */
> +DEVICE_N(novatel_gps, NOVATEL_IDS, 3);
> +
>  /* HP4x (48/49) Generic Serial driver */
>  #define HP4X_IDS()   \
>   { USB_DEVICE(0x03f0, 0x0121) }
> @@ -88,6 +93,7 @@ static struct usb_serial_driver * const serial_drivers[] = {
>   &flashloader_device,
>   &vivopay_device,
>   &moto_modem_device,
> + &novatel_gps_device,
>   &hp4x_device,
>   &suunto_device,
>   &siemens_mpi_device,
> @@ -100,6 +106,7 @@ static const struct usb_device_id id_table[] = {
>   FLASHLOADER_IDS(),
>   VIVOPAY_IDS(),
>   MOTO_IDS(),
> + NOVATEL_IDS(),
>   HP4X_IDS(),
>   SUUNTO_IDS(),
>   SIEMENS_IDS(),
> --
> 1.8.5.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 v2] usb: dwc3: add tracepoints to aid debugging

[Paul Zimmerman]

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, August 19, 2014 1:10 PM
> 
> On Tue, Aug 19, 2014 at 08:00:27PM +, Paul Zimmerman wrote:
> > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > Sent: Tuesday, August 19, 2014 12:09 PM
> > >
> > > When we're debugging hard-to-reproduce and time-sensitive
> > > use cases, printk() poses too much overhead. That's when
> > > the kernel's tracing infrastructure comes into play.
> > >
> > > This patch implements a few initial tracepoints for the
> > > dwc3 driver. More traces can be added as necessary in order
> > > to ease the task of debugging dwc3.
> > >
> > > Signed-off-by: Felipe Balbi 
> > > ---
> > >
> > > Hi guys,
> > >
> > > here's v2 of my dwc3 tracepoints patch. Please have a look and
> > > *CAREFULLY* consider if we want to add anything else.
> > >
> > > Paul, I believe you have much more experience in debugging early
> > > HW releases with FPGA models than any of us, so tracing is likely
> > > to help you, is there anything you'd want me to add to as a tracepoint ?
> >
> > What about the "unexpected" interrupt events? It would be nice to see if
> > we receive e.g. an EVENT_OVERFLOW interrupt. Especially since you have
> > some of those events enabled, but don't have handlers for all of them.
> >
> > Maybe a single tracepoint for all of the unexpected events?
> 
> Makes sense, I was thinking of a neater way to just pass the event
> structure and decode it withing the trace itself. Then we can even
> remove all the event-specific traces, would that help ?

Yeah, that's sounds even better.

> I guess with that we would have a pretty neat setup where we can trace
> TRB lifetime, all register accesses and events.

Nice.

-- 
Paul

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

Re: [PATCH v2] usb: dwc3: add tracepoints to aid debugging

[Felipe Balbi]

On Tue, Aug 19, 2014 at 08:00:27PM +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Tuesday, August 19, 2014 12:09 PM
> > 
> > When we're debugging hard-to-reproduce and time-sensitive
> > use cases, printk() poses too much overhead. That's when
> > the kernel's tracing infrastructure comes into play.
> > 
> > This patch implements a few initial tracepoints for the
> > dwc3 driver. More traces can be added as necessary in order
> > to ease the task of debugging dwc3.
> > 
> > Signed-off-by: Felipe Balbi 
> > ---
> > 
> > Hi guys,
> > 
> > here's v2 of my dwc3 tracepoints patch. Please have a look and
> > *CAREFULLY* consider if we want to add anything else.
> > 
> > Paul, I believe you have much more experience in debugging early
> > HW releases with FPGA models than any of us, so tracing is likely
> > to help you, is there anything you'd want me to add to as a tracepoint ?
> 
> What about the "unexpected" interrupt events? It would be nice to see if
> we receive e.g. an EVENT_OVERFLOW interrupt. Especially since you have
> some of those events enabled, but don't have handlers for all of them.
> 
> Maybe a single tracepoint for all of the unexpected events?

Makes sense, I was thinking of a neater way to just pass the event
structure and decode it withing the trace itself. Then we can even
remove all the event-specific traces, would that help ?

I guess with that we would have a pretty neat setup where we can trace
TRB lifetime, all register accesses and events.

-- 
balbi


signature.asc
Description: Digital signature

RE: [PATCH v2] usb: dwc3: add tracepoints to aid debugging

[Paul Zimmerman]

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, August 19, 2014 12:09 PM
> 
> When we're debugging hard-to-reproduce and time-sensitive
> use cases, printk() poses too much overhead. That's when
> the kernel's tracing infrastructure comes into play.
> 
> This patch implements a few initial tracepoints for the
> dwc3 driver. More traces can be added as necessary in order
> to ease the task of debugging dwc3.
> 
> Signed-off-by: Felipe Balbi 
> ---
> 
> Hi guys,
> 
> here's v2 of my dwc3 tracepoints patch. Please have a look and
> *CAREFULLY* consider if we want to add anything else.
> 
> Paul, I believe you have much more experience in debugging early
> HW releases with FPGA models than any of us, so tracing is likely
> to help you, is there anything you'd want me to add to as a tracepoint ?

What about the "unexpected" interrupt events? It would be nice to see if
we receive e.g. an EVENT_OVERFLOW interrupt. Especially since you have
some of those events enabled, but don't have handlers for all of them.

Maybe a single tracepoint for all of the unexpected events?

-- 
Paul

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

[PATCH v2] usb: dwc3: add tracepoints to aid debugging

[Felipe Balbi]

When we're debugging hard-to-reproduce and time-sensitive
use cases, printk() poses too much overhead. That's when
the kernel's tracing infrastructure comes into play.

This patch implements a few initial tracepoints for the
dwc3 driver. More traces can be added as necessary in order
to ease the task of debugging dwc3.

Signed-off-by: Felipe Balbi 
---

Hi guys,

here's v2 of my dwc3 tracepoints patch. Please have a look and
*CAREFULLY* consider if we want to add anything else.

Paul, I believe you have much more experience in debugging early
HW releases with FPGA models than any of us, so tracing is likely
to help you, is there anything you'd want me to add to as a tracepoint ?

cheers

 drivers/usb/dwc3/Makefile |   5 +-
 drivers/usb/dwc3/debug.c  |  33 
 drivers/usb/dwc3/debug.h  |   3 ++
 drivers/usb/dwc3/ep0.c|   2 +
 drivers/usb/dwc3/gadget.c |  24 ++---
 drivers/usb/dwc3/io.h |  30 +--
 drivers/usb/dwc3/trace.c  |  19 +++
 drivers/usb/dwc3/trace.h  | 130 ++
 8 files changed, 236 insertions(+), 10 deletions(-)
 create mode 100644 drivers/usb/dwc3/debug.c
 create mode 100644 drivers/usb/dwc3/trace.c
 create mode 100644 drivers/usb/dwc3/trace.h

diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..7793e6c 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -1,9 +1,12 @@
+# define_trace.h needs to know how to find our header
+CFLAGS_trace.o := -I$(src)
+
 ccflags-$(CONFIG_USB_DWC3_DEBUG)   := -DDEBUG
 ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
 
 obj-$(CONFIG_USB_DWC3) += dwc3.o
 
-dwc3-y := core.o
+dwc3-y := core.o debug.o trace.o
 
 ifneq ($(filter y,$(CONFIG_USB_DWC3_HOST) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y  += host.o
diff --git a/drivers/usb/dwc3/debug.c b/drivers/usb/dwc3/debug.c
new file mode 100644
index 000..6d01e0c
--- /dev/null
+++ b/drivers/usb/dwc3/debug.c
@@ -0,0 +1,33 @@
+/**
+ * debug.c - DesignWare USB3 DRD Controller Debug/Trace Support
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Felipe Balbi 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "debug.h"
+
+void dwc3_trace(void (*trace)(struct va_format *),
+   const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, fmt);
+   vaf.fmt = fmt;
+   vaf.va = &args;
+
+   trace(&vaf);
+
+   va_end(args);
+}
diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index fceb39d..ff5e524 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -18,6 +18,9 @@
 
 #include "core.h"
 
+void dwc3_trace(void (*trace)(struct va_format *),
+   const char *fmt, ...);
+
 #ifdef CONFIG_DEBUG_FS
 extern int dwc3_debugfs_init(struct dwc3 *);
 extern void dwc3_debugfs_exit(struct dwc3 *);
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 21a3520..8ec8d84 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -726,6 +726,8 @@ static void dwc3_ep0_inspect_setup(struct dwc3 *dwc,
if (!dwc->gadget_driver)
goto out;
 
+   trace_dwc3_ctrl_req(ctrl);
+
len = le16_to_cpu(ctrl->wLength);
if (!len) {
dwc->three_stage_setup = false;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 349cacc..7e1f2c3 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -266,6 +266,7 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct 
dwc3_request *req,
dev_dbg(dwc->dev, "request %p from %s completed %d/%d ===> %d\n",
req, dep->name, req->request.actual,
req->request.length, status);
+   trace_dwc3_gadget_giveback(dwc, req);
 
spin_unlock(&dwc->lock);
req->request.complete(&dep->endpoint, &req->request);
@@ -800,6 +801,8 @@ static struct usb_request 
*dwc3_gadget_ep_alloc_request(struct usb_ep *ep,
req->epnum  = dep->number;
req->dep= dep;
 
+   trace_dwc3_alloc_request(dwc, req);
+
return &req->request;
 }
 
@@ -807,7 +810,10 @@ static void dwc3_gadget_ep_free_request(struct usb_ep *ep,
struct usb_request *request)
 {
struct dwc3_request *req = to_dwc3_request(request);
+   struct dwc3_ep  *dep = to_dwc3_ep(ep);
+   

Re: [PATCH RESEND] usb: chipidea: msm: Use USB PHY API to control PHY state

[Felipe Balbi]

On Fri, Aug 15, 2014 at 12:21:19PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" 
> 
> PHY drivers keep track of the current state of the hardware,
> so don't change PHY settings under it.
> 
> Signed-off-by: Ivan T. Ivanov 

looks correct to me from a PHY API perspective, so:

Acked-by: Felipe Balbi 

However, it doesn't look like msm_phy_init() is equivalent to the lines
removes. Care to comment ?

> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index d72b9d2..81de834 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -20,13 +20,11 @@
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->gadget.dev.parent;
> - int val;
>  
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> - writel(0, USB_AHBBURST);
> - writel(0, USB_AHBMODE);
> + usb_phy_init(ci->transceiver);
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
> @@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>* Put the transceiver in non-driving mode. Otherwise host
>* may not detect soft-disconnection.
>*/
> - val = usb_phy_io_read(ci->transceiver, ULPI_FUNC_CTRL);
> - val &= ~ULPI_FUNC_CTRL_OPMODE_MASK;
> - val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
> - usb_phy_io_write(ci->transceiver, val, ULPI_FUNC_CTRL);
> + usb_phy_notify_disconnect(ci->transceiver, USB_SPEED_UNKNOWN);
>   break;
>   default:
>   dev_dbg(dev, "unknown ci_hdrc event\n");
> -- 
> 1.8.3.2
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/3] usb: gadget/uvc: fix possible lockup in uvc gadget

[Felipe Balbi]

Hi,

On Tue, Aug 19, 2014 at 07:10:10PM +0200, Laurent Pinchart wrote:
> On Tuesday 19 August 2014 11:35:12 Felipe Balbi wrote:
> > On Tue, Aug 19, 2014 at 06:33:07PM +0200, Laurent Pinchart wrote:
> > > On Tuesday 19 August 2014 09:11:57 Felipe Balbi wrote:
> > > > On Fri, Aug 08, 2014 at 05:38:57PM +0200, Michael Grzeschik wrote:
> > > > > If the pending buffers in the queue could not be pushed to the udc
> > > > > endpoint we have to cancel the uvc_queue. Otherwise the gadget will
> > > > > get stuck on this error. This patch calls uvc_queue_cancel if
> > > > > usb_ep_queue failed.
> > > > > 
> > > > > Signed-off-by: Michael Grzeschik 
> > > > 
> > > > Laurent, is this good to be merged as a fix ?
> > > 
> > > The request completion code still makes me feel slightly uneasy due to
> > > fear of race conditions, but as far as I can see this patch doesn't
> > > introduce a regression in that area. Thus,
> > > 
> > > Acked-by: Laurent Pinchart 
> > > 
> > > Felipe, do you plan to push the patch as a fix for v3.17 ?
> > 
> > yeah, I do, unless you have other plans.
> 
> Please do. Thank you.

alright, patch 1 is in my testing/fixes branch. I should be able to send
a pull request to Greg tomorrow.

For patches 2 and 3, Michael, can you please rebase on top of v3.17-rc1?

thank you

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting

[Doug Anderson]

Kever,

On Tue, Aug 5, 2014 at 6:01 PM, Kever Yang  wrote:
> According to the "dr_mode", the otg controller can work as
> device role and host role. Some boards always want to use host mode
> and some other boards want to use gadget mode. We use the dts setting
> to set dwc2's mode, rather than fixing it to whatever hardware says.
>
> Signed-off-by: Kever Yang 
> Acked-by: Paul Zimmerman 
> ---
>
> Changes in v4:
> - From Doug's suggestion:
>  -- remove dr_mode init from Kconfig code
>  -- change the commit meesage
>
> Changes in v3:
> - fix the odd spacing in dwc2_hsotg struct
> - From Jingoo's suggestion:
> change the commit message
> - add dr_mode init from Kconfig
>
> Changes in v2:
> - put spaces around '+' operator
> - expand the comment for dr_mode
> - handle dr_mode is USB_DR_MODE_OTG
>
>  drivers/usb/dwc2/core.c | 18 ++
>  drivers/usb/dwc2/core.h |  5 +
>  drivers/usb/dwc2/platform.c |  4 
>  3 files changed, 27 insertions(+)

In case it's useful, I've actually tested myself that this is
necessary and sufficient to get the OTG port to behave properly as a
host port on an rk3288 board.

Tested-by: Doug Anderson 


Greg: now that the merge window has closed, are you interested in
landing Kever's changes (with Paul's Ack).  There's this series and
another adding rk3288 support.  If you'd like Kever to repost with
Acks or want pointers to patches, please yell!  ;)

-Doug
--
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/3] usbip: move usbip kernel code out of staging

[Greg KH]

On Thu, Aug 07, 2014 at 08:10:28AM +0300, Valentina Manea wrote:
> At this point, USB/IP kernel code is fully functional
> and can be moved out of staging.
> 
> Signed-off-by: Valentina Manea 

This patch moves the code, but now it's "gone" from the build system as
it is not hooked up and can not be built at all.

So while I really wanted to apply this series right now, I can't, as
this is a regression (working driver -> no driver).

Can you redo this series and actually add the driver to the build, as
well as adding a MAINTAINERS entry so that I can apply it all?  I'd like
to get this into 3.17-rc2 if possible, before things start to change
again.

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 RESEND v3 00/12] usb: dwc2/gadget: fix series

[Paul Zimmerman]

> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, August 19, 2014 9:16 AM
> 
> On Tue, Aug 19, 2014 at 03:46:58PM +, Paul Zimmerman wrote:
> > > From: Robert Baldyga [mailto:r.bald...@samsung.com]
> > > Sent: Tuesday, August 19, 2014 1:54 AM
> > >
> > > Hi Paul,
> > >
> > > I'm resending this patchset rebased on linux-next. Now it should apply.
> > >
> > > Thanks,
> > > Robert Baldyga
> > >
> > > Changelog:
> > > v3: https://lkml.org/lkml/2014/8/4/617
> > > - use endpoint index instead of FIFO index for EPFIFO
> > > - extend patch description
> > >
> > > v2: https://lkml.org/lkml/2014/7/16/199
> > > - add patch usb: dwc2/gadget: avoid disabling ep0
> > > - fix FIFO flushing when it's assigned to endpoint dynamically
> > > - write to proper FIFO in s3c_hsotg_write_fifo() function
> > > - use real FIFO size in kill_all_requests
> > > - fix comment in s3c_hsotg_init_fifo() function
> > >
> > > v1: https://lkml.org/lkml/2014/6/23/67
> > >
> > > Andrzej Pietrasiewicz (1):
> > >   usb: dwc2/gadget: Fix comment text
> > >
> > > Kamil Debski (3):
> > >   usb: dwc2/gadget: fix phy disable sequence
> > >   usb: dwc2/gadget: fix phy initialization sequence
> > >   usb: dwc2/gadget: move phy bus legth initialization
> > >
> > > Marek Szyprowski (5):
> > >   usb: dwc2/gadget: hide some not really needed debug messages
> > >   usb: dwc2/gadget: ensure that all fifos have correct memory buffers
> > >   usb: dwc2/gadget: break infinite loop in endpoint disable code
> > >   usb: dwc2/gadget: do not call disconnect method in pullup
> > >   usb: dwc2/gadget: delay enabling irq once hardware is configured
> > > properly
> > >
> > > Robert Baldyga (3):
> > >   usb: dwc2/gadget: assign TX FIFO dynamically
> > >   usb: dwc2/gadget: disable clock when it's not needed
> > >   usb: dwc2/gadget: avoid disabling ep0
> > >
> > >  drivers/usb/dwc2/core.h   |   3 +
> > >  drivers/usb/dwc2/gadget.c | 184 
> > > +++---
> > >  2 files changed, 111 insertions(+), 76 deletions(-)
> >
> > Thanks Robert.
> >
> > For the entire series,
> > Acked-by: Paul Zimmerman 
> >
> > Greg, can you please apply this to your usb-next tree? Thanks.
> 
> For 3.17-final, or 3.18-rc1?

For 3.18-rc1. Thanks.

-- 
Paul

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

Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN

[Christoph Hellwig]

On Thu, Aug 07, 2014 at 11:58:37AM -0400, Alan Stern wrote:
> > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote:
> > > > I doubt either of them forces users to hack up flags for these cases.
> > > 
> > > Why was this change needed in the first place?  There's no explanation 
> > > in the patch itself.
> > 
> > Which chance?  The one to not support SG_FLAG_LUN_INHIBIT?
> 
> No, the patch that started this Bugzilla entry.  Tiziano says it is 
> needed in order to send vendor-specific commands that use the LUN bits 
> in CDB[1].

Yes, I'd really like to know the exact scenario.  What kind of command
is this and who sends it?

--
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 0/4] Allow xHCI drivers to be built as separate modules

[Andrew Bresticker]

It was suggested in the review of the Tegra xHCI driver [1] that we
allow xHCI drivers to be built as individual modules (like EHCI) instead
of building them all into the single xhci-hcd module as they are today.

Patches 1-3 prepare for making the xHCI PCI and platform drivers able
to be built as individual modules and patch 4 actually creates the 3
separate modules (core, platform, PCI).

Based on 3.17-rc1.

Changes from v2:
 - fixed typo in xhci_register_plat
 - exported another symbol needed by xhci-pci module
Changes from v1:
 - rebased on changes introduced by xhci-rcar driver

[1] http://patchwork.ozlabs.org/patch/361265/

Andrew Bresticker (4):
  xhci: Introduce xhci_init_driver()
  xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold
  xhci: Export symbols used by host-controller drivers
  xhci: Allow xHCI drivers to be built as separate modules

 drivers/usb/host/Kconfig  |  5 +++
 drivers/usb/host/Makefile | 12 +++---
 drivers/usb/host/xhci-dbg.c   |  1 +
 drivers/usb/host/xhci-pci.c   | 80 +++
 drivers/usb/host/xhci-plat.c  | 68 ++
 drivers/usb/host/xhci-trace.c |  2 +
 drivers/usb/host/xhci.c   | 97 +--
 drivers/usb/host/xhci.h   | 23 +-
 8 files changed, 116 insertions(+), 172 deletions(-)

-- 
2.1.0.rc2.206.gedb03e5

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

Re: [PATCH v2 1/3] usb: gadget/uvc: fix possible lockup in uvc gadget

[Laurent Pinchart]

On Tuesday 19 August 2014 11:35:12 Felipe Balbi wrote:
> On Tue, Aug 19, 2014 at 06:33:07PM +0200, Laurent Pinchart wrote:
> > On Tuesday 19 August 2014 09:11:57 Felipe Balbi wrote:
> > > On Fri, Aug 08, 2014 at 05:38:57PM +0200, Michael Grzeschik wrote:
> > > > If the pending buffers in the queue could not be pushed to the udc
> > > > endpoint we have to cancel the uvc_queue. Otherwise the gadget will
> > > > get stuck on this error. This patch calls uvc_queue_cancel if
> > > > usb_ep_queue failed.
> > > > 
> > > > Signed-off-by: Michael Grzeschik 
> > > 
> > > Laurent, is this good to be merged as a fix ?
> > 
> > The request completion code still makes me feel slightly uneasy due to
> > fear of race conditions, but as far as I can see this patch doesn't
> > introduce a regression in that area. Thus,
> > 
> > Acked-by: Laurent Pinchart 
> > 
> > Felipe, do you plan to push the patch as a fix for v3.17 ?
> 
> yeah, I do, unless you have other plans.

Please do. Thank you.

-- 
Regards,

Laurent Pinchart


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2 3/3] usb: gadget/uvc: bump isoc requests from 4 to 16

[Laurent Pinchart]

Hi Michael,

Thank you for the patch.

On Friday 08 August 2014 17:38:59 Michael Grzeschik wrote:
> While sending bigger images it is better to use more isochronous
> requests in flight. This patch bumps the default from 4 to 16.

What does this fix ? Does it increase throughput or decrease CPU load ? Have 
you made any measurement ? Would 8 requests also be too low ?

> Signed-off-by: Michael Grzeschik 
> ---
>  drivers/usb/gadget/uvc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
> index 7a9111d..49d9573 100644
> --- a/drivers/usb/gadget/uvc.h
> +++ b/drivers/usb/gadget/uvc.h
> @@ -99,7 +99,7 @@ extern unsigned int uvc_gadget_trace_param;
>  #define DRIVER_VERSION   "0.1.0"
>  #define DRIVER_VERSION_NUMBERKERNEL_VERSION(0, 1, 0)
> 
> -#define UVC_NUM_REQUESTS 4
> +#define UVC_NUM_REQUESTS 16
>  #define UVC_MAX_REQUEST_SIZE 64
>  #define UVC_MAX_EVENTS   4

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 2/3] usb: gadget/uvc: also handle v4l2 ioctl ENUM_FMT

[Laurent Pinchart]

Hi Michael,

Thank you for the patch.

(CC'ing Hans Verkuil and the linux-media mailing list)

On Friday 08 August 2014 17:38:58 Michael Grzeschik wrote:
> This patch adds ENUM_FMT as possible ioctl to the uvc v4l2 device.
> That makes userspace applications with a generic IOCTL calling
> convention make also use of it.
> 
> Signed-off-by: Michael Grzeschik 
> ---
> v1 -> v2:
>  - changed first switch case to simple if
>  - added separate function
>  - added description field
>  - bail out on array boundaries
> 
>  drivers/usb/gadget/uvc_v4l2.c | 30 --
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
> index ad48e81..58633bf 100644
> --- a/drivers/usb/gadget/uvc_v4l2.c
> +++ b/drivers/usb/gadget/uvc_v4l2.c
> @@ -55,14 +55,30 @@ struct uvc_format
>  {
>   u8 bpp;
>   u32 fcc;
> + char *description;
>  };
> 
>  static struct uvc_format uvc_formats[] = {
> - { 16, V4L2_PIX_FMT_YUYV  },
> - { 0,  V4L2_PIX_FMT_MJPEG },
> + { 16, V4L2_PIX_FMT_YUYV, "YUV 4:2:2" },
> + { 0,  V4L2_PIX_FMT_MJPEG, "MJPEG" },

Format descriptions are currently duplicated in every driver, causing higher 
memory usage and different descriptions for the same format depending on the 
driver. Hans, should we try to fix this ?

>  };
> 
>  static int
> +uvc_v4l2_enum_format(struct uvc_video *video, struct v4l2_fmtdesc *fmt)
> +{
> +

There's an extra blank line here.

> + int index = fmt->index;

You can use fmt->index directly below, there's no need for a local variable.

> + if (index >= ARRAY_SIZE(uvc_formats))
> + return -EINVAL;
> +
> + strcpy(fmt->description, uvc_formats[index].description);

How about strlcpy to make sure we don't overflow the buffer ?

> + fmt->pixelformat = uvc_formats[index].fcc;
> +
> + return 0;
> +}
> +
> +static int
>  uvc_v4l2_get_format(struct uvc_video *video, struct v4l2_format *fmt)
>  {
>   fmt->fmt.pix.pixelformat = video->fcc;
> @@ -183,6 +199,16 @@ uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd,
> void *arg) break;
>   }
> 
> + case VIDIOC_ENUM_FMT:
> + {
> + struct v4l2_fmtdesc *fmt = arg;
> +
> + if (fmt->type != video->queue.queue.type)
> + return -EINVAL;
> +
> + return uvc_v4l2_enum_format(video, fmt);
> + }
> +
>   /* Get & Set format */
>   case VIDIOC_G_FMT:

-- 
Regards,

Laurent Pinchart

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

[PATCH v3 2/4] xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold

[Andrew Bresticker]

Instead of calling xhci_compliance_mode_recovery_timer_quirk_check() again
in the PCI suspend path, just check for XHCI_COMP_MODE_QUIRK which will
have been set based on xhci_compliance_mode_recovery_timer_quirk_check()
in xhci_init().

Signed-off-by: Andrew Bresticker 
---
No change from v1/v2.
---
 drivers/usb/host/xhci-pci.c | 2 +-
 drivers/usb/host/xhci.c | 2 +-
 drivers/usb/host/xhci.h | 3 ---
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 88d4553..8093ad6 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -279,7 +279,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
do_wakeup)
 * Systems with the TI redriver that loses port status change events
 * need to have the registers polled during D3, so avoid D3cold.
 */
-   if (xhci_compliance_mode_recovery_timer_quirk_check())
+   if (xhci->quirks & XHCI_COMP_MODE_QUIRK)
pdev->no_d3cold = true;
 
return xhci_suspend(xhci);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f94530a..a5cd831 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -491,7 +491,7 @@ static void compliance_mode_recovery_timer_init(struct 
xhci_hcd *xhci)
  * Systems:
  * Vendor: Hewlett-Packard -> System Models: Z420, Z620 and Z820
  */
-bool xhci_compliance_mode_recovery_timer_quirk_check(void)
+static bool xhci_compliance_mode_recovery_timer_quirk_check(void)
 {
const char *dmi_product_name, *dmi_sys_vendor;
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 194dbd3..71400b3 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1888,7 +1888,4 @@ struct xhci_input_control_ctx 
*xhci_get_input_control_ctx(struct xhci_hcd *xhci,
 struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct 
xhci_container_ctx *ctx);
 struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct 
xhci_container_ctx *ctx, unsigned int ep_index);
 
-/* xHCI quirks */
-bool xhci_compliance_mode_recovery_timer_quirk_check(void);
-
 #endif /* __LINUX_XHCI_HCD_H */
-- 
2.1.0.rc2.206.gedb03e5

--
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 4/4] xhci: Allow xHCI drivers to be built as separate modules

[Andrew Bresticker]

Instead of building all of the xHCI code into a single module, separate
it out into the core (xhci-hcd), PCI (xhci-pci, now selected by the new
config option CONFIG_USB_XHCI_PCI), and platform (xhci-plat) drivers.
Also update the PCI/platform drivers with module descriptions/licenses
and have them register their respective drivers in their initcalls.

Signed-off-by: Andrew Bresticker 
---
No change from v2.
Changes from v1:
 - rebased on changes introduced by xhci-rcar driver
---
 drivers/usb/host/Kconfig |  5 +
 drivers/usb/host/Makefile| 12 ++--
 drivers/usb/host/xhci-pci.c  |  9 +++--
 drivers/usb/host/xhci-plat.c |  9 +++--
 drivers/usb/host/xhci.c  | 22 --
 drivers/usb/host/xhci.h  | 19 ---
 6 files changed, 25 insertions(+), 51 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..f5a5831 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -26,6 +26,11 @@ config USB_XHCI_HCD
 
 if USB_XHCI_HCD
 
+config USB_XHCI_PCI
+   tristate
+   depends on PCI
+   default y
+
 config USB_XHCI_PLATFORM
tristate
 
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 144c038..702d9b7 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -15,22 +15,22 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
-xhci-hcd-$(CONFIG_PCI) += xhci-pci.o
 
-ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
-   xhci-hcd-y  += xhci-plat.o
+xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
-   xhci-hcd-y  += xhci-mvebu.o
+   xhci-plat-hcd-y += xhci-mvebu.o
 endif
 ifneq ($(CONFIG_USB_XHCI_RCAR), )
-   xhci-hcd-y  += xhci-rcar.o
-endif
+   xhci-plat-hcd-y += xhci-rcar.o
 endif
 
 obj-$(CONFIG_USB_WHCI_HCD) += whci/
 
 obj-$(CONFIG_PCI)  += pci-quirks.o
 
+obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+
 obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
 obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 8093ad6..f97d27c 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -346,7 +346,7 @@ static struct pci_driver xhci_pci_driver = {
 #endif
 };
 
-int __init xhci_register_pci(void)
+static int __init xhci_pci_init(void)
 {
xhci_init_driver(&xhci_pci_hc_driver, xhci_pci_setup);
 #ifdef CONFIG_PM
@@ -355,8 +355,13 @@ int __init xhci_register_pci(void)
 #endif
return pci_register_driver(&xhci_pci_driver);
 }
+module_init(xhci_pci_init);
 
-void xhci_unregister_pci(void)
+static void __exit xhci_pci_exit(void)
 {
pci_unregister_driver(&xhci_pci_driver);
 }
+module_exit(xhci_pci_exit);
+
+MODULE_DESCRIPTION("xHCI PCI Host Controller Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index f352368..3d78b0c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -247,14 +247,19 @@ static struct platform_driver usb_xhci_driver = {
 };
 MODULE_ALIAS("platform:xhci-hcd");
 
-int xhci_register_plat(void)
+static int __init xhci_plat_init(void)
 {
xhci_init_driver(&xhci_plat_hc_driver, xhci_plat_setup);
xhci_plat_hc_driver.start = xhci_plat_start;
return platform_driver_register(&usb_xhci_driver);
 }
+module_init(xhci_plat_init);
 
-void xhci_unregister_plat(void)
+static void __exit xhci_plat_exit(void)
 {
platform_driver_unregister(&usb_xhci_driver);
 }
+module_exit(xhci_plat_exit);
+
+MODULE_DESCRIPTION("xHCI Platform Host Controller Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index edfc96f..a29cd7d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4972,18 +4972,6 @@ MODULE_LICENSE("GPL");
 
 static int __init xhci_hcd_init(void)
 {
-   int retval;
-
-   retval = xhci_register_pci();
-   if (retval < 0) {
-   pr_debug("Problem registering PCI driver.\n");
-   return retval;
-   }
-   retval = xhci_register_plat();
-   if (retval < 0) {
-   pr_debug("Problem registering platform driver.\n");
-   goto unreg_pci;
-   }
/*
 * Check the compiler generated sizes of structures that must be laid
 * out in specific ways for hardware access.
@@ -5002,15 +4990,5 @@ static int __init xhci_hcd_init(void)
/* xhci_run_regs has eight fields and embeds 128 xhci_intr_regs */
BUILD_BUG_ON(sizeof(struct xhci_run_regs) != (8+8*128)*32/8);
return 0;
-unreg_pci:
-   xhci_unregister_pci();
-   return retval;
 }
 module_init(xhci_hcd_init);
-
-static void __

[PATCH v3 3/4] xhci: Export symbols used by host-controller drivers

[Andrew Bresticker]

In preparation for allowing the xHCI host controller drivers to be built
as separate modules, export symbols from the xHCI core that may be used
by the host controller drivers.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - exported xhci_dbg_quirks tracepoint
Changes from v1:
 - exported xhci_run()
---
 drivers/usb/host/xhci-dbg.c   | 1 +
 drivers/usb/host/xhci-trace.c | 2 ++
 drivers/usb/host/xhci.c   | 4 
 3 files changed, 7 insertions(+)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index eb009a4..bb89175 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -594,3 +594,4 @@ void xhci_dbg_trace(struct xhci_hcd *xhci, void 
(*trace)(struct va_format *),
trace(&vaf);
va_end(args);
 }
+EXPORT_SYMBOL_GPL(xhci_dbg_trace);
diff --git a/drivers/usb/host/xhci-trace.c b/drivers/usb/host/xhci-trace.c
index 7cf30c8..367b630 100644
--- a/drivers/usb/host/xhci-trace.c
+++ b/drivers/usb/host/xhci-trace.c
@@ -13,3 +13,5 @@
 
 #define CREATE_TRACE_POINTS
 #include "xhci-trace.h"
+
+EXPORT_TRACEPOINT_SYMBOL_GPL(xhci_dbg_quirks);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a5cd831..edfc96f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -653,6 +653,7 @@ int xhci_run(struct usb_hcd *hcd)
"Finished xhci_run for USB2 roothub");
return 0;
 }
+EXPORT_SYMBOL_GPL(xhci_run);
 
 static void xhci_only_stop_hcd(struct usb_hcd *hcd)
 {
@@ -927,6 +928,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
 
return rc;
 }
+EXPORT_SYMBOL_GPL(xhci_suspend);
 
 /*
  * start xHC (not bus-specific)
@@ -1078,6 +1080,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 
return retval;
 }
+EXPORT_SYMBOL_GPL(xhci_resume);
 #endif /* CONFIG_PM */
 
 /*-*/
@@ -4892,6 +4895,7 @@ error:
kfree(xhci);
return retval;
 }
+EXPORT_SYMBOL_GPL(xhci_gen_setup);
 
 static const struct hc_driver xhci_hc_driver = {
.description =  "xhci-hcd",
-- 
2.1.0.rc2.206.gedb03e5

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

Re: [PATCH v2 1/4] xhci: Introduce xhci_init_driver()

[Andrew Bresticker]

On Mon, Aug 18, 2014 at 11:10 PM, Yoshihiro Shimoda
 wrote:
> Hi,
>
> (2014/08/19 1:12), Andrew Bresticker wrote:
>> Since the struct hc_driver is mostly the same across the xhci-pci,
>> xhci-plat, and the upcoming xhci-tegra driver, introduce the function
>> xhci_init_driver() which will populate the hc_driver with the default
>> xHCI operations.  The caller must supply a setup function which will
>> be used as the hc_driver's reset callback.
>>
>> Note that xhci-plat also overrides the default ->start() callback so
>> that it can do rcar-specific initialization.
>>
>> Signed-off-by: Andrew Bresticker 
>> ---
>> Changes from v1:
>>  - rebased on changes introduced by xhci-rcar driver
> < snip >
>> @@ -300,6 +249,8 @@ MODULE_ALIAS("platform:xhci-hcd");
>>
>>  int xhci_register_plat(void)
>>  {
>> + xhci_init_driver(&xhci_plat_hc_driver, xhci_plat_setup);
>> + xhci_plat_hc_drver.start = xhci_plat_start;
>
> Thank you for the care of xhci-rcar driver.
> However, this "xhci_plat_hc_drver" should be "xhci_plat_hc_driver".

D'oh!  Thanks for catching this... had it fixed in my tree but forgot
to update the patches.  v3 incoming.
--
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 1/4] xhci: Introduce xhci_init_driver()

[Andrew Bresticker]

Since the struct hc_driver is mostly the same across the xhci-pci,
xhci-plat, and the upcoming xhci-tegra driver, introduce the function
xhci_init_driver() which will populate the hc_driver with the default
xHCI operations.  The caller must supply a setup function which will
be used as the hc_driver's reset callback.

Note that xhci-plat also overrides the default ->start() callback so
that it can do rcar-specific initialization.

Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - fixed typo in xhci_register_plat
Changes from v1:
 - rebased on changes introduced by xhci-rcar driver
---
 drivers/usb/host/xhci-pci.c  | 69 +---
 drivers/usb/host/xhci-plat.c | 59 -
 drivers/usb/host/xhci.c  | 69 
 drivers/usb/host/xhci.h  |  1 +
 4 files changed, 82 insertions(+), 116 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 687d366..88d4553 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -40,6 +40,8 @@
 
 static const char hcd_name[] = "xhci_hcd";
 
+static struct hc_driver __read_mostly xhci_pci_hc_driver;
+
 /* called after powerup, by probe or system-pm "wakeup" */
 static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev)
 {
@@ -315,68 +317,6 @@ static int xhci_pci_resume(struct usb_hcd *hcd, bool 
hibernated)
 }
 #endif /* CONFIG_PM */
 
-static const struct hc_driver xhci_pci_hc_driver = {
-   .description =  hcd_name,
-   .product_desc = "xHCI Host Controller",
-   .hcd_priv_size =sizeof(struct xhci_hcd *),
-
-   /*
-* generic hardware linkage
-*/
-   .irq =  xhci_irq,
-   .flags =HCD_MEMORY | HCD_USB3 | HCD_SHARED,
-
-   /*
-* basic lifecycle operations
-*/
-   .reset =xhci_pci_setup,
-   .start =xhci_run,
-#ifdef CONFIG_PM
-   .pci_suspend =  xhci_pci_suspend,
-   .pci_resume =   xhci_pci_resume,
-#endif
-   .stop = xhci_stop,
-   .shutdown = xhci_shutdown,
-
-   /*
-* managing i/o requests and associated device resources
-*/
-   .urb_enqueue =  xhci_urb_enqueue,
-   .urb_dequeue =  xhci_urb_dequeue,
-   .alloc_dev =xhci_alloc_dev,
-   .free_dev = xhci_free_dev,
-   .alloc_streams =xhci_alloc_streams,
-   .free_streams = xhci_free_streams,
-   .add_endpoint = xhci_add_endpoint,
-   .drop_endpoint =xhci_drop_endpoint,
-   .endpoint_reset =   xhci_endpoint_reset,
-   .check_bandwidth =  xhci_check_bandwidth,
-   .reset_bandwidth =  xhci_reset_bandwidth,
-   .address_device =   xhci_address_device,
-   .enable_device =xhci_enable_device,
-   .update_hub_device =xhci_update_hub_device,
-   .reset_device = xhci_discover_or_reset_device,
-
-   /*
-* scheduling support
-*/
-   .get_frame_number = xhci_get_frame,
-
-   /* Root hub support */
-   .hub_control =  xhci_hub_control,
-   .hub_status_data =  xhci_hub_status_data,
-   .bus_suspend =  xhci_bus_suspend,
-   .bus_resume =   xhci_bus_resume,
-   /*
-* call back when device connected and addressed
-*/
-   .update_device =xhci_update_device,
-   .set_usb2_hw_lpm =  xhci_set_usb2_hardware_lpm,
-   .enable_usb3_lpm_timeout =  xhci_enable_usb3_lpm_timeout,
-   .disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
-   .find_raw_port_number = xhci_find_raw_port_number,
-};
-
 /*-*/
 
 /* PCI driver selection metadata; PCI hotplugging uses this */
@@ -408,6 +348,11 @@ static struct pci_driver xhci_pci_driver = {
 
 int __init xhci_register_pci(void)
 {
+   xhci_init_driver(&xhci_pci_hc_driver, xhci_pci_setup);
+#ifdef CONFIG_PM
+   xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend;
+   xhci_pci_hc_driver.pci_resume = xhci_pci_resume;
+#endif
return pci_register_driver(&xhci_pci_driver);
 }
 
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..f352368 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -23,6 +23,8 @@
 #include "xhci-mvebu.h"
 #include "xhci-rcar.h"
 
+static struct hc_driver __read_mostly xhci_plat_hc_driver;
+
 static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 {
/*
@@ -60,59 +62,6 @@ static int xhci_plat_start(struct usb_hcd *hcd)
return xhci_run(hcd);
 }
 
-static const struct hc_driver xhci_plat_xhci_driver = {
-   .description =  "xhci-hcd",
-   .product_desc = "xHCI Host Controller"

Re: [PATCH v2 1/3] usb: gadget/uvc: fix possible lockup in uvc gadget

[Laurent Pinchart]

Hi Michael,

Thank you for the patch.

On Friday 08 August 2014 17:38:57 Michael Grzeschik wrote:
> If the pending buffers in the queue could not be pushed to the udc
> endpoint we have to cancel the uvc_queue. Otherwise the gadget will get
> stuck on this error. This patch calls uvc_queue_cancel if usb_ep_queue
> failed.
> 
> Signed-off-by: Michael Grzeschik 
> ---
> v1 -> v2:
>  - moved uvc_queue_cancel outside the spinlock
> 
>  drivers/usb/gadget/uvc_video.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/gadget/uvc_video.c b/drivers/usb/gadget/uvc_video.c
> index 71e896d..a5eb9a3 100644
> --- a/drivers/usb/gadget/uvc_video.c
> +++ b/drivers/usb/gadget/uvc_video.c
> @@ -195,6 +195,7 @@ uvc_video_complete(struct usb_ep *ep, struct usb_request
> *req) printk(KERN_INFO "Failed to queue request (%d).\n", ret);
>   usb_ep_set_halt(ep);
>   spin_unlock_irqrestore(&video->queue.irqlock, flags);
> + uvc_queue_cancel(queue, 0);
>   goto requeue;
>   }
>   spin_unlock_irqrestore(&video->queue.irqlock, flags);
> @@ -281,6 +282,7 @@ error:
>  static int
>  uvc_video_pump(struct uvc_video *video)
>  {
> + struct uvc_video_queue *queue = &video->queue;
>   struct usb_request *req;
>   struct uvc_buffer *buf;
>   unsigned long flags;
> @@ -322,6 +324,7 @@ uvc_video_pump(struct uvc_video *video)
>   printk(KERN_INFO "Failed to queue request (%d)\n", ret);
>   usb_ep_set_halt(video->ep);
>   spin_unlock_irqrestore(&video->queue.irqlock, flags);
> + uvc_queue_cancel(queue, 0);

Just nitpicking here, you could call

uvc_queue_cancel(&video->queue, 0);

without adding a new local variable, given that video->queue is already used 
in several places in this function.

>   break;
>   }
>   spin_unlock_irqrestore(&video->queue.irqlock, flags);

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 1/3] usb: gadget/uvc: fix possible lockup in uvc gadget

[Felipe Balbi]

On Tue, Aug 19, 2014 at 06:33:07PM +0200, Laurent Pinchart wrote:
> On Tuesday 19 August 2014 09:11:57 Felipe Balbi wrote:
> > On Fri, Aug 08, 2014 at 05:38:57PM +0200, Michael Grzeschik wrote:
> > > If the pending buffers in the queue could not be pushed to the udc
> > > endpoint we have to cancel the uvc_queue. Otherwise the gadget will get
> > > stuck on this error. This patch calls uvc_queue_cancel if usb_ep_queue
> > > failed.
> > > 
> > > Signed-off-by: Michael Grzeschik 
> > 
> > Laurent, is this good to be merged as a fix ?
> 
> The request completion code still makes me feel slightly uneasy due to fear 
> of 
> race conditions, but as far as I can see this patch doesn't introduce a 
> regression in that area. Thus,
> 
> Acked-by: Laurent Pinchart 
> 
> Felipe, do you plan to push the patch as a fix for v3.17 ?

yeah, I do, unless you have other plans.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/3] usb: gadget/uvc: fix possible lockup in uvc gadget

[Laurent Pinchart]

On Tuesday 19 August 2014 09:11:57 Felipe Balbi wrote:
> On Fri, Aug 08, 2014 at 05:38:57PM +0200, Michael Grzeschik wrote:
> > If the pending buffers in the queue could not be pushed to the udc
> > endpoint we have to cancel the uvc_queue. Otherwise the gadget will get
> > stuck on this error. This patch calls uvc_queue_cancel if usb_ep_queue
> > failed.
> > 
> > Signed-off-by: Michael Grzeschik 
> 
> Laurent, is this good to be merged as a fix ?

The request completion code still makes me feel slightly uneasy due to fear of 
race conditions, but as far as I can see this patch doesn't introduce a 
regression in that area. Thus,

Acked-by: Laurent Pinchart 

Felipe, do you plan to push the patch as a fix for v3.17 ?

-- 
Regards,

Laurent Pinchart


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH RESEND v3 00/12] usb: dwc2/gadget: fix series

[gre...@linuxfoundation.org]

On Tue, Aug 19, 2014 at 03:46:58PM +, Paul Zimmerman wrote:
> > From: Robert Baldyga [mailto:r.bald...@samsung.com]
> > Sent: Tuesday, August 19, 2014 1:54 AM
> > 
> > Hi Paul,
> > 
> > I'm resending this patchset rebased on linux-next. Now it should apply.
> > 
> > Thanks,
> > Robert Baldyga
> > 
> > Changelog:
> > v3: https://lkml.org/lkml/2014/8/4/617
> > - use endpoint index instead of FIFO index for EPFIFO
> > - extend patch description
> > 
> > v2: https://lkml.org/lkml/2014/7/16/199
> > - add patch usb: dwc2/gadget: avoid disabling ep0
> > - fix FIFO flushing when it's assigned to endpoint dynamically
> > - write to proper FIFO in s3c_hsotg_write_fifo() function
> > - use real FIFO size in kill_all_requests
> > - fix comment in s3c_hsotg_init_fifo() function
> > 
> > v1: https://lkml.org/lkml/2014/6/23/67
> > 
> > Andrzej Pietrasiewicz (1):
> >   usb: dwc2/gadget: Fix comment text
> > 
> > Kamil Debski (3):
> >   usb: dwc2/gadget: fix phy disable sequence
> >   usb: dwc2/gadget: fix phy initialization sequence
> >   usb: dwc2/gadget: move phy bus legth initialization
> > 
> > Marek Szyprowski (5):
> >   usb: dwc2/gadget: hide some not really needed debug messages
> >   usb: dwc2/gadget: ensure that all fifos have correct memory buffers
> >   usb: dwc2/gadget: break infinite loop in endpoint disable code
> >   usb: dwc2/gadget: do not call disconnect method in pullup
> >   usb: dwc2/gadget: delay enabling irq once hardware is configured
> > properly
> > 
> > Robert Baldyga (3):
> >   usb: dwc2/gadget: assign TX FIFO dynamically
> >   usb: dwc2/gadget: disable clock when it's not needed
> >   usb: dwc2/gadget: avoid disabling ep0
> > 
> >  drivers/usb/dwc2/core.h   |   3 +
> >  drivers/usb/dwc2/gadget.c | 184 
> > +++---
> >  2 files changed, 111 insertions(+), 76 deletions(-)
> 
> Thanks Robert.
> 
> For the entire series,
> Acked-by: Paul Zimmerman 
> 
> Greg, can you please apply this to your usb-next tree? Thanks.

For 3.17-final, or 3.18-rc1?

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 RESEND v3 00/12] usb: dwc2/gadget: fix series

[Paul Zimmerman]

> From: Robert Baldyga [mailto:r.bald...@samsung.com]
> Sent: Tuesday, August 19, 2014 1:54 AM
> 
> Hi Paul,
> 
> I'm resending this patchset rebased on linux-next. Now it should apply.
> 
> Thanks,
> Robert Baldyga
> 
> Changelog:
> v3: https://lkml.org/lkml/2014/8/4/617
> - use endpoint index instead of FIFO index for EPFIFO
> - extend patch description
> 
> v2: https://lkml.org/lkml/2014/7/16/199
> - add patch usb: dwc2/gadget: avoid disabling ep0
> - fix FIFO flushing when it's assigned to endpoint dynamically
> - write to proper FIFO in s3c_hsotg_write_fifo() function
> - use real FIFO size in kill_all_requests
> - fix comment in s3c_hsotg_init_fifo() function
> 
> v1: https://lkml.org/lkml/2014/6/23/67
> 
> Andrzej Pietrasiewicz (1):
>   usb: dwc2/gadget: Fix comment text
> 
> Kamil Debski (3):
>   usb: dwc2/gadget: fix phy disable sequence
>   usb: dwc2/gadget: fix phy initialization sequence
>   usb: dwc2/gadget: move phy bus legth initialization
> 
> Marek Szyprowski (5):
>   usb: dwc2/gadget: hide some not really needed debug messages
>   usb: dwc2/gadget: ensure that all fifos have correct memory buffers
>   usb: dwc2/gadget: break infinite loop in endpoint disable code
>   usb: dwc2/gadget: do not call disconnect method in pullup
>   usb: dwc2/gadget: delay enabling irq once hardware is configured
> properly
> 
> Robert Baldyga (3):
>   usb: dwc2/gadget: assign TX FIFO dynamically
>   usb: dwc2/gadget: disable clock when it's not needed
>   usb: dwc2/gadget: avoid disabling ep0
> 
>  drivers/usb/dwc2/core.h   |   3 +
>  drivers/usb/dwc2/gadget.c | 184 
> +++---
>  2 files changed, 111 insertions(+), 76 deletions(-)

Thanks Robert.

For the entire series,
Acked-by: Paul Zimmerman 

Greg, can you please apply this to your usb-next tree? Thanks.

-- 
Paul

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

Re: [PATCH] usbcore: Fix wrong device in an error message in hub_port_connect()

[Takashi Iwai]

At Tue, 19 Aug 2014 10:25:20 -0500,
Greg Kroah-Hartman wrote:
> 
> On Tue, Aug 19, 2014 at 10:15:37AM -0500, Greg Kroah-Hartman wrote:
> > On Tue, Aug 19, 2014 at 04:46:31PM +0200, Takashi Iwai wrote:
> > > At Tue, 19 Aug 2014 10:35:58 -0400 (EDT),
> > > Alan Stern wrote:
> > > > 
> > > > On Tue, 19 Aug 2014, Takashi Iwai wrote:
> > > > 
> > > > > The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
> > > > > failures of the same port] added the check of the reliable port, but
> > > > > it also replaced the device argument to dev_err() wrongly, which leads
> > > > > to a NULL dereference.
> > > > > 
> > > > > This patch restores the right device, port_dev->dev.
> > > > > 
> > > > > [The fix suggested by Hannes]
> > > > > 
> > > > > Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce 
> > > > > failures of the same port')
> > > > > Reported-by: Hannes Reinecke 
> > > > > Signed-off-by: Takashi Iwai 
> > > > > ---
> > > > >  drivers/usb/core/hub.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > > > > index 8a4dcbc7a75f..22635590860c 100644
> > > > > --- a/drivers/usb/core/hub.c
> > > > > +++ b/drivers/usb/core/hub.c
> > > > > @@ -4631,7 +4631,7 @@ static void hub_port_connect(struct usb_hub 
> > > > > *hub, int port1, u16 portstatus,
> > > > >   if (status != -ENODEV &&
> > > > >   port1 != unreliable_port &&
> > > > >   printk_ratelimit())
> > > > > - dev_err(&udev->dev, "connect-debounce 
> > > > > failed, port %d disabled\n",
> > > > > + dev_err(&port_dev->dev, 
> > > > > "connect-debounce failed, port %d disabled\n",
> > > > >   port1);
> > > > >  
> > > > >   portstatus &= ~USB_PORT_STAT_CONNECTION;
> > > > 
> > > > In fact, this looks like it might be a mistaken patch conflict 
> > > > resolution.
> > > > 
> > > > Anyway, the proposed fix is redundant.  There's no need to mention the 
> > > > port number in the error message, because the port number is already 
> > > > part of the device name for port_dev->dev.  The statement should be:
> > > > 
> > > > +   dev_err(&port_dev->dev, 
> > > > "connect-debounce failed\n");
> > > > 
> > > > like it was before Oliver's patch.
> > > 
> > > Indeed...  Greg, let me know if I should respin the patch, or you
> > > prefer applying more fix on the top.
> > 
> > Ugh, I just applied this, so can you send me an additional one to add to
> > the top?
> 
> Actually, I never pushed this out publicly due to a horrible network
> connection, so a "new" patch would be better.

OK, then I'll respin and resubmit.  Disregard the previous patch.


Takashi
--
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] usbcore: Fix wrong device in an error message in hub_port_connect()

[Takashi Iwai]

The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
failures of the same port] added the check of the reliable port, but
it also replaced the device argument to dev_err() wrongly, which leads
to a NULL dereference.

This patch restores the right device, port_dev->dev.  Also, since
dev_err() itself shows the port number, reduce the port number shown
in the error message, essentially reverting to the state before the
commit 5ee0f803cc3a.

[The fix suggested by Hannes, and the error message cleanup suggested
 by Alan Stern]

Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of 
the same port')
Reported-by: Hannes Reinecke 
Cc: 
Signed-off-by: Takashi Iwai 
---
v1->v2: cleanup the error message

 drivers/usb/core/hub.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8a4dcbc7a75f..e0eaeb8697bb 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4631,9 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
if (status != -ENODEV &&
port1 != unreliable_port &&
printk_ratelimit())
-   dev_err(&udev->dev, "connect-debounce failed, 
port %d disabled\n",
-   port1);
-
+   dev_err(&port_dev->dev, "connect-debounce 
failed\n");
portstatus &= ~USB_PORT_STAT_CONNECTION;
unreliable_port = port1;
} else {
-- 
2.0.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] usbcore: Fix wrong device in an error message in hub_port_connect()

[Greg Kroah-Hartman]

On Tue, Aug 19, 2014 at 10:15:37AM -0500, Greg Kroah-Hartman wrote:
> On Tue, Aug 19, 2014 at 04:46:31PM +0200, Takashi Iwai wrote:
> > At Tue, 19 Aug 2014 10:35:58 -0400 (EDT),
> > Alan Stern wrote:
> > > 
> > > On Tue, 19 Aug 2014, Takashi Iwai wrote:
> > > 
> > > > The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
> > > > failures of the same port] added the check of the reliable port, but
> > > > it also replaced the device argument to dev_err() wrongly, which leads
> > > > to a NULL dereference.
> > > > 
> > > > This patch restores the right device, port_dev->dev.
> > > > 
> > > > [The fix suggested by Hannes]
> > > > 
> > > > Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce 
> > > > failures of the same port')
> > > > Reported-by: Hannes Reinecke 
> > > > Signed-off-by: Takashi Iwai 
> > > > ---
> > > >  drivers/usb/core/hub.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > > > index 8a4dcbc7a75f..22635590860c 100644
> > > > --- a/drivers/usb/core/hub.c
> > > > +++ b/drivers/usb/core/hub.c
> > > > @@ -4631,7 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, 
> > > > int port1, u16 portstatus,
> > > > if (status != -ENODEV &&
> > > > port1 != unreliable_port &&
> > > > printk_ratelimit())
> > > > -   dev_err(&udev->dev, "connect-debounce 
> > > > failed, port %d disabled\n",
> > > > +   dev_err(&port_dev->dev, 
> > > > "connect-debounce failed, port %d disabled\n",
> > > > port1);
> > > >  
> > > > portstatus &= ~USB_PORT_STAT_CONNECTION;
> > > 
> > > In fact, this looks like it might be a mistaken patch conflict 
> > > resolution.
> > > 
> > > Anyway, the proposed fix is redundant.  There's no need to mention the 
> > > port number in the error message, because the port number is already 
> > > part of the device name for port_dev->dev.  The statement should be:
> > > 
> > > + dev_err(&port_dev->dev, "connect-debounce 
> > > failed\n");
> > > 
> > > like it was before Oliver's patch.
> > 
> > Indeed...  Greg, let me know if I should respin the patch, or you
> > prefer applying more fix on the top.
> 
> Ugh, I just applied this, so can you send me an additional one to add to
> the top?

Actually, I never pushed this out publicly due to a horrible network
connection, so a "new" patch would be better.

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] usbcore: Reduce redundant error message in hub_port_connect()

[Takashi Iwai]

Alan Stern pointed out that the port number shown in the error message
from hub_port_connect() is redundant.  This patch removes it,
essentially reverts to the state before the commit 5ee0f803cc3a.

Signed-off-by: Takashi Iwai 
---

I wasn't sure whether this deserves Cc to stable.
Feel free to queue it.

 drivers/usb/core/hub.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 22635590860c..e0eaeb8697bb 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4631,9 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
if (status != -ENODEV &&
port1 != unreliable_port &&
printk_ratelimit())
-   dev_err(&port_dev->dev, "connect-debounce 
failed, port %d disabled\n",
-   port1);
-
+   dev_err(&port_dev->dev, "connect-debounce 
failed\n");
portstatus &= ~USB_PORT_STAT_CONNECTION;
unreliable_port = port1;
} else {
-- 
2.0.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: xhci driver causes Kernel-Oops starting with kernel 3.16

[Manuel Reimer]

On 08/19/2014 03:18 PM, Mathias Nyman wrote:

Did the same machine work with previous kernel versions?


Yes. I use Arch Linux so I get kernel updates regularly.

I can't tell you exactly in which kernel the problem first occurred. I 
can only tell that Kernel 3.16 is the first kernel where I got that Oops 
and the second time was with 3.16.1. With about 4 or 5 boots in between 
without any problems.


I never had this problem prior 3.16. This means either that the problem 
did not exist from 3.5.4 (first kernel I used with my initial 
installation of Arch Linux) up to 3.15.8 or it means that some piece of 
my hardware is broken somehow and starts to cause problems... :(



How about if you compile xhci as a module, and load it, does it still fail 
sometimes?


As far as I can see it is compiled as module. Kernel config can be found 
here:



The failure only occurs sometimes (twice, so far). It is not easily 
possible to reproduce the problem. It only occurred while booting and a 
system reset (reset button) always worked to get the system up to a 
stable state in a second attempt.


Greetings,

Manuel
--
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] usbcore: Fix wrong device in an error message in hub_port_connect()

[Greg Kroah-Hartman]

On Tue, Aug 19, 2014 at 04:46:31PM +0200, Takashi Iwai wrote:
> At Tue, 19 Aug 2014 10:35:58 -0400 (EDT),
> Alan Stern wrote:
> > 
> > On Tue, 19 Aug 2014, Takashi Iwai wrote:
> > 
> > > The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
> > > failures of the same port] added the check of the reliable port, but
> > > it also replaced the device argument to dev_err() wrongly, which leads
> > > to a NULL dereference.
> > > 
> > > This patch restores the right device, port_dev->dev.
> > > 
> > > [The fix suggested by Hannes]
> > > 
> > > Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures 
> > > of the same port')
> > > Reported-by: Hannes Reinecke 
> > > Signed-off-by: Takashi Iwai 
> > > ---
> > >  drivers/usb/core/hub.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > > index 8a4dcbc7a75f..22635590860c 100644
> > > --- a/drivers/usb/core/hub.c
> > > +++ b/drivers/usb/core/hub.c
> > > @@ -4631,7 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, 
> > > int port1, u16 portstatus,
> > >   if (status != -ENODEV &&
> > >   port1 != unreliable_port &&
> > >   printk_ratelimit())
> > > - dev_err(&udev->dev, "connect-debounce failed, 
> > > port %d disabled\n",
> > > + dev_err(&port_dev->dev, "connect-debounce 
> > > failed, port %d disabled\n",
> > >   port1);
> > >  
> > >   portstatus &= ~USB_PORT_STAT_CONNECTION;
> > 
> > In fact, this looks like it might be a mistaken patch conflict 
> > resolution.
> > 
> > Anyway, the proposed fix is redundant.  There's no need to mention the 
> > port number in the error message, because the port number is already 
> > part of the device name for port_dev->dev.  The statement should be:
> > 
> > +   dev_err(&port_dev->dev, "connect-debounce 
> > failed\n");
> > 
> > like it was before Oliver's patch.
> 
> Indeed...  Greg, let me know if I should respin the patch, or you
> prefer applying more fix on the top.

Ugh, I just applied this, so can you send me an additional one to add to
the top?

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: xhci driver causes Kernel-Oops starting with kernel 3.16

[Mathias Nyman]

On 08/18/2014 06:59 PM, Manuel Reimer wrote:
> Hello,
> 
> I already opened a bug report for my problem here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=82731#c1
> 
> Starting with Kernel 3.16 I get kernel Oops from time to time when booting my 
> desktop system.
> 
> A reset helps to bring the system up without problems.
> 
> I've attached a dmesg dump to my bug report:
> https://bugzilla.kernel.org/attachment.cgi?id=147061
> 
> Thank you very much in advance for any help.
> 

This should fix the Oops
(Patch added to bugreport as well)
Does it work for you?


diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 26129d3..59483c6 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1819,7 +1819,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
xhci_cleanup_command_queue(xhci);
 
num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
-   for (i = 0; i < num_ports; i++) {
+   for (i = 0; i < num_ports && xhci->rh_bw; i++) {
struct xhci_interval_bw_table *bwt = &xhci->rh_bw[i].bw_table;
for (j = 0; j < XHCI_MAX_INTERVAL; j++) {
struct list_head *ep = &bwt->interval_bw[j].endpoints;

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

Re: [PATCH v2 2/3] usb: core: fix below build warning

[Alan Stern]

On Tue, 19 Aug 2014, Peter Chen wrote:

> linux-2.6/drivers/usb/core/hub.c: In function 'usb_disconnect':
> linux-2.6/drivers/usb/core/hub.c:2110: warning: 'hub' may be used 
> uninitialized in this function
> linux-2.6/drivers/usb/core/hub.c:2111: warning: 'port1' may be used 
> uninitialized in this function
> 
> Signed-off-by: Peter Chen 
> ---
> Change for v2:
> - Delete the unnecessary change
> 
>  drivers/usb/core/hub.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 1fcad4d..170731c 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2108,8 +2108,8 @@ void usb_disconnect(struct usb_device **pdev)
>  {
>   struct usb_port *port_dev = NULL;
>   struct usb_device *udev = *pdev;
> - struct usb_hub *hub;
> - int port1;
> + struct usb_hub *hub = NULL;
> + int port1 = 1;
>  
>   /* mark the device as inactive, so any further urb submissions for
>* this device (and any of its children) will fail immediately.

Acked-by: Alan Stern 

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

Re: [PATCH 01/13] usb: gadget: introduce .connect gadget driver API

[Alan Stern]

On Tue, 19 Aug 2014, Peter Chen wrote:

> > > --- a/include/linux/usb/gadget.h
> > > +++ b/include/linux/usb/gadget.h
> > > @@ -873,12 +873,39 @@ struct usb_gadget_driver {
> > >   void(*disconnect)(struct usb_gadget *);
> > >   void(*suspend)(struct usb_gadget *);
> > >   void(*resume)(struct usb_gadget *);
> > > + int (*connect)(struct usb_gadget *, bool connect);
> > >  
> > >   /* FIXME support safe rmmod */
> > >   struct device_driverdriver;
> > >  };
> > 
> > This looks strange.  Why do you have the "bool connect" parameter?  
> 
> How can I tell the gadget driver to pull down dp after vbus is off?
> 
> > There's already a disconnect callback.
> 
> Maybe I need to use other name rather than connect, the .disconnect sometimes
> is called at bus reset handler so I can't put dp control in it.

We could fix that.  Right now there are only about four files that 
define a usb_gadget_driver structure.  All you have to do is make sure 
they each contain a reset handler.

Alan Stern

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

Re: [PATCH v3 0/3] usb: gadget: f_fs: userspace API fixes and improvements

[Felipe Balbi]

On Wed, Jul 30, 2014 at 11:43:40AM +0200, Robert Baldyga wrote:
> This patchset contains changes in FunctionFS making it easier and
> safer to use. It fixes bug in endpoint files handling code, adds new
> ioctl allowing to obtain endpoint descriptor, and introduces virtual
> address mapping which allows to separate endpoint address space in
> function from physical endpoint addresses, and introduces new endpoint
> files naming convention.

I'll drop this from my queue for now. Please fix the minor comment from
Sergei.

-- 
balbi


signature.asc
Description: Digital signature

Re: Bug 82571 - Mouse erratic and polling issues with USB 3.0 port and Logitech G9x mouse.

[Alan Stern]

On Mon, 18 Aug 2014, Commander wrote:

> > Currently there is no way to change the polling rate, unless you use a
> > USB-2 port.
> I see.
> 
> Any ideas why the USB 3.0 port should affect the game Witcher 2 like
> in the video if that is an hardware/driver issue or SDL or maybe
> combination?

I don't know.  Maybe the mouse itself expects to be polled faster and 
doesn't work properly if it isn't.

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: Transient USB disconnects

[Alan Stern]

On Tue, 19 Aug 2014, David Laight wrote:

> I think I've discovered our underlying problem.
> 
> I scoped the USB data lines (NFI why the hardware guys hadn't looked at 
> them!).
> As well as the SOF (every 125us) there is a rather nasty decaying transient
> every 41us that is almost 400mV and lasts about as long as the SOF.
> (These seem to be generated by some PWM fan controllers, possibly ground 
> lift!)
> 
> I suspect that when the transient lines up with the SOF the envelope detector
> in the USB host detects the 800mV that would appear when the target is
> unplugged - so actions an unplug event and drives a USB reset.

Your device is plugged into Intel's "rate-matching" hub, not directly 
into the host controller.

> This is all the USB monitor sees - normal data (with acks) and a sudden
> host reset - no retries.
> 
> This rather begs the question of why the driver trace shows repeated URB
> submissions - since something should know that the 'unplug' has been 
> signalled.
> However I've not tried to align the USB monitor and scope traces, nor the
> driver events (possible by using the UART signals one of the 5 COM ports).

Since the device is plugged into a hub, the hub knows about the
disconnection.  But it can't inform the kernel until the host
controller polls it, which occurs at 128-ms intervals.

Alan Stern

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

Re: [PATCH] usbcore: Fix wrong device in an error message in hub_port_connect()

[Takashi Iwai]

At Tue, 19 Aug 2014 10:35:58 -0400 (EDT),
Alan Stern wrote:
> 
> On Tue, 19 Aug 2014, Takashi Iwai wrote:
> 
> > The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
> > failures of the same port] added the check of the reliable port, but
> > it also replaced the device argument to dev_err() wrongly, which leads
> > to a NULL dereference.
> > 
> > This patch restores the right device, port_dev->dev.
> > 
> > [The fix suggested by Hannes]
> > 
> > Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures 
> > of the same port')
> > Reported-by: Hannes Reinecke 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/usb/core/hub.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 8a4dcbc7a75f..22635590860c 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -4631,7 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
> > port1, u16 portstatus,
> > if (status != -ENODEV &&
> > port1 != unreliable_port &&
> > printk_ratelimit())
> > -   dev_err(&udev->dev, "connect-debounce failed, 
> > port %d disabled\n",
> > +   dev_err(&port_dev->dev, "connect-debounce 
> > failed, port %d disabled\n",
> > port1);
> >  
> > portstatus &= ~USB_PORT_STAT_CONNECTION;
> 
> In fact, this looks like it might be a mistaken patch conflict 
> resolution.
> 
> Anyway, the proposed fix is redundant.  There's no need to mention the 
> port number in the error message, because the port number is already 
> part of the device name for port_dev->dev.  The statement should be:
> 
> + dev_err(&port_dev->dev, "connect-debounce 
> failed\n");
> 
> like it was before Oliver's patch.

Indeed...  Greg, let me know if I should respin the patch, or you
prefer applying more fix on the top.


thanks,

Takashi
--
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: use kcalloc instead of kzalloc

[Alan Stern]

On Tue, 19 Aug 2014, Arjun Sreedharan wrote:

> kcalloc has protection from integer overflows
> which could arise from the multiplication of
> number of elements and size.
> 
> Signed-off-by: Arjun Sreedharan 

As Clemens pointed out, integer overflows cannot occur here.  This 
patch is not needed.

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: [linux-usb] USB Gadget drivers Windows 7/8 support and .bAlternateSetting in interface descriptor

[Felipe Balbi]

On Tue, Aug 19, 2014 at 10:27:39PM +0800, Peter Chen wrote:
> On Tue, Aug 19, 2014 at 06:05:27PM +0800, Xuebing Wang wrote:
> > 
> > On 08/19/2014 12:58 PM, Peter Chen wrote:
> > >>My environment is Freescale i.MX6SL EVK board (as USB peripheral device),
> > >>which is based on kernel 3.10.17. i.MX6SL uses ChipIdea dual-role
> > >>controller.
> > >>
> > >>My problem is that gadget drivers g_ether and g_audio (UAC1 enabled) can
> > >>NOT be detected by Windows 7 natively, while g_mass_storage, g_serial,
> > >>g_hid can be detected by Windows 7 natively.
> > >>
> > >>1) I found that both Ether and USB Audio uses .bAlternateSetting, while
> > >>Mass Storage, Serial and HID do NOT. I am wondering if this is related to
> > >>how Gadget framework handles USB_REQ_SET_INTERFACE request?
> > >>
> > >If possible, would you use Linux PC or Mac OS (macbook pro+) to test?
> > >>From my previous experiences, g_audio works not well with windows.
> > 
> > Thanks Peter. g_audio is now working with Ubuntu and MacOS host, but
> > can NOT get detected by Windows 7.
> > 
> > I am not sure if this Windows 7 detection issue is not specific to
> > g_audio (UAC1), because Windows can NOT natively detect g_ether
> > (even with RNDIS CONFIG_USB_ETH_RNDIS=y enabled).
> > 
> > Also, in file f_rndis.c, it says "/* Some controllers can't support
> > RNDIS ... */", I am not sure what does this mean. Does it mean
> > possibly controller like ChipIdea does NOT support RNDIS?
> > 
> 
> RNDIS is software stuff, isn't it?

it probably means that some HW configuration doesn't have enough
endpoints, or doesn't support a certain transfer type ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usbcore: Fix wrong device in an error message in hub_port_connect()

[Alan Stern]

On Tue, 19 Aug 2014, Takashi Iwai wrote:

> The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
> failures of the same port] added the check of the reliable port, but
> it also replaced the device argument to dev_err() wrongly, which leads
> to a NULL dereference.
> 
> This patch restores the right device, port_dev->dev.
> 
> [The fix suggested by Hannes]
> 
> Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of 
> the same port')
> Reported-by: Hannes Reinecke 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/usb/core/hub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 8a4dcbc7a75f..22635590860c 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -4631,7 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
> port1, u16 portstatus,
>   if (status != -ENODEV &&
>   port1 != unreliable_port &&
>   printk_ratelimit())
> - dev_err(&udev->dev, "connect-debounce failed, 
> port %d disabled\n",
> + dev_err(&port_dev->dev, "connect-debounce 
> failed, port %d disabled\n",
>   port1);
>  
>   portstatus &= ~USB_PORT_STAT_CONNECTION;

In fact, this looks like it might be a mistaken patch conflict 
resolution.

Anyway, the proposed fix is redundant.  There's no need to mention the 
port number in the error message, because the port number is already 
part of the device name for port_dev->dev.  The statement should be:

+   dev_err(&port_dev->dev, "connect-debounce 
failed\n");

like it was before Oliver's patch.

Alan Stern

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

Re: [PATCH] Newer Technology uSCSI SCSI-USB converter

[Greg KH]

On Fri, Aug 15, 2014 at 08:11:19PM +0100, Mark wrote:
> The uSCSI from Newer Technology is a SCSI-USB converter with USB ID 
> 06ca:2003. Like several other SCSI-USB products, it's a Shuttle Technology 
> OEM device. Copying the unusual-devs.h entry for device 04e6:0002 allows it 
> to work with Linux
> 
> There are currently six entries for Shuttle-developed SCSI-USB devices in 
> unusual-devs.h (grep for euscsi):
>   04e6:0002  Shuttle eUSCSI BridgeUSB_SC_DEVICE, USB_PR_DEVICE
>   04e6:000b  Shuttle eUSCSI BridgeUSB_SC_SCSI, USB_PR_BULK
>   04e6:000c  Shuttle eUSCSI BridgeUSB_SC_SCSI, USB_PR_BULK
>   050d:0115  Belkin USB SCSI Adaptor  USB_SC_SCSI, USB_PR_BULK
>   07af:0004  Microtech USB-SCSI-DB25  USB_SC_DEVICE, USB_PR_DEVICE
>   07af:0005  Microtech USB-SCSI-HD50  USB_SC_DEVICE, USB_PR_DEVICE
> 
> lsusb -v output for the uSCSI lists
>   bInterfaceSubClass  6 SCSI
>   bInterfaceProtocol 80 Bulk (Zip)
> 
> 
> This patch adds an entry for the uSCSI to unusual_devs.h.
> 
> diff -up linux-3.16/drivers/usb/storage/unusual_devs.h.orig 
> linux-3.16/drivers/usb/storage/unusual_devs.h
> --- linux-3.16/drivers/usb/storage/unusual_devs.h.orig2014-08-03 
> 23:25:02.0 +0100
> +++ linux-3.16/drivers/usb/storage/unusual_devs.h 2014-08-15 
> 19:48:54.0 +0100

I need a signed-off-by: line to be able to properly apply this patch.

Can you please read the kernel file, Documentation/SubmittingPatches and
read the section about signed-off-by: to understand what it means, and
then resend this with that information so that I can apply 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: [linux-usb] Is UAC1 (USB Audio Class 1.0) broken?

[Felipe Balbi]

On Sun, Aug 17, 2014 at 05:52:55PM +0800, Xuebing Wang wrote:
> Hi Community, Felipe,
> 
> I am trying to get UAC1 working on Freescale i.MX6SL EVK board (as USB
> peripheral device), which is based on kernel 3.10.17.

v3.10 ? Unless you test on something more recent (like v3.16 or
v3.17-rc1) you're on your own. How about asking for support from whoever
gave you this kernel ?

> In order to get UAC1 working with my Ubuntu 12.04 LTS host, I have to make a
> few changes to driver/usb/gadget/f_uac1.c

what changes ? care to send a patch ? Why do you need such change ? Are
you fixing a bug ?

> I check Mr. Torvald's master branch, some kernel stable branches, something
> similar to my change to f_uac1.c is not there.
> 
> Then, I did some more basic testing, and found:
> 1) Windows 7 can not detect. Still need more work to get Windows 7 detected.
> 2) MacOS (forgot exact version) complains 'The selected device has no output
> controls', which results in that I can not adjust volume. Music playback via
> UAC1 on MacOS is no problem.
> 
> Anybody tried UAC1 (or UAC2) recently? Is UAC1 broken?

it has been a while since I messed with UAC1, but I remember using it
early during dwc3 isochronous development as a testing ground. At it
transferred data just fine. I just care for volume controls however.

Try a newer kernel on your board otherwise community can't help
supporting vendor kernels.

-- 
balbi


signature.asc
Description: Digital signature

Re: What is the command line commands to use UAC2 at USB client side?

[Peter Chen]

On Tue, Aug 19, 2014 at 11:09:44AM +0200, Daniel Mack wrote:
> On 08/19/2014 11:01 AM, Jassi Brar wrote:
> > On Tue, Aug 19, 2014 at 2:15 PM, Daniel Mack  wrote:
> >> On 08/19/2014 02:01 AM, Xuebing Wang wrote:
> >>
> > root@imx6slevk:~#
> > root@imx6slevk:~# arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0
> > Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, 
> > Stereo
> > Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, 
> > Stereo
>  Such a setup should work, I recently tried it myself.
> 
>  The other direction (capturing from host, playback on device), however,
>  has a major problem as the device interface has no timing mechanism, and
>  hence 'arecord | aplay' on the gadget side fails. I've prepared patches
>  and a more comprehensive description for this, but I'm waiting for
>  Andrzej's patches to be reviewed, as mine are based upon his.
> >>
> > Hmm... I tested 48KHz USB-IN without noise, 44.1KHz did show noise
> > though ... iirc
> 
> With USB-IN, you're referring to arecord on the host side, and aplay on
> the gadget? Playing/ recording wave files on both sides worked fine for
> me. The only problem here is that once you link one side to a sink or
> source that expects audio to be transported at least roughly with the
> announces sample rate, things break because there is nothing that
> controls the timing. It's easy to fix, and as I said, I have patches for
> this that I'll send out shortly.
> 

Will you add feedback endpoint for that?

> However, I thought Xuebing's setup is the other way around, right?
> 
> >>> Does it work with Windows 7/8 host?
> >>
> >> I have no idea, and no Windows box to test on.
> >>
> > IIRC Windows doesn't have native support for UAC2.
> 
> That's true, you need a third party driver for that. I was referring to
> UAC1, but I didn't test this either.
> 
> 
> Daniel
> 

-- 
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: [linux-usb] USB Gadget drivers Windows 7/8 support and .bAlternateSetting in interface descriptor

[Peter Chen]

On Tue, Aug 19, 2014 at 06:05:27PM +0800, Xuebing Wang wrote:
> 
> On 08/19/2014 12:58 PM, Peter Chen wrote:
> >>My environment is Freescale i.MX6SL EVK board (as USB peripheral device),
> >>which is based on kernel 3.10.17. i.MX6SL uses ChipIdea dual-role
> >>controller.
> >>
> >>My problem is that gadget drivers g_ether and g_audio (UAC1 enabled) can
> >>NOT be detected by Windows 7 natively, while g_mass_storage, g_serial,
> >>g_hid can be detected by Windows 7 natively.
> >>
> >>1) I found that both Ether and USB Audio uses .bAlternateSetting, while
> >>Mass Storage, Serial and HID do NOT. I am wondering if this is related to
> >>how Gadget framework handles USB_REQ_SET_INTERFACE request?
> >>
> >If possible, would you use Linux PC or Mac OS (macbook pro+) to test?
> >>From my previous experiences, g_audio works not well with windows.
> 
> Thanks Peter. g_audio is now working with Ubuntu and MacOS host, but
> can NOT get detected by Windows 7.
> 
> I am not sure if this Windows 7 detection issue is not specific to
> g_audio (UAC1), because Windows can NOT natively detect g_ether
> (even with RNDIS CONFIG_USB_ETH_RNDIS=y enabled).
> 
> Also, in file f_rndis.c, it says "/* Some controllers can't support
> RNDIS ... */", I am not sure what does this mean. Does it mean
> possibly controller like ChipIdea does NOT support RNDIS?
> 

RNDIS is software stuff, isn't it?

> 
> >>2) Also, I am not sure if it is related to ChipIdea quirk
> >>(gadget_supports_altsettings in file gadget_chips.h)?
> >>
> >I can't find chipidea quirk at gadget_chips.h, besides, altsettings
> >are software stuff.
> >
> >Peter
> 
> -- 
> Thanks,
> Xuebing Wang
> 

-- 
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 resend] Revert "usb: gadget: u_ether: synchronize with transmit when stopping queue"

[Tony Lindgren]

* roy.qing...@gmail.com  [140819 17:24]:
> From: Li RongQing 
> 
> This reverts commit a9232076374334ca2bc2a448dfde96d38a54349a.
> 
> It introduced a dead lock, and did not fix anything.
> 
> it made netif_tx_lock() be called in IRQ context, but in softirq context,
> the same lock is locked without disabling IRQ. In fact, the commit a923207637
> did not fix anything, since netif_stop_queue did not free the any resource

Yeah I'm seeing this too:

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: [PATCH 02/13] usb: udc: set the udc is ready to pullup dp when it needs

[Peter Chen]

On Tue, Aug 19, 2014 at 01:46:17AM +, Paul Zimmerman wrote:
> > From: Peter Chen [mailto:peter.c...@freescale.com]
> > Sent: Sunday, August 17, 2014 9:14 PM
> > 
> > Except for chipidea driver, all other udc drivers will tell the
> > gadget driver that they are ready to pullup dp at udc_start, it
> > is the default behaviour.
> > 
> > The chipidea driver is ready to pullup dp when the vbus is there,
> > and isn't ready to pullup dp when the vbus is not there. Other
> > udc drivers which should not pull up when vbus is not there should
> > change like chipidea does to pass the Back-Voltage Testing at
> > www.usb.org/developers/docs/USB-IFTestProc1_3.pdf.
> > 
> > Signed-off-by: Peter Chen 
> > ---
> >  drivers/usb/chipidea/udc.c  |9 -
> >  drivers/usb/dwc2/gadget.c   |2 ++
> >  drivers/usb/dwc3/gadget.c   |2 ++
> >  drivers/usb/gadget/udc/amd5536udc.c |1 +
> >  drivers/usb/gadget/udc/atmel_usba_udc.c |2 ++
> >  drivers/usb/gadget/udc/bcm63xx_udc.c|2 ++
> >  drivers/usb/gadget/udc/dummy_hcd.c  |1 +
> >  drivers/usb/gadget/udc/fotg210-udc.c|1 +
> >  drivers/usb/gadget/udc/fsl_qe_udc.c |1 +
> >  drivers/usb/gadget/udc/fsl_udc_core.c   |2 ++
> >  drivers/usb/gadget/udc/fusb300_udc.c|1 +
> >  drivers/usb/gadget/udc/gr_udc.c |2 ++
> >  drivers/usb/gadget/udc/lpc32xx_udc.c|2 ++
> >  drivers/usb/gadget/udc/m66592-udc.c |2 ++
> >  drivers/usb/gadget/udc/mv_u3d_core.c|1 +
> >  drivers/usb/gadget/udc/mv_udc_core.c|2 ++
> >  drivers/usb/gadget/udc/net2272.c|1 +
> >  drivers/usb/gadget/udc/net2280.c|1 +
> >  drivers/usb/gadget/udc/omap_udc.c   |1 +
> >  drivers/usb/gadget/udc/pch_udc.c|1 +
> >  drivers/usb/gadget/udc/pxa25x_udc.c |1 +
> >  drivers/usb/gadget/udc/pxa27x_udc.c |1 +
> >  drivers/usb/gadget/udc/r8a66597-udc.c   |1 +
> >  drivers/usb/gadget/udc/s3c-hsudc.c  |1 +
> >  drivers/usb/gadget/udc/s3c2410_udc.c|1 +
> >  drivers/usb/musb/musb_gadget.c  |2 ++
> >  drivers/usb/renesas_usbhs/mod_gadget.c  |7 ++-
> >  27 files changed, 45 insertions(+), 6 deletions(-)
> 
> Instead of modifying all of the UDC drivers, how about adding a flag to
> 'struct usb_gadget' named 'needs_ready' or similar? If the UDC doesn't
> set the flag, udc-core would call usb_udc_ready_to_connect() on behalf
> of the UDC. If the UDC sets the flag (chipidea only?) then the UDC would
> be responsible for calling usb_udc_ready_to_connect().
> 

USB spec requires dp is not pulled up when the vbus is not there, the dwc3 is
the newest core, I don't think other older udc cores all has similar capability
that does don't draw back voltage if software pullup bit is set and vbus is
not there.

This patchset will delete the unconditional pullup dp operation at udc-core,
and we need to pullup dp at the end of hardware initialization (not consider
vbus case), then the end of .udc_start at udc driver is the old place.

-- 
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 v3 2/3] usb: gadget: f_fs: add ioctl returning ep descriptor

[Felipe Balbi]

On Wed, Jul 30, 2014 at 07:28:24PM +0400, Sergei Shtylyov wrote:
> On 07/30/2014 01:43 PM, Robert Baldyga wrote:
> 
> >This patch introduces ioctl named FUNCTIONFS_ENDPOINT_DESC, which
> >returns endpoint descriptor to userspace. It works only if function
> >is active.
> 
> >Signed-off-by: Robert Baldyga 
> >---
> >  drivers/usb/gadget/f_fs.c   | 17 +
> >  include/uapi/linux/usb/functionfs.h |  6 ++
> >  2 files changed, 23 insertions(+)
> 
> >diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
> >index 6b806be..7f16c5a 100644
> >--- a/drivers/usb/gadget/f_fs.c
> >+++ b/drivers/usb/gadget/f_fs.c
> >@@ -1031,6 +1031,23 @@ static long ffs_epfile_ioctl(struct file *file, 
> >unsigned code,
> > case FUNCTIONFS_ENDPOINT_REVMAP:
> > ret = epfile->ep->num;
> > break;
> >+case FUNCTIONFS_ENDPOINT_DESC:
> >+{
> >+int desc_idx;
> >+struct usb_endpoint_descriptor *desc;
> >+
> >+if (epfile->ffs->gadget->speed == USB_SPEED_SUPER)
> >+desc_idx = 2;
> >+else if (epfile->ffs->gadget->speed == USB_SPEED_HIGH)
> >+desc_idx = 1;
> >+else
> >+desc_idx = 0;
> 
>I think the above is asking to be a *switch* statement instead.

agreed.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] USB: pch_udc: USB gadget device support for Intel Quark X1000

[Felipe Balbi]

Hi,

On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote:
> From: Bryan O'Donoghue 
> 
> This patch is to enable the USB gadget device for Intel Quark X1000
> 
> Signed-off-by: Bryan O'Donoghue 
> Signed-off-by: Bing Niu 
> Signed-off-by: Alvin (Weike) Chen 

Can someone confirm to me this is not another incarnation of chipidea ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] USB: pch_udc: Add support for Intel Quark X1000 USB gadget device

[Felipe Balbi]

On Mon, Aug 04, 2014 at 11:00:07AM -0700, Chen, Alvin wrote:
> From: "Alvin (Weike) Chen" 
> 
> Hi,
> Intel Quark X1000 consists of one USB gadget device which can be PCI 
> enumerated. 
> pch_udc layer doesn't support it. Thus, we add support for Intel Quark X1000 
> USB
> gadget device as well.

where is the patch ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/3] usb: gadget/uvc: fix possible lockup in uvc gadget

[Felipe Balbi]

Hi,

On Fri, Aug 08, 2014 at 05:38:57PM +0200, Michael Grzeschik wrote:
> If the pending buffers in the queue could not be pushed to the udc
> endpoint we have to cancel the uvc_queue. Otherwise the gadget will get
> stuck on this error. This patch calls uvc_queue_cancel if usb_ep_queue
> failed.
> 
> Signed-off-by: Michael Grzeschik 

Laurent, is this good to be merged as a fix ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usbcore: Fix wrong device in an error message in hub_port_connect()

[Takashi Iwai]

At Tue, 19 Aug 2014 15:13:24 +0200,
Takashi Iwai wrote:
> 
> The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
> failures of the same port] added the check of the reliable port, but
> it also replaced the device argument to dev_err() wrongly, which leads
> to a NULL dereference.
> 
> This patch restores the right device, port_dev->dev.
> 
> [The fix suggested by Hannes]
> 
> Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of 
> the same port')

I overlooked that this commit has a Cc to stable.  Then please queue
the fix patch to stable, too.


thanks,

Takashi

> Reported-by: Hannes Reinecke 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/usb/core/hub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 8a4dcbc7a75f..22635590860c 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -4631,7 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
> port1, u16 portstatus,
>   if (status != -ENODEV &&
>   port1 != unreliable_port &&
>   printk_ratelimit())
> - dev_err(&udev->dev, "connect-debounce failed, 
> port %d disabled\n",
> + dev_err(&port_dev->dev, "connect-debounce 
> failed, port %d disabled\n",
>   port1);
>  
>   portstatus &= ~USB_PORT_STAT_CONNECTION;
> -- 
> 2.0.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
> 
--
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] usbcore: Fix wrong device in an error message in hub_port_connect()

[Takashi Iwai]

The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
failures of the same port] added the check of the reliable port, but
it also replaced the device argument to dev_err() wrongly, which leads
to a NULL dereference.

This patch restores the right device, port_dev->dev.

[The fix suggested by Hannes]

Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of 
the same port')
Reported-by: Hannes Reinecke 
Signed-off-by: Takashi Iwai 
---
 drivers/usb/core/hub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8a4dcbc7a75f..22635590860c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4631,7 +4631,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
if (status != -ENODEV &&
port1 != unreliable_port &&
printk_ratelimit())
-   dev_err(&udev->dev, "connect-debounce failed, 
port %d disabled\n",
+   dev_err(&port_dev->dev, "connect-debounce 
failed, port %d disabled\n",
port1);
 
portstatus &= ~USB_PORT_STAT_CONNECTION;
-- 
2.0.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: xhci driver causes Kernel-Oops starting with kernel 3.16

[Mathias Nyman]

On 08/18/2014 06:59 PM, Manuel Reimer wrote:
> Hello,
> 
> I already opened a bug report for my problem here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=82731#c1
> 
> Starting with Kernel 3.16 I get kernel Oops from time to time when booting my 
> desktop system.
> 
> A reset helps to bring the system up without problems.
> 
> I've attached a dmesg dump to my bug report:
> https://bugzilla.kernel.org/attachment.cgi?id=147061
> 
> Thank you very much in advance for any help.
> 

Thanks for the report.
Looks like there are two issues here, first, for some reason it fails to read 
the xhci extended capability register sometimes.

Secondly, we fail at failing:) so if we fail in the middle of xhci_mem_init(), 
before all needed memory is allocated we still
call xhci_mem_cleanup() which will try to access and free things not yet 
allocated.

The second part should be easier to fix.

Did the same machine work with previous kernel versions?
How about if you compile xhci as a module, and load it, does it still fail 
sometimes?

-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

[PATCH 3/3] xhci: rework cycle bit checking for new dequeue pointers

[Mathias Nyman]

When we manually need to move the TR dequeue pointer we need to set the
correct cycle bit as well. Previously we used the trb pointer from the
last event received as a base, but this was changed in
commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
to use the dequeue pointer from the endpoint context instead

It turns out some Asmedia controllers advance the dequeue pointer
stored in the endpoint context past the event triggering TRB, and
this messed up the way the cycle bit was calculated.

Instead of adding a quirk or complicating the already hard to follow cycle bit
code, the whole cycle bit calculation is now simplified and adapted to handle
event and endpoint context dequeue pointer differences.

Fixes: 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
Reported-by: Maciej Puzio 
Reported-by: Evan Langlois 
Reviewed-by: Julius Werner 
Tested-by: Maciej Puzio 
Tested-by: Evan Langlois 
Signed-off-by: Mathias Nyman 
Cc: sta...@vger.kernel.org
---
 drivers/usb/host/xhci-ring.c | 101 +--
 drivers/usb/host/xhci.c  |   3 ++
 2 files changed, 42 insertions(+), 62 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ac8cf23..abed30b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -364,32 +364,6 @@ static void ring_doorbell_for_active_rings(struct xhci_hcd 
*xhci,
}
 }
 
-/*
- * Find the segment that trb is in.  Start searching in start_seg.
- * If we must move past a segment that has a link TRB with a toggle cycle state
- * bit set, then we will toggle the value pointed at by cycle_state.
- */
-static struct xhci_segment *find_trb_seg(
-   struct xhci_segment *start_seg,
-   union xhci_trb  *trb, int *cycle_state)
-{
-   struct xhci_segment *cur_seg = start_seg;
-   struct xhci_generic_trb *generic_trb;
-
-   while (cur_seg->trbs > trb ||
-   &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {
-   generic_trb = &cur_seg->trbs[TRBS_PER_SEGMENT - 1].generic;
-   if (generic_trb->field[3] & cpu_to_le32(LINK_TOGGLE))
-   *cycle_state ^= 0x1;
-   cur_seg = cur_seg->next;
-   if (cur_seg == start_seg)
-   /* Looped over the entire list.  Oops! */
-   return NULL;
-   }
-   return cur_seg;
-}
-
-
 static struct xhci_ring *xhci_triad_to_transfer_ring(struct xhci_hcd *xhci,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id)
@@ -459,9 +433,12 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
struct xhci_virt_device *dev = xhci->devs[slot_id];
struct xhci_virt_ep *ep = &dev->eps[ep_index];
struct xhci_ring *ep_ring;
-   struct xhci_generic_trb *trb;
+   struct xhci_segment *new_seg;
+   union xhci_trb *new_deq;
dma_addr_t addr;
u64 hw_dequeue;
+   bool cycle_found = false;
+   bool td_last_trb_found = false;
 
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
ep_index, stream_id);
@@ -486,45 +463,45 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
hw_dequeue = le64_to_cpu(ep_ctx->deq);
}
 
-   /* Find virtual address and segment of hardware dequeue pointer */
-   state->new_deq_seg = ep_ring->deq_seg;
-   state->new_deq_ptr = ep_ring->dequeue;
-   while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
-   != (dma_addr_t)(hw_dequeue & ~0xf)) {
-   next_trb(xhci, ep_ring, &state->new_deq_seg,
-   &state->new_deq_ptr);
-   if (state->new_deq_ptr == ep_ring->dequeue) {
-   WARN_ON(1);
-   return;
-   }
-   }
+   new_seg = ep_ring->deq_seg;
+   new_deq = ep_ring->dequeue;
+   state->new_cycle_state = hw_dequeue & 0x1;
+
/*
-* Find cycle state for last_trb, starting at old cycle state of
-* hw_dequeue. If there is only one segment ring, find_trb_seg() will
-* return immediately and cannot toggle the cycle state if this search
-* wraps around, so add one more toggle manually in that case.
+* We want to find the pointer, segment and cycle state of the new trb
+* (the one after current TD's last_trb). We know the cycle state at
+* hw_dequeue, so walk the ring until both hw_dequeue and last_trb are
+* found.
 */
-   state->new_cycle_state = hw_dequeue & 0x1;
-   if (ep_ring->first_seg == ep_ring->first_seg->next &&
-   cur_td->last_trb < state->new_deq_ptr)
-   state->new_cycle_state ^= 0x1;
+   do {
+   if (!cycle_found && xhci_trb_virt_to_dma(new_seg, new_deq)
+   == (dma_addr_t)(hw_dequeue & ~0x

[PATCH 1/3] xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_STOP_INVAL

[Mathias Nyman]

From: Hans de Goede 

When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G
Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a
the integrated Intel xhci controller on a Haswell laptop:

00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC 
[8086:9c31] (rev 04)

The following error gets logged to dmesg:

xhci error: Transfer event TRB DMA ptr not part of current TD

Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found
fixes this.

Signed-off-by: Hans de Goede 
Signed-off-by: Mathias Nyman 
Cc: sta...@vger.kernel.org
---
 drivers/usb/host/xhci-ring.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 60fb52a..ac8cf23 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2487,7 +2487,8 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 * last TRB of the previous TD. The command completion handle
 * will take care the rest.
 */
-   if (!event_seg && trb_comp_code == COMP_STOP_INVAL) {
+   if (!event_seg && (trb_comp_code == COMP_STOP ||
+  trb_comp_code == COMP_STOP_INVAL)) {
ret = 0;
goto cleanup;
}
-- 
1.8.3.2

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

[PATCH 2/3] usb: xhci: amd chipset also needs short TX quirk

[Mathias Nyman]

From: Huang Rui 

AMD xHC also needs short tx quirk after tested on most of chipset
generations. That's because there is the same incorrect behavior like
Fresco Logic host. Please see below message with on USB webcam
attached on xHC host:

[  139.262944] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.266934] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.270913] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.274937] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.278914] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.282936] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.286915] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.290938] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.294913] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[  139.298917] xhci_hcd :00:10.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?

Reported-by: Arindam Nath 
Tested-by: Shriraj-Rai P 
Cc: 
Signed-off-by: Huang Rui 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-pci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 687d366..95d0a6d 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -101,6 +101,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
/* AMD PLL quirk */
if (pdev->vendor == PCI_VENDOR_ID_AMD && usb_amd_find_chipset_info())
xhci->quirks |= XHCI_AMD_PLL_FIX;
+
+   if (pdev->vendor == PCI_VENDOR_ID_AMD)
+   xhci->quirks |= XHCI_TRUST_TX_LENGTH;
+
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
xhci->quirks |= XHCI_LPM_SUPPORT;
xhci->quirks |= XHCI_INTEL_HOST;
-- 
1.8.3.2

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

[PATCH 0/3] xhci: fixes for usb-linus

[Mathias Nyman]

Hi Greg

These following xhci fixes for usb-linus apply on top of 3.17-rc1

It includes the first patch of Hans de Goede's xhci UAS fixes. I'll send the 
rest of
his xhci cleanup patches to usb-next.

The rework cycle bit patch has a bit more code, primary goal was to fix a issue
introduced in commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue 
pointer")
added to 3.15, but turned out code was getting so complex it needed some 
refurbishing.

Hans de Goede (1):
  xhci: Treat not finding the event_seg on COMP_STOP the same as
COMP_STOP_INVAL

Huang Rui (1):
  usb: xhci: amd chipset also needs short TX quirk

Mathias Nyman (1):
  xhci: rework cycle bit checking for new dequeue pointers

 drivers/usb/host/xhci-pci.c  |   4 ++
 drivers/usb/host/xhci-ring.c | 104 +--
 drivers/usb/host/xhci.c  |   3 ++
 3 files changed, 48 insertions(+), 63 deletions(-)

-- 
1.8.3.2

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

Re: [PATCH v4] usb: hcd: add generic PHY support

[Sergei Shtylyov]

Hello.

On 8/19/2014 1:33 PM, Greg KH wrote:


Add the generic PHY support, analogous to the USB PHY support. Intended it to be
used with the PCI EHCI/OHCI drivers and the xHCI platform driver.



Signed-off-by: Sergei Shtylyov 
Signed-off-by: Yoshihiro Shimoda 



---
This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.



The USB PHY driver patch with which this patch is intended to be used, has been
just posted, along with the platform PHY device tree patches; the patches that
link the PCI EHCI/OHCI  devices to the PHY device will follow shortly.



Greg, may I ask what elase are you waiting for with this patch. I don't
see it in 3.17-rc1 and nobody has commented on this version. I've posted to
linux-usb all my patches that need this one, and there are patch series from
other people now depending on this patch...



I don't even see it in my patch queue anymore, are you sure it's not
already in Linus's tree,


  Yes, I am.


or that someone else didn't take it?


   Hm, who else might have taken this patch, especially w/o notifying me?


If not, then please resend.


   Sigh... OK.


thanks,



greg k-h


WBR, Sergei

--
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: use kcalloc instead of kzalloc

[Clemens Ladisch]

Arjun Sreedharan wrote:
> kcalloc has protection from integer overflows
> which could arise from the multiplication of
> number of elements and size.

You are implying that such an overflow could arise in this code.
This is false.

> @@ -380,8 +380,7 @@ static int usb_parse_interface(struct device *ddev, int 
> cfgno,
>
>   if (num_ep > 0) {
>   /* Can't allocate 0 bytes */
> - len = sizeof(struct usb_host_endpoint) * num_ep;
> - alt->endpoint = kzalloc(len, GFP_KERNEL);
> + alt->endpoint = kcalloc(num_ep, sizeof(struct 
> usb_host_endpoint), GFP_KERNEL);

bNumEndpoints is an unsigned 8-bit integer.

And even if you did not notice this, you should have noticed the if()
directly before this one.

> @@ -683,13 +682,11 @@ int usb_get_configuration(struct usb_device *dev)
>   return -EINVAL;
>   }
>
> - length = ncfg * sizeof(struct usb_host_config);
> - dev->config = kzalloc(length, GFP_KERNEL);
> + dev->config = kcalloc(ncfg, sizeof(struct usb_host_config), GFP_KERNEL);
>   if (!dev->config)
>   goto err2;
>
> - length = ncfg * sizeof(char *);
> - dev->rawdescriptors = kzalloc(length, GFP_KERNEL);
> + dev->rawdescriptors = kcalloc(ncfg, sizeof(char *), GFP_KERNEL);

Same oversights here.


Regards,
Clemens
--
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: use kcalloc instead of kzalloc

[Arjun Sreedharan]

kcalloc has protection from integer overflows
which could arise from the multiplication of
number of elements and size.

Signed-off-by: Arjun Sreedharan 
---
 drivers/usb/core/config.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index b2a540b..abde67d 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -318,7 +318,7 @@ static int usb_parse_interface(struct device *ddev, int 
cfgno,
struct usb_interface_cache *intfc;
struct usb_host_interface *alt;
int i, n;
-   int len, retval;
+   int retval;
int num_ep, num_ep_orig;
 
d = (struct usb_interface_descriptor *) buffer;
@@ -380,8 +380,7 @@ static int usb_parse_interface(struct device *ddev, int 
cfgno,
 
if (num_ep > 0) {
/* Can't allocate 0 bytes */
-   len = sizeof(struct usb_host_endpoint) * num_ep;
-   alt->endpoint = kzalloc(len, GFP_KERNEL);
+   alt->endpoint = kcalloc(num_ep, sizeof(struct 
usb_host_endpoint), GFP_KERNEL);
if (!alt->endpoint)
return -ENOMEM;
}
@@ -683,13 +682,11 @@ int usb_get_configuration(struct usb_device *dev)
return -EINVAL;
}
 
-   length = ncfg * sizeof(struct usb_host_config);
-   dev->config = kzalloc(length, GFP_KERNEL);
+   dev->config = kcalloc(ncfg, sizeof(struct usb_host_config), GFP_KERNEL);
if (!dev->config)
goto err2;
 
-   length = ncfg * sizeof(char *);
-   dev->rawdescriptors = kzalloc(length, GFP_KERNEL);
+   dev->rawdescriptors = kcalloc(ncfg, sizeof(char *), GFP_KERNEL);
if (!dev->rawdescriptors)
goto err2;
 
-- 
1.8.1.msysgit.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: Transient USB disconnects

[David Laight]

From: Alan Stern 
> On Fri, 15 Aug 2014, David Laight wrote:
> 
> > With all the usb dynamic-debug enabled the first errors I see are 'detected 
> > XactErr'
> > len 0/1522 and len 2048/18944 (all 32 retries).
> > Then some '3strikes' messages (75 in total split between the endpoints).
> >
> > I've not yet looked at what those errors actually mean.
> 
> "Detected XactErr" means a transaction error occurred (the Transaction
> Error (XactErr) bit was set in the qTD's status field).  The len values
> are the number of bytes transferred and the number of bytes requested.
> Usually this occurs because the host doesn't receive a handshake or
> data packet from the device.
> 
> The "3strikes" messages mean an URB was aborted because there were too
> many errors.

I think I've discovered our underlying problem.

I scoped the USB data lines (NFI why the hardware guys hadn't looked at them!).
As well as the SOF (every 125us) there is a rather nasty decaying transient
every 41us that is almost 400mV and lasts about as long as the SOF.
(These seem to be generated by some PWM fan controllers, possibly ground lift!)

I suspect that when the transient lines up with the SOF the envelope detector
in the USB host detects the 800mV that would appear when the target is
unplugged - so actions an unplug event and drives a USB reset.

This is all the USB monitor sees - normal data (with acks) and a sudden
host reset - no retries.

This rather begs the question of why the driver trace shows repeated URB
submissions - since something should know that the 'unplug' has been signalled.
However I've not tried to align the USB monitor and scope traces, nor the
driver events (possible by using the UART signals one of the 5 COM ports).

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: [BUG] usb_dev_resume returns -113 due to work items queued by usb on pm_wq is not executed before suspending.

[Du, ChangbinX]

> Commit d6236f6d1d88 prevents the roothub resuming work item from being
> queued.
> 
> > 4) We force system suspending process aborted (by modifying code) just
> after the usb
> >   Device suspend callback is invoked.
> > 5) Then PM core will call resume callback of the usb device to recovery. On
> this step
> >   usb_dev_resume() invokes and it return -113 error. Because the
> can_submit flag of
> >   root hub is 0. Root hub resuming work item is still pending.
> 
> I still think that commit has already fixed your problem.
> 
> Alan Stern

Yes, thanks. Issue didn't reproduce after applying that patch.
--
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 2/2] usb: gadget: Add xilinx usb2 device support

[Daniel Mack]

On 08/19/2014 11:56 AM, Daniel Mack wrote:
> On 07/22/2014 11:08 AM, Subbaraya Sundeep Bhatta wrote:

>>  drivers/usb/gadget/Kconfig  |   14 +
>>  drivers/usb/gadget/Makefile |1 +
>>  drivers/usb/gadget/udc-xilinx.c | 2261 
>> +++
>>  3 files changed, 2276 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/usb/gadget/udc-xilinx.c
> 
> As your driver has a DT binding, you have to describe it in
> Documentation/devicetree/bindings.

Ah, sorry. I missed patch 1/2 which does that.


Thanks,
Daniel

--
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: [linux-usb] USB Gadget drivers Windows 7/8 support and .bAlternateSetting in interface descriptor

[Xuebing Wang]

On 08/19/2014 12:58 PM, Peter Chen wrote:
  

My environment is Freescale i.MX6SL EVK board (as USB peripheral device),
which is based on kernel 3.10.17. i.MX6SL uses ChipIdea dual-role
controller.

My problem is that gadget drivers g_ether and g_audio (UAC1 enabled) can
NOT be detected by Windows 7 natively, while g_mass_storage, g_serial,
g_hid can be detected by Windows 7 natively.

1) I found that both Ether and USB Audio uses .bAlternateSetting, while
Mass Storage, Serial and HID do NOT. I am wondering if this is related to
how Gadget framework handles USB_REQ_SET_INTERFACE request?


If possible, would you use Linux PC or Mac OS (macbook pro+) to test?
>From my previous experiences, g_audio works not well with windows.


Thanks Peter. g_audio is now working with Ubuntu and MacOS host, but can 
NOT get detected by Windows 7.


I am not sure if this Windows 7 detection issue is not specific to 
g_audio (UAC1), because Windows can NOT natively detect g_ether (even 
with RNDIS CONFIG_USB_ETH_RNDIS=y enabled).


Also, in file f_rndis.c, it says "/* Some controllers can't support 
RNDIS ... */", I am not sure what does this mean. Does it mean possibly 
controller like ChipIdea does NOT support RNDIS?




2) Also, I am not sure if it is related to ChipIdea quirk
(gadget_supports_altsettings in file gadget_chips.h)?

  
I can't find chipidea quirk at gadget_chips.h, besides, altsettings

are software stuff.

Peter


--
Thanks,
Xuebing Wang

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

[Daniel Mack]

Hi,

On 07/22/2014 11:08 AM, Subbaraya Sundeep Bhatta wrote:
> This patch adds xilinx usb2 device driver support

Add some more information here, please. Copying the text from the
Kconfig option is already a good start.

>  drivers/usb/gadget/Kconfig  |   14 +
>  drivers/usb/gadget/Makefile |1 +
>  drivers/usb/gadget/udc-xilinx.c | 2261 
> +++
>  3 files changed, 2276 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/usb/gadget/udc-xilinx.c

As your driver has a DT binding, you have to describe it in
Documentation/devicetree/bindings.

> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -459,6 +459,20 @@ config USB_EG20T
> ML7213/ML7831 is companion chip for Intel Atom E6xx series.
> ML7213/ML7831 is completely compatible for Intel EG20T PCH.
>
> +config USB_GADGET_XILINX
> + tristate "Xilinx USB Driver"
> + depends on COMPILE_TEST

Why would you depend on that?

Also, your code uses device tree functions unconditionally, which is
fine, but it must hence depend on 'OF'.

> +struct xusb_ep {
> + struct usb_ep ep_usb;
> + struct list_head queue;
> + struct xusb_udc *udc;
> + const struct usb_endpoint_descriptor *desc;
> + u32 rambase;
> + u32 offset;
> + char name[4];
> + u16 epnumber;
> + u16 maxpacket;
> + u16 buffer0count;
> + u16 buffer1count;
> + u8 buffer0ready;
> + u8 buffer1ready;
> + u8 eptype;
> + u8 curbufnum;
> + u8 is_in;
> + u8 is_iso;

Some of those could probably become booleans.

> +struct xusb_udc {
> + struct usb_gadget gadget;
> + struct xusb_ep ep[8];
> + struct usb_gadget_driver *driver;
> + struct usb_ctrlrequest setup;
> + struct xusb_req *req;
> + struct device *dev;
> + u32 usb_state;
> + u32 remote_wkp;
> + u32 setupseqtx;
> + u32 setupseqrx;
> + void __iomem *base_address;
> + spinlock_t lock;
> + bool dma_enabled;
> +
> + unsigned int (*read_fn)(void __iomem *);
> + void (*write_fn)(void __iomem *, u32, u32);
> +};
> +
> +/* Endpoint buffer start addresses in the core */
> +static u32 rambase[8] = { 0x22, 0x1000, 0x1100, 0x1200, 0x1300, 0x1400, 
> 0x1500,
> + 0x1600 };

As stated by Peter, indenting such lines to match the position of the
line before makes such code much prettier and more readable. It's also
done in the majority of drivers.

This counts for many locations in your code.

> +/* Control endpoint configuration.*/
> +static const struct usb_endpoint_descriptor config_bulk_out_desc = {
> + .bLength= USB_DT_ENDPOINT_SIZE,
> + .bDescriptorType= USB_DT_ENDPOINT,
> + .bEndpointAddress   = USB_DIR_OUT,
> + .bmAttributes   = USB_ENDPOINT_XFER_BULK,
> + .wMaxPacketSize = cpu_to_le16(64),

Why not use EP0_MAX_PACKET here?

> +static void xudc_wrstatus(struct xusb_udc *udc)
> +{
> + struct xusb_ep *ep0 = &udc->ep[XUSB_EP_NUMBER_ZERO];
> + u32 epcfgreg;
> +
> + epcfgreg = udc->read_fn(udc->base_address + ep0->offset)|
> + XUSB_EP_CFG_DATA_TOGGLE_MASK;
> + udc->write_fn(udc->base_address, ep0->offset, epcfgreg);
> + udc->write_fn(udc->base_address, ep0->offset + XUSB_EP_BUF0COUNT_OFFSET,
> + 0);

Just a nit, but renaming 'base_address' to something like 'base' or
'addr' would help you get around or maximum line constraint here and in
some other places.

> +static int xudc_dma_send(struct xusb_ep *ep, struct xusb_req *req,
> + u8 *buffer, u32 length)
> +{
> + u32 *eprambase;
> + dma_addr_t src;
> + dma_addr_t dst;
> + int ret;
> + struct xusb_udc *udc = ep->udc;
> +
> + src = req->usb_req.dma + req->usb_req.actual;
> + if (req->usb_req.length)
> + dma_sync_single_for_device(udc->dev, src,
> + length, DMA_TO_DEVICE);
> + if (!ep->curbufnum && !ep->buffer0ready) {
> + /* Get the Buffer address and copy the transmit data.*/
> + eprambase = (u32 __force *)(udc->base_address +
> + ep->rambase);
> + dst = virt_to_phys(eprambase);
> + udc->write_fn(udc->base_address, ep->offset +
> + XUSB_EP_BUF0COUNT_OFFSET, length);
> + udc->write_fn(udc->base_address, XUSB_DMA_CONTROL_OFFSET,
> + XUSB_DMA_BRR_CTRL | (1 << ep->epnumber));
> + ep->buffer0ready = 1;
> + ep->curbufnum = 1;
> + } else if (ep->curbufnum && !ep->buffer1ready) {
> + /* Get the Buffer address and copy the transmit data.*/
> + eprambase = (u32 __force *)(udc->base_address +
> + ep->rambase + ep->ep_usb.maxpacket);
> + dst = virt_to_phys(eprambase);
> + udc->write_fn(udc->base_address, ep->offset +
> +

Re: What is the command line commands to use UAC2 at USB client side?

[Jassi Brar]

On Tue, Aug 19, 2014 at 2:39 PM, Daniel Mack  wrote:
> On 08/19/2014 11:01 AM, Jassi Brar wrote:
>> On Tue, Aug 19, 2014 at 2:15 PM, Daniel Mack  wrote:
>>> On 08/19/2014 02:01 AM, Xuebing Wang wrote:
>>>
>> root@imx6slevk:~#
>> root@imx6slevk:~# arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0
>> Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, 
>> Stereo
>> Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
> Such a setup should work, I recently tried it myself.
>
> The other direction (capturing from host, playback on device), however,
> has a major problem as the device interface has no timing mechanism, and
> hence 'arecord | aplay' on the gadget side fails. I've prepared patches
> and a more comprehensive description for this, but I'm waiting for
> Andrzej's patches to be reviewed, as mine are based upon his.
>>>
>> Hmm... I tested 48KHz USB-IN without noise, 44.1KHz did show noise
>> though ... iirc
>
> With USB-IN, you're referring to arecord on the host side, and aplay on
> the gadget? Playing/ recording wave files on both sides worked fine for
> me. The only problem here is that once you link one side to a sink or
> source that expects audio to be transported at least roughly with the
> announces sample rate, things break because there is nothing that
> controls the timing. It's easy to fix, and as I said, I have patches for
> this that I'll send out shortly.
>
Its been quite some time now, but I think we designed the uac2 to rely
on USB's ISO packets' rate control to send and receive audio data at
announced sampling rate. For some rates though the data rate doesn't
become a multiple of packetsize and we see a periodic 'click' noise.
Probably we are talking about the same thing. Please try to CC me on
your patches.

> However, I thought Xuebing's setup is the other way around, right?
>
Yes, Xuebing tested USB-OUT.

Cheers,
-Jassi
--
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] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

[Sharma, Sanjeev]

Thanks for letting me know.

Sanjeev Sharma

-Original Message-
From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] 
Sent: Tuesday, August 19, 2014 3:01 PM
To: Sharma, Sanjeev
Cc: kra...@redhat.com; mdharm-...@one-eyed-alien.net; 
linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; 
linux-s...@vger.kernel.org; Hans de Goede
Subject: Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote:
> Hi Greg,
> 
> Any feedback on this patch ?

The merge window ended 2 days ago, _and_ I'm at the kernel summit this week, 
_and_ my queue is currently sitting at:
$ mdfrm -c ~/mail/todo/
1317 messages in /home/gregkh/mail/todo/

So please be patient.  I'll get to it in a few weeks.

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 v4] usb: hcd: add generic PHY support

[Greg KH]

On Tue, Aug 19, 2014 at 02:34:59AM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 07/23/2014 02:17 AM, Sergei Shtylyov wrote:
> 
> >Add the generic PHY support, analogous to the USB PHY support. Intended it 
> >to be
> >used with the PCI EHCI/OHCI drivers and the xHCI platform driver.
> 
> >Signed-off-by: Sergei Shtylyov 
> >Signed-off-by: Yoshihiro Shimoda 
> 
> >---
> >This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
> 
> >The USB PHY driver patch with which this patch is intended to be used, has 
> >been
> >just posted, along with the platform PHY device tree patches; the patches 
> >that
> >link the PCI EHCI/OHCI  devices to the PHY device will follow shortly.
> 
>Greg, may I ask what elase are you waiting for with this patch. I don't
> see it in 3.17-rc1 and nobody has commented on this version. I've posted to
> linux-usb all my patches that need this one, and there are patch series from
> other people now depending on this patch...

I don't even see it in my patch queue anymore, are you sure it's not
already in Linus's tree, or that someone else didn't take it?  If not,
then please resend.

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] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

[gre...@linuxfoundation.org]

On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote:
> Hi Greg,
> 
> Any feedback on this patch ?

The merge window ended 2 days ago, _and_ I'm at the kernel summit this
week, _and_ my queue is currently sitting at:
$ mdfrm -c ~/mail/todo/
1317 messages in /home/gregkh/mail/todo/

So please be patient.  I'll get to it in a few weeks.

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: What is the command line commands to use UAC2 at USB client side?

[Daniel Mack]

On 08/19/2014 11:01 AM, Jassi Brar wrote:
> On Tue, Aug 19, 2014 at 2:15 PM, Daniel Mack  wrote:
>> On 08/19/2014 02:01 AM, Xuebing Wang wrote:
>>
> root@imx6slevk:~#
> root@imx6slevk:~# arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0
> Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, 
> Stereo
> Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
 Such a setup should work, I recently tried it myself.

 The other direction (capturing from host, playback on device), however,
 has a major problem as the device interface has no timing mechanism, and
 hence 'arecord | aplay' on the gadget side fails. I've prepared patches
 and a more comprehensive description for this, but I'm waiting for
 Andrzej's patches to be reviewed, as mine are based upon his.
>>
> Hmm... I tested 48KHz USB-IN without noise, 44.1KHz did show noise
> though ... iirc

With USB-IN, you're referring to arecord on the host side, and aplay on
the gadget? Playing/ recording wave files on both sides worked fine for
me. The only problem here is that once you link one side to a sink or
source that expects audio to be transported at least roughly with the
announces sample rate, things break because there is nothing that
controls the timing. It's easy to fix, and as I said, I have patches for
this that I'll send out shortly.

However, I thought Xuebing's setup is the other way around, right?

>>> Does it work with Windows 7/8 host?
>>
>> I have no idea, and no Windows box to test on.
>>
> IIRC Windows doesn't have native support for UAC2.

That's true, you need a third party driver for that. I was referring to
UAC1, but I didn't test this either.


Daniel

--
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 RESEND v3 07/12] usb: dwc2/gadget: break infinite loop in endpoint disable code

[Robert Baldyga]

From: Marek Szyprowski 

This patch fixes possible freeze caused by infinite loop in interrupt
context.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 3faa4f3..c829c05 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1651,6 +1651,7 @@ static void s3c_hsotg_txfifo_flush(struct s3c_hsotg 
*hsotg, unsigned int idx)
dev_err(hsotg->dev,
"%s: timeout flushing fifo (GRSTCTL=%08x)\n",
__func__, val);
+   break;
}
 
udelay(1);
-- 
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 RESEND v3 11/12] usb: dwc2/gadget: disable clock when it's not needed

[Robert Baldyga]

When device is stopped or suspended clock is not needed so we
can disable it for this time.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index b914365..148ef3c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2893,6 +2893,8 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
hsotg->gadget.dev.of_node = hsotg->dev->of_node;
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
 
+   clk_enable(hsotg->clk);
+
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
hsotg->supplies);
if (ret) {
@@ -2941,6 +2943,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
 
regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
 
+   clk_disable(hsotg->clk);
+
return 0;
 }
 
@@ -2972,8 +2976,10 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
spin_lock_irqsave(&hsotg->lock, flags);
if (is_on) {
s3c_hsotg_phy_enable(hsotg);
+   clk_enable(hsotg->clk);
s3c_hsotg_core_init(hsotg);
} else {
+   clk_disable(hsotg->clk);
s3c_hsotg_phy_disable(hsotg);
}
 
@@ -3636,6 +3642,7 @@ static int s3c_hsotg_suspend(struct platform_device 
*pdev, pm_message_t state)
 
ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies),
 hsotg->supplies);
+   clk_disable(hsotg->clk);
}
 
return ret;
@@ -3650,6 +3657,8 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
if (hsotg->driver) {
dev_info(hsotg->dev, "resuming usb gadget %s\n",
 hsotg->driver->driver.name);
+
+   clk_enable(hsotg->clk);
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
  hsotg->supplies);
}
-- 
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 RESEND v3 12/12] usb: dwc2/gadget: avoid disabling ep0

[Robert Baldyga]

Endpoint 0 should not be disabled, so we start loop counter from number 1.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 148ef3c..3c1dfe1 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2929,7 +2929,7 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
return -ENODEV;
 
/* all endpoints should be shutdown */
-   for (ep = 0; ep < hsotg->num_of_eps; ep++)
+   for (ep = 1; ep < hsotg->num_of_eps; ep++)
s3c_hsotg_ep_disable(&hsotg->eps[ep].ep);
 
spin_lock_irqsave(&hsotg->lock, flags);
-- 
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 RESEND v3 08/12] usb: dwc2/gadget: do not call disconnect method in pullup

[Robert Baldyga]

From: Marek Szyprowski 

This leads to potential spinlock recursion in composite framework, other
udc drivers also don't call it directly from pullup method.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c829c05..1d5e387 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2944,7 +2944,6 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
s3c_hsotg_phy_enable(hsotg);
s3c_hsotg_core_init(hsotg);
} else {
-   s3c_hsotg_disconnect(hsotg);
s3c_hsotg_phy_disable(hsotg);
}
 
-- 
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