Re: [PATCH v4 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

[Baolin Wang]

Hi Felipe,

On 28 November 2016 at 14:43, Baolin Wang  wrote:
> For some mobile devices with strict power management, we also want to suspend
> the host when the slave is detached for power saving. Thus we add the host
> suspend/resume functions to support this requirement.
>
> Signed-off-by: Baolin Wang 
> ---
> Changes since v3:
>  - No updates.
>
> Changes since v2:
>  - Remove pm_children_suspended() and other unused macros.
>
>  Changes since v1:
>- Add pm_runtime.h head file to avoid kbuild error.
> ---
>  drivers/usb/dwc3/Kconfig |7 +++
>  drivers/usb/dwc3/core.c  |   26 +-
>  drivers/usb/dwc3/core.h  |   15 +++
>  drivers/usb/dwc3/host.c  |   37 +
>  4 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index a45b4f1..47bb2f3 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -47,6 +47,13 @@ config USB_DWC3_DUAL_ROLE
>
>  endchoice
>
> +config USB_DWC3_HOST_SUSPEND
> +   bool "Choose if the DWC3 host (xhci) can be suspend/resume"
> +   depends on USB_DWC3_HOST=y || USB_DWC3_DUAL_ROLE=y
> +   help
> + We can suspend the host when the slave is detached for power saving,
> + and resume the host when one slave is attached.
> +
>  comment "Platform Glue Driver Support"
>
>  config USB_DWC3_OMAP
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 9a4a5e4..7ad4bc3 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
> pm_runtime_use_autosuspend(dev);
> pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
> pm_runtime_enable(dev);
> +   pm_suspend_ignore_children(dev, true);
> ret = pm_runtime_get_sync(dev);
> if (ret < 0)
> goto err1;
> @@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
>  static int dwc3_suspend_common(struct dwc3 *dwc)
>  {
> unsigned long   flags;
> +   int ret;
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> +   spin_lock_irqsave(>lock, flags);
> +   dwc3_gadget_suspend(dwc);
> +   spin_unlock_irqrestore(>lock, flags);
> +   break;
> case USB_DR_MODE_OTG:
> +   ret = dwc3_host_suspend(dwc);
> +   if (ret)
> +   return ret;
> +
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_suspend(dwc);
> spin_unlock_irqrestore(>lock, flags);
> break;
> case USB_DR_MODE_HOST:
> +   ret = dwc3_host_suspend(dwc);
> +   if (ret)
> +   return ret;
> default:
> /* do nothing */
> break;
> @@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> +   spin_lock_irqsave(>lock, flags);
> +   dwc3_gadget_resume(dwc);
> +   spin_unlock_irqrestore(>lock, flags);
> +   break;
> case USB_DR_MODE_OTG:
> +   ret = dwc3_host_resume(dwc);
> +   if (ret)
> +   return ret;
> +
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_resume(dwc);
> spin_unlock_irqrestore(>lock, flags);
> -   /* FALLTHROUGH */
> +   break;
> case USB_DR_MODE_HOST:
> +   ret = dwc3_host_resume(dwc);
> +   if (ret)
> +   return ret;
> default:
> /* do nothing */
> break;
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index b585a30..db41908 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -1226,4 +1226,19 @@ static inline void dwc3_ulpi_exit(struct dwc3 *dwc)
>  { }
>  #endif
>
> +#if IS_ENABLED(CONFIG_USB_DWC3_HOST_SUSPEND)
> +int dwc3_host_suspend(struct dwc3 *dwc);
> +int dwc3_host_resume(struct dwc3 *dwc);
> +#else
> +static inline int dwc3_host_suspend(struct dwc3 *dwc)
> +{
> +   return 0;
> +}
> +
> +static inline int dwc3_host_resume(struct dwc3 *dwc)
> +{
> +   return 0;
> +}
> +#endif
> +
>  #endif /* __DRIVERS_USB_DWC3_CORE_H */
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index ed82464..8e5309d6 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -16,6 +16,7 @@
>   */
>
>  #include 
> +#include 
>
>  #include "core.h"
>
> @@ -130,3 +131,39 @@ void dwc3_host_exit(struct dwc3 *dwc)
>   dev_name(>xhci->dev));
> platform_device_unregister(dwc->xhci);
>  }
> +
> +#ifdef 

Re: [PATCHv13,1/3] lib/string: add sysfs_match_string helper

[Heikki Krogerus]

On Wed, Dec 07, 2016 at 03:54:45PM -0800, Guenter Roeck wrote:
> > +int __sysfs_match_string(const char * const *array, size_t n, const char 
> > *str)
> > +{
> > +   const char *item;
> > +   int index;
> > +
> > +   for (index = 0; index < n; index++) {
> > +   item = array[index];
> > +   if (!item)
> > +   break;
> > +   if (!sysfs_streq(item, str))
> 
> No idea how this slipped in: sysfs_streq() returns true on a match,
> meaning the "!" here is wrong.

Good catch. Thanks Guenter.

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

Re: [PATCH v4 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi Mathias and Felipe,

On 28 November 2016 at 14:43, Baolin Wang  wrote:
> Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
> Also call pm_runtime_get_noresume() in probe() function in case the parent
> device doesn't call suspend/resume callback by runtime PM now.
>
> Signed-off-by: Baolin Wang 
> ---
> Changes since v3:
>  - Fix kbuild error.
>
> Changes since v2:
>  - Add pm_runtime_get_noresume() in probe() function.
>  - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() 
> function.
>
> Changes since v1:
>  - No updates.
> ---
>  drivers/usb/host/xhci-plat.c |   41 -
>  1 file changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index ed56bf9..5805c6a 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if (ret)
> goto dealloc_usb2_hcd;
>
> +   pm_runtime_get_noresume(>dev);
> +   pm_runtime_set_active(>dev);
> +   pm_runtime_enable(>dev);
> +
> return 0;
>
>
> @@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> struct clk *clk = xhci->clk;
>
> +   pm_runtime_set_suspended(>dev);
> +   pm_runtime_put_noidle(>dev);
> +   pm_runtime_disable(>dev);
> +
> usb_remove_hcd(xhci->shared_hcd);
> usb_phy_shutdown(hcd->usb_phy);
>
> @@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)
>
> return xhci_resume(xhci, 0);
>  }
> +#endif /* CONFIG_PM_SLEEP */
> +
> +#ifdef CONFIG_PM
> +static int xhci_plat_runtime_suspend(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_suspend(xhci, device_may_wakeup(dev));
> +}
> +
> +static int xhci_plat_runtime_resume(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_resume(xhci, 0);
> +}
> +
> +static int xhci_plat_runtime_idle(struct device *dev)
> +{
> +   return 0;
> +}
> +#endif /* CONFIG_PM */
>
>  static const struct dev_pm_ops xhci_plat_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
> +
> +   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, 
> xhci_plat_runtime_resume,
> +  xhci_plat_runtime_idle)
>  };
> -#define DEV_PM_OPS (_plat_pm_ops)
> -#else
> -#define DEV_PM_OPS NULL
> -#endif /* CONFIG_PM */
>
>  static const struct acpi_device_id usb_xhci_acpi_match[] = {
> /* XHCI-compliant USB Controller */
> @@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
> .remove = xhci_plat_remove,
> .driver = {
> .name = "xhci-hcd",
> -   .pm = DEV_PM_OPS,
> +   .pm = _plat_pm_ops,
> .of_match_table = of_match_ptr(usb_xhci_of_match),
> .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> },
> --
> 1.7.9.5
>

Do you have any comments about this patch? Thanks.

-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe 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 0/4] musb fixes for v4.9-rc cycle

[Tony Lindgren]

* Laurent Pinchart  [161123 08:44]:
> Hello,
> 
> On Wednesday 23 Nov 2016 18:40:09 Tomi Valkeinen wrote:
> > On 23/11/16 18:34, Tony Lindgren wrote:
> > > OK. And what changes to your current .config make the musb_bus_suspend()
> > > issues show up?
> > > 
> > > If it happens with USB-B cable from host to musb with musb set to host
> > > only mode I'm not suprised there are errors :)
> > 
> > I have no USB cables connected. I have attached my config. If
> > CONFIG_USB_MUSB_HDRC is disabled, the musb error goes away.
> 
> For what it's worth, that's exactly the same problem I experienced. See 
> https://www.spinics.net/lists/linux-usb/msg149172.html for an analysis.

The problem is that with the built-in musb configuration we're trying to
set USB-B cable to host mode with ID pin not grounded. That's not going
to work on most hardware unless the PHY can configure the ID pin.

Here's how to fix the .config for built-in musb:

1. Change to have CONFIG_USB_GADGET=y

2. Then change CONFIG_USB_MUSB_DUAL_ROLE=y instead of CONFIG_USB_MUSB_HOST

We should probably get rid of CONFIG_USB_MUSB_HOST to avoid this.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe 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: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Jerry Huang]

Hi, Balbi,
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Wednesday, December 07, 2016 9:39 PM
> To: Jerry Huang ; st...@rowland.harvard.edu;
> linux-usb@vger.kernel.org; Mathias Nyman
> ; Arnd Bergmann 
> Cc: Sriram Dash ; Greg Kroah-Hartman
> 
> Subject: RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
> 
> 
> Hi,
> 
> Jerry Huang  writes:
> >> Jerry Huang  writes:
> >> >> Jerry Huang  writes:
> >> >> > Hi, Balbi,
> >> >> > Sorry for later responding.
> >> >> > I tested Linux 4.8, 4.7, 4.6 and 4.5, has the same issue:
> >> >> > [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
> >> >> >
> >> >> > Then I found one patch (dwc3 initiated xhci probe problem in
> >> >> > arm64
> >> >> > 4.4
> >> >> kernel due to DMA setup) as below link, and I applied this patch
> >> >> to Linux-4.5, the USB3.0 worked well! Therefore I applied this
> >> >> patch to Linux-4.9-rc7, and the USB3.0 works well, too! Which used
> >> >> of_dma_configure(>dev,
> >> >> dwc->dev->of_node) to set dma.
> >> >> > https://patches.linaro.org/patch/65892/
> >> >> >
> >> >> > However, in Linux-4.9-rc8, I found these 6 patches applied:
> >> >> > https://patchwork.kernel.org/patch/9434163/
> >> >> > https://patchwork.kernel.org/patch/9434155/
> >> >> > https://patchwork.kernel.org/patch/9434131/
> >> >> > https://patchwork.kernel.org/patch/9434165/
> >> >> > https://patchwork.kernel.org/patch/9434167/
> >> >> > https://patchwork.kernel.org/patch/9434133/
> >> >> > and the commit ID are:
> >> >> > 9863f279c1d48e366a179e76683247f239b30975
> >> >> > 0abcfafea32452f1d07901320efa8c17470dbeed
> >> >> > ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
> >> >> > e9d10c536b26732d38d59fa3639b85bcd819837e
> >> >> > 60478aead82d761c71a2a402b3fd2817af9e57ac
> >> >> > 21f57eb38129042d2910d1e9b5fd36f3eea93637
> >> >> >
> >> >> > And I got the below error when I attached one  USB3.0 disk (Just
> >> >> > USB2.0
> >> >> disk can work). From above 6 patches, it seems remove
> >> >> dma_set_coherent_mask from file drivers/usb/dwc3/host.c.
> >> >> >
> >> >> > usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
> >> >> > [   16.224264] usb 4-1: device descriptor read/8, error -61
> >> >> > [   16.336179] usb 4-1: new SuperSpeed USB device number 2 using
> xhci-
> >> >> hcd
> >> >> > [   16.360257] usb 4-1: device descriptor read/8, error -61
> >> >> > [   16.652196] usb 4-1: new SuperSpeed USB device number 3 using
> xhci-
> >> >> hcd
> >> >> > [   16.676256] usb 4-1: device descriptor read/8, error -61
> >> >> > [   16.788179] usb 4-1: new SuperSpeed USB device number 3 using
> xhci-
> >> >> hcd
> >> >> > [   16.812255] usb 4-1: device descriptor read/8, error -61
> >> >> >
> >> >> > So, how to handle this issue?
> >> >>
> >> >> oh, it's the DMA thing. We have patches going to next for this.
> >> >> Arnd, do you know if next has all missing pieces? There was
> >> >> something pending on XHCI IIRC, right?
> >> > So, there are some patches for this issue? Where can I find it? I
> >> > need these
> >> patches for my work.
> >>
> >> https://lkml.org/lkml/2016/11/17/339
> > You means these below 6 patches?  They have been applied to Linux-4.9-
> rc8.
> > Based on Linux-4.9-rc8, I got the error when I connect USB3.0 disk to board
> (USB2.0 disk works well):
> > [   16.360257] usb 4-1: device descriptor read/8, error -61
> > So, I think all these 6 patches did not set the USB3.0 DMA coherent
> > correctly, and we need another patch to handle it.
> 
> okay, please prepare one such patch :-)
We still need this patch, after applying it to Linux-4.9-rc8, the USB3.0 can 
work well.
https://patches.linaro.org/patch/65892/
dwc3 initiated xhci probe problem in arm64 4.4 kernel due to DMA setup

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

RE: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[fx IWATA NOBUO]

Dear Shuah,

> I noticed that in many places sysfs_attr_init() is called before populating
> the fields such as name etc. However, I don't think the order matters.
> 
> sysfs_attr_init() doesn't depend on name or any other fields being set:
> 
> #define sysfs_attr_init(attr)   \
> do {\
> static struct lock_class_key __key; \
> \
> (attr)->key = &__key;   \
> } while (0)
> 
> Are you concerned about something else?

Yes.

If the macro name is 'attr_set_key', I don't have any concern.

The name is 'attr_init' so I think there's possibility that some other
items in attr may initialized in future.

Also I think 'initialize struct first, then set items' is idiomatic order.

Best Regards,

nobuo.iwata
//
> -Original Message-
> From: Shuah Khan [mailto:shua...@osg.samsung.com]
> Sent: Thursday, December 08, 2016 11:51 AM
> To: fx IWATA NOBUO; Andrey Konovalov
> Cc: Greg Kroah-Hartman; Valentina Manea; Shuah Khan;
> linux-usb@vger.kernel.org; LKML; Shuah Khan; Shuah Khan
> Subject: Re: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map
> 
> Hi Nobuo.iwata,
> 
> I noticed that in many places sysfs_attr_init() is called before populating
> the fields such as name etc. However, I don't think the order matters.
> 
> sysfs_attr_init() doesn't depend on name or any other fields being set:
> 
> #define sysfs_attr_init(attr)   \
> do {\
> static struct lock_class_key __key; \
> \
> (attr)->key = &__key;   \
> } while (0)
> 
> Are you concerned about something else?
> 
> thanks,
> -- Shuah
> 
> 
> On 12/07/2016 07:15 PM, fx IWATA NOBUO wrote:
> > Dear Shuah,
> >
> > I'm afraid there's one thing I have concerned.
> >
> > I think it's better to move sysfs_attr_init() before
> > status->attr.attr.name = status->name;
> >
> > Best Regards,
> >
> > nobuo.iwata
> > //
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org
> >> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Andrey
> >> Konovalov
> >> Sent: Tuesday, December 06, 2016 9:07 PM
> >> To: Shuah Khan
> >> Cc: Greg Kroah-Hartman; Valentina Manea; Shuah Khan;
> >> linux-usb@vger.kernel.org; LKML
> >> Subject: Re: [PATCH] usbip: fix warning in
> >> vhci_hcd_probe/lockdep_init_map
> >>
> >> On Mon, Dec 5, 2016 at 9:00 PM, Shuah Khan 
> wrote:
> >>> Hi Andrey,
> >>>
> >>> On 12/05/2016 12:56 PM, Shuah Khan wrote:
>  vhci_hcd calls sysfs_create_group() with dynamically allocated
>  sysfs attributes triggering the lock-class key not persistent
>  warning. Call
>  sysfs_attr_init() for dynamically allocated sysfs attributes to fix
> it.
> 
>  vhci_hcd vhci_hcd: USB/IP Virtual Host Controller vhci_hcd vhci_hcd:
>  new USB bus registered, assigned bus number 2
>  BUG: key 88006a7e8d18 not in .data!
>  [ cut here ]
>  WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
>  lockdep_init_map+0x60c/0x770
>  DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
>  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58 Hardware
>  name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>   88006bce6eb8 81f96c8a 0a02
>  11000d79cd6a
>   ed000d79cd62 00046bce6ed8 41b58ab3
>  8598af40
>   81f969f8  41b58ab3
>  0200 Call Trace:
>   [< inline >] __dump_stack lib/dump_stack.c:15
>   [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>  [] __warn+0x19f/0x1e0 kernel/panic.c:550
>  [] warn_slowpath_fmt+0xc5/0x110
>  kernel/panic.c:565 []
>  lockdep_init_map+0x60c/0x770
>  kernel/locking/lockdep.c:3131  []
>  __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
> >> [] sysfs_add_file_mode_ns+0x225/0x520
> >> fs/sysfs/file.c:305
>   [< inline >] create_files fs/sysfs/group.c:64
>   [] internal_create_group+0x239/0x8f0
>  fs/sysfs/group.c:134  []
>  sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>  [] vhci_start+0x5b4/0x7a0
>  drivers/usb/usbip/vhci_hcd.c:978  []
>  usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
>  [] vhci_hcd_probe+0x97/0x130
>  drivers/usb/usbip/vhci_hcd.c:1103
>   ---
>   ---
>  ---[ end trace c33c7b202cf3aac8 ]---
> 
>  Signed-off-by: Shuah Khan 
>  Reported-by: Andrey Konovalov 
> >>>
> >>> Here is the fix. Fixed the warning I reproduced on my system.
> >>> Let me know if it works for you.
> >>
> >> Hi Shuah,
> >>
> >> This fixes the warning I've been seeing.
> >>
> 

[PATCH] usb: musb: fix compilation warning on unused function

[Jérémy Lefaure]

The function musb_run_resume_work is called only when CONFIG_PM is
enabled. So this function should not be defined when CONFIG_PM is
disabled. Otherwise the compiler issues a warning:

drivers/usb/musb/musb_core.c:2057:12: error: ‘musb_run_resume_work’ defined but
not used [-Werror=unused-function]
 static int musb_run_resume_work(struct musb *musb)
^~~~

Signed-off-by: Jérémy Lefaure 
---

I think that adding a preprocessor condition is a better way to fix this than
moving the function into the scope of the existing condition to preserve the
git history.

 drivers/usb/musb/musb_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 9e22646..fca288bb 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2050,6 +2050,7 @@ struct musb_pending_work {
struct list_head node;
 };
 
+#ifdef CONFIG_PM
 /*
  * Called from musb_runtime_resume(), musb_resume(), and
  * musb_queue_resume_work(). Callers must take musb->lock.
@@ -2077,6 +2078,7 @@ static int musb_run_resume_work(struct musb *musb)
 
return error;
 }
+#endif
 
 /*
  * Called to run work if device is active or else queue the work to happen
-- 
2.10.2

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

[PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

Somehow starting with v4.9-rc7 there have been imprecise
external aborts on omap5-uevm dwc3 controller. I have not been
able to bisect what exactly triggered this as it does not always
happen. It seems that something changed with probing that
now exposes the issue:

Unhandled fault: imprecise external abort (0x1406) at 0x
...
PC is at dwc3_omap_interrupt_thread+0x20/0x80
LR is at irq_thread_fn+0x1c/0x54
...
[] (dwc3_omap_interrupt_thread) from []
(irq_thread_fn+0x1c/0x54)
[] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0)
[] (irq_thread) from [] (kthread+0xdc/0xf4)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)
...

Unable to handle kernel paging request at virtual address ffec
...
Internal error: Oops: 37 [#2] SMP ARM
PC is at kthread_data+0x4/0xc
LR is at irq_thread_dtor+0x28/0xd0
...
[] (kthread_data) from [] (irq_thread_dtor+0x28/0xd0)
[] (irq_thread_dtor) from [] (task_work_run+0xb8/0xdc)
[] (task_work_run) from [] (do_exit+0x314/0xa20)
[] (do_exit) from [] (die+0x410/0x474)
[] (die) from [] (do_DataAbort+0xb4/0xb8)
[] (do_DataAbort) from [] (__dabt_svc+0x58/0x80)
Exception stack(0xee777ec8 to 0xee777f10)
7ec0:   014d ee6e6f10 0034 fc020034 ee6e6f10 ee1eec00
7ee0:   ee6ec640 c038a4bc    ee777f18
7f00: c038a4d8 c0989fa8 6013 
[] (__dabt_svc) from [] 
(dwc3_omap_interrupt_thread+0x20/0x80)
[] (dwc3_omap_interrupt_thread) from [] 
(irq_thread_fn+0x1c/0x54)
[] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0)
[] (irq_thread) from [] (kthread+0xdc/0xf4)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)

Fix the issue by making sure the dwc3 interrupts are disabled
before we call devm_request_threaded_irq().

Note that there does not seem to be issues with the dwc3 wrapper
accessing these registers even before the dwc3 core is probed.
If some of these registers are specific to the dwc3 core, we can
have IRQ disabled with irq_set_status_flags(omap->irq, IRQ_NOAUTOEN)
on start-up instead of accessing the dwc3 registers.

Reported-by: Kevin Hilman 
Cc: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
 drivers/usb/dwc3/dwc3-omap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -511,6 +511,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
 
+   dwc3_omap_disable_irqs(omap);
+
ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
dwc3_omap_interrupt_thread, IRQF_SHARED,
"dwc3-omap", omap);
-- 
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: dwc3: gadget: Fix full speed mode

[John Youn]

On 12/7/2016 4:44 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
 Roger Quadros  writes:
> DCFG.DEVSPD == 0x3 is not valid and we need to set
> DCFG.DEVSPD to 0x1 for full speed mode.

 seems like it has been made invalid somewhere between 1.73a and
 2.60a. Can you figure it out from Documentation why and when it was made
 invalid? We might need revision checks here.

>>>
>>> I'll try to dig out more.
>>
>> I couldn't figure out more information on this. The changelogs in the TRMs
>> don't capture this change and I don't have access to all TRM versions
>> so I can't say which version it got changed and why.
>>
>> Can we please involve someone from Synopsis to provide this information?
>> Thanks.
> 
> John, could you help us with this query? We'd like to understand why one
> of the FULLSPEED modes got removed. Do we need a revision check or can
> we assume that the other mode was never supposed to be used?
> 

Full speed is 0x1. 0x3 may still work due to how the bits are
checked. But it definitely should be 0x1.

I'm not sure if it was 0x3 before. I still need to confirm whether
that was the case or not and if so why.

Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe 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] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

Hi Nobuo.iwata,

I noticed that in many places sysfs_attr_init() is called
before populating the fields such as name etc. However, I
don't think the order matters.

sysfs_attr_init() doesn't depend on name or any other fields
being set:

#define sysfs_attr_init(attr)   \
do {\
static struct lock_class_key __key; \
\
(attr)->key = &__key;   \
} while (0)

Are you concerned about something else?

thanks,
-- Shuah


On 12/07/2016 07:15 PM, fx IWATA NOBUO wrote:
> Dear Shuah,
> 
> I'm afraid there's one thing I have concerned.
> 
> I think it's better to move sysfs_attr_init() before
> status->attr.attr.name = status->name;
> 
> Best Regards,
> 
> nobuo.iwata
> //
>> -Original Message-
>> From: linux-usb-ow...@vger.kernel.org
>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Andrey Konovalov
>> Sent: Tuesday, December 06, 2016 9:07 PM
>> To: Shuah Khan
>> Cc: Greg Kroah-Hartman; Valentina Manea; Shuah Khan;
>> linux-usb@vger.kernel.org; LKML
>> Subject: Re: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map
>>
>> On Mon, Dec 5, 2016 at 9:00 PM, Shuah Khan  wrote:
>>> Hi Andrey,
>>>
>>> On 12/05/2016 12:56 PM, Shuah Khan wrote:
 vhci_hcd calls sysfs_create_group() with dynamically allocated sysfs
 attributes triggering the lock-class key not persistent warning. Call
 sysfs_attr_init() for dynamically allocated sysfs attributes to fix it.

 vhci_hcd vhci_hcd: USB/IP Virtual Host Controller vhci_hcd vhci_hcd:
 new USB bus registered, assigned bus number 2
 BUG: key 88006a7e8d18 not in .data!
 [ cut here ]
 WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
 lockdep_init_map+0x60c/0x770
 DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58 Hardware
 name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  88006bce6eb8 81f96c8a 0a02 11000d79cd6a
  ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
  81f969f8  41b58ab3 0200
 Call Trace:
  [< inline >] __dump_stack lib/dump_stack.c:15
  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] __warn+0x19f/0x1e0 kernel/panic.c:550
 [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
 [] lockdep_init_map+0x60c/0x770
 kernel/locking/lockdep.c:3131  []
 __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
>> [] sysfs_add_file_mode_ns+0x225/0x520
>> fs/sysfs/file.c:305
  [< inline >] create_files fs/sysfs/group.c:64
  [] internal_create_group+0x239/0x8f0
 fs/sysfs/group.c:134  []
 sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
 [] vhci_start+0x5b4/0x7a0
 drivers/usb/usbip/vhci_hcd.c:978  []
 usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
 [] vhci_hcd_probe+0x97/0x130
 drivers/usb/usbip/vhci_hcd.c:1103
  ---
  ---
 ---[ end trace c33c7b202cf3aac8 ]---

 Signed-off-by: Shuah Khan 
 Reported-by: Andrey Konovalov 
>>>
>>> Here is the fix. Fixed the warning I reproduced on my system.
>>> Let me know if it works for you.
>>
>> Hi Shuah,
>>
>> This fixes the warning I've been seeing.
>>
>> Thanks!
>>
>>>
>>> thanks,
>>> -- Shuah
>>>
 ---
  drivers/usb/usbip/vhci_sysfs.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/usb/usbip/vhci_sysfs.c
 b/drivers/usb/usbip/vhci_sysfs.c index c404017..b96e5b1 100644
 --- a/drivers/usb/usbip/vhci_sysfs.c
 +++ b/drivers/usb/usbip/vhci_sysfs.c
 @@ -361,6 +361,7 @@ static void set_status_attr(int id)
   status->attr.attr.name = status->name;
   status->attr.attr.mode = S_IRUGO;
   status->attr.show = status_show;
 + sysfs_attr_init(>attr.attr);
  }

  static int init_status_attrs(void)

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

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

RE: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[fx IWATA NOBUO]

Dear Shuah,

I'm afraid there's one thing I have concerned.

I think it's better to move sysfs_attr_init() before
status->attr.attr.name = status->name;

Best Regards,

nobuo.iwata
//
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Andrey Konovalov
> Sent: Tuesday, December 06, 2016 9:07 PM
> To: Shuah Khan
> Cc: Greg Kroah-Hartman; Valentina Manea; Shuah Khan;
> linux-usb@vger.kernel.org; LKML
> Subject: Re: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map
> 
> On Mon, Dec 5, 2016 at 9:00 PM, Shuah Khan  wrote:
> > Hi Andrey,
> >
> > On 12/05/2016 12:56 PM, Shuah Khan wrote:
> >> vhci_hcd calls sysfs_create_group() with dynamically allocated sysfs
> >> attributes triggering the lock-class key not persistent warning. Call
> >> sysfs_attr_init() for dynamically allocated sysfs attributes to fix it.
> >>
> >> vhci_hcd vhci_hcd: USB/IP Virtual Host Controller vhci_hcd vhci_hcd:
> >> new USB bus registered, assigned bus number 2
> >> BUG: key 88006a7e8d18 not in .data!
> >> [ cut here ]
> >> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
> >> lockdep_init_map+0x60c/0x770
> >> DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
> >> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58 Hardware
> >> name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >>  88006bce6eb8 81f96c8a 0a02 11000d79cd6a
> >>  ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
> >>  81f969f8  41b58ab3 0200
> >> Call Trace:
> >>  [< inline >] __dump_stack lib/dump_stack.c:15
> >>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
> >> [] __warn+0x19f/0x1e0 kernel/panic.c:550
> >> [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
> >> [] lockdep_init_map+0x60c/0x770
> >> kernel/locking/lockdep.c:3131  []
> >> __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
> [] sysfs_add_file_mode_ns+0x225/0x520
> fs/sysfs/file.c:305
> >>  [< inline >] create_files fs/sysfs/group.c:64
> >>  [] internal_create_group+0x239/0x8f0
> >> fs/sysfs/group.c:134  []
> >> sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
> >> [] vhci_start+0x5b4/0x7a0
> >> drivers/usb/usbip/vhci_hcd.c:978  []
> >> usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
> >> [] vhci_hcd_probe+0x97/0x130
> >> drivers/usb/usbip/vhci_hcd.c:1103
> >>  ---
> >>  ---
> >> ---[ end trace c33c7b202cf3aac8 ]---
> >>
> >> Signed-off-by: Shuah Khan 
> >> Reported-by: Andrey Konovalov 
> >
> > Here is the fix. Fixed the warning I reproduced on my system.
> > Let me know if it works for you.
> 
> Hi Shuah,
> 
> This fixes the warning I've been seeing.
> 
> Thanks!
> 
> >
> > thanks,
> > -- Shuah
> >
> >> ---
> >>  drivers/usb/usbip/vhci_sysfs.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/usb/usbip/vhci_sysfs.c
> >> b/drivers/usb/usbip/vhci_sysfs.c index c404017..b96e5b1 100644
> >> --- a/drivers/usb/usbip/vhci_sysfs.c
> >> +++ b/drivers/usb/usbip/vhci_sysfs.c
> >> @@ -361,6 +361,7 @@ static void set_status_attr(int id)
> >>   status->attr.attr.name = status->name;
> >>   status->attr.attr.mode = S_IRUGO;
> >>   status->attr.show = status_show;
> >> + sysfs_attr_init(>attr.attr);
> >>  }
> >>
> >>  static int init_status_attrs(void)
> >>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe 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: ch341

[Russell Senior]

> "Johan" == Johan Hovold  writes:

>> I attach the tty's with GNU screen (but I have also tried microcom
>> and minicom with the same results).  This was my first experience
>> with or even awareness of ch341. I have much more experience with
>> pl2303 and somewhat less with ftdi.  With these ch341, when I type in
>> an 'a' on one terminal, I get 0x01 out the other terminal.  If I type
>> in a 'b', I get an 0x02, etc, on up to 'z' yielding 0x1a.
>> 
>> I found your name/contact in the git commits.
>> 
>> Any idea what is going on?

Johan> Sounds like it could be related to an incorrect line setting
Johan> (e.g. the devices are using 5-bit words). Some changes just went
Johan> in that add support for changing this. Could you try building a
Johan> kernel based on the usb-next branch of:

Johan>  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git

Johan> and see if that works better?

I built usb-next (3c3dd1e) and saw the same behavior.  Loopback
(connecting RX and TX) worked on pl2303-based usb-serial adapter (with
PC levels, not TTL), and did not ('a' -> 0x01, 'b' -> 0x02, etc) with
ch341-based usb-serial adapter (again with PC levels, measured MIN/MAX
voltages with a DVM and saw, about -7V/+7V).

I still suspect shoddy hardware.  It would be nice to hear someone else
with the ch341-based hardware to say it works for them.


-- 
Russell Senior, President
russ...@personaltelco.net
--
To unsubscribe from this list: send the line "unsubscribe 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 3/3] USB: OHCI: nxp: remove useless extern declaration

[Vladimir Zapolskiy]

On 12/08/2016 12:34 AM, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> Remove usb_disabled() extern declaration as it is already declared
> as extern in include/linux/usb.h.
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Vladimir Zapolskiy 
> Cc: Sylvain Lemieux 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-usb@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> changelog V1->V2:
> patch discrition is update with proper message.
> 

I'm fine with the change, thank you for the clean-up.

Acked-by: Vladimir Zapolskiy 

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe 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: OHCI: nxp: fix code warnings

[Vladimir Zapolskiy]

On 12/08/2016 01:54 AM, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> This patch will fix the checkpatch.pl following warnings:
> WARNING: Missing a blank line after declarations
> WARNING: braces {} are not necessary for single statement blocks
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Vladimir Zapolskiy 
> Cc: Sylvain Lemieux 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-usb@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---

Looks good, thank you for the change.

Acked-by: Vladimir Zapolskiy 

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv13,1/3] lib/string: add sysfs_match_string helper

[Guenter Roeck]

On Thu, Nov 24, 2016 at 02:21:42PM +0200, Heikki Krogerus wrote:
> Make a simple helper for matching strings with sysfs
> attribute files. In most parts the same as match_string(),
> except sysfs_match_string() uses sysfs_streq() instead of
> strcmp() for matching. This is more convenient when used
> with sysfs attributes.
> 
> Signed-off-by: Heikki Krogerus 
> Reviewed-by: Guenter Roeck 
> Tested-by: Guenter Roeck 
> ---
>  include/linux/string.h | 10 ++
>  lib/string.c   | 26 ++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 26b6f6a..c4011b2 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -135,6 +135,16 @@ static inline int strtobool(const char *s, bool *res)
>  }
>  
>  int match_string(const char * const *array, size_t n, const char *string);
> +int __sysfs_match_string(const char * const *array, size_t n, const char *s);
> +
> +/**
> + * sysfs_match_string - matches given string in an array
> + * @_a: array of strings
> + * @_s: string to match with
> + *
> + * Helper for __sysfs_match_string(). Calculates the size of @a 
> automatically.
> + */
> +#define sysfs_match_string(_a, _s) __sysfs_match_string(_a, ARRAY_SIZE(_a), 
> _s)
>  
>  #ifdef CONFIG_BINARY_PRINTF
>  int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
> diff --git a/lib/string.c b/lib/string.c
> index ed83562..c7a20cb 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -656,6 +656,32 @@ int match_string(const char * const *array, size_t n, 
> const char *string)
>  }
>  EXPORT_SYMBOL(match_string);
>  
> +/**
> + * __sysfs_match_string - matches given string in an array
> + * @array: array of strings
> + * @n: number of strings in the array or -1 for NULL terminated arrays
> + * @str: string to match with
> + *
> + * Returns index of @str in the @array or -EINVAL, just like match_string().
> + * Uses sysfs_streq instead of strcmp for matching.
> + */
> +int __sysfs_match_string(const char * const *array, size_t n, const char 
> *str)
> +{
> + const char *item;
> + int index;
> +
> + for (index = 0; index < n; index++) {
> + item = array[index];
> + if (!item)
> + break;
> + if (!sysfs_streq(item, str))

No idea how this slipped in: sysfs_streq() returns true on a match,
meaning the "!" here is wrong.

Guenter

> + return index;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(__sysfs_match_string);
> +
>  #ifndef __HAVE_ARCH_MEMSET
>  /**
>   * memset - Fill a region of memory with the given value
--
To unsubscribe from this list: send the line "unsubscribe 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: serial: option: add dlink dwm-158

[Giuseppe Lippolis]

Dear Johan,
Thanks for the tips.

Here is the patch.
Bye.

---
 drivers/usb/serial/option.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 9894e34..386b687 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1989,6 +1989,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d02, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x02, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
+   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
/* D-Link DWM-158 */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
/* D-Link DWM-221 B1 */
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-152/C1 */
-- 
2.7.4

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

Re: usb/gadget: use-after-free in gadgetfs_setup

[Alan Stern]

On Wed, 7 Dec 2016, Andrey Konovalov wrote:

> > And in any case, is there any way you can post the series of system
> > calls that syzkaller makes so we can tell what went wrong?
> 
> I've attached a reproducer for a use-after-free in gadgetfs_setup().
> You need to enable KASAN to see the reports.

Okay, that helps.  I see the problem: dev->hs_config ends up containing
a stale pointer in dev_config().  The patch below ought to fix that;  
please verify that it really does.

The syzkaller test also shows that there should be a few more checks 
for valid values in dev->config->wTotalLength and 
dev->hs_config->wTotalLength.  I'll do those in a separate patch.

Alan Stern



Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
===
--- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
+++ usb-4.x/drivers/usb/gadget/legacy/inode.c
@@ -1799,6 +1799,8 @@ dev_config (struct file *fd, const char
goto fail;
kbuf += total;
length -= total;
+   } else {
+   dev->hs_config = NULL;
}
 
/* could support multiple configs, using another encoding! */

--
To unsubscribe from this list: send the line "unsubscribe 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: misc: rio500: fix result type for error message

[Oliver Neukum]

On Wed, 2016-12-07 at 15:50 +0100, Greg KH wrote:
> On Wed, Dec 07, 2016 at 08:12:10PM +0900, Kim Jae Joong wrote:
> > Fix variable type for dev_err about usb_bulk_msg()
> 
> What was wrong with it before this change?  What warning are you
> "changing"?

It was subtle. The error message printed a status with
error codes. Those are nagative. The format string gave "unsigned"
I had to stare at this for minutes to see it.

Regards
Oliver


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

Re: [PATCH 3/3] usb: gadget: udc: core: Continue driver search if bind failed

[Krzysztof Opasiak]

On 12/07/2016 04:31 PM, Alan Stern wrote:
> On Wed, 7 Dec 2016, Krzysztof Opasiak wrote:
> 
>> If we found a matching driver but its bind() function failed for some
>> reason, let's continue our search as there may be some other gadget
>> pending on a list which bind() will succeed for this udc.
>>
>> Reported-by: Alan Stern 
>> Signed-off-by: Krzysztof Opasiak 
>> ---
>>  drivers/usb/gadget/udc/core.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
>> index a83e6017a8b0..b02a166ba380 100644
>> --- a/drivers/usb/gadget/udc/core.c
>> +++ b/drivers/usb/gadget/udc/core.c
>> @@ -1083,16 +1083,22 @@ static void usb_udc_nop_release(struct device *dev)
>>  /* should be called with udc_lock held */
>>  static int check_pending_gadget_drivers(struct usb_udc *udc)
>>  {
>> -struct usb_gadget_driver *driver;
>> +struct usb_gadget_driver *driver, *tmp;
>>  int ret = 0;
>>  
>> -list_for_each_entry(driver, _driver_pending_list, pending)
>> +list_for_each_entry_safe(driver, tmp, _driver_pending_list,
>> + pending)
>>  if (!driver->udc_name || strcmp(driver->udc_name,
>>  dev_name(>dev)) == 0) {
>>  ret = udc_bind_to_driver(udc, driver);
>> +if (ret == 0)
>> +break;
>>  if (ret != -EPROBE_DEFER)
>>  list_del_init(>pending);
> 
> These two tests are in the wrong order.  You should call 
> list_del_init() even when ret == 0.

Good catch. I fixed this in v2.

Thank you,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] usb: gadget: udc: core: Reinit pending list node

[Krzysztof Opasiak]

Use list_del_init() instead of list_del() in case
if gadget driver bind() fails to avaid troubles
during usb_gadget_unregister_driver().

Reported-by: Alan Stern 
Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/udc/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 73292459acd6..a83e6017a8b0 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1091,7 +1091,7 @@ static int check_pending_gadget_drivers(struct usb_udc 
*udc)
dev_name(>dev)) == 0) {
ret = udc_bind_to_driver(udc, driver);
if (ret != -EPROBE_DEFER)
-   list_del(>pending);
+   list_del_init(>pending);
break;
}
 
-- 
2.9.3

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

[PATCH v2 1/3] usb: gadget: udc-core: Rescan pending list on driver unbind

[Krzysztof Opasiak]

Since:

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

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

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

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

Thanks to this, when we unload first gadget:

$ rmmod g_zero.ko

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

Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/udc/core.c | 45 +--
 1 file changed, 31 insertions(+), 14 deletions(-)

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

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

[PATCH v2 3/3] usb: gadget: udc: core: Continue driver search if bind failed

[Krzysztof Opasiak]

If we found a matching driver but its bind() function failed for some
reason, let's continue our search as there may be some other gadget
pending on a list which bind() will succeed for this udc.

Reported-by: Alan Stern 
Signed-off-by: Krzysztof Opasiak 
---
Changes since v1:
- break from the loop after removing driver from list not before
---
 drivers/usb/gadget/udc/core.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index a83e6017a8b0..431472d31def 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1083,16 +1083,22 @@ static void usb_udc_nop_release(struct device *dev)
 /* should be called with udc_lock held */
 static int check_pending_gadget_drivers(struct usb_udc *udc)
 {
-   struct usb_gadget_driver *driver;
+   struct usb_gadget_driver *driver, *tmp;
int ret = 0;
 
-   list_for_each_entry(driver, _driver_pending_list, pending)
+   list_for_each_entry_safe(driver, tmp, _driver_pending_list,
+pending)
if (!driver->udc_name || strcmp(driver->udc_name,
dev_name(>dev)) == 0) {
ret = udc_bind_to_driver(udc, driver);
if (ret != -EPROBE_DEFER)
list_del_init(>pending);
-   break;
+   if (ret == 0)
+   break;
+   /*
+* We failed to bind this driver, so let's try
+* next one.
+*/
}
 
return ret;
-- 
2.9.3

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

Re: [PATCH 3/3] usb: gadget: udc: core: Continue driver search if bind failed

[Alan Stern]

On Wed, 7 Dec 2016, Krzysztof Opasiak wrote:

> If we found a matching driver but its bind() function failed for some
> reason, let's continue our search as there may be some other gadget
> pending on a list which bind() will succeed for this udc.
> 
> Reported-by: Alan Stern 
> Signed-off-by: Krzysztof Opasiak 
> ---
>  drivers/usb/gadget/udc/core.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> index a83e6017a8b0..b02a166ba380 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -1083,16 +1083,22 @@ static void usb_udc_nop_release(struct device *dev)
>  /* should be called with udc_lock held */
>  static int check_pending_gadget_drivers(struct usb_udc *udc)
>  {
> - struct usb_gadget_driver *driver;
> + struct usb_gadget_driver *driver, *tmp;
>   int ret = 0;
>  
> - list_for_each_entry(driver, _driver_pending_list, pending)
> + list_for_each_entry_safe(driver, tmp, _driver_pending_list,
> +  pending)
>   if (!driver->udc_name || strcmp(driver->udc_name,
>   dev_name(>dev)) == 0) {
>   ret = udc_bind_to_driver(udc, driver);
> + if (ret == 0)
> + break;
>   if (ret != -EPROBE_DEFER)
>   list_del_init(>pending);

These two tests are in the wrong order.  You should call 
list_del_init() even when ret == 0.

> - break;
> + /*
> +  * We failed to bind this driver, so let's try
> +  * next one.
> +  */
>   }
>  
>   return ret;

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: Re: [PATCH] usb: chipidea: use better pattern with WARN_ON()

[Greg KH]

On Wed, Dec 07, 2016 at 03:00:29PM +, Atul Raj wrote:
> On 7 Dec 2016 18:56, "Greg KH"  wrote:
>  >
>  > On Wed, Dec 07, 2016 at 05:46:09PM +0530, Atul Raj wrote:
>  > > Instead of using:
>  > > if (cond) {
>  > >WARN_ON(1);
>  > >do_stuff();
>  > > }
>  > >
>  > > Use a better pattern with WARN_ON() placed in if condition:
>  > >
>  > > if (WARN_ON(cond))
>  > >do_stuff();
>  >
>  > Why?  What does this help with?
>  >
> 
>  This removed a extra line from code so I suggested the patch.
>  I tried to submit the basic patch taking inspiration from below commit
>  Please check commit 2bdf6ea5
>  Please let me know how does this helped with?
> 
>  > And why are you sending patches that are different, yet have identical
>  > subject lines?
> 
>  I made two different patched but did not notice the subject is same.
>  Sorry for that. If you think the patches are worth I will send you the
>  patches again.
> 
>  >
>  > thanks,
>  >
>  > greg k-h
> 
>  I am in learning phase and I will persistently try until I succeed. :)

I suggest you learn on the drivers/staging/ portion of the kernel, which
is where that work is welcomed, before trying to touch other areas of
the kernel that are not as easy to contribute to unless you know what
you are doing.

thanks,

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

Re: [PATCH] usb: misc: rio500: fix result type for error message

[Greg KH]

On Wed, Dec 07, 2016 at 08:12:10PM +0900, Kim Jae Joong wrote:
> Fix variable type for dev_err about usb_bulk_msg()

What was wrong with it before this change?  What warning are you
"changing"?

thanks,

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

Re: [PATCH 00/25] usb: host: xhci: cleanup series

[Mathias Nyman]

On 07.12.2016 14:41, Felipe Balbi wrote:


Hi,

Felipe Balbi  writes:

hi Mathias,

here's a much longer series of cleanups which I have been working on for
the past few days. Let me know what you think about it.

I did some light tests SKL and everything still works as before. I know
you have some reservations about my changes to trb_in_td() but IMHO, if
we can assume this function to be always correct, there's no need to add
debugging messages to it and as for the trb_in_td() call which existed
only for debugging purposes, I guess we need to find a better way of
adding debug statements for that part of the code.

Let me know what you think.


I have patches updated in xhci-cleanup on my k.org branch. Just making
sure these are all the comments I'll get. Mathias, are you done
reviewing?



Not yet, there are other things pending that took priority over this series

-Mathias
 


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

RE: Re: [PATCH] usb: chipidea: use better pattern with WARN_ON()

[Atul Raj]

On 7 Dec 2016 18:56, "Greg KH"  wrote:
 >
 > On Wed, Dec 07, 2016 at 05:46:09PM +0530, Atul Raj wrote:
 > > Instead of using:
 > > if (cond) {
 > >WARN_ON(1);
 > >do_stuff();
 > > }
 > >
 > > Use a better pattern with WARN_ON() placed in if condition:
 > >
 > > if (WARN_ON(cond))
 > >do_stuff();
 >
 > Why?  What does this help with?
 >

 This removed a extra line from code so I suggested the patch.
 I tried to submit the basic patch taking inspiration from below commit
 Please check commit 2bdf6ea5
 Please let me know how does this helped with?

 > And why are you sending patches that are different, yet have identical
 > subject lines?

 I made two different patched but did not notice the subject is same.
 Sorry for that. If you think the patches are worth I will send you the
 patches again.

 >
 > thanks,
 >
 > greg k-h

 I am in learning phase and I will persistently try until I succeed. :)

 Thanks

Re: [PATCH 1/1] NET: usb: cdc_mbim: add quirk for supporting Telit LE922A

[Bjørn Mork]

Daniele Palmas  writes:

> Telit LE922A MBIM based composition does not work properly
> with altsetting toggle done in cdc_ncm_bind_common.
>
> This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk
> to avoid this procedure that, instead, is mandatory for
> other modems.
>
> Signed-off-by: Daniele Palmas 

Thanks.  This looks as nice as we can possibly do for now.  I am happy
to add

Reviewed-by: Bjørn Mork 


This patch also helped me understanding the problem you face even
better: It's not the "set_altsetting 0" that's causing problems, but the
"set_altsetting X" prior to that.  And that is certainly not something
that a firmware should expect. I will look at the Huawei modem again
when I get some time and see if there is any way we can possibly avoid
it.




Bjørn
--
To unsubscribe from this list: send the line "unsubscribe 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: gadget: udc: core: Reinit pending list node

[Krzysztof Opasiak]

Use list_del_init() instead of list_del() in case
if gadget driver bind() fails to avaid troubles
during usb_gadget_unregister_driver().

Reported-by: Alan Stern 
Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/udc/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 73292459acd6..a83e6017a8b0 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1091,7 +1091,7 @@ static int check_pending_gadget_drivers(struct usb_udc 
*udc)
dev_name(>dev)) == 0) {
ret = udc_bind_to_driver(udc, driver);
if (ret != -EPROBE_DEFER)
-   list_del(>pending);
+   list_del_init(>pending);
break;
}
 
-- 
2.9.3

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

[PATCH 1/3] usb: gadget: udc-core: Rescan pending list on driver unbind

[Krzysztof Opasiak]

Since:

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

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

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

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

Thanks to this, when we unload first gadget:

$ rmmod g_zero.ko

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

Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/udc/core.c | 45 +--
 1 file changed, 31 insertions(+), 14 deletions(-)

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

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

[PATCH 3/3] usb: gadget: udc: core: Continue driver search if bind failed

[Krzysztof Opasiak]

If we found a matching driver but its bind() function failed for some
reason, let's continue our search as there may be some other gadget
pending on a list which bind() will succeed for this udc.

Reported-by: Alan Stern 
Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/udc/core.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index a83e6017a8b0..b02a166ba380 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1083,16 +1083,22 @@ static void usb_udc_nop_release(struct device *dev)
 /* should be called with udc_lock held */
 static int check_pending_gadget_drivers(struct usb_udc *udc)
 {
-   struct usb_gadget_driver *driver;
+   struct usb_gadget_driver *driver, *tmp;
int ret = 0;
 
-   list_for_each_entry(driver, _driver_pending_list, pending)
+   list_for_each_entry_safe(driver, tmp, _driver_pending_list,
+pending)
if (!driver->udc_name || strcmp(driver->udc_name,
dev_name(>dev)) == 0) {
ret = udc_bind_to_driver(udc, driver);
+   if (ret == 0)
+   break;
if (ret != -EPROBE_DEFER)
list_del_init(>pending);
-   break;
+   /*
+* We failed to bind this driver, so let's try
+* next one.
+*/
}
 
return ret;
-- 
2.9.3

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

RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Felipe Balbi]

Hi,

Jerry Huang  writes:
>> Jerry Huang  writes:
>> >> Jerry Huang  writes:
>> >> > Hi, Balbi,
>> >> > Sorry for later responding.
>> >> > I tested Linux 4.8, 4.7, 4.6 and 4.5, has the same issue:
>> >> > [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
>> >> >
>> >> > Then I found one patch (dwc3 initiated xhci probe problem in arm64
>> >> > 4.4
>> >> kernel due to DMA setup) as below link, and I applied this patch to
>> >> Linux-4.5, the USB3.0 worked well! Therefore I applied this patch to
>> >> Linux-4.9-rc7, and the USB3.0 works well, too! Which used
>> >> of_dma_configure(>dev,
>> >> dwc->dev->of_node) to set dma.
>> >> > https://patches.linaro.org/patch/65892/
>> >> >
>> >> > However, in Linux-4.9-rc8, I found these 6 patches applied:
>> >> > https://patchwork.kernel.org/patch/9434163/
>> >> > https://patchwork.kernel.org/patch/9434155/
>> >> > https://patchwork.kernel.org/patch/9434131/
>> >> > https://patchwork.kernel.org/patch/9434165/
>> >> > https://patchwork.kernel.org/patch/9434167/
>> >> > https://patchwork.kernel.org/patch/9434133/
>> >> > and the commit ID are:
>> >> > 9863f279c1d48e366a179e76683247f239b30975
>> >> > 0abcfafea32452f1d07901320efa8c17470dbeed
>> >> > ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
>> >> > e9d10c536b26732d38d59fa3639b85bcd819837e
>> >> > 60478aead82d761c71a2a402b3fd2817af9e57ac
>> >> > 21f57eb38129042d2910d1e9b5fd36f3eea93637
>> >> >
>> >> > And I got the below error when I attached one  USB3.0 disk (Just
>> >> > USB2.0
>> >> disk can work). From above 6 patches, it seems remove
>> >> dma_set_coherent_mask from file drivers/usb/dwc3/host.c.
>> >> >
>> >> > usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
>> >> > [   16.224264] usb 4-1: device descriptor read/8, error -61
>> >> > [   16.336179] usb 4-1: new SuperSpeed USB device number 2 using xhci-
>> >> hcd
>> >> > [   16.360257] usb 4-1: device descriptor read/8, error -61
>> >> > [   16.652196] usb 4-1: new SuperSpeed USB device number 3 using xhci-
>> >> hcd
>> >> > [   16.676256] usb 4-1: device descriptor read/8, error -61
>> >> > [   16.788179] usb 4-1: new SuperSpeed USB device number 3 using xhci-
>> >> hcd
>> >> > [   16.812255] usb 4-1: device descriptor read/8, error -61
>> >> >
>> >> > So, how to handle this issue?
>> >>
>> >> oh, it's the DMA thing. We have patches going to next for this. Arnd,
>> >> do you know if next has all missing pieces? There was something
>> >> pending on XHCI IIRC, right?
>> > So, there are some patches for this issue? Where can I find it? I need 
>> > these
>> patches for my work.
>> 
>> https://lkml.org/lkml/2016/11/17/339
> You means these below 6 patches?  They have been applied to Linux-4.9-rc8.
> Based on Linux-4.9-rc8, I got the error when I connect USB3.0 disk to board 
> (USB2.0 disk works well):
> [   16.360257] usb 4-1: device descriptor read/8, error -61
> So, I think all these 6 patches did not set the USB3.0 DMA coherent
> correctly, and we need another patch to handle it.

okay, please prepare one such patch :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: ch341

[Johan Hovold]

On Wed, Dec 07, 2016 at 04:42:21AM -0800, Russell Senior wrote:

> I just bought a bag of usb-serial converters off of ebay, from china for
> super low price (~$2/each).  I just plugged a couple of them in,
> connected together through a null-modem adapter.  When I plug them, on
> both stock ubuntu 16.04's kernel and 4.8.9 built from git, I get a
> reasonable looking dmesg:
> 
> [822616.501963] usb 2-2.3: new full-speed USB device number 16 using xhci_hcd
> [822616.602985] usb 2-2.3: New USB device found, idVendor=1a86, idProduct=7523
> [822616.602988] usb 2-2.3: New USB device strings: Mfr=0, Product=2, 
> SerialNumber=0
> [822616.602989] usb 2-2.3: Product: USB2.0-Ser!
> [822617.633618] usbcore: registered new interface driver usbserial
> [822617.633638] usbcore: registered new interface driver usbserial_generic
> [822617.633653] usbserial: USB Serial support registered for generic
> [822617.638736] usbcore: registered new interface driver ch341
> [822617.638755] usbserial: USB Serial support registered for ch341-uart
> [822617.638770] ch341 2-2.3:1.0: ch341-uart converter detected
> [822617.640272] usb 2-2.3: ch341-uart converter now attached to ttyUSB0
> [822625.294363] usb 2-2.2: new full-speed USB device number 17 using xhci_hcd
> [822625.395324] usb 2-2.2: New USB device found, idVendor=1a86, idProduct=7523
> [822625.395327] usb 2-2.2: New USB device strings: Mfr=0, Product=2, 
> SerialNumber=0
> [822625.395328] usb 2-2.2: Product: USB2.0-Ser!
> [822625.396487] ch341 2-2.2:1.0: ch341-uart converter detected
> [822625.397575] usb 2-2.2: ch341-uart converter now attached to ttyUSB1
> 
> I attach the tty's with GNU screen (but I have also tried microcom and
> minicom with the same results).  This was my first experience with or
> even awareness of ch341. I have much more experience with pl2303 and
> somewhat less with ftdi.  With these ch341, when I type in an 'a' on one
> terminal, I get 0x01 out the other terminal.  If I type in a 'b', I get
> an 0x02, etc, on up to 'z' yielding 0x1a.
> 
> I found your name/contact in the git commits.
> 
> Any idea what is going on?

Sounds like it could be related to an incorrect line setting (e.g. the
devices are using 5-bit words). Some changes just went in that add
support for changing this. Could you try building a kernel based on the
usb-next branch of:

git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git

and see if that works better?

> My leading theory at the moment is that the manufacturer didn't populate
> all the parts, and the vendor got an great deal on them, which they
> passed on to me!

Note that some of these converters use TTL-level signalling which could
appear as corrupt transfers if you try to connect it to an RS232 port
(but not when connecting to another device also using TTL).

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

Re: [PATCH] usb: chipidea: use better pattern with WARN_ON()

[Greg KH]

On Wed, Dec 07, 2016 at 05:46:09PM +0530, Atul Raj wrote:
> Instead of using:
> if (cond) {
>WARN_ON(1);
>do_stuff();
> }
> 
> Use a better pattern with WARN_ON() placed in if condition:
> 
> if (WARN_ON(cond))
>do_stuff();

Why?  What does this help with?

And why are you sending patches that are different, yet have identical
subject lines?

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 0/1] NET: usb: cdc_mbim: add quirk for supporting Telit LE922A

[Daniele Palmas]

Telit LE922A MBIM based composition does not work properly
with altsetting toggle done in cdc_ncm_bind_common.

This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk
to avoid this procedure that, instead, is mandatory for
other modems.

References:
https://www.spinics.net/lists/linux-usb/msg149249.html
https://www.spinics.net/lists/linux-usb/msg149819.html

Thanks to Bjørn for the productive discussion and feedback!

Daniele Palmas (1):
  NET: usb: cdc_mbim: add quirk for supporting Telit LE922A

 drivers/net/usb/cdc_mbim.c  | 21 +
 drivers/net/usb/cdc_ncm.c   | 14 +-
 include/linux/usb/cdc_ncm.h |  3 ++-
 3 files changed, 32 insertions(+), 6 deletions(-)

-- 
2.7.4

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

Re: [PATCHv13 2/3] usb: USB Type-C connector class

[Heikki Krogerus]

Hi Oliver,

On Wed, Dec 07, 2016 at 10:46:48AM +0100, Oliver Neukum wrote:
> On Fri, 2016-12-02 at 10:04 -0800, Guenter Roeck wrote:
> 
> Hi,
> 
> > At least for my part I very much concentrated on making sure that
> > the user space ABI as well as the port driver API are sane and usable.
> 
> Rightly so, as this part cannot be changed once included in a kernel
> release.
> So, can we agree that that part at least is ready to go?

I at least have no plans on doing any changes to the ABI. The API will
change.

> > The driver interface is not my area of expertise. As such, my testing
> > and understanding of that part was limited to "it appears to work,
> > it must be ok". I very much relied on you to get this part right.
> > 
> > That makes me feel really bad. It isn't fun to have my "Reviewed-by"
> > on a patch that gets (and apparently deserves) a WTF from a senior
> > kernel maintainer. This hurts both your and my reputation, and obviously
> > will make me quite hesitant to add a "Reviewed-by:" to the next version
> > of the series.
> 
> The driver model is arcane. It is the reason we have people who really
> understand it review code.
> 
> But I think it is a reason we need to question assumptions.
> Is it really true that the lifetimes of both ends of a plug
> are tightly locked? What happens if you unplug a cable
> whose ends have different power supplies?

This is just a sidenote. Since both plugs will be registered and
unregistered separately with the new API I'm going to propose,
removing only one of the plugs will then be possible. I can't say if
the specifications actually allow that, but the API will not block
it. Both plugs are in any case represented as their own devices with
the cable as the parent as before.


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe 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/1] NET: usb: cdc_mbim: add quirk for supporting Telit LE922A

[Daniele Palmas]

Telit LE922A MBIM based composition does not work properly
with altsetting toggle done in cdc_ncm_bind_common.

This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk
to avoid this procedure that, instead, is mandatory for
other modems.

Signed-off-by: Daniele Palmas 
---
 drivers/net/usb/cdc_mbim.c  | 21 +
 drivers/net/usb/cdc_ncm.c   | 14 +-
 include/linux/usb/cdc_ncm.h |  3 ++-
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 96a5028..3a98f37 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -602,6 +602,21 @@ static const struct driver_info cdc_mbim_info_ndp_to_end = 
{
.data = CDC_NCM_FLAG_NDP_TO_END,
 };
 
+/* Some modems (e.g. Telit LE922A6) do not work properly with altsetting
+ * toggle done in cdc_ncm_bind_common. CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE
+ * flag is used to avoid this procedure.
+ */
+static const struct driver_info cdc_mbim_info_avoid_altsetting_toggle = {
+   .description = "CDC MBIM",
+   .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN,
+   .bind = cdc_mbim_bind,
+   .unbind = cdc_mbim_unbind,
+   .manage_power = cdc_mbim_manage_power,
+   .rx_fixup = cdc_mbim_rx_fixup,
+   .tx_fixup = cdc_mbim_tx_fixup,
+   .data = CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE,
+};
+
 static const struct usb_device_id mbim_devs[] = {
/* This duplicate NCM entry is intentional. MBIM devices can
 * be disguised as NCM by default, and this is necessary to
@@ -626,6 +641,12 @@ static const struct usb_device_id mbim_devs[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, USB_CLASS_COMM, 
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
  .driver_info = (unsigned long)_mbim_info_ndp_to_end,
},
+
+   /* Telit LE922A6 in MBIM composition */
+   { USB_DEVICE_AND_INTERFACE_INFO(0x1bc7, 0x1041, USB_CLASS_COMM, 
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_mbim_info_avoid_altsetting_toggle,
+   },
+
/* default entry */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, 
USB_CDC_PROTO_NONE),
  .driver_info = (unsigned long)_mbim_info_zlp,
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 877c951..afbfc0f 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -839,11 +839,18 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
usb_interface *intf, u8 data_
 
iface_no = ctx->data->cur_altsetting->desc.bInterfaceNumber;
 
+   /* Device-specific flags */
+   ctx->drvflags = drvflags;
+
/* Reset data interface. Some devices will not reset properly
 * unless they are configured first.  Toggle the altsetting to
-* force a reset
+* force a reset.
+* Some other devices do not work properly with this procedure
+* that can be avoided using quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE
 */
-   usb_set_interface(dev->udev, iface_no, data_altsetting);
+   if (!(ctx->drvflags & CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE))
+   usb_set_interface(dev->udev, iface_no, data_altsetting);
+
temp = usb_set_interface(dev->udev, iface_no, 0);
if (temp) {
dev_dbg(>dev, "set interface failed\n");
@@ -890,9 +897,6 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
usb_interface *intf, u8 data_
/* finish setting up the device specific data */
cdc_ncm_setup(dev);
 
-   /* Device-specific flags */
-   ctx->drvflags = drvflags;
-
/* Allocate the delayed NDP if needed. */
if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END) {
ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL);
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 3a375d0..00d2324 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -81,7 +81,8 @@
 #define CDC_NCM_TIMER_INTERVAL_MAX (U32_MAX / NSEC_PER_USEC)
 
 /* Driver flags */
-#define CDC_NCM_FLAG_NDP_TO_END0x02/* NDP is placed at end 
of frame */
+#define CDC_NCM_FLAG_NDP_TO_END0x02/* NDP is 
placed at end of frame */
+#define CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE  0x04/* Avoid altsetting 
toggle during init */
 
 #define cdc_ncm_comm_intf_is_mbim(x)  ((x)->desc.bInterfaceSubClass == 
USB_CDC_SUBCLASS_MBIM && \
   (x)->desc.bInterfaceProtocol == 
USB_CDC_PROTO_NONE)
-- 
2.7.4

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

Re: ch341

[Russell Senior]

Hi,

I just bought a bag of usb-serial converters off of ebay, from china for
super low price (~$2/each).  I just plugged a couple of them in,
connected together through a null-modem adapter.  When I plug them, on
both stock ubuntu 16.04's kernel and 4.8.9 built from git, I get a
reasonable looking dmesg:

[822616.501963] usb 2-2.3: new full-speed USB device number 16 using xhci_hcd
[822616.602985] usb 2-2.3: New USB device found, idVendor=1a86, idProduct=7523
[822616.602988] usb 2-2.3: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[822616.602989] usb 2-2.3: Product: USB2.0-Ser!
[822617.633618] usbcore: registered new interface driver usbserial
[822617.633638] usbcore: registered new interface driver usbserial_generic
[822617.633653] usbserial: USB Serial support registered for generic
[822617.638736] usbcore: registered new interface driver ch341
[822617.638755] usbserial: USB Serial support registered for ch341-uart
[822617.638770] ch341 2-2.3:1.0: ch341-uart converter detected
[822617.640272] usb 2-2.3: ch341-uart converter now attached to ttyUSB0
[822625.294363] usb 2-2.2: new full-speed USB device number 17 using xhci_hcd
[822625.395324] usb 2-2.2: New USB device found, idVendor=1a86, idProduct=7523
[822625.395327] usb 2-2.2: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[822625.395328] usb 2-2.2: Product: USB2.0-Ser!
[822625.396487] ch341 2-2.2:1.0: ch341-uart converter detected
[822625.397575] usb 2-2.2: ch341-uart converter now attached to ttyUSB1

I attach the tty's with GNU screen (but I have also tried microcom and
minicom with the same results).  This was my first experience with or
even awareness of ch341. I have much more experience with pl2303 and
somewhat less with ftdi.  With these ch341, when I type in an 'a' on one
terminal, I get 0x01 out the other terminal.  If I type in a 'b', I get
an 0x02, etc, on up to 'z' yielding 0x1a.

I found your name/contact in the git commits.

Any idea what is going on?

My leading theory at the moment is that the manufacturer didn't populate
all the parts, and the vendor got an great deal on them, which they
passed on to me!


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

Re: [PATCH 1/2] usb: dwc3: gadget: Fix full speed mode

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>>> Roger Quadros  writes:
 DCFG.DEVSPD == 0x3 is not valid and we need to set
 DCFG.DEVSPD to 0x1 for full speed mode.
>>>
>>> seems like it has been made invalid somewhere between 1.73a and
>>> 2.60a. Can you figure it out from Documentation why and when it was made
>>> invalid? We might need revision checks here.
>>>
>> 
>> I'll try to dig out more.
>
> I couldn't figure out more information on this. The changelogs in the TRMs
> don't capture this change and I don't have access to all TRM versions
> so I can't say which version it got changed and why.
>
> Can we please involve someone from Synopsis to provide this information?
> Thanks.

John, could you help us with this query? We'd like to understand why one
of the FULLSPEED modes got removed. Do we need a revision check or can
we assume that the other mode was never supposed to be used?

thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 00/25] usb: host: xhci: cleanup series

[Felipe Balbi]

Hi,

Felipe Balbi  writes:
> hi Mathias,
>
> here's a much longer series of cleanups which I have been working on for
> the past few days. Let me know what you think about it.
>
> I did some light tests SKL and everything still works as before. I know
> you have some reservations about my changes to trb_in_td() but IMHO, if
> we can assume this function to be always correct, there's no need to add
> debugging messages to it and as for the trb_in_td() call which existed
> only for debugging purposes, I guess we need to find a better way of
> adding debug statements for that part of the code.
>
> Let me know what you think.

I have patches updated in xhci-cleanup on my k.org branch. Just making
sure these are all the comments I'll get. Mathias, are you done
reviewing?

(no, I'm not walking 2.5m to ask you in person heh)

-- 
balbi


signature.asc
Description: PGP signature

RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Jerry Huang]

> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Wednesday, December 07, 2016 4:41 PM
> To: Jerry Huang ; st...@rowland.harvard.edu;
> linux-usb@vger.kernel.org; Mathias Nyman
> ; Arnd Bergmann 
> Cc: Sriram Dash ; Greg Kroah-Hartman
> 
> Subject: RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
> 
> 
> (no top-posting, please. It's the 2nd time I'm asking)
Sorry for that I didn't notice it.
> 
> Hi,
> 
> Jerry Huang  writes:
> > Hi, Balbi,
> > Sorry for later responding.
> > I tested Linux 4.8, 4.7, 4.6 and 4.5, has the same issue:
> > [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
> >
> > Then I found one patch (dwc3 initiated xhci probe problem in arm64 4.4
> kernel due to DMA setup) as below link, and I applied this patch to Linux-4.5,
> the USB3.0 worked well! Therefore I applied this patch to Linux-4.9-rc7, and
> the USB3.0 works well, too! Which used of_dma_configure(>dev,
> dwc->dev->of_node) to set dma.
> > https://patches.linaro.org/patch/65892/
> >
> > However, in Linux-4.9-rc8, I found these 6 patches applied:
> > https://patchwork.kernel.org/patch/9434163/
> > https://patchwork.kernel.org/patch/9434155/
> > https://patchwork.kernel.org/patch/9434131/
> > https://patchwork.kernel.org/patch/9434165/
> > https://patchwork.kernel.org/patch/9434167/
> > https://patchwork.kernel.org/patch/9434133/
> > and the commit ID are:
> > 9863f279c1d48e366a179e76683247f239b30975
> > 0abcfafea32452f1d07901320efa8c17470dbeed
> > ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
> > e9d10c536b26732d38d59fa3639b85bcd819837e
> > 60478aead82d761c71a2a402b3fd2817af9e57ac
> > 21f57eb38129042d2910d1e9b5fd36f3eea93637
> >
> > And I got the below error when I attached one  USB3.0 disk (Just USB2.0
> disk can work). From above 6 patches, it seems remove
> dma_set_coherent_mask from file drivers/usb/dwc3/host.c.
> >
> > usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
> > [   16.224264] usb 4-1: device descriptor read/8, error -61
> > [   16.336179] usb 4-1: new SuperSpeed USB device number 2 using xhci-
> hcd
> > [   16.360257] usb 4-1: device descriptor read/8, error -61
> > [   16.652196] usb 4-1: new SuperSpeed USB device number 3 using xhci-
> hcd
> > [   16.676256] usb 4-1: device descriptor read/8, error -61
> > [   16.788179] usb 4-1: new SuperSpeed USB device number 3 using xhci-
> hcd
> > [   16.812255] usb 4-1: device descriptor read/8, error -61
> >
> > So, how to handle this issue?
> 
> oh, it's the DMA thing. We have patches going to next for this. Arnd, do you
> know if next has all missing pieces? There was something pending on XHCI
> IIRC, right?
So, there are some patches for this issue? Where can I find it? I need these 
patches for my work.

> 
> (keeping context below)
> 
> > -Original Message-
> > From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> > Sent: Monday, December 05, 2016 7:00 PM
> > To: Jerry Huang ; st...@rowland.harvard.edu;
> > linux-usb@vger.kernel.org; Mathias Nyman
> > 
> > Cc: Sriram Dash 
> > Subject: RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
> >
> >
> > (no top-posting, please)
> >
> > Hi,
> >
> > it helps if you include maintainers for correct drivers.
> scripts/get_maintainer.pl helps a lot.
> >
> > Jerry Huang  writes:
> >> And I tested USB2.0 disk, with Sriram's 6 patches, it works well. So Just
> USB3.0 can't work.
> >>
> >> BTW,
> >> The board with USB3.0 DWC3 controller and the USB3.0 disk work well
> with Linux-4.1.8.
> >
> > alright, in that case you can bisect. Please do so and find the first commit
> when this started happening.
> >
> >> -Original Message-
> >> From: Jerry Huang
> >> Sent: Monday, December 05, 2016 6:11 PM
> >> To: st...@rowland.harvard.edu; linux-usb@vger.kernel.org
> >> Cc: Sriram Dash 
> >> Subject: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
> >>
> >> Hi, Guys,
> >> 1. I tested the USB3.0 DWC3 with latest Linux-4.9-rc7 on LS1043ardb board.
> >> But I got the below errors, this error is returned from
> dma_supported(dev, mask) while running " dma_set_mask_and_coherent"
> in function " xhci_plat_probe".
> >> ...
> >> [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
> >> [0.762438] xhci-hcd: probe of xhci-hcd.1.auto failed with error -5
> >> [0.768712] xhci-hcd: probe of xhci-hcd.2.auto failed with error -5
> >> [0.775049] usbcore: registered new interface driver usb-storage
> >> ...
> >>
> >> 2. Then, I applied 6 patches from Sriram:
> >> https://patchwork.kernel.org/patch/9434163/
> >> https://patchwork.kernel.org/patch/9434155/
> >> https://patchwork.kernel.org/patch/9434131/
> >> https://patchwork.kernel.org/patch/9434165/
> >> 

Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

2016-12-05 14:04 GMT+01:00 Daniele Palmas :
> Hi,
>
> 2016-12-05 11:10 GMT+01:00 Bjørn Mork :
>> Daniele Palmas  writes:
>>
>>> I went back to this and further checking revealed that MBIM function
>>> reset is not needed and the only problem is related to commit
>>> 48906f62c96cc2cd35753e59310cb70eb08cc6a5 cdc_ncm: toggle altsetting to
>>> force reset before setup, that, however, is mandatory for some Huawei
>>> modems.
>>
>> Interesting.  That does sound like an odd firmware bug to me. I have a
>> bit of a hard time understanding how this can be.  Using data interface
>> altsetting 0 to reset the function is documented in the NCM spec:
>>
>
> Agree, this is likely a firmware bug and it is also proved by all the
> other modems that accept the procedure without issues.
>
>> "
>>   7.2 Using Alternate Settings to Reset an NCM Function
>>
>>   To place the network aspects of a function in a known state, the host
>>   shall:
>>   • select alternate setting 0 of the NCM Data Interface (this is the
>> setting with no endpoints). This can be done explicitly using
>> SetInterface, or implicitly using SetConfiguration. See [USB30] for
>> details.
>>   • select the NCM operational parameters by sending commands to the NCM
>> Communication Interface, then
>>   • select the second alternate interface setting of the NCM Data
>> Interface (this is the setting with a bulk IN endpoint and a bulk
>> OUT endpoint).
>>
>>   Whenever alternate setting 0 is selected by the host, the function
>>   shall:
>>   • flush function buffers
>>   • reset the packet filter to its default state
>>   • clear all multicast address filters
>>   • clear all power filters set using
>> SetEthernetPowerManagementPatternFilter
>>   • reset statistics counters to zero
>>   • restore its Ethernet address to its default state
>>   • reset its IN NTB size to the value given by field dwNtbInMaxSize
>> from the NTB Parameter Struc- ture
>>   • reset the NTB format to NTB-16
>>   • reset the current Maximum Datagram Size to a function-specific
>> default. If SetMaxDatagramSize is not supported, then the maximum
>> datagram size shall be the same as the value in wMaxSegmentSize of
>> the Ethernet Networking Functional Descriptor. If SetMaxDatagramSize
>> is supported by the function, then the host must either query the
>> function to determine the current effective maximum datagram size,
>> or must explicitly set the maximum datagram size. If the host wishes
>> to set the Maximum Datagram Size, it may do so prior to selecting
>> the second alternate interface set- ting of the data
>> interface. Doing so will ensure that the change takes effect prior
>> to send or receiving data.
>>   • reset CRC mode so that the function will not append CRCs to
>> datagrams sent on the IN pipe
>>   • reset NTB sequence numbers to zero
>>
>>   When the host selects the second alternate interface setting of the
>>   NCM Data Interface, the function shall perform the following actions
>>   in the following order.
>>   • If connected to the network, the function shall send a
>> ConnectionSpeedChange notification to the host indicating the
>> current connection speed.
>>   • Whether connected or not, the function shall then send a
>> NetworkConnection notification to the host, with wValue indicating
>> the current state of network connectivity
>> "
>>
>> The addition of the "RESET" request in MBIM did not change these
>> requirements AFAICS.  Supporting NCM style "altsetting 0 reset" is
>> required by default inheritance.  The description of dual NCM/MBIM
>> functions in the MBIM spec further emphasizes this:
>>
>> "
>>   Regardless of the previous sequence of SET_INTERFACE commands targeting
>>   the Communication Interface, the host is able to put the function into
>>   a defined state by the following sequence:
>>
>>   1. SET_INTERFACE(Data Interface, 0)
>>   2. SET_INTERFACE(Communication Interface, desired alternate setting)
>>   3. Sending the required class commands for the targeted alternate
>> setting
>>   4. SET_INTERFACE(Data Interface, 1 if Communication Interface,0 and
>> Data Interface,2 Communication Interface 1)
>> "
>>
>>
>> This, along with the lack of *any* sort of discussion of the
>> relation/interfaction between "MBIM RESET" and "data interface
>> altsetting 0" makes the MBIM RESET control request either ambigious or
>> redundant.  Or both...
>>
>> FWIW, I've always considered RESET a symptom of the sloppy MBIM spec
>> development.  It did not exactly work to their advantage that the first
>> (and only?) published errata simply was an excuse to add new features
>> (the "MBIM extended functional descriptor" and "MBIM loopback testmode")
>> without updating the revision number.  Causing even more confusion,
>> since we now have two different MBIMv1.0 specs.
>>
>> Well, whatever.  No need to get all 

[PATCH] usb: chipidea: use better pattern with WARN_ON()

[Atul Raj]

Instead of using:
if (cond) {
   WARN_ON(1);
   do_stuff();
}

Use a better pattern with WARN_ON() placed in if condition:

if (WARN_ON(cond))
   do_stuff();

Signed-off-by: Atul Raj 
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 0991794..2228e44 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -374,10 +374,8 @@ static int imx_controller_resume(struct device *dev)
 
dev_dbg(dev, "at %s\n", __func__);
 
-   if (!data->in_lpm) {
-   WARN_ON(1);
+   if (WARN_ON(!data->in_lpm))
return 0;
-   }
 
ret = imx_prepare_enable_clks(dev);
if (ret)
@@ -442,10 +440,8 @@ static int ci_hdrc_imx_runtime_suspend(struct device *dev)
struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
int ret;
 
-   if (data->in_lpm) {
-   WARN_ON(1);
+   if (WARN_ON(data->in_lpm))
return 0;
-   }
 
ret = imx_usbmisc_set_wakeup(data->usbmisc_data, true);
if (ret) {
-- 
2.10.2.windows.1

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

[PATCH] usb: chipidea: use better pattern with WARN_ON()

[Atul Raj]

Instead of using:
if (cond) {
   WARN_ON(1);
   do_stuff();
}

Use a better pattern with WARN_ON() placed in if condition:

if (WARN_ON(cond))
   do_stuff();

Signed-off-by: Atul Raj 
---
 drivers/usb/chipidea/core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3dbb4a2..dabd7b4 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -1169,10 +1169,8 @@ static int ci_suspend(struct device *dev)
if (ci->in_lpm)
pm_runtime_resume(dev);
 
-   if (ci->in_lpm) {
-   WARN_ON(1);
+   if (WARN_ON(ci->in_lpm))
return 0;
-   }
 
if (device_may_wakeup(dev)) {
if (ci_otg_is_fsm_mode(ci))
@@ -1215,10 +1213,8 @@ static int ci_runtime_suspend(struct device *dev)
 
dev_dbg(dev, "at %s\n", __func__);
 
-   if (ci->in_lpm) {
-   WARN_ON(1);
+   if (WARN_ON(ci->in_lpm))
return 0;
-   }
 
if (ci_otg_is_fsm_mode(ci))
ci_otg_fsm_suspend_for_srp(ci);
-- 
2.10.2.windows.1

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

Re: [PATCH 1/2] usb: dwc3: gadget: Fix full speed mode

[Roger Quadros]

Hi,

On 29/11/16 14:28, Roger Quadros wrote:
> Hi,
> 
> On 29/11/16 13:51, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros  writes:
>>> DCFG.DEVSPD == 0x3 is not valid and we need to set
>>> DCFG.DEVSPD to 0x1 for full speed mode.
>>
>> seems like it has been made invalid somewhere between 1.73a and
>> 2.60a. Can you figure it out from Documentation why and when it was made
>> invalid? We might need revision checks here.
>>
> 
> I'll try to dig out more.

I couldn't figure out more information on this. The changelogs in the TRMs
don't capture this change and I don't have access to all TRM versions
so I can't say which version it got changed and why.

Can we please involve someone from Synopsis to provide this information?
Thanks.

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

Re: [PATCH] add dlink dwm-158 to usb-serial-option

[Johan Hovold]

On Tue, Dec 06, 2016 at 09:24:19PM +0100, Giuseppe Lippolis wrote:
> I try to attach the file.

This still wouldn't apply without some manual intervention. Next time,
try sending the patch to yourself first (e.g. using git-send-email) and
make sure you can apply the result with git-am.

> Adding registration for 3G modem DWM-158 in usb-serial-option
> 
> Signed-off-by: Giuseppe Lippolis 

I also changed the subject and added a module prefix:

"USB: serial: option: add dlink dwm-158"

before applying.

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

Re: usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

On Tue, Dec 6, 2016 at 9:30 PM, Alan Stern  wrote:
> [CC: list drastically trimmed]
>
> On Tue, 6 Dec 2016, Andrey Konovalov wrote:
>
>> On Tue, Dec 6, 2016 at 1:28 PM, Andrey Konovalov  
>> wrote:
>> > On Mon, Dec 5, 2016 at 8:31 PM, Alan Stern  
>> > wrote:
>> >> On Mon, 5 Dec 2016, Andrey Konovalov wrote:
>> >>
>> >>> Hi!
>> >>>
>> >>> I've got the following error report while running the syzkaller fuzzer.
>> >>>
>> >>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>> >>>
>> >>> BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr
>> >>> 88003dfe5bf2
>
>> >> Can you test whether the patch below fixes this problem?
>> >
>> > Hi Alan,
>> >
>> > Yes, I believe it does.
>> > It also seems to fix the warnings in dummy_free_request() I've been 
>> > getting.
>>
>> It seems that I was wrong. Still see both use-after-free and warnings.
>
> You posted three messages about possibly related problems:
>
> use-after-free in gadgetfs_setup (this one),
>
> GPF in usb_gadget_unregister_driver,
>
> warning in dummy_free_request.
>
> Are you saying the patch below didn't fix any of them?

No, as far as I can see.

>
> And in any case, is there any way you can post the series of system
> calls that syzkaller makes so we can tell what went wrong?

I've attached a reproducer for a use-after-free in gadgetfs_setup().
You need to enable KASAN to see the reports.

Thanks for looking at this!

>
> Alan Stern
>
>> >> Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
>> >> ===
>> >> --- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
>> >> +++ usb-4.x/drivers/usb/gadget/legacy/inode.c
>> >> @@ -1762,6 +1762,10 @@ dev_config (struct file *fd, const char
>> >> }
>> >> spin_unlock_irq(>lock);
>> >>
>> >> +   /* Registered but not yet bound to a UDC driver? */
>> >> +   if (dev->gadget_registered)
>> >> +   return -EIO;
>> >> +
>> >> if (len < (USB_DT_CONFIG_SIZE + USB_DT_DEVICE_SIZE + 4))
>> >> return -EINVAL;
>> >>
>


gadget-setup-uaf-poc.c
Description: Binary data

RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Jerry Huang]

Hi, Balbi,
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Wednesday, December 07, 2016 5:11 PM
> To: Jerry Huang ; st...@rowland.harvard.edu;
> linux-usb@vger.kernel.org; Mathias Nyman
> ; Arnd Bergmann 
> Cc: Sriram Dash ; Greg Kroah-Hartman
> 
> Subject: RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
> 
> 
> Hi,
> 
> Jerry Huang  writes:
> >> Jerry Huang  writes:
> >> > Hi, Balbi,
> >> > Sorry for later responding.
> >> > I tested Linux 4.8, 4.7, 4.6 and 4.5, has the same issue:
> >> > [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
> >> >
> >> > Then I found one patch (dwc3 initiated xhci probe problem in arm64
> >> > 4.4
> >> kernel due to DMA setup) as below link, and I applied this patch to
> >> Linux-4.5, the USB3.0 worked well! Therefore I applied this patch to
> >> Linux-4.9-rc7, and the USB3.0 works well, too! Which used
> >> of_dma_configure(>dev,
> >> dwc->dev->of_node) to set dma.
> >> > https://patches.linaro.org/patch/65892/
> >> >
> >> > However, in Linux-4.9-rc8, I found these 6 patches applied:
> >> > https://patchwork.kernel.org/patch/9434163/
> >> > https://patchwork.kernel.org/patch/9434155/
> >> > https://patchwork.kernel.org/patch/9434131/
> >> > https://patchwork.kernel.org/patch/9434165/
> >> > https://patchwork.kernel.org/patch/9434167/
> >> > https://patchwork.kernel.org/patch/9434133/
> >> > and the commit ID are:
> >> > 9863f279c1d48e366a179e76683247f239b30975
> >> > 0abcfafea32452f1d07901320efa8c17470dbeed
> >> > ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
> >> > e9d10c536b26732d38d59fa3639b85bcd819837e
> >> > 60478aead82d761c71a2a402b3fd2817af9e57ac
> >> > 21f57eb38129042d2910d1e9b5fd36f3eea93637
> >> >
> >> > And I got the below error when I attached one  USB3.0 disk (Just
> >> > USB2.0
> >> disk can work). From above 6 patches, it seems remove
> >> dma_set_coherent_mask from file drivers/usb/dwc3/host.c.
> >> >
> >> > usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
> >> > [   16.224264] usb 4-1: device descriptor read/8, error -61
> >> > [   16.336179] usb 4-1: new SuperSpeed USB device number 2 using xhci-
> >> hcd
> >> > [   16.360257] usb 4-1: device descriptor read/8, error -61
> >> > [   16.652196] usb 4-1: new SuperSpeed USB device number 3 using xhci-
> >> hcd
> >> > [   16.676256] usb 4-1: device descriptor read/8, error -61
> >> > [   16.788179] usb 4-1: new SuperSpeed USB device number 3 using xhci-
> >> hcd
> >> > [   16.812255] usb 4-1: device descriptor read/8, error -61
> >> >
> >> > So, how to handle this issue?
> >>
> >> oh, it's the DMA thing. We have patches going to next for this. Arnd,
> >> do you know if next has all missing pieces? There was something
> >> pending on XHCI IIRC, right?
> > So, there are some patches for this issue? Where can I find it? I need these
> patches for my work.
> 
> https://lkml.org/lkml/2016/11/17/339
You means these below 6 patches?  They have been applied to Linux-4.9-rc8.
Based on Linux-4.9-rc8, I got the error when I connect USB3.0 disk to board 
(USB2.0 disk works well):
[   16.360257] usb 4-1: device descriptor read/8, error -61
So, I think all these 6 patches did not set the USB3.0 DMA coherent correctly, 
and we need another patch to handle it.

All these patches can't be opened on lkml website, but I found them on 
patchwork.
[PATCH v5 1/6] usb: separate out sysdev pointer from usb_bus 
(https://lkml.org/lkml/2016/11/17/349)
[PATCH v5 2/6] usb: chipidea: use bus->sysdev for DMA configuration 
(https://lkml.org/lkml/2016/11/17/340 )
[PATCH v5 3/6] usb: ehci: fsl: use bus->sysdev for DMA configuration 
(https://lkml.org/lkml/2016/11/17/334)
[PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration 
(https://lkml.org/lkml/2016/11/17/348 )
[PATCH v5 5/6] usb: dwc3: use bus->sysdev for DMA configuration 
(https://lkml.org/lkml/2016/11/17/347)
[PATCH v5 6/6] usb: dwc3: Do not set dma coherent mask - LKML.ORG 
(https://lkml.org/lkml/2016/11/17/337)

On patchwork.kernel.org:
https://patchwork.kernel.org/patch/9434163/
https://patchwork.kernel.org/patch/9434155/
https://patchwork.kernel.org/patch/9434131/
https://patchwork.kernel.org/patch/9434165/
https://patchwork.kernel.org/patch/9434167/
https://patchwork.kernel.org/patch/9434133/

the commit ID for them:
9863f279c1d48e366a179e76683247f239b30975
0abcfafea32452f1d07901320efa8c17470dbeed
ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
e9d10c536b26732d38d59fa3639b85bcd819837e
60478aead82d761c71a2a402b3fd2817af9e57ac
21f57eb38129042d2910d1e9b5fd36f3eea93637

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

[PATCH] usb: misc: rio500: fix result type for error message

[Kim Jae Joong]

Fix variable type for dev_err about usb_bulk_msg()

Signed-off-by: Kim Jae Joong 
---
 drivers/usb/misc/rio500.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/misc/rio500.c b/drivers/usb/misc/rio500.c
index 13731d5..fc329c9 100644
--- a/drivers/usb/misc/rio500.c
+++ b/drivers/usb/misc/rio500.c
@@ -421,7 +421,7 @@ static long ioctl_rio(struct file *file, unsigned int cmd, 
unsigned long arg)
} else if (result != -EREMOTEIO) {
mutex_unlock(&(rio->lock));
dev_err(>rio_dev->dev,
-   "Read Whoops - result:%u partial:%u 
this_read:%u\n",
+   "Read Whoops - result:%d partial:%u 
this_read:%u\n",
result, partial, this_read);
return -EIO;
} else {
-- 
1.9.1

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

Re: [PATCH] usb: gadget: udc: atmel: Fix check in usba_ep_enable()

[Boris Brezillon]

On Tue,  6 Dec 2016 22:59:43 +0100
Boris Brezillon  wrote:

> desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK is not necessarily
> equal to ep->index and that's perfectly fine. The usba endpoint index is
> just an internal identifier used by the driver to know which registers
> to use for a USB endpoint.
> 
> Enforcing this constraint is not only useless, but can also lead to
> errors since nothing guarantees that the endpoint number and index are
> matching when an endpoint is selected for a specific descriptor, thus
> leading to errors at ->enable() time when it's already too late to choose
> another endpoint.

Please ignore this patch. The real bug has been fixed in commit
bbe097f092b0 ("usb: gadget: udc: atmel: fix endpoint name").

> 
> Signed-off-by: Boris Brezillon 
> ---
> Hi,
> 
> I intentionally didn't add the Cc stable and Fixes tags because this
> bug dates back to the drivers creation, and I fear the index <->
> epnum constraint was actually required at that time.
> 
> Note that I discovered this bug thanks to the WARN_ON_ONCE() in
> usb_ep_queue() [1] which was introduced in 4.5.
> It might appear that this problem was silently ignored before that
> (with part of the usba_ep_enable() code being skipped without any
> notice).
> 
> Regards,
> 
> Boris
> 
> [1]http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/core.c#L264
> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index bb1f6c8f0f01..981d2639d413 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -531,11 +531,8 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
> usb_endpoint_descriptor *desc)
>  
>   maxpacket = usb_endpoint_maxp(desc) & 0x7ff;
>  
> - if (((desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) != ep->index)
> - || ep->index == 0
> - || desc->bDescriptorType != USB_DT_ENDPOINT
> - || maxpacket == 0
> - || maxpacket > ep->fifo_size) {
> + if (ep->index == 0 || desc->bDescriptorType != USB_DT_ENDPOINT ||
> + maxpacket == 0 || maxpacket > ep->fifo_size) {
>   DBG(DBG_ERR, "ep_enable: Invalid argument");
>   return -EINVAL;
>   }

--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv13 2/3] usb: USB Type-C connector class

[Oliver Neukum]

On Fri, 2016-12-02 at 10:04 -0800, Guenter Roeck wrote:

Hi,

> At least for my part I very much concentrated on making sure that
> the user space ABI as well as the port driver API are sane and usable.

Rightly so, as this part cannot be changed once included in a kernel
release.
So, can we agree that that part at least is ready to go?

> The driver interface is not my area of expertise. As such, my testing
> and understanding of that part was limited to "it appears to work,
> it must be ok". I very much relied on you to get this part right.
> 
> That makes me feel really bad. It isn't fun to have my "Reviewed-by"
> on a patch that gets (and apparently deserves) a WTF from a senior
> kernel maintainer. This hurts both your and my reputation, and obviously
> will make me quite hesitant to add a "Reviewed-by:" to the next version
> of the series.

The driver model is arcane. It is the reason we have people who really
understand it review code.

But I think it is a reason we need to question assumptions.
Is it really true that the lifetimes of both ends of a plug
are tightly locked? What happens if you unplug a cable
whose ends have different power supplies?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe 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 RESEND] usb: gadget: udc-core: Rescan pending list on driver unbind

[Krzysztof Opasiak]

Hi Alan,

On 12/06/2016 09:21 PM, Alan Stern wrote:
> Krzysztof:
> 
> Your patch doesn't address a bug that has been present in
> usb_add_gadget_udc_release() for some time.  If the bind callback fails
> with any error other than -EPROBE_DEFER, the driver remains unbound to
> the gadget but it is not added back on to the
> gadget_driver_pending_list.  As a result, when the driver is
> unregistered, the list_del() call will cause problems.
> 

You are absolutely right. I have never claimed that I fixed anything
more than described in commit msg;)

> There's a good reason not to add the driver back on to the list: If 
> it's not working then we don't want to keep trying to probe it over and 
> over again.  I think the best thing to do would be 
> list_del_init(>pending), so that at least unregistration won't 
> cause an oops.
> 

Sounds reasonable. I will submit a patch for this.

> There's another thing.  If the bind callback fails, why not continue 
> the loop in check_pending_gadget_drivers()?  Maybe another pending 
> driver will succeed.  (Of course, to do this would require using 
> list_for_each_entry_safe instead of list_for_each_entry.)

Yah. True. That's how probing drivers for devices usually works. I'll
submit a patch for this.

@Felipe
Please ignore this patch. I will post it together with fixes suggested
by Alan in a series so they can be easily applied without ordering problems.

Best regards,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv13 2/3] usb: USB Type-C connector class

[Heikki Krogerus]

On Fri, Dec 02, 2016 at 10:04:39AM -0800, Guenter Roeck wrote:
> At least for my part I very much concentrated on making sure that
> the user space ABI as well as the port driver API are sane and usable.
> 
> The driver interface is not my area of expertise. As such, my testing
> and understanding of that part was limited to "it appears to work,
> it must be ok". I very much relied on you to get this part right.
> 
> That makes me feel really bad. It isn't fun to have my "Reviewed-by"
> on a patch that gets (and apparently deserves) a WTF from a senior
> kernel maintainer. This hurts both your and my reputation, and obviously
> will make me quite hesitant to add a "Reviewed-by:" to the next version
> of the series.

I don't usually get very upset about stronger comments, even if they
are coming from senior kernel maintainer like Greg, but your concern
does make me feel like crap. I'm sorry Guenter.

Please just note that nobody else has considered the approach as a
problem or noticed it before Greg any more then you, and this code has
by now been review by many, including some people who I consider senior
kernel developers and maintainers, both internally inside Intel and
also publicly on these lists.

> No more shortcuts, please.

No.


Br,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe 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: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Felipe Balbi]

Hi,

Jerry Huang  writes:
>> Jerry Huang  writes:
>> > Hi, Balbi,
>> > Sorry for later responding.
>> > I tested Linux 4.8, 4.7, 4.6 and 4.5, has the same issue:
>> > [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
>> >
>> > Then I found one patch (dwc3 initiated xhci probe problem in arm64 4.4
>> kernel due to DMA setup) as below link, and I applied this patch to 
>> Linux-4.5,
>> the USB3.0 worked well! Therefore I applied this patch to Linux-4.9-rc7, and
>> the USB3.0 works well, too! Which used of_dma_configure(>dev,
>> dwc->dev->of_node) to set dma.
>> > https://patches.linaro.org/patch/65892/
>> >
>> > However, in Linux-4.9-rc8, I found these 6 patches applied:
>> > https://patchwork.kernel.org/patch/9434163/
>> > https://patchwork.kernel.org/patch/9434155/
>> > https://patchwork.kernel.org/patch/9434131/
>> > https://patchwork.kernel.org/patch/9434165/
>> > https://patchwork.kernel.org/patch/9434167/
>> > https://patchwork.kernel.org/patch/9434133/
>> > and the commit ID are:
>> > 9863f279c1d48e366a179e76683247f239b30975
>> > 0abcfafea32452f1d07901320efa8c17470dbeed
>> > ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
>> > e9d10c536b26732d38d59fa3639b85bcd819837e
>> > 60478aead82d761c71a2a402b3fd2817af9e57ac
>> > 21f57eb38129042d2910d1e9b5fd36f3eea93637
>> >
>> > And I got the below error when I attached one  USB3.0 disk (Just USB2.0
>> disk can work). From above 6 patches, it seems remove
>> dma_set_coherent_mask from file drivers/usb/dwc3/host.c.
>> >
>> > usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
>> > [   16.224264] usb 4-1: device descriptor read/8, error -61
>> > [   16.336179] usb 4-1: new SuperSpeed USB device number 2 using xhci-
>> hcd
>> > [   16.360257] usb 4-1: device descriptor read/8, error -61
>> > [   16.652196] usb 4-1: new SuperSpeed USB device number 3 using xhci-
>> hcd
>> > [   16.676256] usb 4-1: device descriptor read/8, error -61
>> > [   16.788179] usb 4-1: new SuperSpeed USB device number 3 using xhci-
>> hcd
>> > [   16.812255] usb 4-1: device descriptor read/8, error -61
>> >
>> > So, how to handle this issue?
>> 
>> oh, it's the DMA thing. We have patches going to next for this. Arnd, do you
>> know if next has all missing pieces? There was something pending on XHCI
>> IIRC, right?
> So, there are some patches for this issue? Where can I find it? I need these 
> patches for my work.

https://lkml.org/lkml/2016/11/17/339

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v13 05/10] usbip: exporting devices: modifications to daemon

[Krzysztof Opasiak]

On 12/07/2016 01:05 AM, fx IWATA NOBUO wrote:
> Hello,
> 
>> how about usbip_meta_driver_set(type)?
> 
> Good.
> 
> I'd like to confirm the 'type' parameter.
> 
> #define USBIP_DRIVER_TYPE_HOST   0
> #define USBIP_DRIVER_TYPE_DEVICE 1
> 
> Then usbip_meta_driver_init should not be included.
> It must be usbip_meta_driver_set(USBIP_DRIVER_TYPE_HOST).
> 

Yes, that's exactly what I mean.

Best regards,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Felipe Balbi]

(no top-posting, please. It's the 2nd time I'm asking)

Hi,

Jerry Huang  writes:
> Hi, Balbi,
> Sorry for later responding.
> I tested Linux 4.8, 4.7, 4.6 and 4.5, has the same issue:
> [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
>
> Then I found one patch (dwc3 initiated xhci probe problem in arm64 4.4 kernel 
> due to DMA setup) as below link, and I applied this patch to Linux-4.5, the 
> USB3.0 worked well! Therefore I applied this patch to Linux-4.9-rc7, and the 
> USB3.0 works well, too! Which used of_dma_configure(>dev, 
> dwc->dev->of_node) to set dma.
> https://patches.linaro.org/patch/65892/ 
>
> However, in Linux-4.9-rc8, I found these 6 patches applied:
> https://patchwork.kernel.org/patch/9434163/
> https://patchwork.kernel.org/patch/9434155/
> https://patchwork.kernel.org/patch/9434131/
> https://patchwork.kernel.org/patch/9434165/
> https://patchwork.kernel.org/patch/9434167/
> https://patchwork.kernel.org/patch/9434133/
> and the commit ID are:
> 9863f279c1d48e366a179e76683247f239b30975
> 0abcfafea32452f1d07901320efa8c17470dbeed
> ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
> e9d10c536b26732d38d59fa3639b85bcd819837e
> 60478aead82d761c71a2a402b3fd2817af9e57ac
> 21f57eb38129042d2910d1e9b5fd36f3eea93637
>
> And I got the below error when I attached one  USB3.0 disk (Just USB2.0 disk 
> can work). From above 6 patches, it seems remove dma_set_coherent_mask from 
> file drivers/usb/dwc3/host.c.
>
> usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
> [   16.224264] usb 4-1: device descriptor read/8, error -61
> [   16.336179] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
> [   16.360257] usb 4-1: device descriptor read/8, error -61
> [   16.652196] usb 4-1: new SuperSpeed USB device number 3 using xhci-hcd
> [   16.676256] usb 4-1: device descriptor read/8, error -61
> [   16.788179] usb 4-1: new SuperSpeed USB device number 3 using xhci-hcd
> [   16.812255] usb 4-1: device descriptor read/8, error -61
>
> So, how to handle this issue?

oh, it's the DMA thing. We have patches going to next for this. Arnd, do
you know if next has all missing pieces? There was something pending on
XHCI IIRC, right?

(keeping context below)

> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com] 
> Sent: Monday, December 05, 2016 7:00 PM
> To: Jerry Huang ; st...@rowland.harvard.edu; 
> linux-usb@vger.kernel.org; Mathias Nyman 
> Cc: Sriram Dash 
> Subject: RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
>
>
> (no top-posting, please)
>
> Hi,
>
> it helps if you include maintainers for correct drivers. 
> scripts/get_maintainer.pl helps a lot.
>
> Jerry Huang  writes:
>> And I tested USB2.0 disk, with Sriram's 6 patches, it works well. So Just 
>> USB3.0 can't work.
>>
>> BTW,
>> The board with USB3.0 DWC3 controller and the USB3.0 disk work well with 
>> Linux-4.1.8.
>
> alright, in that case you can bisect. Please do so and find the first commit 
> when this started happening.
>
>> -Original Message-
>> From: Jerry Huang
>> Sent: Monday, December 05, 2016 6:11 PM
>> To: st...@rowland.harvard.edu; linux-usb@vger.kernel.org
>> Cc: Sriram Dash 
>> Subject: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
>>
>> Hi, Guys,
>> 1. I tested the USB3.0 DWC3 with latest Linux-4.9-rc7 on LS1043ardb board.
>> But I got the below errors, this error is returned from dma_supported(dev, 
>> mask) while running " dma_set_mask_and_coherent" in function " 
>> xhci_plat_probe".
>> ...
>> [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
>> [0.762438] xhci-hcd: probe of xhci-hcd.1.auto failed with error -5
>> [0.768712] xhci-hcd: probe of xhci-hcd.2.auto failed with error -5
>> [0.775049] usbcore: registered new interface driver usb-storage
>> ...
>>
>> 2. Then, I applied 6 patches from Sriram:
>> https://patchwork.kernel.org/patch/9434163/
>> https://patchwork.kernel.org/patch/9434155/
>> https://patchwork.kernel.org/patch/9434131/
>> https://patchwork.kernel.org/patch/9434165/
>> https://patchwork.kernel.org/patch/9434167/
>> https://patchwork.kernel.org/patch/9434133/
>>
>> however, I got another error as below shows when I attach one USB disk to 
>> this board.
>> It seems USB device return the 8 bytes descriptor, but all 8 byte data 
>> driver read  are zero from the buffer received.
>> Has any comment for this issue?
>>
>> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd [  
>> 164.323396] usb 2-1: device descriptor read/8, error -61
>
> hmm, connection refused. Mathias, any idea?
>
> BTW, are you sure this board worked with *upstream* (as in, Linus' tree)
> v4.1 or were you using some vendor kernel which is based off of v4.1?
>
> Care to check v4.8, v4.7 and v4.6?



-- 
balbi


signature.asc
Description: PGP signature

RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Jerry Huang]

Hi, Balbi,
Sorry for later responding.
I tested Linux 4.8, 4.7, 4.6 and 4.5, has the same issue:
[0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5

Then I found one patch (dwc3 initiated xhci probe problem in arm64 4.4 kernel 
due to DMA setup) as below link, and I applied this patch to Linux-4.5, the 
USB3.0 worked well! Therefore I applied this patch to Linux-4.9-rc7, and the 
USB3.0 works well, too! Which used of_dma_configure(>dev, 
dwc->dev->of_node) to set dma.
https://patches.linaro.org/patch/65892/ 

However, in Linux-4.9-rc8, I found these 6 patches applied:
https://patchwork.kernel.org/patch/9434163/
https://patchwork.kernel.org/patch/9434155/
https://patchwork.kernel.org/patch/9434131/
https://patchwork.kernel.org/patch/9434165/
https://patchwork.kernel.org/patch/9434167/
https://patchwork.kernel.org/patch/9434133/
and the commit ID are:
9863f279c1d48e366a179e76683247f239b30975
0abcfafea32452f1d07901320efa8c17470dbeed
ec3a36d441f2adcb8a0d3f6534ac488f2202c87a
e9d10c536b26732d38d59fa3639b85bcd819837e
60478aead82d761c71a2a402b3fd2817af9e57ac
21f57eb38129042d2910d1e9b5fd36f3eea93637

And I got the below error when I attached one  USB3.0 disk (Just USB2.0 disk 
can work). From above 6 patches, it seems remove dma_set_coherent_mask from 
file drivers/usb/dwc3/host.c.

usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
[   16.224264] usb 4-1: device descriptor read/8, error -61
[   16.336179] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
[   16.360257] usb 4-1: device descriptor read/8, error -61
[   16.652196] usb 4-1: new SuperSpeed USB device number 3 using xhci-hcd
[   16.676256] usb 4-1: device descriptor read/8, error -61
[   16.788179] usb 4-1: new SuperSpeed USB device number 3 using xhci-hcd
[   16.812255] usb 4-1: device descriptor read/8, error -61

So, how to handle this issue?

Best Regards
Jerry Huang

-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com] 
Sent: Monday, December 05, 2016 7:00 PM
To: Jerry Huang ; st...@rowland.harvard.edu; 
linux-usb@vger.kernel.org; Mathias Nyman 
Cc: Sriram Dash 
Subject: RE: USB3.0 DWC3 can't work with latest Linux-4.9.rc7


(no top-posting, please)

Hi,

it helps if you include maintainers for correct drivers. 
scripts/get_maintainer.pl helps a lot.

Jerry Huang  writes:
> And I tested USB2.0 disk, with Sriram's 6 patches, it works well. So Just 
> USB3.0 can't work.
>
> BTW,
> The board with USB3.0 DWC3 controller and the USB3.0 disk work well with 
> Linux-4.1.8.

alright, in that case you can bisect. Please do so and find the first commit 
when this started happening.

> -Original Message-
> From: Jerry Huang
> Sent: Monday, December 05, 2016 6:11 PM
> To: st...@rowland.harvard.edu; linux-usb@vger.kernel.org
> Cc: Sriram Dash 
> Subject: USB3.0 DWC3 can't work with latest Linux-4.9.rc7
>
> Hi, Guys,
> 1. I tested the USB3.0 DWC3 with latest Linux-4.9-rc7 on LS1043ardb board.
> But I got the below errors, this error is returned from dma_supported(dev, 
> mask) while running " dma_set_mask_and_coherent" in function " 
> xhci_plat_probe".
> ...
> [0.756166] xhci-hcd: probe of xhci-hcd.0.auto failed with error -5
> [0.762438] xhci-hcd: probe of xhci-hcd.1.auto failed with error -5
> [0.768712] xhci-hcd: probe of xhci-hcd.2.auto failed with error -5
> [0.775049] usbcore: registered new interface driver usb-storage
> ...
>
> 2. Then, I applied 6 patches from Sriram:
> https://patchwork.kernel.org/patch/9434163/
> https://patchwork.kernel.org/patch/9434155/
> https://patchwork.kernel.org/patch/9434131/
> https://patchwork.kernel.org/patch/9434165/
> https://patchwork.kernel.org/patch/9434167/
> https://patchwork.kernel.org/patch/9434133/
>
> however, I got another error as below shows when I attach one USB disk to 
> this board.
> It seems USB device return the 8 bytes descriptor, but all 8 byte data driver 
> read  are zero from the buffer received.
> Has any comment for this issue?
>
> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd [  
> 164.323396] usb 2-1: device descriptor read/8, error -61

hmm, connection refused. Mathias, any idea?

BTW, are you sure this board worked with *upstream* (as in, Linus' tree)
v4.1 or were you using some vendor kernel which is based off of v4.1?

Care to check v4.8, v4.7 and v4.6?

best

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

RE: [PATCH v13 00/10] usbip: exporting devices

[fx IWATA NOBUO]

Hello,

> Generally what this series does is just changing the initiator role.

Please note that this series 'adds' new operation.
Current (bind-and attach) operation is kept as it is.
New operation is available if the new daemon is started.

> 1) I would like to see some real numbers of performance difference not
> just "smoother motion" like described in [1]. Then we can see what's
> the real performance difference between this and simple web
> sockets/tcp tunnel
> Footnotes:
> 1 -
> https://www.mail-archive.com/linux-usb@vger.kernel.org/msg69028.html

Please note that userspace URBs transmission and WebSocket command/
daemon has been excluded at v7 of this set.
Currently this set is intended to use with tunneling proxy.

> 2) This series contains some fixes/improvements which in my opinion
> should be split into separate series on which this one may depend.

4 patches have been applied which are found developing this series.
usbip: adding names db to port operation
usbip: safe completion against unbind operation
usbip: event handler as one thread
usbip: deletion of incorrect socket descriptor checking

I remind your comments and will make new patches.

> 4) In most patches there are some mistakes which should be fixed
> before applying.

I will create v14.

Best Regards,

n.iwata
//
> -Original Message-
> From: Krzysztof Opasiak [mailto:k.opas...@samsung.com]
> Sent: Saturday, December 03, 2016 3:10 AM
> To: fx IWATA NOBUO; valentina.mane...@gmail.com; shuah...@samsung.com;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
> Cc: fx MICHIMURA TADAO; Krzysztof Opasiak
> Subject: Re: [PATCH v13 00/10] usbip: exporting devices
> 
> Dear all,
> 
> On 11/22/2016 07:48 AM, Nobuo Iwata wrote:
> > Dear all,
> >
> > This series of patches adds exporting device operation to USB/IP.
> >
> > NOTE:
> > This patch set modifies only userspace codes in tools/usb/usbip.
> >
> > 1. Goal
> >
> > 1-1) To give flexibility to direction of connection Using USB/IP in
> > internet, there can be two cases.
> > a) an application is inside firewall and devices are outside.
> > b) devices are inside firewall and an application is inside.
> > In case-a, import works because the connection is from inside.
> > In case-b, import doesn't works because the connection is from outside.
> > Connection from device side is needed. This patch set adds the
> > direction of connection establishment.
> >
> 
> This feature looks for me like a knife. It may be useful in some cases but
> you may also hurt your self or some one else quite easily.
> 
> > NOTE:
> > Directions of URBs requests and responses are not changed. Only
> > direction of connection establishment initiated with usbip command is
> > added to exsiting one.
> >
> 
> Generally what this series does is just changing the initiator role.
> 
> Classically Client connects to a server to get some device which is
> available.
> 
> This patch allows to leave your server waiting for new devices to be
> connected to it from a remote machine.
> 
> I see some points when it may be useful. For example you can start some
> virtual machine and connect different devices to it and check what's the
> system reaction.  This may be useful is you would like to test for example
> some malware if it's playing badly with some USB devices.
> 
> Of course you could do the same thing without this series but then you need
> to interact with the VM each time when you would like to connect and
> disconnect the device.
> 
> > 4. Combination with vUDC
> >
> > New operations work with vUDC. --device option specifies vUDC mode as
> > well as list operaion. With stub, connect and disconnect execute bind
> > and unbind internally. With vUDC, they do not execute bind and unbind.
> > They are done by UDC interface.
> >
> 
> If you combine what I wrote above with vUDC you can get quite nice
> automated testing laboratory for USB malware investigation as you can
> emulate any USB device quite easily and then simply attach it to VM.
> 
> > 5. Security consideration
> >
> > When application side daemon is not started, this patch set doesn't
> > affect exsiting security.
> >
> > Daemons accept following requests form network :
> > EXISTING) 'list --remote' and 'attach'
> > NEW) 'connect' and 'desconnect'
> >
> > TCP wrappers allows and/or denies network access. It is enabled when
> > the daemons are compiled with ./configure --with-tcp-wrappers.
> >
> > When the daemons are running with SSL or Secure WebSocket tunneling
> > proxy, the proxy can use client authentication with certificate files.
> >
> 
> There are also other security implications.
> 
> With this patch it's quite easy to leak some USB outside restricted
> company network.
> 
> Let's say that malicious employee has server and you run usbipa on it on
> port 9418 which is git (just example). Then he goes to his company
> connect his restricted USB license key or anything else to the computer
> and simply pass it using USB/IP to his remote 

Re: [PATCH 1/1] Fixed to checkpatch errors to usbtmc.c

[Greg Kroah-Hartman]

On Tue, Dec 06, 2016 at 02:57:00PM +0200, Ozgur Karatas wrote:
> Hello all,

This isn't needed in a changelog text.

> I will solve a checkpatch.pl script errors.

> drivers/usb/class/usbtmc.c:719: ERROR: else should follow close brace '}'
> drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
> drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
> drivers/usb/class/usbtmc.c:735: ERROR: space required after that ',' (ctx:VxV)
> drivers/usb/class/usbtmc.c:746: ERROR: else should follow close brace '}'
> drivers/usb/class/usbtmc.c:752: ERROR: space required after that ',' (ctx:VxV)
> drivers/usb/class/usbtmc.c:752: ERROR: space required after that ',' (ctx:VxV)
> drivers/usb/class/usbtmc.c:1403: ERROR: space required before the open 
> parenthesis '('
> total: 8 errors, 25 warnings, 1558 lines checked

Please break this up into one patch per "type" of fix please.

> Regards,

This isn't needed either :)

thanks,

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