[PATCH] usb: gadgetfs: restrict upper bound on device configuration size

[Greg Kroah-Hartman]

Andrey Konovalov reported that we were not properly checking the upper
limit before of a device configuration size before calling
memdup_user(), which could cause some problems.

So set the upper limit to PAGE_SIZE * 4, which should be good enough for
all devices.

Reported-by: Andrey Konovalov 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
 inode.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Felipe, any objection for me to take this through my tree now?

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index bd82dd12deff..298886b40361 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -1762,7 +1762,8 @@ dev_config (struct file *fd, const char __user *buf, 
size_t len, loff_t *ptr)
}
spin_unlock_irq(>lock);
 
-   if (len < (USB_DT_CONFIG_SIZE + USB_DT_DEVICE_SIZE + 4))
+   if ((len < (USB_DT_CONFIG_SIZE + USB_DT_DEVICE_SIZE + 4)) ||
+   (len > PAGE_SIZE * 4))
return -EINVAL;
 
/* we might need to change message format someday */
--
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: pxa27x: fix warnings and errors

[Greg Kroah-Hartman]

On Mon, Dec 05, 2016 at 10:18:58PM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> This patch will fix the checkpatch.pl warnings and errors.
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-usb@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/usb/host/ohci-pxa27x.c | 28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> index 79efde8f..c50a767 100644
> --- a/drivers/usb/host/ohci-pxa27x.c
> +++ b/drivers/usb/host/ohci-pxa27x.c
> @@ -106,7 +106,8 @@
>  #define UHCHIE_UPS2IE(1 << 12)   /* Power Sense Port2 IntEn */
>  #define UHCHIE_UPS1IE(1 << 11)   /* Power Sense Port1 IntEn */
>  #define UHCHIE_TAIE  (1 << 10)   /* HCI Interface Transfer Abort
> -Interrupt Enable*/
> +  * Interrupt Enable
> +  */
>  #define UHCHIE_HBAIE (1 << 8)/* HCI Buffer Active IntEn */
>  #define UHCHIE_RWIE  (1 << 7)/* Remote Wake-up IntEn */
>  
> @@ -128,14 +129,14 @@ struct pxa27x_ohci {
>  #define to_pxa27x_ohci(hcd)  (struct pxa27x_ohci *)(hcd_to_ohci(hcd)->priv)
>  
>  /*
> -  PMM_NPS_MODE -- PMM Non-power switching mode
> -  Ports are powered continuously.
> -
> -  PMM_GLOBAL_MODE -- PMM global switching mode
> -  All ports are powered at the same time.
> -
> -  PMM_PERPORT_MODE -- PMM per port switching mode
> -  Ports are powered individually.
> + * PMM_NPS_MODE -- PMM Non-power switching mode
> + * Ports are powered continuously.
> + *
> + * PMM_GLOBAL_MODE -- PMM global switching mode
> + * All ports are powered at the same time.
> + *
> + * PMM_PERPORT_MODE -- PMM per port switching mode
> + * Ports are powered individually.
>   */
>  static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *pxa_ohci, int mode)
>  {
> @@ -157,10 +158,7 @@ static int pxa27x_ohci_select_pmm(struct pxa27x_ohci 
> *pxa_ohci, int mode)
>   uhcrhdb |= (0x7<<17);
>   break;
>   default:
> - printk( KERN_ERR
> - "Invalid mode %d, set to non-power switch mode.\n",
> - mode );
> -
> + pr_err("Invalid mode %d,set to non-power switch mode.\n", mode);

Use dev_err() please.

>   uhcrhda |= RH_A_NPS;
>   }
>  
> @@ -541,7 +539,7 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
>  
>  
>   if (time_before(jiffies, ohci->next_statechange))
> - msleep(5);
> + usleep_range(5000, 1);

This is totally wrong :(


>   ohci->next_statechange = jiffies;
>  
>   ret = ohci_suspend(hcd, do_wakeup);
> @@ -561,7 +559,7 @@ static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
>   int status;
>  
>   if (time_before(jiffies, ohci->next_statechange))
> - msleep(5);
> + usleep_range(5000, 1);

As is this :(

Did you not check these changes?

--
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: pxa27x: fix warnings and errors

[Greg Kroah-Hartman]

On Mon, Dec 05, 2016 at 10:18:58PM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> This patch will fix the checkpatch.pl warnings and errors.

what warnings and errors?  Please always be specific.

And don't send a single patch to fix everything up, break it up into
logical types of fixes please.

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: usb:xhci: support disable usb2 LPM Remote Wakeup

[Greg Kroah-Hartman]

On Tue, Dec 06, 2016 at 01:59:00PM +0700, Thang Q. Nguyen wrote:
> Hi,
> Do you have any feedback on this?
> 
> Thanks,
> Thang Q. Nguyen
> 
> On Sun, Dec 4, 2016 at 7:42 PM, Thang Q. Nguyen  wrote:

It has been 1 day, please relax, wait, and be patient.  If after 2 weeks
there has not been a response, then feel free to resend, but not after
just 1 day...

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: usb:xhci: support disable usb2 LPM Remote Wakeup

[Thang Q. Nguyen]

Hi,
Do you have any feedback on this?

Thanks,
Thang Q. Nguyen

On Sun, Dec 4, 2016 at 7:42 PM, Thang Q. Nguyen  wrote:
> From: Thang Nguyen 
>
> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
> device or host initiated via resume signaling; device-initiated resumes
> can be optionally enabled/disabled by software. This patch adds support
> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>
> Signed-off-by: Vu Nguyen 
> Signed-off-by: Thang Nguyen 
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>  drivers/usb/host/xhci-plat.c   | 3 +++
>  drivers/usb/host/xhci.c| 5 -
>  drivers/usb/host/xhci.h| 1 +
>  4 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 966885c..9b4cd14 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -25,6 +25,7 @@ Required properties:
>
>  Optional properties:
>- clocks: reference to a clock
> +  - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
>- usb3-lpm-capable: determines if platform is USB3 LPM capable
>
>  Example:
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index ed56bf9..15c540d 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -220,6 +220,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
> goto disable_clk;
> }
>
> +   if (device_property_read_bool(>dev, "usb2-rwe-disable"))
> +   xhci->quirks |= XHCI_RWE_DISABLE;
> +
> if (device_property_read_bool(>dev, "usb3-lpm-capable"))
> xhci->quirks |= XHCI_LPM_SUPPORT;
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 1a4ca02..f804868 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4183,7 +4183,10 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
> }
>
> pm_val &= ~PORT_HIRD_MASK;
> -   pm_val |= PORT_HIRD(hird) | PORT_RWE | 
> PORT_L1DS(udev->slot_id);
> +   if ((xhci->quirks & XHCI_RWE_DISABLE) && (xhci->hci_version 
> <= 0x100))
> +   pm_val |= PORT_HIRD(hird) | PORT_L1DS(udev->slot_id);
> +   else
> +   pm_val |= PORT_HIRD(hird) | PORT_RWE | 
> PORT_L1DS(udev->slot_id);
> writel(pm_val, pm_addr);
> pm_val = readl(pm_addr);
> pm_val |= PORT_HLE;
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index f945380..2b9bc33 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1656,6 +1656,7 @@ struct xhci_hcd {
>  #define XHCI_SSIC_PORT_UNUSED  (1 << 22)
>  #define XHCI_NO_64BIT_SUPPORT  (1 << 23)
>  #define XHCI_MISSING_CAS   (1 << 24)
> +#define XHCI_RWE_DISABLE   (1 << 25)
> unsigned intnum_active_eps;
> unsigned intlimit_active_eps;
> /* There are two roothubs to keep track of bus suspend info for */
> --
> 2.7.4
>



-- 

Thang Q. Nguyen| Staff SW Eng.

C: +849.7684.7606 | O: +848.3770.0640

F: +848.3770.0641  | tqngu...@apm.com
--
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 05/10] usbip: exporting devices: modifications to daemon

[fx IWATA NOBUO]

Hello,

> > usbip_driver_ has widely used as function names and file
> > names for host side abstraction.
> > If they were usbip_host_, I can use usbip_driver_open/close
> > for both host(stub/vudc) and vhci.
> 
> usbip_host() is not correct name to use for both stub and vudc as from
> USB point of view stub is on a host but vudc is on a device side

OK.

> maybe a kind of usbipd_backed_init() would be more suitable?

Naming problem again but I recognize usbip_open_driver() is worse than
connect.
I think the word 'backend' has wide meaning and more strict word is
better.

init   driver = _driver; NA
( )driver = _driver;   NA
open   usbip_driver_open  usbip_vhci_driver_open
close  usbip_driver_close usbip_vhci_driver_close

Here, I'd like to use word 'driver'.
I searched analogy meta_, super_ in kernel.

How about usbip_meta_driver_init/open/close()?

> >> usbip_update_driver() is t totally unrelated to what this assignment
> >> really does.
> So as above. I suggest to call it usbipd_backend() instead of driver.

Please, let me know good verb representing 'driver = _driver'.

> >>> + memset(, 0, sizeof(req));
> >>> + memset(, 0, sizeof(reply));
> >>
> >> You don't need to 0 the reply.
> >
> > This is moved from usbipd.c.
> > I will remove.

I found the 'reply' is not used so I will remove the definition too.

> > PACK_OP_PACK   1
> > PACK_OP_UNPACK 0
> 
> Please do this outside this set as it's totally unrelated and just
> mark this series as depending on that change. It's a good idea to
> change this in all files not only in those you touch.

OK. I will.

Thank you for your help,

n.iwata
//
> -Original Message-
> From: Krzysztof Opasiak [mailto:k.opas...@samsung.com]
> Sent: Friday, December 02, 2016 11:20 PM
> To: fx IWATA NOBUO; valentina.mane...@gmail.com; shuah...@samsung.com;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
> Cc: fx MICHIMURA TADAO
> Subject: Re: [PATCH v13 05/10] usbip: exporting devices: modifications to
> daemon
> 
> 
> 
> On 12/02/2016 09:36 AM, fx IWATA NOBUO wrote:
> > Hello,
> >
> >>> -static int do_accept(int listenfd)
> >>> +static int do_accept(int listenfd, char *host, char *port)
> >
> >> In my opinion you should pass also the size of those arrays to this
> >> function instead of hardcoding them like this.
> >
> > OK. I will add them.
> >
> >>> - if (usbip_driver_open(driver))
> >>> + if (usbip_open_driver())
> >>
> >> What's the purpose of this function?
> >
> >>> - usbip_driver_close(driver);
> >>> + usbip_close_driver();
> >>
> >> As above? Why not make this a global variable and leave those calls
> >> as they were?
> >
> > usbip_driver_open/close - host side abstraction including stub and vudc.
> >
> > usbip_open/close_driver - abstraction both host(stub/vudc) and vhci.
> >
> > usbip_driver_ has widely used as function names and file
> > names for host side abstraction.
> > If they were usbip_host_, I can use usbip_driver_open/close
> > for both host(stub/vudc) and vhci.
> 
> usbip_host() is not correct name to use for both stub and vudc as from
> USB point of view stub is on a host but vudc is on a device side
> 
> maybe a kind of usbipd_backed_init() would be more suitable?
> 
> >
> >> I totally don't understand why those functions exist?
> >> Their names are very confusing and they don't implement any
> >> additional functionality.
> >
> > The abstraction is shared with patch 7/10.
> >
> >>> - driver = _driver;
> >>> + usbip_update_driver();
> >>
> >> usbip_update_driver() is t totally unrelated to what this assignment
> >> really does.
> >>
> >> It changes the backend from stub driver to vudc not updating the driver.
> >
> > It used to make symmetric device side and application side.
> > In device side, it switches to device driver.
> > In application side, no operation.
> >
> 
> So as above. I suggest to call it usbipd_backend() instead of driver.
> 
> >> usbip_dev.c is not a best name for this file. It causes confusion (at
> >> least to me) as I don't know to what the dev part is related, usb
> >> device, device (stub side) or what?
> >
> > Device side.
> 
> It's misleading as in USB we have host and device and this file is used
> on both (stub and vudc).
> 
> >
> >>> + memset(, 0, sizeof(req));
> >>> + memset(, 0, sizeof(reply));
> >>
> >> You don't need to 0 the reply.
> >
> > This is moved from usbipd.c.
> > I will remove.
> >
> >>> + PACK_OP_DEVLIST_REPLY(1, );
> >> Could you please make the defines for 1 and 0 in this macro?
> >> As far as I understand the code it means pack and unpack but it would
> >> be much more readable if we have a define for this.
> >
> > Here's the list in the original code.
> >
> > usbip_attach.c: PACK_OP_IMPORT_REQUEST(0, );
> > usbip_attach.c: PACK_OP_IMPORT_REPLY(0, );
> > usbip_list.c:   PACK_OP_DEVLIST_REPLY(0, );
> > usbip_network.c:PACK_OP_COMMON(1, _common);
> > usbip_network.c:PACK_OP_COMMON(0, 

RE: [PATCH 01/12] phy: rcar-gen3-usb2: Replace the deprecated extcon API

[Yoshihiro Shimoda]

Hi,

> From: Chanwoo Choi
> Sent: Wednesday, November 30, 2016 2:57 PM
> 
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_set_state_sync()
> 
> Signed-off-by: Chanwoo Choi 

Thank you for the patch!

Acked-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda


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

RE: [PATCH 12/12] usb: renesas_usbhs: Replace the deprecated extcon API

[Yoshihiro Shimoda]

Hi,

> From: Chanwoo Choi
> Sent: Wednesday, November 30, 2016 2:58 PM
> 
> This patch replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> 
> Signed-off-by: Chanwoo Choi 

Thank you for the patch!

Acked-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

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

[PATCH] usbip: add missing compile time generated files to .gitignore

[Shuah Khan]

Add the following files to .gitignore

compile
libsrc/libusbip_la-sysfs_utils.lo
libsrc/libusbip_la-usbip_device_driver.lo
libsrc/libusbip_la-usbip_host_common.lo

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/.gitignore | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/usb/usbip/.gitignore b/tools/usb/usbip/.gitignore
index 9aad9e3..03b892c 100644
--- a/tools/usb/usbip/.gitignore
+++ b/tools/usb/usbip/.gitignore
@@ -2,6 +2,7 @@ Makefile
 Makefile.in
 aclocal.m4
 autom4te.cache/
+compile
 config.guess
 config.h
 config.h.in
@@ -21,7 +22,10 @@ src/Makefile.in
 stamp-h1
 libsrc/libusbip.la
 libsrc/libusbip_la-names.lo
+libsrc/libusbip_la-sysfs_utils.lo
 libsrc/libusbip_la-usbip_common.lo
+libsrc/libusbip_la-usbip_device_driver.lo
+libsrc/libusbip_la-usbip_host_common.lo
 libsrc/libusbip_la-usbip_host_driver.lo
 libsrc/libusbip_la-vhci_driver.lo
 src/usbip
-- 
2.7.4

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

Re: [PATCH 01/12] phy: rcar-gen3-usb2: Replace the deprecated extcon API

[Chanwoo Choi]

Hi Kishon,

Could you review and pick the patch1/2 for phy driver?

Best Regards,
Chanwoo Choi

On 2016년 11월 30일 14:57, Chanwoo Choi wrote:
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_set_state_sync()
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/phy/phy-rcar-gen3-usb2.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c 
> b/drivers/phy/phy-rcar-gen3-usb2.c
> index bd2430d7339c..7f8081f157f4 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -93,11 +93,11 @@ static void rcar_gen3_phy_usb2_work(struct work_struct 
> *work)
>work);
>  
>   if (ch->extcon_host) {
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, true);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB, false);
>   } else {
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, false);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB, true);
>   }
>  }
>  
> 

--
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 03/12] power_supply: axp288_charger: Replace the extcon API

[Chanwoo Choi]

Hi Sebastian,

Could you please review and pick the patch3/4 for power-supply driver?

Best Regards,
Chanwoo Choi

On 2016년 11월 30일 14:57, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/power/supply/axp288_charger.c | 51 
> +--
>  1 file changed, 13 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/power/supply/axp288_charger.c 
> b/drivers/power/supply/axp288_charger.c
> index 75b8e0c7402b..1115052e9a69 100644
> --- a/drivers/power/supply/axp288_charger.c
> +++ b/drivers/power/supply/axp288_charger.c
> @@ -581,15 +581,15 @@ static void axp288_charger_extcon_evt_worker(struct 
> work_struct *work)
>   bool old_connected = info->cable.connected;
>  
>   /* Determine cable/charger type */
> - if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_SDP) > 0) {
> + if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) {
>   dev_dbg(>pdev->dev, "USB SDP charger  is connected");
>   info->cable.connected = true;
>   info->cable.chg_type = POWER_SUPPLY_TYPE_USB;
> - } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_CDP) > 0) {
> + } else if (extcon_get_state(edev, EXTCON_CHG_USB_CDP) > 0) {
>   dev_dbg(>pdev->dev, "USB CDP charger is connected");
>   info->cable.connected = true;
>   info->cable.chg_type = POWER_SUPPLY_TYPE_USB_CDP;
> - } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_DCP) > 0) {
> + } else if (extcon_get_state(edev, EXTCON_CHG_USB_DCP) > 0) {
>   dev_dbg(>pdev->dev, "USB DCP charger is connected");
>   info->cable.connected = true;
>   info->cable.chg_type = POWER_SUPPLY_TYPE_USB_DCP;
> @@ -686,7 +686,7 @@ static int axp288_charger_handle_otg_evt(struct 
> notifier_block *nb,
>   struct axp288_chrg_info *info =
>   container_of(nb, struct axp288_chrg_info, otg.id_nb);
>   struct extcon_dev *edev = info->otg.cable;
> - int usb_host = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
> + int usb_host = extcon_get_state(edev, EXTCON_USB_HOST);
>  
>   dev_dbg(>pdev->dev, "external connector USB-Host is %s\n",
>   usb_host ? "attached" : "detached");
> @@ -841,33 +841,27 @@ static int axp288_charger_probe(struct platform_device 
> *pdev)
>   /* Register for extcon notification */
>   INIT_WORK(>cable.work, axp288_charger_extcon_evt_worker);
>   info->cable.nb.notifier_call = axp288_charger_handle_cable_evt;
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_SDP,
> - >cable.nb);
> + ret = devm_extcon_register_notifier(>dev, info->cable.edev,
> + EXTCON_CHG_USB_SDP, >cable.nb);
>   if (ret) {
>   dev_err(>pdev->dev,
>   "failed to register extcon notifier for SDP %d\n", ret);
>   return ret;
>   }
>  
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_CDP,
> - >cable.nb);
> + ret = devm_extcon_register_notifier(>dev, info->cable.edev,
> + EXTCON_CHG_USB_CDP, >cable.nb);
>   if (ret) {
>   dev_err(>pdev->dev,
>   "failed to register extcon notifier for CDP %d\n", ret);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_SDP, >cable.nb);
>   return ret;
>   }
>  
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_DCP,
> - >cable.nb);
> + ret = devm_extcon_register_notifier(>dev, info->cable.edev,
> + EXTCON_CHG_USB_DCP, >cable.nb);
>   if (ret) {
>   dev_err(>pdev->dev,
>   "failed to register extcon notifier for DCP %d\n", ret);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_SDP, >cable.nb);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_CDP, >cable.nb);
>   return ret;
>   }
>  
> @@ -887,13 +881,13 @@ static int axp288_charger_probe(struct platform_device 
> *pdev)
>   /* Register for OTG notification */
>   INIT_WORK(>otg.work, axp288_charger_otg_evt_worker);
>   info->otg.id_nb.notifier_call = axp288_charger_handle_otg_evt;
> - ret = extcon_register_notifier(info->otg.cable, EXTCON_USB_HOST,
> ->otg.id_nb);
> + ret = devm_extcon_register_notifier(>dev, info->otg.cable,
> + EXTCON_USB_HOST, >otg.id_nb);
>   if (ret)

Re: [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier

[Chanwoo Choi]

On 2016년 12월 06일 01:32, Bin Liu wrote:
> On Wed, Nov 30, 2016 at 09:45:03AM +0100, Maxime Ripard wrote:
>> On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote:
>>> This patch just uses the resource-managed extcon API when registering
>>> the extcon notifier.
>>>
>>> Signed-off-by: Chanwoo Choi 
>>
>> Acked-by: Maxime Ripard 
> 
> It would be ideal if the subject was "usb: musb: sunxi: ...".
> 
> Acked-by: Bin Liu 
> 

Thanks for the review. I'll change the subject.

-- 
Best Regards,
Chanwoo Choi
--
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 FIX] usb: core: usbport: Use proper LED API to fix potential crash

[Rafał Miłecki]

From: Rafał Miłecki 

Calling brightness_set manually isn't safe as some LED drivers don't
implement this callback. The best idea is to just use a proper helper
which will fallback to the brightness_set_blocking callback if needed.

This fixes:
[ 1461.761528] Unable to handle kernel NULL pointer dereference at virtual 
address 
(...)
[ 1462.117049] Backtrace:
[ 1462.119521] [] (usbport_trig_port_store [ledtrig_usbport]) from 
[] (dev_attr_store+0x20/0x2c)
[ 1462.129826]  r7:dcabc7c0 r6:dee0ff80 r5:0002 r4:bf228164
[ 1462.135511] [] (dev_attr_store) from [] 
(sysfs_kf_write+0x48/0x4c)
[ 1462.143459]  r5:0002 r4:c023f738
[ 1462.147049] [] (sysfs_kf_write) from [] 
(kernfs_fop_write+0xf8/0x1f8)
[ 1462.155258]  r5:0002 r4:df4a1000
[ 1462.158850] [] (kernfs_fop_write) from [] 
(__vfs_write+0x34/0x120)
[ 1462.166800]  r10: r9:dee0e000 r8:c000fc24 r7:0002 r6:dee0ff80 
r5:c01689c0
[ 1462.174660]  r4:df727a80
[ 1462.177204] [] (__vfs_write) from [] 
(vfs_write+0xac/0x170)
[ 1462.184543]  r9:dee0e000 r8:c000fc24 r7:dee0ff80 r6:b6f092d0 r5:df727a80 
r4:0002
[ 1462.192319] [] (vfs_write) from [] (SyS_write+0x4c/0xa8)
[ 1462.199396]  r9:dee0e000 r8:c000fc24 r7:0002 r6:b6f092d0 r5:df727a80 
r4:df727a80
[ 1462.207174] [] (SyS_write) from [] 
(ret_fast_syscall+0x0/0x3c)
[ 1462.214774]  r7:0004 r6: r5: r4:
[ 1462.220456] Code: bad PC value
[ 1462.223560] ---[ end trace 676638a3a12c7a56 ]---

Reported-by: Ralph Sennhauser 
Signed-off-by: Rafał Miłecki 
Fixes: 0f247626cbb ("usb: core: Introduce a USB port LED trigger")
Cc: sta...@vger.kernel.org # 4.9+
---
Hi Greg,

I'm aware this may too late for 4.9 so I added Cc stable entry. I guess it's OK
if you pick it to usb-next.
---
 drivers/usb/core/ledtrig-usbport.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/core/ledtrig-usbport.c 
b/drivers/usb/core/ledtrig-usbport.c
index 3ed5162..1713248 100644
--- a/drivers/usb/core/ledtrig-usbport.c
+++ b/drivers/usb/core/ledtrig-usbport.c
@@ -74,8 +74,7 @@ static void usbport_trig_update_count(struct 
usbport_trig_data *usbport_data)
 
usbport_data->count = 0;
usb_for_each_dev(usbport_data, usbport_trig_usb_dev_check);
-   led_cdev->brightness_set(led_cdev,
-usbport_data->count ? LED_FULL : LED_OFF);
+   led_set_brightness(led_cdev, usbport_data->count ? LED_FULL : LED_OFF);
 }
 
 /***
@@ -228,12 +227,12 @@ static int usbport_trig_notify(struct notifier_block *nb, 
unsigned long action,
case USB_DEVICE_ADD:
usbport_trig_add_usb_dev_ports(usb_dev, usbport_data);
if (observed && usbport_data->count++ == 0)
-   led_cdev->brightness_set(led_cdev, LED_FULL);
+   led_set_brightness(led_cdev, LED_FULL);
return NOTIFY_OK;
case USB_DEVICE_REMOVE:
usbport_trig_remove_usb_dev_ports(usbport_data, usb_dev);
if (observed && --usbport_data->count == 0)
-   led_cdev->brightness_set(led_cdev, LED_OFF);
+   led_set_brightness(led_cdev, LED_OFF);
return NOTIFY_OK;
}
 
-- 
2.10.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] Add DT bindings documentation for Synopsys UDC driver

[Rob Herring]

On Wed, Nov 30, 2016 at 11:35:09AM +0530, Raviteja Garimella wrote:
> This patch adds documentation for Synopsis Designware Cores AHB
> Subsystem Device Controller (UDC).
> 
> Signed-off-by: Raviteja Garimella 
> ---
>  .../devicetree/bindings/usb/snps,dw-ahb-udc.txt| 29 
> ++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt 
> b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> new file mode 100644
> index 000..64e1fbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> @@ -0,0 +1,29 @@
> +Synopsys USB Device controller.
> +
> +The device node is used for Synopsys Designware Cores AHB
> +Subsystem Device Controller (UDC).
> +
> +Required properties:
> + - compatible: should be "snps,dw-ahbudc"

Needs an SoC specific compatible string.

> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> + - phy-names: name of phy node. Must be usb2drd.

A name is pointless when there's only 1 phy. Is this a device or dual 
role device(DRD)?

> + - extcon: phandle to the extcon device

I don't think extcon should be required. If this is UDC only, I'm not 
sure why you'd need it.

> +
> +Example:
> +
> + usbdrd_phy: phy@6501c000 {
> + #phy-cells = <0>;
> + compatible = "brcm,ns2-drd-phy";
> + reg = <0x6600 0x1000>,
> + }
> +
> + udc_dwc: usb@664e {
> + compatible = "snps,dw-ahb-udc";

Doesn't match above.

> + reg = <0x664e 0x2000>;
> + interrupts = ;
> + phys = <_phy>;
> + phy-names = "usb2drd";
> + extcon = <_phy>";

You are already describing the phy connection, you shouldn't need both.

> + };
> -- 
> 2.1.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] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

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.

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

[PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

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 
---
 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)
-- 
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 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
> Read of size 2 by task syz-executor0/22994
> CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  88006df06a18 81f96aba e0528500 11000dbe0cd6
>  ed000dbe0cce 88006df068f0 41b58ab3 8598b4c8
>  81f96828 11000dbe0ccd 88006df06708 88006df06748
> Call Trace:
>   [  201.343209]  [< inline >] __dump_stack lib/dump_stack.c:15
>   [  201.343209]  [] dump_stack+0x292/0x398
> lib/dump_stack.c:51
>  [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
>  [< inline >] print_address_description mm/kasan/report.c:197
>  [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
>  [< inline >] kasan_report mm/kasan/report.c:306
>  [] __asan_report_load_n_noabort+0x3a/0x40
> mm/kasan/report.c:337
>  [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298
>  [] gadgetfs_setup+0x208a/0x20e0
> drivers/usb/gadget/legacy/inode.c:1368
>  [] dummy_timer+0x11f0/0x36d0
> drivers/usb/gadget/udc/dummy_hcd.c:1858
>  [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
>  [< inline >] expire_timers kernel/time/timer.c:1348
>  [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
>  [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
>  [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
>  [< inline >] invoke_softirq kernel/softirq.c:364
>  [] irq_exit+0x19e/0x1d0 kernel/softirq.c:405
>  [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
>  [] smp_apic_timer_interrupt+0x7b/0xa0
> arch/x86/kernel/apic/apic.c:960
>  [] apic_timer_interrupt+0x8c/0xa0
> arch/x86/entry/entry_64.S:489
>   [  201.343209]  [] ?
> _raw_spin_unlock_irqrestore+0x119/0x1a0
>  [] try_to_wake_up+0x174/0x1160 kernel/sched/core.c:2099
>  [< inline >] wake_up_process kernel/sched/core.c:2165
>  [] wake_up_q+0x8a/0xe0 kernel/sched/core.c:469
>  [] futex_wake+0x5be/0x6c0 kernel/futex.c:1453
>  [] do_futex+0x11bd/0x1f00 kernel/futex.c:3219
>  [< inline >] SYSC_futex kernel/futex.c:3275
>  [] SyS_futex+0x2fc/0x400 kernel/futex.c:3243
>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2

Can you test whether the patch below fixes this problem?

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;
 

--
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/1] net: usb: set error code when usb_alloc_urb fails

[David Miller]

From: Pan Bian 
Date: Sat,  3 Dec 2016 19:24:48 +0800

> In function lan78xx_probe(), variable ret takes the errno code on
> failures. However, when the call to usb_alloc_urb() fails, its value
> will keeps 0. 0 indicates success in the context, which is inconsistent
> with the execution result. This patch fixes the bug, assigning
> "-ENOMEM" to ret when usb_alloc_urb() returns a NULL pointer.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188771
> 
> Signed-off-by: Pan Bian 

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

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

[Jerry Huang]

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
[  164.435180] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[  164.459380] usb 2-1: device descriptor read/8, error -61
[  164.779230] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
[  164.803350] usb 2-1: device descriptor read/8, error -61
[  164.915181] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
[  164.943393] usb 2-1: device descriptor read/8, error -61
[  165.263231] usb 2-1: new SuperSpeed USB device number 4 using xhci-hcd
[  165.287352] usb 2-1: device descriptor read/8, error -61
[  165.399181] usb 2-1: new SuperSpeed USB device number 4 using xhci-hcd
[  165.427394] usb 2-1: device descriptor read/8, error -61
[  165.747231] usb 2-1: new SuperSpeed USB device number 5 using xhci-hcd
[  165.775347] usb 2-1: device descriptor read/8, error -61
[  165.887181] usb 2-1: new SuperSpeed USB device number 5 using xhci-hcd
[  165.915396] usb 2-1: device descriptor read/8, error -61
[  166.055194] usb usb2-port1: unable to enumerate USB device

Best Regards
Jerry Huang
--
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: used managed kasprintf

[David Laight]

From: Alexandre Belloni
> Sent: 02 December 2016 16:19
> On 02/12/2016 at 15:59:57 +, David Laight wrote :
> > From: Alexandre Belloni
> > > Sent: 01 December 2016 10:27
> > > Use devm_kasprintf instead of simple kasprintf to free the allocated 
> > > memory
> > > when needed.
> >
> > s/when needed/when the device is freed/
> >
> > > Suggested-by: Peter Rosin 
> > > Signed-off-by: Alexandre Belloni 
> > > ---
> > >  drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> > > b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > > index 45bc997d0711..aec72fe8273c 100644
> > > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> > > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > > @@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct 
> > > platform_device *pdev,
> > >   dev_err(>dev, "of_probe: name error(%d)\n", ret);
> > >   goto err;
> > >   }
> > > - ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
> > > + ep->ep.name = devm_kasprintf(>dev, GFP_KERNEL, "ep%d",
> > > +  ep->index);
> >
> > Acually why bother mallocing such a small string at all.
> > The maximum length is 12 bytes even if 'index' are unrestricted.
> >
> 
> IIRC, using statically allocated string is failing somewhere is the USB
> core but I don't remember all the details.

I can't imagine that changing ep->ep.name from 'char *' to 'char [12]' would
make any difference.

David

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

ERROR Transfer event for disabled endpoint or incorrect stream ring

[Nicolas Repentin]

Hi,

Using kernel 4.4 or more (4.8.11-1 on arch), an USB 3.0 external HDD dies all 
the time when writing on it.
Tested on multiple computers, multiples disks, and multiple external disks.

Only works on my 3.10 kernel (CentOS7).

On dmesg I got this :


[  117.372521] sd 2:0:0:0: [sdb] Synchronize Cache(10) failed: Result: 
hostbyte=0x07 driverbyte=0x00
[  117.776461] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[  117.802078] scsi host2: uas
[  117.803347] scsi 2:0:0:0: Direct-Access USB3.00203 
PQ: 0 ANSI: 6
[  124.401296] sd 2:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 
TB/2.73 TiB)
[  124.401306] sd 2:0:0:0: [sdb] 4096-byte physical blocks
[  124.401927] sd 2:0:0:0: [sdb] Write Protect is off
[  124.401935] sd 2:0:0:0: [sdb] Mode Sense: 53 00 00 08
[  124.402295] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[  124.476482]  sdb: sdb1 sdb2 sdb3
[  124.479096] sd 2:0:0:0: [sdb] Attached SCSI disk
[  163.496129] xhci_hcd :00:14.0: ERROR Transfer event for disabled 
endpoint or incorrect stream ring
[  163.496135] xhci_hcd :00:14.0: @00026a3e3f10   
0400 07088001
[  195.690550] sd 2:0:0:0: [sdb] tag#10 uas_eh_abort_handler 0 uas-tag 11 
inflight: CMD OUT
[  195.690560] sd 2:0:0:0: [sdb] tag#10 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 98 00 00 00 04 00 00 00
[  195.690765] sd 2:0:0:0: [sdb] tag#9 uas_eh_abort_handler 0 uas-tag 10 
inflight: CMD OUT
[  195.690772] sd 2:0:0:0: [sdb] tag#9 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
94 00 00 00 04 00 00 00
[  195.690849] sd 2:0:0:0: [sdb] tag#8 uas_eh_abort_handler 0 uas-tag 9 
inflight: CMD OUT
[  195.690854] sd 2:0:0:0: [sdb] tag#8 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
90 00 00 00 04 00 00 00
[  195.690922] sd 2:0:0:0: [sdb] tag#7 uas_eh_abort_handler 0 uas-tag 8 
inflight: CMD OUT
[  195.690927] sd 2:0:0:0: [sdb] tag#7 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
8c 00 00 00 04 00 00 00
[  195.690993] sd 2:0:0:0: [sdb] tag#6 uas_eh_abort_handler 0 uas-tag 7 
inflight: CMD OUT
[  195.690999] sd 2:0:0:0: [sdb] tag#6 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
88 00 00 00 04 00 00 00
[  195.691067] sd 2:0:0:0: [sdb] tag#5 uas_eh_abort_handler 0 uas-tag 6 
inflight: CMD OUT
[  195.691072] sd 2:0:0:0: [sdb] tag#5 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
84 00 00 00 04 00 00 00
[  195.691133] sd 2:0:0:0: [sdb] tag#4 uas_eh_abort_handler 0 uas-tag 5 
inflight: CMD OUT
[  195.691139] sd 2:0:0:0: [sdb] tag#4 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
80 00 00 00 04 00 00 00
[  195.691203] sd 2:0:0:0: [sdb] tag#3 uas_eh_abort_handler 0 uas-tag 4 
inflight: CMD OUT
[  195.691208] sd 2:0:0:0: [sdb] tag#3 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
7c 00 00 00 04 00 00 00
[  195.691268] sd 2:0:0:0: [sdb] tag#2 uas_eh_abort_handler 0 uas-tag 3 
inflight: CMD OUT
[  195.691274] sd 2:0:0:0: [sdb] tag#2 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
78 00 00 00 04 00 00 00
[  195.691336] sd 2:0:0:0: [sdb] tag#1 uas_eh_abort_handler 0 uas-tag 2 
inflight: CMD OUT
[  195.691341] sd 2:0:0:0: [sdb] tag#1 CDB: opcode=0x8a 8a 00 00 00 00 00 00 00 
74 00 00 00 04 00 00 00
[  195.691414] sd 2:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 28 
inflight: CMD OUT
[  195.691419] sd 2:0:0:0: [sdb] tag#27 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 70 00 00 00 04 00 00 00
[  195.691482] sd 2:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 27 
inflight: CMD OUT
[  195.691487] sd 2:0:0:0: [sdb] tag#26 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 6c 00 00 00 04 00 00 00
[  195.691554] sd 2:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 26 
inflight: CMD OUT
[  195.691563] sd 2:0:0:0: [sdb] tag#25 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 68 00 00 00 04 00 00 00
[  195.691622] sd 2:0:0:0: [sdb] tag#24 uas_eh_abort_handler 0 uas-tag 25 
inflight: CMD OUT
[  195.691631] sd 2:0:0:0: [sdb] tag#24 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 64 00 00 00 04 00 00 00
[  195.691763] sd 2:0:0:0: [sdb] tag#23 uas_eh_abort_handler 0 uas-tag 24 
inflight: CMD OUT
[  195.691776] sd 2:0:0:0: [sdb] tag#23 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 60 00 00 00 04 00 00 00
[  195.691849] sd 2:0:0:0: [sdb] tag#22 uas_eh_abort_handler 0 uas-tag 23 
inflight: CMD OUT
[  195.691855] sd 2:0:0:0: [sdb] tag#22 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 5c 00 00 00 04 00 00 00
[  195.691946] sd 2:0:0:0: [sdb] tag#21 uas_eh_abort_handler 0 uas-tag 22 
inflight: CMD OUT
[  195.691954] sd 2:0:0:0: [sdb] tag#21 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 58 00 00 00 04 00 00 00
[  195.692017] sd 2:0:0:0: [sdb] tag#20 uas_eh_abort_handler 0 uas-tag 21 
inflight: CMD OUT
[  195.692022] sd 2:0:0:0: [sdb] tag#20 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 54 00 00 00 04 00 00 00
[  195.692111] sd 2:0:0:0: [sdb] tag#19 uas_eh_abort_handler 0 uas-tag 20 
inflight: CMD OUT
[  195.692120] sd 2:0:0:0: [sdb] tag#19 CDB: opcode=0x8a 8a 00 00 00 00 00 00 
00 50 00 00 00 04 00 00 00
[  195.692182] sd 2:0:0:0: [sdb] 

Re: [PATCH 2/3] usb: musb: Add a quirk to preserve MUSB_DEVCTL during suspend

[Bin Liu]

On Fri, Dec 02, 2016 at 03:23:50PM +0100, Alexandre Bailon wrote:
> On 11/29/2016 06:56 PM, Bin Liu wrote:
> > On Tue, Nov 29, 2016 at 06:41:04PM +0100, Alexandre Bailon wrote:
> >> On 11/29/2016 05:16 PM, Bin Liu wrote:
> >>> Hi,
> >>>
> >>> On Mon, Nov 28, 2016 at 05:26:20PM +0100, Alexandre Bailon wrote:
>  On da8xx, VBUS is not maintained during suspend when musb is in host 
>  mode.
>  On resume, all the connected devices will be disconnected and then will
>  be enumerated again.
>  This happens because MUSB_DEVCTL is cleared during suspend.
>  Add a quirk to preserve MUSB_DEVCTL during a suspend.
> >>>
> >>> Will preserving MUSB_DEVCTL prevent the device getting disconnected?
> >> Yes. Preserving MUSB_DEVCTL keeps VBUS on though the PHY is off during
> >> suspend.
> > 
> > VBUS will be on, but does it prevent disconnecting the usb device on
> > resume? I don't have a DA8xx to test, but I doubt it, since the PHY is
> > off.
> Actually, the PHY is not really off.

I guess the PHY should be off when the system is suspended for an
aggressive power saving.

Sekhar, any comments?

Regards,
-Bin.

> The name is probably confusing but the PHY off only put the PHY in the
> lowest power state (chapter 10.11.1 of omapl138 TRM).
> I have tried with the TI kernel and it was able to suspend and resume
> the omapl138-lcdk without without getting a disconnect.
> That why I wrote this series.
> 
> Regards,
> Alexandre
> > 
> >> Note that in device mode, the disconnect still happen but I think it's
> >> the expected behavior.
> > 
> > Right, the PHY off disables the pullup.
> > 
> >>> This doesn't happen on am335x. The PHY is off during suspend, during
> >>> resume, PHY gets on, MUSB generates MUSB_CONNECT interrupt, then
> >>> re-enumeration happens.
> >> I haven't been able to try on the BBB. I don't know if my config is
> >> incorrect or if some patches are missing but I was not able to
> >> suspend it.
> > 
> > I heard the mainline kernel currently is broken on am335x PM, so
> > suspend/resume doesn't work. I had to test it on TI kernel.
> > 
> > Regards,
> > -Bin.
> > 
> >>
> >> Regards,
> >> Alexandre
> >>>
> >>> Regards,
> >>> -Bin.
> >>>
> 
>  Signed-off-by: Alexandre Bailon 
>  ---
>   drivers/usb/musb/musb_core.c | 13 +++--
>   drivers/usb/musb/musb_core.h |  1 +
>   2 files changed, 8 insertions(+), 6 deletions(-)
> 
>  diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>  index 9e22646..7e2cd98 100644
>  --- a/drivers/usb/musb/musb_core.c
>  +++ b/drivers/usb/musb/musb_core.c
>  @@ -1040,14 +1040,15 @@ static void musb_enable_interrupts(struct musb 
>  *musb)
>   
>   }
>   
>  -static void musb_generic_disable(struct musb *musb)
>  +static void musb_generic_disable(struct musb *musb, bool suspend)
>   {
>   void __iomem*mbase = musb->mregs;
>   
>   musb_disable_interrupts(musb);
>   
>   /* off */
>  -musb_writeb(mbase, MUSB_DEVCTL, 0);
>  +if (!suspend || !(musb->io.quirks & MUSB_PRESERVE_DEVCTL))
>  +musb_writeb(mbase, MUSB_DEVCTL, 0);
>   }
>   
>   /*
>  @@ -1106,7 +1107,7 @@ void musb_stop(struct musb *musb)
>   {
>   /* stop IRQs, timers, ... */
>   musb_platform_disable(musb);
>  -musb_generic_disable(musb);
>  +musb_generic_disable(musb, false);
>   musb_dbg(musb, "HDRC disabled");
>   
>   /* FIXME
>  @@ -2310,7 +2311,7 @@ musb_init_controller(struct device *dev, int nIrq, 
>  void __iomem *ctrl)
>   
>   /* be sure interrupts are disabled before connecting ISR */
>   musb_platform_disable(musb);
>  -musb_generic_disable(musb);
>  +musb_generic_disable(musb, false);
>   
>   /* Init IRQ workqueue before request_irq */
>   INIT_DELAYED_WORK(>irq_work, musb_irq_work);
>  @@ -2486,7 +2487,7 @@ static int musb_remove(struct platform_device 
>  *pdev)
>   musb_gadget_cleanup(musb);
>   spin_lock_irqsave(>lock, flags);
>   musb_platform_disable(musb);
>  -musb_generic_disable(musb);
>  +musb_generic_disable(musb, false);
>   spin_unlock_irqrestore(>lock, flags);
>   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
>   pm_runtime_dont_use_autosuspend(musb->controller);
>  @@ -2663,7 +2664,7 @@ static int musb_suspend(struct device *dev)
>   unsigned long   flags;
>   
>   musb_platform_disable(musb);
>  -musb_generic_disable(musb);
>  +musb_generic_disable(musb, true);
>   WARN_ON(!list_empty(>pending_list));
>   
>   spin_lock_irqsave(>lock, flags);
>  diff --git a/drivers/usb/musb/musb_core.h 

Re: [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier

[Bin Liu]

On Wed, Nov 30, 2016 at 09:45:03AM +0100, Maxime Ripard wrote:
> On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote:
> > This patch just uses the resource-managed extcon API when registering
> > the extcon notifier.
> > 
> > Signed-off-by: Chanwoo Choi 
> 
> Acked-by: Maxime Ripard 

It would be ideal if the subject was "usb: musb: sunxi: ...".

Acked-by: Bin Liu 

Regards,
-Bin.
--
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/1] net: usb: set error code when usb_alloc_urb fails

[Woojung.Huh]

> Signed-off-by: Pan Bian 
> ---
>  drivers/net/usb/lan78xx.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index db558b8..f33460c 100644
> --- a/drivers/net/usb/lan78xx.c
> +++ b/drivers/net/usb/lan78xx.c
> @@ -3395,6 +3395,7 @@ static int lan78xx_probe(struct usb_interface *intf,
>   if (buf) {
>   dev->urb_intr = usb_alloc_urb(0, GFP_KERNEL);
>   if (!dev->urb_intr) {
> + ret = -ENOMEM;
>   kfree(buf);
>   goto out3;
>   } else {
> --
> 1.9.1
> 
Acked-by: Woojung Huh 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XHCI controller does not detect USB key insertion

[Mason]

On 05/12/2016 09:26, Neil Armstrong wrote:

> On 12/02/2016 07:00 PM, Mason wrote:
>
>> On 02/12/2016 14:46, Neil Armstrong wrote:
>>
>>> On 12/02/2016 11:24 AM, Mason wrote:
>>>
 (Sad face) All the documentation I have is in front of me, and nothing
 is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI
 controller + Synopsys PHY.

 The documentation I have:

 Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals)
 Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf 
 (documents IP registers)
 PHY databook (very low-level stuff)
 SoC register mapping (for how the SoC maps the IP signals to registers)
>>>
>>> You should have all the necessary bits to enable and configure the Embedded 
>>> Synopsys PHY !
>>>
>>> You should have some register mapping of the PHY signals, or at least a way 
>>> to write those registers.
>>>
>>> You should have a reset, clock gate and eventually a power regulator to 
>>> enable in order to have the PHY running.
>>
>> I'll dump all the non-0 non-standard registers. Maybe someone
>> more experienced than me will spot an obvious mistake.
>>
>> host_usb30_0_config: 0x2e800
>>  - host_usb30_0_fladj 0x20
>>  - host_usb30_0_usb30_controller_cg_disable   0x0
>>  - host_usb30_0_mode_select   0x1
>>  - host_usb30_0_device_reset_mode 0x0
>>
>> host_usb30_0_control: 0x2e804
>>  - host_usb30_0_app_lfps_u3_wp0x0
>>  - host_usb30_0_link_up   0x1
>>  - host_usb30_0_msi_msg_sent  0x0
>>  - host_usb30_0_usb3_p0_over_current  0x0
>>  - host_usb30_0_usb2_p0_over_current  0x0
>>
>> host_usb30_0_test: 0x2e808
>>  - host_usb30_0_test_powerdown_hsp0x0
>>  - host_usb30_0_test_powerdown_ssp0x0
>>  - host_usb30_0_test_burnin   0x0
>>  - host_usb30_0_acjt_level0x14
>>  - host_usb30_0_lane0_tx2rx_loopbk0x0
>>  - host_usb30_0_rtune_req 0x0
>>
>> host_usb30_0_status: 0x2e80c
>>  - host_usb30_0_phystatus 0x0
>>  - host_usb30_0_usb2_p0_pp0x1
>>  - host_usb30_0_usb3_p0_pp0x1
>>  - host_usb30_0_usb3_sleep0x0
>>  - host_usb30_0_rtune_ack 0x0
>>
>> host_usb30_0_clk_rst_0: 0x2e810
>>  - host_usb30_0_commononn 0x1
>>  - host_usb30_0_portreset 0x0
>>  - host_usb30_0_refclksel 0x2
>>  - host_usb30_0_teneable  0x1
>>  - host_usb30_0_fsel  0x27
>>  - host_usb30_0_mpll_multiplier   0x19
>>  - host_usb30_0_ref_clkdiv2   0x0
>>  - host_usb30_0_ref_ssp_en0x1
>>  - host_usb30_0_ref_use_pad   0x0
>>  - host_usb30_0_ssc_en0x1
>>  - host_usb30_0_ssc_range 0x0
>>
>> host_usb30_0_clk_rst_1: 0x2e814
>>  - host_usb30_0_ssc_ref_clk_sel   0x88
>>  - host_usb30_0_sleepm0x1
>>  - host_usb30_0_vbusvldext0x1
>>
>> host_usb30_0_param_0: 0x2e818
>>  - host_usb30_0_compdistune   0x4
>>  - host_usb30_0_otgtune   0x4
>>  - host_usb30_0_sqrxtune  0x3
>>  - host_usb30_0_txfsltune 0x3
>>  - host_usb30_0_txhsxvtune0x3
>>  - host_usb30_0_txpreempltune 0x0
>>  - host_usb30_0_txpreemppulsetune 0x0
>>  - host_usb30_0_txrestune 0x1
>>  - host_usb30_0_txrisetune0x2
>>  - host_usb30_0_txvreftune0x4
>>
>> host_usb30_0_param_1: 0x2e81c
>>  - host_usb30_0_los_bias  0x5
>>  - host_usb30_0_los_level 0xc
>>  - host_usb30_0_pcs_rx_los_mask_val   0xf0
>>  - host_usb30_0_pcs_tx_deemph_3p5db   0x18
>>  - host_usb30_0_pcs_tx_deemph_6db 0x21
>>
>> host_usb30_0_param_2: 0x2e820
>>  - host_usb30_0_pcs_tx_swing_full 0x73
>>  - host_usb30_0_lane0_tx_term_offset  0x0
>>  - host_usb30_0_tx_vboost_lvl 0x4
>>
>> host_usb30_0_SNPS_CR_ADD: 0x2e880
>>  - host_usb30_0_snps_cr_add   0xe03c
> 
> This is obviously 

Re: [PATCH] USB: cdc-acm: add device id for GW Instek AFG-125

[Oliver Neukum]

On Mon, 2016-12-05 at 06:53 -0800, Nathaniel Quillin wrote:
> Add device-id entry for GW Instek AFG-125, which has a byte swapped
> bInterfaceSubClass (0x20).
> 
> Signed-off-by: Nathaniel Quillin 
Acked-by: Oliver Neukum 

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

usb/gadget: warning in dummy_free_request

[Andrey Konovalov]

Hi!

I've got the following error report while running the syzkaller fuzzer.

On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).

WARNING: CPU: 0 PID: 5257 at drivers/usb/gadget/udc/dummy_hcd.c:672
dummy_free_request+0x153/0x170
Kernel panic - not syncing: panic_on_warn set ...

usb 2-1: string descriptor 0 read error: -71
usb 2-1: New USB device found, idVendor=, idProduct=
usb 2-1: New USB device strings: Mfr=0, Product=170, SerialNumber=0
CPU: 0 PID: 5257 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006af0ec48 81f96aba 0200 11000d5e1d1c
 ed000d5e1d14 0a06 41b58ab3 8598b4c8
 81f96828 41b58ab3 85942a10 81432790
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] panic+0x1cb/0x3a9 kernel/panic.c:179
 [] __warn+0x1c4/0x1e0 kernel/panic.c:542
 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
 [] dummy_free_request+0x153/0x170
drivers/usb/gadget/udc/dummy_hcd.c:672
 [] usb_ep_free_request+0xc0/0x420
drivers/usb/gadget/udc/core.c:195
 [] gadgetfs_unbind+0x131/0x190
drivers/usb/gadget/legacy/inode.c:1612
 [] usb_gadget_remove_driver+0x10f/0x2b0
drivers/usb/gadget/udc/core.c:1228
 [] usb_gadget_unregister_driver+0x1b6/0x2c0
drivers/usb/gadget/udc/core.c:1357
 [] dev_release+0x80/0x160
drivers/usb/gadget/legacy/inode.c:1187
 [] __fput+0x332/0x7f0 fs/file_table.c:208
 [] fput+0x15/0x20 fs/file_table.c:244
 [] task_work_run+0x19b/0x270 kernel/task_work.c:116
 [< inline >] exit_task_work include/linux/task_work.h:21
 [] do_exit+0x16aa/0x2530 kernel/exit.c:828
 [] do_group_exit+0x149/0x420 kernel/exit.c:932
 [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
 [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807
 [] exit_to_usermode_loop+0x170/0x200
arch/x86/entry/common.c:156
 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
 [] syscall_return_slowpath+0x3d3/0x420
arch/x86/entry/common.c:259
 [] entry_SYSCALL_64_fastpath+0xc0/0xc2
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
--
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: cdc-acm: add device id for GW Instek AFG-125

[Nathaniel Quillin]

Add device-id entry for GW Instek AFG-125, which has a byte swapped
bInterfaceSubClass (0x20).

Signed-off-by: Nathaniel Quillin 
---
 drivers/usb/class/cdc-acm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index fada988..c5ff13f 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1719,6 +1719,7 @@ static const struct usb_device_id acm_ids[] = {
{ USB_DEVICE(0x20df, 0x0001), /* Simtec Electronics Entropy Key */
.driver_info = QUIRK_CONTROL_LINE_STATE, },
{ USB_DEVICE(0x2184, 0x001c) }, /* GW Instek AFG-2225 */
+   { USB_DEVICE(0x2184, 0x0036) }, /* GW Instek AFG-125 */
{ USB_DEVICE(0x22b8, 0x6425), /* Motorola MOTOMAGX phones */
},
/* Motorola H24 HSPA module: */
-- 
2.8.0.rc3.226.g39d4020

--
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: OHCI: nxp: remove useless extern declaration

[Greg Kroah-Hartman]

On Sat, Dec 03, 2016 at 03:25:23AM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> Remove usb_disabled() extern declaration as it is already declared
> as EXPORT_SYMBOL_GPL declaration.

merge this with your first patch please, it belongs with it.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] USB: OHCI: nxp: remove useless extern declaration

[Greg Kroah-Hartman]

On Sat, Dec 03, 2016 at 03:25:23AM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> Remove usb_disabled() extern declaration as it is already declared
> as EXPORT_SYMBOL_GPL declaration.

And same thing again...

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

Re: [PATCH 2/3] USB: OHCI: omap: remove useless extern declaration

[Greg Kroah-Hartman]

On Sat, Dec 03, 2016 at 03:25:22AM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> Remove usb_disabled() and ocpi_enable() extern declaration
> as it is already declared as EXPORT_SYMBOL_GPL declaration.

Same here, EXPORT_SYMBOL* doesn't matter for stuff like this.

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 1/3] USB: OHCI: at91: remove useless extern declaration

[Greg Kroah-Hartman]

On Sat, Dec 03, 2016 at 03:25:21AM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> Remove usb_disabled() extern declaration as it is already declared
> as EXPORT_SYMBOL_GPL declaration in drivers/usb/core/usb.c

The EXPORT_SYMBOL_GPL() has nothing to do with this, it's the fact that
it is exported in include/linux/usb.h that matters.

Please fix the text up and resend.

thanks,

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

Re: [PATCH 1/2] usb: host: xhci: Fix possible wild pointer when handling abort command

[Mathias Nyman]

On 05.12.2016 09:51, Baolin Wang wrote:

When current command was supposed to be aborted, host will free the command
in handle_cmd_completion() function. But it might be still referenced by
xhci->current_cmd, which need to set NULL.

Signed-off-by: Baolin Wang 
---
This patch is based on Lu Baolu's new fix patch:
usb: xhci: fix possible wild pointer
https://www.spinics.net/lists/linux-usb/msg150219.html
---
  drivers/usb/host/xhci-ring.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 62dd1c7..9965a4c 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1362,8 +1362,11 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
 */
if (cmd_comp_code == COMP_CMD_ABORT) {
xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
-   if (cmd->status == COMP_CMD_ABORT)
+   if (cmd->status == COMP_CMD_ABORT) {
+   if (xhci->current_cmd == cmd)
+   xhci->current_cmd = NULL;
goto event_handled;
+   }
}

cmd_type = TRB_FIELD_TO_TYPE(le32_to_cpu(cmd_trb->generic.field[3]));



True, thanks

-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: usb/gadget: GPF in usb_gadget_unregister_driver

[Krzysztof Opasiak]

On 12/05/2016 01:50 PM, Andrey Konovalov wrote:
> On Sat, Dec 3, 2016 at 6:13 PM, Greg Kroah-Hartman
>  wrote:
>> On Sat, Dec 03, 2016 at 05:36:35PM +0100, Andrey Konovalov wrote:
>>> Hi!
>>>
>>> I've got the following error report while running the syzkaller fuzzer.
>>>
>>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>>
>>> general protection fault:  [#1] SMP KASAN
>>> Dumping ftrace buffer:
>>>(ftrace buffer empty)
>>> Modules linked in:
>>> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: 88006cd0db40 task.stack: 88006a05
>>> RIP: 0010:[]  []
>>> __list_del_entry+0xce/0x280 lib/list_debug.c:57
>>> RSP: 0018:88006a056ea8  EFLAGS: 00010246
>>> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8
>>> RDX:  RSI: 88006cd0e340 RDI: 860cead0
>>> RBP: 88006a056f38 R08:  R09: 
>>> R10: 0006 R11:  R12: 
>>> R13:  R14: 860cea00 R15: 88006a056f10
>>> FS:  () GS:88003ec0() knlGS:
>>> CS:  0010 DS:  ES:  CR0: 80050033
>>> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0
>>> Stack:
>>>  859785e0 41b58ab3 8593717a 8201a9d0
>>>  11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338
>>>  0a06 11000d40ade4 88006cd0e340 
>>> Call Trace:
>>>  [] list_del+0xd/0x70 lib/list_debug.c:77
>>>  [] usb_gadget_unregister_driver+0x120/0x240
>>> drivers/usb/gadget/udc/core.c:1365
>>>  [] dev_release+0x80/0x160
>>> drivers/usb/gadget/legacy/inode.c:1187
>>>  [] __fput+0x332/0x7f0 fs/file_table.c:208
>>>  [] fput+0x15/0x20 fs/file_table.c:244
>>>  [] task_work_run+0x19b/0x270 kernel/task_work.c:116
>>>  [< inline >] exit_task_work include/linux/task_work.h:21
>>>  [] do_exit+0x16aa/0x2530 kernel/exit.c:828
>>>  [] do_group_exit+0x149/0x420 kernel/exit.c:932
>>>  [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
>>>  [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807
>>>  [] exit_to_usermode_loop+0x170/0x200
>>> arch/x86/entry/common.c:156
>>>  [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>>>  [] syscall_return_slowpath+0x3d3/0x420
>>> arch/x86/entry/common.c:259
>>>  [] entry_SYSCALL_64_fastpath+0xc0/0xc2
>>> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f
>>> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
>>> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00
>>> RIP  [] __list_del_entry+0xce/0x280 lib/list_debug.c:57
>>>  RSP 
>>> ---[ end trace 883f708e6720200f ]---
>>> Kernel panic - not syncing: Fatal exception
>>> Dumping ftrace buffer:
>>>(ftrace buffer empty)
>>> Kernel Offset: disabled
>>
>> Any hints as to what you were doing when this happend?
> 
> I've looked at the code.
> 
> As far as I can see, it's possible for usb_gadget_probe_driver() to
> return 0 without adding driver to gadget_driver_pending_list (in case
> strcmp() returns 0 and driver->match_existing_only == true).
> As a result dev->gadget_registered will be set to true in dev_config()
> and dev_release() will call usb_gadget_unregister_driver(), which in
> turn will try to remove driver from gadget_driver_pending_list.
> 
> Does it make any sense?
> 

Yes. We should add gadget to pending list only if suitable UDC has not
been found and gadget driver is willing to wait for new UDC to appear.
Otherwise we call udc_bind_to_gadget() and if this success then we
should just return 0 as we took some free udc. usually you should have
empty pending list;)

Your description sounds really quite similar to what Felix fixed in his
patch[1]. This patch fix this function in case when we found matching
UDC but it is busy.

Footnotes:
1 - http://marc.info/?l=linux-usb=148054830631070=2

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

[Mathias Nyman]

On 05.12.2016 13:00, Felipe Balbi wrote:


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



usb/core/message.c  usb_get_descritptor() sets the -61 (ENODATA) if
the control transfer received data,  but the descriptor type byte doesn't match.
(as the 8 zeros probably would do)

does xhci verbose debugging show any control transfer related messages during 
this?

echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control

-Mathias
  


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

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

[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 frustrated about that. We have to
> deal with whatever the firmware developers serve us.  And,
> unfortunately, it is not surprising that unclear and ambigious specs
> leads to 

usb/gadget: use-after-free in gadgetfs_setup

[Andrey Konovalov]

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
Read of size 2 by task syz-executor0/22994
CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006df06a18 81f96aba e0528500 11000dbe0cd6
 ed000dbe0cce 88006df068f0 41b58ab3 8598b4c8
 81f96828 11000dbe0ccd 88006df06708 88006df06748
Call Trace:
  [  201.343209]  [< inline >] __dump_stack lib/dump_stack.c:15
  [  201.343209]  [] dump_stack+0x292/0x398
lib/dump_stack.c:51
 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [< inline >] print_address_description mm/kasan/report.c:197
 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [< inline >] kasan_report mm/kasan/report.c:306
 [] __asan_report_load_n_noabort+0x3a/0x40
mm/kasan/report.c:337
 [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298
 [] gadgetfs_setup+0x208a/0x20e0
drivers/usb/gadget/legacy/inode.c:1368
 [] dummy_timer+0x11f0/0x36d0
drivers/usb/gadget/udc/dummy_hcd.c:1858
 [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
 [< inline >] expire_timers kernel/time/timer.c:1348
 [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
 [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
 [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
 [< inline >] invoke_softirq kernel/softirq.c:364
 [] irq_exit+0x19e/0x1d0 kernel/softirq.c:405
 [< inline >] exiting_irq arch/x86/include/asm/apic.h:659
 [] smp_apic_timer_interrupt+0x7b/0xa0
arch/x86/kernel/apic/apic.c:960
 [] apic_timer_interrupt+0x8c/0xa0
arch/x86/entry/entry_64.S:489
  [  201.343209]  [] ?
_raw_spin_unlock_irqrestore+0x119/0x1a0
 [] try_to_wake_up+0x174/0x1160 kernel/sched/core.c:2099
 [< inline >] wake_up_process kernel/sched/core.c:2165
 [] wake_up_q+0x8a/0xe0 kernel/sched/core.c:469
 [] futex_wake+0x5be/0x6c0 kernel/futex.c:1453
 [] do_futex+0x11bd/0x1f00 kernel/futex.c:3219
 [< inline >] SYSC_futex kernel/futex.c:3275
 [] SyS_futex+0x2fc/0x400 kernel/futex.c:3243
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Object at 88003dfe5bf0, in cache kmalloc-32 size: 32
Allocated:
PID = 21625
 [  201.343209] [] save_stack_trace+0x16/0x20
arch/x86/kernel/stacktrace.c:57
 [  201.343209] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [  201.343209] [< inline >] set_track mm/kasan/kasan.c:507
 [  201.343209] [] kasan_kmalloc+0xad/0xe0
mm/kasan/kasan.c:598
 [  201.343209] [] kasan_slab_alloc+0x12/0x20
mm/kasan/kasan.c:537
 [  201.343209] [< inline >] slab_post_alloc_hook mm/slab.h:417
 [  201.343209] [< inline >] slab_alloc_node mm/slub.c:2708
 [  201.343209] [< inline >] slab_alloc mm/slub.c:2716
 [  201.343209] []
__kmalloc_track_caller+0x195/0x290 mm/slub.c:4240
 [  201.343209] [] memdup_user+0x2c/0xa0 mm/util.c:137
 [  201.343209] [] dev_config+0x2eb/0x1190
drivers/usb/gadget/legacy/inode.c:1778
 [  201.343209] [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
 [  201.343209] [] vfs_write+0x170/0x4e0 fs/read_write.c:560
 [  201.343209] [< inline >] SYSC_write fs/read_write.c:607
 [  201.343209] [] SyS_write+0xfb/0x230 fs/read_write.c:599
 [  201.343209] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 21625
 [  201.343209] [] save_stack_trace+0x16/0x20
arch/x86/kernel/stacktrace.c:57
 [  201.343209] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [  201.343209] [< inline >] set_track mm/kasan/kasan.c:507
 [  201.343209] [] kasan_slab_free+0x73/0xc0
mm/kasan/kasan.c:571
 [  201.343209] [< inline >] slab_free_hook mm/slub.c:1352
 [  201.343209] [< inline >] slab_free_freelist_hook mm/slub.c:1374
 [  201.343209] [< inline >] slab_free mm/slub.c:2951
 [  201.343209] [] kfree+0xe7/0x2b0 mm/slub.c:3871
 [  201.343209] [] dev_config+0xc0b/0x1190
drivers/usb/gadget/legacy/inode.c:1848
 [  201.343209] [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
 [  201.343209] [] vfs_write+0x170/0x4e0 fs/read_write.c:560
 [  201.343209] [< inline >] SYSC_write fs/read_write.c:607
 [  201.343209] [] SyS_write+0xfb/0x230 fs/read_write.c:599
 [  201.343209] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Memory state around the buggy address:
 88003dfe5a80: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
 88003dfe5b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88003dfe5b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb
 ^
 88003dfe5c00: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88003dfe5c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message 

Re: usb/gadget: GPF in usb_gadget_unregister_driver

[Andrey Konovalov]

On Sat, Dec 3, 2016 at 6:13 PM, Greg Kroah-Hartman
 wrote:
> On Sat, Dec 03, 2016 at 05:36:35PM +0100, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following error report while running the syzkaller fuzzer.
>>
>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 88006cd0db40 task.stack: 88006a05
>> RIP: 0010:[]  []
>> __list_del_entry+0xce/0x280 lib/list_debug.c:57
>> RSP: 0018:88006a056ea8  EFLAGS: 00010246
>> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8
>> RDX:  RSI: 88006cd0e340 RDI: 860cead0
>> RBP: 88006a056f38 R08:  R09: 
>> R10: 0006 R11:  R12: 
>> R13:  R14: 860cea00 R15: 88006a056f10
>> FS:  () GS:88003ec0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0
>> Stack:
>>  859785e0 41b58ab3 8593717a 8201a9d0
>>  11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338
>>  0a06 11000d40ade4 88006cd0e340 
>> Call Trace:
>>  [] list_del+0xd/0x70 lib/list_debug.c:77
>>  [] usb_gadget_unregister_driver+0x120/0x240
>> drivers/usb/gadget/udc/core.c:1365
>>  [] dev_release+0x80/0x160
>> drivers/usb/gadget/legacy/inode.c:1187
>>  [] __fput+0x332/0x7f0 fs/file_table.c:208
>>  [] fput+0x15/0x20 fs/file_table.c:244
>>  [] task_work_run+0x19b/0x270 kernel/task_work.c:116
>>  [< inline >] exit_task_work include/linux/task_work.h:21
>>  [] do_exit+0x16aa/0x2530 kernel/exit.c:828
>>  [] do_group_exit+0x149/0x420 kernel/exit.c:932
>>  [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
>>  [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807
>>  [] exit_to_usermode_loop+0x170/0x200
>> arch/x86/entry/common.c:156
>>  [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>>  [] syscall_return_slowpath+0x3d3/0x420
>> arch/x86/entry/common.c:259
>>  [] entry_SYSCALL_64_fastpath+0xc0/0xc2
>> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f
>> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00
>> RIP  [] __list_del_entry+0xce/0x280 lib/list_debug.c:57
>>  RSP 
>> ---[ end trace 883f708e6720200f ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>
> Any hints as to what you were doing when this happend?

I've looked at the code.

As far as I can see, it's possible for usb_gadget_probe_driver() to
return 0 without adding driver to gadget_driver_pending_list (in case
strcmp() returns 0 and driver->match_existing_only == true).
As a result dev->gadget_registered will be set to true in dev_config()
and dev_release() will call usb_gadget_unregister_driver(), which in
turn will try to remove driver from gadget_driver_pending_list.

Does it make any sense?

>
> 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: usb/gadget: GPF in usb_gadget_unregister_driver

[Andrey Konovalov]

On Sat, Dec 3, 2016 at 6:31 PM, Felix Hädicke  wrote:
> Hi,
>> Hi!
>>
>> I've got the following error report while running the syzkaller fuzzer.
>>
>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 88006cd0db40 task.stack: 88006a05
>> RIP: 0010:[]  []
>> __list_del_entry+0xce/0x280 lib/list_debug.c:57
>> RSP: 0018:88006a056ea8  EFLAGS: 00010246
>> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8
>> RDX:  RSI: 88006cd0e340 RDI: 860cead0
>> RBP: 88006a056f38 R08:  R09: 
>> R10: 0006 R11:  R12: 
>> R13:  R14: 860cea00 R15: 88006a056f10
>> FS:  () GS:88003ec0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0
>> Stack:
>>  859785e0 41b58ab3 8593717a 8201a9d0
>>  11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338
>>  0a06 11000d40ade4 88006cd0e340 
>> Call Trace:
>>  [] list_del+0xd/0x70 lib/list_debug.c:77
>>  [] usb_gadget_unregister_driver+0x120/0x240
>> drivers/usb/gadget/udc/core.c:1365
>>  [] dev_release+0x80/0x160
>> drivers/usb/gadget/legacy/inode.c:1187
>>  [] __fput+0x332/0x7f0 fs/file_table.c:208
>>  [] fput+0x15/0x20 fs/file_table.c:244
>>  [] task_work_run+0x19b/0x270 kernel/task_work.c:116
>>  [< inline >] exit_task_work include/linux/task_work.h:21
>>  [] do_exit+0x16aa/0x2530 kernel/exit.c:828
>>  [] do_group_exit+0x149/0x420 kernel/exit.c:932
>>  [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
>>  [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807
>>  [] exit_to_usermode_loop+0x170/0x200
>> arch/x86/entry/common.c:156
>>  [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>>  [] syscall_return_slowpath+0x3d3/0x420
>> arch/x86/entry/common.c:259
>>  [] entry_SYSCALL_64_fastpath+0xc0/0xc2
>> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f
>> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00
>> RIP  [] __list_del_entry+0xce/0x280 lib/list_debug.c:57
>>  RSP 
>> ---[ end trace 883f708e6720200f ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> --
>> 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
>
> Looks similar to the oops which I had reported a few days ago. See mail
> "PROBLEM: Oops when unbinding an inactive gadget configfs configuration
> from UDC". Maybe you want to test my bugfix proposal "usb: gadget: udc:
> core: fix return code of usb_gadget_probe_driver()".

Hi Felix,

Looks quite similar, but your patch doesn't help in my case.

Thanks!

>
> Regards,
> Felix
>
--
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: GPF in usb_gadget_unregister_driver

[Andrey Konovalov]

On Sat, Dec 3, 2016 at 6:13 PM, Greg Kroah-Hartman
 wrote:
> On Sat, Dec 03, 2016 at 05:36:35PM +0100, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following error report while running the syzkaller fuzzer.
>>
>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2).
>>
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 88006cd0db40 task.stack: 88006a05
>> RIP: 0010:[]  []
>> __list_del_entry+0xce/0x280 lib/list_debug.c:57
>> RSP: 0018:88006a056ea8  EFLAGS: 00010246
>> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8
>> RDX:  RSI: 88006cd0e340 RDI: 860cead0
>> RBP: 88006a056f38 R08:  R09: 
>> R10: 0006 R11:  R12: 
>> R13:  R14: 860cea00 R15: 88006a056f10
>> FS:  () GS:88003ec0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0
>> Stack:
>>  859785e0 41b58ab3 8593717a 8201a9d0
>>  11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338
>>  0a06 11000d40ade4 88006cd0e340 
>> Call Trace:
>>  [] list_del+0xd/0x70 lib/list_debug.c:77
>>  [] usb_gadget_unregister_driver+0x120/0x240
>> drivers/usb/gadget/udc/core.c:1365
>>  [] dev_release+0x80/0x160
>> drivers/usb/gadget/legacy/inode.c:1187
>>  [] __fput+0x332/0x7f0 fs/file_table.c:208
>>  [] fput+0x15/0x20 fs/file_table.c:244
>>  [] task_work_run+0x19b/0x270 kernel/task_work.c:116
>>  [< inline >] exit_task_work include/linux/task_work.h:21
>>  [] do_exit+0x16aa/0x2530 kernel/exit.c:828
>>  [] do_group_exit+0x149/0x420 kernel/exit.c:932
>>  [] get_signal+0x76d/0x17b0 kernel/signal.c:2307
>>  [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807
>>  [] exit_to_usermode_loop+0x170/0x200
>> arch/x86/entry/common.c:156
>>  [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
>>  [] syscall_return_slowpath+0x3d3/0x420
>> arch/x86/entry/common.c:259
>>  [] entry_SYSCALL_64_fastpath+0xc0/0xc2
>> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f
>> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00
>> RIP  [] __list_del_entry+0xce/0x280 lib/list_debug.c:57
>>  RSP 
>> ---[ end trace 883f708e6720200f ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>
> Any hints as to what you were doing when this happend?

Hi Greg,

I was running a fuzzer that mounts gadgetfs and concurrently writes
garbage to /dev/gadget/dummy_udc.

I'll see if I can reproduce it.

Thanks!

>
> 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 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

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

"
  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 frustrated about that. We have to
deal with whatever the firmware developers serve us.  And,
unfortunately, it is not surprising that unclear and ambigious specs
leads to incompatible firmware implementations.

I wonder, what happens if you unload the MBIM driver and let the USB
core reset the data interface to altsetting 0?  Will the device then
fail when the driver is loaded again?  If not, then where is the
difference?  And can we possibly reorder the driver set_interface
requests to make them similar to the USB core reset

Until 

[PATCH 1/1 v2] input: usbhid: fix improper return value

[Pan Bian]

Function hid_post_reset() should return negative error codes on
failures. However, in its implementation, it incorrectly returns 1.
This patch fixes the bug, returning proper error codes on failures.

Signed-off-by: Pan Bian 
---
 drivers/hid/usbhid/hid-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ae83af6..333108e 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1459,7 +1459,7 @@ static int hid_post_reset(struct usb_interface *intf)
rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
if (!rdesc) {
dbg_hid("couldn't allocate rdesc memory (post_reset)\n");
-   return 1;
+   return -ENOMEM;
}
status = hid_get_class_descriptor(dev,
interface->desc.bInterfaceNumber,
@@ -1467,13 +1467,13 @@ static int hid_post_reset(struct usb_interface *intf)
if (status < 0) {
dbg_hid("reading report descriptor failed (post_reset)\n");
kfree(rdesc);
-   return 1;
+   return status;
}
status = memcmp(rdesc, hid->dev_rdesc, hid->dev_rsize);
kfree(rdesc);
if (status != 0) {
dbg_hid("report descriptor changed\n");
-   return 1;
+   return -EPERM;
}
 
/* No need to do another reset or clear a halted endpoint */
-- 
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: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Felipe Balbi]

(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: AW: add usb option device

[Johan Hovold]

On Sat, Dec 03, 2016 at 07:47:11PM +0100, Giuseppe Lippolis wrote:
> Dear All,
> 
> > If possible you want to tell the option driver which interfaces to 
> > bind to (white-listing) rather than specifying which not to bind to 
> > (black-listing). The latter typically means probing all interfaces, 
> > checking the black list, and then bailing out for unsupported 
> > interfaces.
> 
> I try to use the blacklist to specify which interface not to bind:
> 
>   static const struct option_blacklist_info dlink_dwm_158_ blacklist = {
>   .reserved = BIT(0) | BIT(1),
>   };
> 
>   { USB_DEVICE (0x2001, 0x7d04),
>   .driver_info = (kernel_ulong_t)_dwm_158_blacklist },
> 
> The result seems positive, after boot:

> T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
> D:  Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=2001 ProdID=7d04 Rev= 3.00
> S:  Manufacturer=D-Link,Inc
> S:  Product=D-Link DWM-158
> C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
> A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
> E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=125us
> I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
> I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
> E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=125us
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
> E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Yes, that would work, but if you look at the interface definitions above
you see that simply matching all interfaces with class 0xff (i.e.
white-listing) would suffice and is therefore preferred.

> On the kernel v4.8.12, I see similar d-link devices with the same
> VENDOR_ID declared in this way:
> 
>   { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d01, 0xff, 0x02, 0x01) },
> /* D-Link DWM-156 (variant) */
>   { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d01, 0xff, 0x00, 0x00) },
> /* D-Link DWM-156 (variant) */
>   { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d02, 0xff, 0x02, 0x01) },
>   { 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, 0x7e19, 0xff), 
> /* D-Link DWM-221 B1 */
> .driver_info = (kernel_ulong_t)_intf4_blacklist },
> 
> Shall I declare a 
>   #define DLINK_VENDOR_ID 0x2001
> Or use the hardcoded style ?

Just stick to the hard-coded 0x2001 for now. There are two (or three)
other VIDs used for D-Link in option and it looks like one of them is
really the PCI vendor id.

Either way, we can clean that up later.

> Another question when is appropriate to use USB_DEVICE and when
> USB_DEVICE_INTERFACE_CLASS ?

So if you just use USB_DEVICE_INTERFACE_CLASS() you don't need to do any
blacklisting at all:

{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },

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: USB3.0 DWC3 can't work with latest Linux-4.9.rc7

[Jerry Huang]

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.

Best Regards
Jerry Huang


-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 
[  164.435180] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd 
[  164.459380] usb 2-1: device descriptor read/8, error -61 
[  164.779230] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd 
[  164.803350] usb 2-1: device descriptor read/8, error -61 
[  164.915181] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd 
[  164.943393] usb 2-1: device descriptor read/8, error -61 
[  165.263231] usb 2-1: new SuperSpeed USB device number 4 using xhci-hcd 
[  165.287352] usb 2-1: device descriptor read/8, error -61 
[  165.399181] usb 2-1: new SuperSpeed USB device number 4 using xhci-hcd 
[  165.427394] usb 2-1: device descriptor read/8, error -61 
[  165.747231] usb 2-1: new SuperSpeed USB device number 5 using xhci-hcd 
[  165.775347] usb 2-1: device descriptor read/8, error -61 
[  165.887181] usb 2-1: new SuperSpeed USB device number 5 using xhci-hcd 
[  165.915396] usb 2-1: device descriptor read/8, error -61 
[  166.055194] usb usb2-port1: unable to enumerate USB device

Best Regards
Jerry Huang
--
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-core: Rescan pending list on driver unbind

[Marek Szyprowski]

Hi Krzysztof,


On 2016-12-05 11:09, Krzysztof Opasiak wrote:

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 


Reviewed-by: Marek Szyprowski 


---
  drivers/usb/gadget/udc/core.c | 44 ++-
  1 file changed, 31 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 9483489080f6..6c8f6ea8eb96 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
@@ -1136,17 +1154,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 +1362,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);


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

--
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: turn off padding of resume time delays

[Felipe Balbi]

Hi,

Todd Brandt  writes:
> Add a module parameter that replaces the USB_RESUME_TIMEOUT
> and other hardcoded delay numbers with the USB spec minimums.
> By default the patch retains the current values.
>
> The USB subsystem currently uses heavily padded values for TDRSMDN
> and TRSTRCY. This patch keeps the current values by default, but if

there's a reason for that. We've found many broken devices over the
years and a lot of inconsistencies were also found while with host
controller A or B or C, because they all used different timings.

Using spec minimum is, actually, a recipe for disaster :-) There's no
way we can guarantee all devices currently in use are respecting that
part of the spec.

This is a very fragile part of the USB spec which different folks have
different understanding and that's why so many devices are "broken".

I'd be careful with such a patchset. It's a nice idea, but I'd be
careful :-)

-- 
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 1/1] USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041

[Johan Hovold]

On Thu, Dec 01, 2016 at 04:38:39PM +0100, Daniele Palmas wrote:
> This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A.
> 
> Since the interface positions are the same than the ones used
> for other Telit compositions, previous defined blacklists are used.
> 
> Signed-off-by: Daniele Palmas 

Applied, thanks.

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

Re: [PATCH 0/2] USB: resume time optimization by using spec minimums

[Oliver Neukum]

On Sat, 2016-12-03 at 10:05 +0100, Greg KH wrote:
> I think these values have grown over the years due to bad devices
> being
> reported.  Look at the kernel logs for details.  So we can not reduce
> them by default.
> 
> That being said, this is a nice change, but I really hate module
> parameters.

Maybe we could, by default, use the shorter times for internal devices
and hubs?

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 2/3 v3] xhci: Fix race related to abort operation

[OGAWA Hirofumi]

Vincent Pelletier  writes:

> Problem is, I could not reproduce the "Command completion event does not
> match command" error either (which used to happen even on successful
> boots), even without your patch. Checking my syslog, I see it did
> happen with my previous kernel (vanilla 4.6.0).
> Could something else since 4.6.0 have improved xhci initialisation on
>   00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx, 
> Celeron N2000 Series USB xHCI (rev 0e)
> From a naive "git log drivers/usb/host/xhci*" read,
>   commit 3425aa03f484d45dc21e0e791c2f6c74ea656421
>   Author: Mathias Nyman 
>   Date:   Wed Jun 1 18:09:08 2016 +0300
>   xhci: Fix handling timeouted commands on hosts in weird states.
> caught my eye, along with some quirk reworks but I can't tell if they
> could be related to the improvement.
> FWIW the following log line
> did not change since (at least) 4.4.0 on this machine:
>   xhci_hcd :00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 
> 0x9810
>
> So I cannot tell for sure whether your patch set improves the situation.
>
> What I can say though is that after about 5 boots *with* your patch is
> that I had no boot failure nor xhci warnings, so at least no obvious
> regression either.

Thanks for testing. Looks like that root abort cause itself was fixed
somewhere.  I think that workaround is not needed anymore though,
Mathias will decide whether removing or not.

Thanks.
-- 
OGAWA Hirofumi 
--
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/1] usb: xhci: fix possible wild pointer

[Lu Baolu]

Hi,

On 12/02/2016 09:39 PM, Mathias Nyman wrote:
> On 02.12.2016 04:29, Lu Baolu wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when xhci->current_cmd is accessed after that.
>>
>> A real-life case could be like this. The host takes a very long
>> time to respond to a command, and the command timer is fired at
>> the same time when the command completion event arrives. The
>> command completion handler frees xhci->current_cmd before the
>> timer function can grab xhci->lock. Afterward, timer function
>> grabs the lock and go ahead with checking and setting members
>> of xhci->current_cmd.
>>
>> Cc:  # v3.16+
>> Signed-off-by: Lu Baolu 
>> ---
>>   drivers/usb/host/xhci-ring.c | 16 +++-
>>   1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index bdf6b13..13e05f6 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>>   bool second_timeout = false;
>>   xhci = (struct xhci_hcd *) data;
>>
>> -/* mark this command to be cancelled */
>>   spin_lock_irqsave(>lock, flags);
>> -if (xhci->current_cmd) {
>> -if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> -second_timeout = true;
>> -xhci->current_cmd->status = COMP_CMD_ABORT;
>> +if (!xhci->current_cmd) {
>> +spin_unlock_irqrestore(>lock, flags);
>> +return;
>>   }
>>
>> +if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> +second_timeout = true;
>> +xhci->current_cmd->status = COMP_CMD_ABORT;
>> +
>>   /* Make sure command ring is running before aborting it */
>>   hw_ring_state = xhci_read_64(xhci, >op_regs->cmd_ring);
>>   if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
>> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd 
>> *xhci,
>>   xhci->current_cmd = list_entry(cmd->cmd_list.next,
>>  struct xhci_command, cmd_list);
>>   mod_timer(>cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
>> +} else if (xhci->current_cmd == cmd) {
>> +xhci->current_cmd = NULL;
>> +} else {
>> +xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>>   }
>>
>>   event_handled:
>>
>
> Thanks,
>
> I might do some tweaking to (or remove)  the warn message when applying if
> that is ok

Sure.

>
> -Mathias
>

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

Re: [PATCH 1/1] input: usbhid: fix improper check

[Oliver Neukum]

On Sun, 2016-12-04 at 13:10 +0800, Pan Bian wrote:
> From: Pan Bian 
> 
> Function hid_post_reset() returns 0 on success, or 1 on failures.

It seems like hid_post_reset() is buggy in not returning
a proper error code in the failure case. So your diagnosis
is right, but the fix is at the wrong place.

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 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

Hi,

2016-11-28 12:23 GMT+01:00 Daniele Palmas :
> 2016-11-26 22:17 GMT+01:00 Bjørn Mork :
>> Bjørn Mork  writes:
>>
>>> Finally, I found my modems (or at least a number of them) again today.
>>> But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
>>> giving us a hard time.  It does not work with your patch. The symptom is
>>> the same as earlier:  The modem returns MBIM frames with 32bit headers.
>>>
>>> So for now, I have to NAK this patch.
>>>
>>> I am sure we can find a good solution that makes all of these modems
>>> work, but I cannot support a patch that breaks previously working
>>> configurations. Sorry.  I'll do a few experiments and see if there is a
>>> simple fix for this.  Otherwise we'll probably have to do the quirk
>>> game.
>>
>>
>> This is a proof-of-concept only, but it appears to be working.  Please
>> test with your device(s) too.  It's still mostly your code, as you can
>> see.
>
> Sorry, this does not work :-(
>
> The problem is always in the altsetting toggle: if I comment that
> part, your patch is working fine.
>
> I'm now wondering if the safest thing is to add a very simple quirk in
> cdc_mbim that makes this toggle not to be applied with the buggy
> modems and then unconditionally add the RESET_FUNCTION request in
> cdc_mbim_bind after cdc_ncm_bind_common has been executed.
>

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.

My proposal is to add something like
CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk to avoid the toggle.

To have a conservative approach, I would add only Telit LE922 to this
quirk and keep also the usleep_range delay, since I do not have a
clear view on all the VIDs/PIDs affected by this quirk. Then other
modems, once tested, can be added to the quirk if the delay is not
enough.

If this approach, though ugly, has chances to be accepted I can write
a new patch.

Thanks,
Daniele

> Daniele
>
>>
>> If this turns out to work, then I believe we should refactor
>> cdc_ncm_init() and cdc_ncm_bind_common() to make the whole
>> initialisation sequence a bit cleaner.  And maybe also include
>> cdc_mbim_bind().  Ideally, the MBIM specific RESET should happen there
>> instead of "polluting" the NCM driver with MBIM specific code.
>>
>> But anyway:  The sequence that seems to work for both the  E3372h-153
>> and the EM7455 is
>>
>>  USB_CDC_GET_NTB_PARAMETERS
>>  USB_CDC_RESET_FUNCTION
>>  usb_set_interface(dev->udev, 'data interface no', 0);
>>  remaining parts of cdc_ncm_init(), excluding USB_CDC_GET_NTB_PARAMETERS
>>  usb_set_interface(dev->udev, 'data interface no', 'data alt setting');
>>
>> without any additional delay between the two usb_set_interface() calls.
>> So the major difference from your patch is that I moved the two control
>> requests out of cdc_ncm_init() to allow running them _before_ setting
>> the data interface to altsetting 0.
>>
>> But maybe I was just lucky.  This was barely proof tested.  Needs a lot
>> more testing and cleanups as suggested.  I'd appreciate it if you
>> continued that, as I don't really have any time for it...
>>
>> FWIW, I also ran a quick test with a D-Link DWM-156A7 (Mediatek MBIM
>> firmware) and a Huawei E367 (Qualcomm device with early Huawei MBIM
>> firmware, distinctly different from the E3372h-153 and most other
>> MBIM devices I've seen)
>>
>>
>>
>> Bjørn
>>
>> ---
>>  drivers/net/usb/cdc_ncm.c| 48 
>> 
>>  include/uapi/linux/usb/cdc.h |  1 +
>>  2 files changed, 32 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
>> index 877c9516e781..be019cbf1719 100644
>> --- a/drivers/net/usb/cdc_ncm.c
>> +++ b/drivers/net/usb/cdc_ncm.c
>> @@ -488,16 +488,6 @@ static int cdc_ncm_init(struct usbnet *dev)
>> u8 iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
>> int err;
>>
>> -   err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
>> - USB_TYPE_CLASS | USB_DIR_IN
>> - |USB_RECIP_INTERFACE,
>> - 0, iface_no, >ncm_parm,
>> - sizeof(ctx->ncm_parm));
>> -   if (err < 0) {
>> -   dev_err(>intf->dev, "failed GET_NTB_PARAMETERS\n");
>> -   return err; /* GET_NTB_PARAMETERS is required */
>> -   }
>> -
>> /* set CRC Mode */
>> if (cdc_ncm_flags(dev) & USB_CDC_NCM_NCAP_CRC_MODE) {
>> dev_dbg(>intf->dev, "Setting CRC mode off\n");
>> @@ -837,12 +827,43 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
>> usb_interface *intf, u8 data_
>> }
>> }
>>
>> +   iface_no = 

Re: XHCI controller does not detect USB key insertion

[Neil Armstrong]

Hi Mason,

On 12/02/2016 07:00 PM, Mason wrote:
> [ Fix incorrect address for Felipe ]
> 
> On 02/12/2016 14:46, Neil Armstrong wrote:
> 
>> On 12/02/2016 11:24 AM, Mason wrote:
>>
>>> (Sad face) All the documentation I have is in front of me, and nothing
>>> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI
>>> controller + Synopsys PHY.
>>>
>>> The documentation I have:
>>>
>>> Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals)
>>> Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents 
>>> IP registers)
>>> PHY databook (very low-level stuff)
>>> SoC register mapping (for how the SoC maps the IP signals to registers)
>>
>> You should have all the necessary bits to enable and configure the Embedded 
>> Synopsys PHY !
>>
>> You should have some register mapping of the PHY signals, or at least a way 
>> to write those registers.
>>
>> You should have a reset, clock gate and eventually a power regulator to 
>> enable in order to have the PHY running.
> 
> I'll dump all the non-0 non-standard registers. Maybe someone
> more experienced than me will spot an obvious mistake.
> 
> host_usb30_0_config: 0x2e800
>   - host_usb30_0_fladj 0x20
>   - host_usb30_0_usb30_controller_cg_disable   0x0
>   - host_usb30_0_mode_select   0x1
>   - host_usb30_0_device_reset_mode 0x0
> 
> host_usb30_0_control: 0x2e804
>   - host_usb30_0_app_lfps_u3_wp0x0
>   - host_usb30_0_link_up   0x1
>   - host_usb30_0_msi_msg_sent  0x0
>   - host_usb30_0_usb3_p0_over_current  0x0
>   - host_usb30_0_usb2_p0_over_current  0x0
> 
> host_usb30_0_test: 0x2e808
>   - host_usb30_0_test_powerdown_hsp0x0
>   - host_usb30_0_test_powerdown_ssp0x0
>   - host_usb30_0_test_burnin   0x0
>   - host_usb30_0_acjt_level0x14
>   - host_usb30_0_lane0_tx2rx_loopbk0x0
>   - host_usb30_0_rtune_req 0x0
> 
> host_usb30_0_status: 0x2e80c
>   - host_usb30_0_phystatus 0x0
>   - host_usb30_0_usb2_p0_pp0x1
>   - host_usb30_0_usb3_p0_pp0x1
>   - host_usb30_0_usb3_sleep0x0
>   - host_usb30_0_rtune_ack 0x0
> 
> host_usb30_0_clk_rst_0: 0x2e810
>   - host_usb30_0_commononn 0x1
>   - host_usb30_0_portreset 0x0
>   - host_usb30_0_refclksel 0x2
>   - host_usb30_0_teneable  0x1
>   - host_usb30_0_fsel  0x27
>   - host_usb30_0_mpll_multiplier   0x19
>   - host_usb30_0_ref_clkdiv2   0x0
>   - host_usb30_0_ref_ssp_en0x1
>   - host_usb30_0_ref_use_pad   0x0
>   - host_usb30_0_ssc_en0x1
>   - host_usb30_0_ssc_range 0x0
> 
> host_usb30_0_clk_rst_1: 0x2e814
>   - host_usb30_0_ssc_ref_clk_sel   0x88
>   - host_usb30_0_sleepm0x1
>   - host_usb30_0_vbusvldext0x1
> 
> host_usb30_0_param_0: 0x2e818
>   - host_usb30_0_compdistune   0x4
>   - host_usb30_0_otgtune   0x4
>   - host_usb30_0_sqrxtune  0x3
>   - host_usb30_0_txfsltune 0x3
>   - host_usb30_0_txhsxvtune0x3
>   - host_usb30_0_txpreempltune 0x0
>   - host_usb30_0_txpreemppulsetune 0x0
>   - host_usb30_0_txrestune 0x1
>   - host_usb30_0_txrisetune0x2
>   - host_usb30_0_txvreftune0x4
> 
> host_usb30_0_param_1: 0x2e81c
>   - host_usb30_0_los_bias  0x5
>   - host_usb30_0_los_level 0xc
>   - host_usb30_0_pcs_rx_los_mask_val   0xf0
>   - host_usb30_0_pcs_tx_deemph_3p5db   0x18
>   - host_usb30_0_pcs_tx_deemph_6db 0x21
> 
> host_usb30_0_param_2: 0x2e820
>   - host_usb30_0_pcs_tx_swing_full 0x73
>   - host_usb30_0_lane0_tx_term_offset  0x0
>   - host_usb30_0_tx_vboost_lvl 0x4
> 
> host_usb30_0_SNPS_CR_ADD: 0x2e880
>   - host_usb30_0_snps_cr_add   0xe03c

This is obviously the PHY registers.

Commonly, the 

Re: Aw: Re: [PATCH] usb: gadget: udc: core: fix return code of usb_gadget_probe_driver()

[Krzysztof Opasiak]

On 12/03/2016 07:47 PM, Felix Hädicke wrote:
> Hi,
> 
>> On 12/01/2016 10:44 PM, Felix Hädicke wrote:
>>> Hi,
>>>
 Hi,

 Good catch but I have a few comments to commit message:

 On 12/01/2016 12:24 AM, Felix Hädicke wrote:
> This fixes a regression which was introduced by commit f1bddbb, by
> reverting a small fragment of commit 855ed04.
>
 Not exactly. The regression has been introduced by commit 855ed04
 itself.This commit replaced previous construction similar what you sent
 now with simple if():

 @@ -535,11 +556,7 @@ int usb_gadget_probe_driver(struct
 usb_gadget_driver *driver)
 if (!ret)
 break;
 }
 -   if (ret)
 -   ret = -ENODEV;
 -   else if (udc->driver)
 -   ret = -EBUSY;
 -   else
 +   if (!ret && !udc->driver)
 goto found;
 } else {
 list_for_each_entry(udc, _list, list) {
>>>
>>> The regression bug I want to fix with this patch was introduced with
>>> commit f1bddbb, not 855ed04. With 855ed04, the this if/else construct
>>> was changed. But concerning the usb_gadget_probe_driver() return code,
>>> this was ok. 
>>
>> Nope. Return code was 0 and gadget has not been bound to any udc but
>> added to pending list. Consider the following sequence:
>>
>> echo "udc" > g1/UDC
>> echo "udc" > g2/UDC
>> echo "" > g1/UDC
>>
>> The expected result is that second line should fail with EBUSY. And
>> without f1bddbb the returned value will be 0 and g2 will be pending on a
>> list. After line 3 udc will be free but g2 will still be hanging on a
>> pending list.
> 
> As I understand 855ed04, it is the new expected behaviour that
> usb_gadget_probe_driver() returns 0, even if there is no UDC (with the
> given name) available yet, or another gadget driver is already active.

At least for configfs gadgets this should fail with -EBUSY.

> So there is no bug here (at least none concerning the
> usb_gadget_probe_driver() return code).
> 
> But with commit f1bddbb, there is a new code path in which a strcmp()
> return code is returned from usb_gadget_probe_driver(), which does not
> make sense.
> 
> And the issue you are describing is still there, my patch does not fix it:
> 1. rmmod 
> 2. modprobe 
> 2. modprobe 
> 3. modprobe 
> The first gadget driver is now active.
> 4. rmmod 
> -> The second driver is not activated (although it is in the pending list).
> 

True, but only for gadget's which didn't specify udc_name and all
gadgets composed using ConfigFS specify this (that's why I gave you
configfs example above). Nevertheless for legacy gadgets which don't
specify udc_name this should be also fixed. I'll submit a patch in a moment.

>>
>>> There was no code path were a value which was not meant to
>>> be the function return code was accidentally returned. With commit
>>> f1bddbb, and the introduction of a new code path for the flag
>>> match_existing_only, this changed.
>>>
>>
>> This flag changed the error from "leave it on the list forever when udc
>> is busy" to "NULL ptr dereference" which is obviously much worse.
>>
 After that commit, if UDC is busy, gadget is added to the list of
 pending gadgets. Unfortunately this list is not rescanned in
 usb_gadget_unregister_driver(). This means that such gadget is going to
 stay on this list forever so it's a bug.
>>>
>>> Ok, I can confirm this bug. But it is not the issue which I am
>>> addressing with this patch. This is just about the
>>> usb_gadget_probe_driver() return code (on which other functions,
>>> paritcularly gadget configfs's|gadget_dev_desc_UDC_store|() rely).
>>>
>>
>> This commit fixes both f1bddbb and 855ed04 just the bug is a little bit
>> different but it's still a bug.
>>
 Commit f1bddbb make this bug more visible (as it causes NULL pointer
 dereference) as gadget has not been added to the list of pending gadgets
 and we try to remove it from there.

 Summing up, in my personal opinion I think that you should add:

 Fixes: 855ed04 ("usb: gadget: udc-core: independent registration of
 gadgets and gadget drivers")
>>>
>>> As explained above, I think this would be wrong.
>>>
>>
>> I understand that your target was to fix NULL ptr dereference but you
>> can kill two birds with the same stone as you fix also the previous bug;).
>>
>> I suggested to place commit 855ed04 instead of f1bddbb because 855ed04
>> appears earlier in a tree and even if someone doesn't have f1bddbb your
>> patch is useful for him because it fix a bug introduced in that commit
>> (gadget pending forever).
> 
> But it didn't introduce the bug which is fixed with this patch.
> 

Ok, leave it as is.

Best regards,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send 

[PATCH 2/2] usb: host: xhci: Handle the right timeout command

[Baolin Wang]

If a command event is found on the event ring during an interrupt,
we need to stop the command timer with del_timer(). Since del_timer()
can fail if the timer is running and waiting on the xHCI lock, then
it maybe get the wrong timeout command in xhci_handle_command_timeout()
if host fetched a new command and updated the xhci->current_cmd in
handle_cmd_completion(). For this situation, we need a way to signal
to the command timer that everything is fine and it should exit.

We should introduce a counter (xhci->current_cmd_pending) for the number
of pending commands. If we need to cancel the command timer and del_timer()
succeeds, we decrement the number of pending commands. If del_timer() fails,
we leave the number of pending commands alone.

For handling timeout command, in xhci_handle_command_timeout() we will check
the counter after decrementing it, if the counter (xhci->current_cmd_pending)
is 0, which means xhci->current_cmd is the right timeout command. If the
counter (xhci->current_cmd_pending) is greater than 0, which means current
timeout command has been handled by host and host has fetched new command as
xhci->current_cmd, then just return and wait for new current command.

Signed-off-by: Baolin Wang 
---
 drivers/usb/host/xhci-ring.c |   29 -
 drivers/usb/host/xhci.h  |1 +
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 9965a4c..edc9ac2 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1253,6 +1253,7 @@ static void xhci_handle_stopped_cmd_ring(struct xhci_hcd 
*xhci,
if ((xhci->cmd_ring->dequeue != xhci->cmd_ring->enqueue) &&
!(xhci->xhc_state & XHCI_STATE_DYING)) {
xhci->current_cmd = cur_cmd;
+   xhci->current_cmd_pending++;
mod_timer(>cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
xhci_ring_cmd_db(xhci);
}
@@ -1269,11 +1270,27 @@ void xhci_handle_command_timeout(unsigned long data)
xhci = (struct xhci_hcd *) data;
 
spin_lock_irqsave(>lock, flags);
+   xhci->current_cmd_pending--;
+
if (!xhci->current_cmd) {
spin_unlock_irqrestore(>lock, flags);
return;
}
 
+   /*
+* If the current_cmd_pending is 0, which means current command is
+* timeout.
+*
+* If the current_cmd_pending is greater than 0, which means current
+* timeout command has been handled by host and host has fetched new
+* command as xhci->current_cmd, then just return and wait for new
+* current command.
+*/
+   if (xhci->current_cmd_pending > 0) {
+   spin_unlock_irqrestore(>lock, flags);
+   return;
+   }
+
if (xhci->current_cmd->status == COMP_CMD_ABORT)
second_timeout = true;
xhci->current_cmd->status = COMP_CMD_ABORT;
@@ -1282,6 +1299,8 @@ void xhci_handle_command_timeout(unsigned long data)
hw_ring_state = xhci_read_64(xhci, >op_regs->cmd_ring);
if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
(hw_ring_state & CMD_RING_RUNNING))  {
+   /* Will add command timer again to wait for abort event */
+   xhci->current_cmd_pending++;
spin_unlock_irqrestore(>lock, flags);
xhci_dbg(xhci, "Command timeout\n");
ret = xhci_abort_cmd_ring(xhci);
@@ -1336,7 +1355,13 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
 
cmd = list_entry(xhci->cmd_list.next, struct xhci_command, cmd_list);
 
-   del_timer(>cmd_timer);
+   /*
+* If the command timer is running on another CPU, we don't decrement
+* current_cmd_pending, since we didn't successfully stop the command
+* timer.
+*/
+   if (del_timer(>cmd_timer))
+   xhci->current_cmd_pending--;
 
trace_xhci_cmd_completion(cmd_trb, (struct xhci_generic_trb *) event);
 
@@ -1427,6 +1452,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
if (cmd->cmd_list.next != >cmd_list) {
xhci->current_cmd = list_entry(cmd->cmd_list.next,
   struct xhci_command, cmd_list);
+   xhci->current_cmd_pending++;
mod_timer(>cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
} else if (xhci->current_cmd == cmd) {
xhci->current_cmd = NULL;
@@ -3927,6 +3953,7 @@ static int queue_command(struct xhci_hcd *xhci, struct 
xhci_command *cmd,
if (xhci->cmd_list.next == >cmd_list &&
!timer_pending(>cmd_timer)) {
xhci->current_cmd = cmd;
+   xhci->current_cmd_pending++;
mod_timer(>cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
}
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index