Re: [PATCH] USB: quirks: Fix another ELAN touchscreen

[Oliver Neukum]

On Mon, 2015-11-23 at 18:37 +0100, Adrien Vergé wrote:
> > Makes one wonder however whether we shouldn't be applying
> ALWAYS_POLL to
> > all ELAN devices by default anyway.
> 
> True! But I don't want to risk breaking anything on other models in
> this patch.

ALWAYS_POLL just extends an existing behavior. The chances
of breaking anything are slim. I'd go for the approach
based on the vendor ID.

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 v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Peter Chen]

On Mon, Nov 23, 2015 at 10:32:53AM -0500, Alan Stern wrote:
> On Mon, 23 Nov 2015, Marek Szyprowski wrote:
> 
> > From: Ruslan Bilovol 
> > 
> > Change behavior during registration of gadgets and
> > gadget drivers in udc-core. Instead of previous
> > approach when for successful probe of usb gadget driver
> > at least one usb gadget should be already registered
> > use another one where gadget drivers and gadgets
> > can be registered in udc-core independently.
> > 
> > Independent registration of gadgets and gadget drivers
> > is useful for built-in into kernel gadget and gadget
> > driver case - because it's possible that gadget is
> > really probed only on late_init stage (due to deferred
> > probe) whereas gadget driver's probe is silently failed
> > on module_init stage due to no any UDC added.
> > 
> > Also it is useful for modules case - now there is no
> > difference what module to insert first: gadget module
> > or gadget driver one.
> > 
> > Tested-by: Maxime Ripard 
> > Signed-off-by: Ruslan Bilovol 
> > [simplified code as requested by Alan Stern and Felipe Balbi,
> >  fixed checkpatch issues]
> > Signed-off-by: Marek Szyprowski 
> > Tested-by: Peter Chen 
> 
> I missed this the last time through...
> 
> > @@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, 
> > struct usb_gadget *gadget,
> > usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
> > udc->vbus = true;
> >  
> > +   /* pick up one of pending gadget drivers */
> > +   list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
> > +   if (!driver->udc_name || strcmp(driver->udc_name,
> > +   dev_name(&udc->dev)) == 0) {
> > +   ret = udc_bind_to_driver(udc, driver);
> > +   if (ret)
> > +   goto err4;
> > +   list_del(&driver->pending);
> 
> This has to be list_del_init().  And somewhere in
> usb_gadget_probe_driver() you need to do
> INIT_LIST_HEAD(&driver->pending).
> 
> > @@ -577,6 +596,10 @@ int usb_gadget_unregister_driver(struct 
> > usb_gadget_driver *driver)
> > break;
> > }
> >  
> > +   if (ret) {
> > +   list_del(&driver->pending);
> 
> Otherwise this will cause a crash or corrupt some random area of 
> memory.
> 

Alan, would you please explain more what use case will cause memory
corruption for above code?

-- 

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

Re: [PATCH v3 6/8] usb: dwc2: host: Assume all devices are on one single_tt hub

[Doug Anderson]

John,

On Thu, Nov 19, 2015 at 8:33 PM, John Youn  wrote:
> Patches 1-3:
> Acked-by: John Youn 
>
> Patch 2:
> Tested-by: John Youn 
>
> Tested on core version 3.20 using internal TE for un-aligned
> buffers.
>
> I haven't had time to look into the scheduling patches yet. But I
> agree with you that there are fundamental problems. I'll await
> your rewrite.

Thanks!  I'm going to attempt to at least get things reposted with
your tags before Thanksgiving.  I'm hopeful that I'll actually be able
to post a RFC patch for the microframe rewrite by then, too!  :)

I have something that seems to be sane at
, but it
obviously still needs a lot of cleanup.  I also need to pick all of
the things that have landed on Felipe's tree recently and rebase atop
those.

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

[PATCH] USB: MUSB: fail with error when no DMA controller set

[Aaro Koskinen]

Fail with error when no DMA controller is set.

Signed-off-by: Aaro Koskinen 
---
 drivers/usb/musb/musb_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 18cfc0a..f8d3b40 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2095,6 +2095,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 #ifndef CONFIG_MUSB_PIO_ONLY
if (!musb->ops->dma_init || !musb->ops->dma_exit) {
dev_err(dev, "DMA controller not set\n");
+   status = -ENODEV;
goto fail2;
}
musb_dma_controller_create = musb->ops->dma_init;
-- 
2.4.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 v4 3/3] usb: chipidea: register driver as a peripheral with the phy

[Tim Bird]

On 11/23/2015 12:29 AM, Peter Chen wrote:
> On Fri, Nov 20, 2015 at 03:47:20PM -0800, Tim Bird wrote:
>> Register the chipidea driver with the phy, so that the phy
>> driver can kick the gadget driver when it resumes from low power.
>> The phy-msm-usb (Qualcomm) driver requires this in order to
>> recover gadget operation after you disconnect the USB cable
>> and reconnect it.
>>
>> Signed-off-by: Tim Bird 
>> ---
>>  drivers/usb/chipidea/udc.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
>> index 8223fe7..06234cd 100644
>> --- a/drivers/usb/chipidea/udc.c
>> +++ b/drivers/usb/chipidea/udc.c
>> @@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
>>  
>>  ci->gadget.ep0 = &ci->ep0in->ep;
>>  
>> +if (ci->usb_phy) {
>> +retval = otg_set_peripheral(ci->usb_phy->otg, &ci->gadget);
>> +if (retval)
>> +goto destroy_eps;
>> +}
>> +
>>  retval = usb_add_gadget_udc(dev, &ci->gadget);
>>  if (retval)
>>  goto destroy_eps;
> 
> Hi Tim,
> 
> I am afraid it can't work for current chipidea framework (find this
> problem after testing), the chipidea core manages its host and device
> function using its own API start/stop, it does not define struct usb_otg
> APIs. In fact, it is not reasonable control host and device function
> at PHY driver.

OK.  I'm going to re-evaluate the phy-msm-usb.c code, and try to figure out
what it should look like under the current framework.

Thanks for looking at it and testing it.  I may have questions as I go.
 -- Tim

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

[PATCH v2] USB: quirks: Fix another ELAN touchscreen

[Adrien Vergé]

Like other buggy models that had their fixes [1], the touchscreen with
id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
quirk. Otherwise, it fails to respond, blocks the boot for a random
amount of time and pollutes dmesg with:

[ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
[ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2889.502005] usb 1-5: can't read configurations, error -71
[ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
[ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2891.783443] usb 1-5: can't read configurations, error -71

[1]: See commits c68929f, 876af5d, d749947, a32c99e and dc703ec.

Tested-by: Adrien Vergé 
Signed-off-by: Adrien Vergé 
Acked-by: Jiri Kosina 
---
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/usbhid/hid-quirks.c | 1 +
 drivers/usb/core/quirks.c   | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ac1feea..6b68408 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -321,6 +321,7 @@
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN_01030x0103
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN_010c0x010c
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F0x016f
+#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_21B80x21b8
 
 #define USB_VENDOR_ID_ELECOM   0x056e
 #define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 94bb137..7a45942 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -77,6 +77,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_0103, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_010c, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F, 
HID_QUIRK_ALWAYS_POLL },
+   { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_21B8, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, 
HID_QUIRK_NOGET },
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index f5a3819..fcd6ac0 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -125,6 +125,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x04f3, 0x016f), .driver_info =
USB_QUIRK_DEVICE_QUALIFIER },
 
+   { USB_DEVICE(0x04f3, 0x21b8), .driver_info =
+   USB_QUIRK_DEVICE_QUALIFIER },
+
/* Roland SC-8820 */
{ USB_DEVICE(0x0582, 0x0007), .driver_info = USB_QUIRK_RESET_RESUME },
 
-- 
2.5.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] USB: quirks: Fix another ELAN touchscreen

[Adrien Vergé]

2015-11-23 15:52 GMT+01:00 Jiri Kosina :

> The drivers/hid part is
>
> Acked-by: Jiri Kosina 

Thanks.

> Makes one wonder however whether we shouldn't be applying ALWAYS_POLL to
> all ELAN devices by default anyway.

True! But I don't want to risk breaking anything on other models in this patch.

I'll submit a v2 with appropriate signed-off-by and acked-by.
--
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

[GIT PULL] USB fixes for v4.4-rc3

[Felipe Balbi]

Hi Greg,

Here's my second round of fixes for current -rc as promissed.

Let me know if you want anything to be changed, but response
may be slow.

'vacation-mode' is a major mode which prevents emacs from being
used :-p

regards

The following changes since commit d134c48d889ddceadf4c990e6f3df16b816ed5d4:

  usb: gadget: atmel_usba_udc: Expose correct device speed (2015-11-17 11:35:49 
-0600)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v4.4-rc3

for you to fetch changes up to f74875dc36135ebae82a8e005f4b7f52289d2c40:

  usb: dwc2: fix kernel oops during driver probe (2015-11-20 09:29:47 -0600)


usb: fixes for v4.4-rc3

Here's our second round of fixes. Some of the bugs are pretty old like
the one on pxa27x suspend implementation.

The most important part is a randbuild warning fix on MUSB CPPI DMA
engine by Arnd, a couple fixes by Felipe Tonello on f_midi (first one
makes sure we only transmit on enabled ep IN while second plugs a memory
leak) and a NULL pointer dereference fix on renesas usbhs.

Note that we also have a new compatible string being added for the MXS
PHY.


Arnd Bergmann (1):
  usb: musb: USB_TI_CPPI41_DMA requires dmaengine support

Daniel Walter (1):
  usb: gadget: functionfs: fix missing access_ok checks

Felipe Balbi (1):
  usb: gadget: pxa27x: fix suspend callback

Felipe F. Tonello (2):
  usb: gadget: f_midi: Transmit data only when IN ep is enabled
  usb: gadget: f_midi: fix leak on failed to enqueue out requests

John Youn (1):
  usb: dwc2: Make PHY optional

Peter Chen (2):
  usb: kconfig: fix warning of select USB_OTG
  usb: phy: mxs: add "fsl,imx6ul-usbphy" compatible string

Stefan Wahren (3):
  usb: dwc2: Return errors from PHY
  usb: dwc2: make otg clk optional
  usb: dwc2: fix kernel oops during driver probe

Yoshihiro Shimoda (1):
  usb: renesas_usbhs: gadget: Fix NULL pointer dereference in 
usbhsg_ep_dequeue()

 drivers/usb/core/Kconfig   |  3 +-
 drivers/usb/dwc2/platform.c| 81 ++
 drivers/usb/gadget/function/f_fs.c |  6 +--
 drivers/usb/gadget/function/f_midi.c   |  3 +-
 drivers/usb/gadget/udc/pxa27x_udc.c|  3 ++
 drivers/usb/musb/Kconfig   |  2 +-
 drivers/usb/phy/Kconfig|  4 +-
 drivers/usb/phy/phy-mxs-usb.c  |  5 +++
 drivers/usb/renesas_usbhs/mod_gadget.c | 11 -
 9 files changed, 78 insertions(+), 40 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [4.3] kworker busy in pm_runtime_work

[Alan Stern]

On Sun, 22 Nov 2015, Daniel J Blueman wrote:

> On 16 November 2015 at 23:22, Alan Stern  wrote:
> > On Mon, 16 Nov 2015, Daniel J Blueman wrote:
> >
> >> Tuning USB suspend [1] in 4.3 on a Dell XPS 15 9553 (Skylake), I see a
> >> kworker thread spinning in rpm_suspend [2].
> >>
> >> What is the most useful debug to get here beyond the immediate [3]?
> >
> > You can try doing:
> >
> > echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
> 
> kworker and ksoftirqd spinning occurs when I echo 'auto' to all the
> USB control entries. Using Alan's excellent tip, we see this being
> logged repeatedly at a high rate:
> [  353.245180] usb usb1-port4: status 0107 change 
> [  353.245194] usb usb1-port12: status 0507 change 
> [  353.245202] hub 1-0:1.0: state 7 ports 16 chg  evt 
> [  353.245203] hub 1-0:1.0: hub_suspend
> [  353.245205] usb usb1: bus auto-suspend, wakeup 1
> [  353.245206] usb usb1: bus suspend fail, err -16
> [  353.245207] hub 1-0:1.0: hub_resume
> ...
> 
> So, EBUSY. Both the webcam is not open, and the bluetooth interface
> [1] is rfkill'd; the situation occurs even if I unload all related
> modules.
> 
> What further debug would be useful?
> 
> Thanks!
>   Daniel
> 
> -- [1]
> 
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp.
> Bus 001 Device 003: ID 1bcf:2b95 Sunplus Innovation Technology Inc.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Since bus 1 uses an xHCI controller, you should do:

echo 'module xhci-hcd =p' >/sys/kernel/debug/dynamic_debug/control

I'm reasonably sure this will end up printing "suspend failed 
because a port is resuming", since that's the only place where 
xhci_bus_suspend() fails with -EBUSY, but you should try it to confirm 
this.

Alan Stern

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

Re: [PATCH v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Alan Stern]

On Mon, 23 Nov 2015, Marek Szyprowski wrote:

> From: Ruslan Bilovol 
> 
> Change behavior during registration of gadgets and
> gadget drivers in udc-core. Instead of previous
> approach when for successful probe of usb gadget driver
> at least one usb gadget should be already registered
> use another one where gadget drivers and gadgets
> can be registered in udc-core independently.
> 
> Independent registration of gadgets and gadget drivers
> is useful for built-in into kernel gadget and gadget
> driver case - because it's possible that gadget is
> really probed only on late_init stage (due to deferred
> probe) whereas gadget driver's probe is silently failed
> on module_init stage due to no any UDC added.
> 
> Also it is useful for modules case - now there is no
> difference what module to insert first: gadget module
> or gadget driver one.
> 
> Tested-by: Maxime Ripard 
> Signed-off-by: Ruslan Bilovol 
> [simplified code as requested by Alan Stern and Felipe Balbi,
>  fixed checkpatch issues]
> Signed-off-by: Marek Szyprowski 
> Tested-by: Peter Chen 

I missed this the last time through...

> @@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, 
> struct usb_gadget *gadget,
>   usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
>   udc->vbus = true;
>  
> + /* pick up one of pending gadget drivers */
> + list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
> + if (!driver->udc_name || strcmp(driver->udc_name,
> + dev_name(&udc->dev)) == 0) {
> + ret = udc_bind_to_driver(udc, driver);
> + if (ret)
> + goto err4;
> + list_del(&driver->pending);

This has to be list_del_init().  And somewhere in
usb_gadget_probe_driver() you need to do
INIT_LIST_HEAD(&driver->pending).

> @@ -577,6 +596,10 @@ int usb_gadget_unregister_driver(struct 
> usb_gadget_driver *driver)
>   break;
>   }
>  
> + if (ret) {
> + list_del(&driver->pending);

Otherwise this will cause a crash or corrupt some random area of 
memory.

Alan Stern

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

Re: Not enough host controller resources for new device state

[Alan Stern]

On Mon, 23 Nov 2015, Patrick Shirkey wrote:

> Thanks Alan,
> 
> FYI, running these commands exhibits some interesting behavior on my machine.
> 
> Unbinding disables all external ports.
> 
> [7946053.417529] xhci_hcd :00:14.0: remove, state 4
> [7946053.417537] usb usb4: USB disconnect, device number 1
> [7946053.418082] xhci_hcd :00:14.0: USB bus 4 deregistered
> [7946053.418091] xhci_hcd :00:14.0: remove, state 1
> [7946053.418110] usb usb3: USB disconnect, device number 1
> [7946053.418112] usb 3-1: USB disconnect, device number 2
> [7946053.469171] usb 3-2: USB disconnect, device number 3
> [7946053.469643] sd 196:0:0:0: [sdf] Synchronizing SCSI cache
> [7946053.469692] sd 196:0:0:0: [sdf] Synchronize Cache(10) failed: Result:
> hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
> [7946053.503557] usb 3-3: USB disconnect, device number 4
> [7946053.531384] usb 3-4: USB disconnect, device number 5
> [7946053.531389] usb 3-4.1: USB disconnect, device number 7
> [7946053.531392] usb 3-4.1.1: USB disconnect, device number 10
> [7946053.531394] usb 3-4.1.1.5: USB disconnect, device number 14
> [7946053.532460] usb 3-4.2: USB disconnect, device number 9
> [7946053.532465] usb 3-4.2.1: USB disconnect, device number 12
> [7946053.532468] usb 3-4.2.1.5: USB disconnect, device number 17
> [7946053.533093] usb 3-4.2.2: USB disconnect, device number 15
> [7946053.533402] usb 3-4.2.5: USB disconnect, device number 19
> [7946053.535962] usb 3-4.3: USB disconnect, device number 11
> [7946053.535967] usb 3-4.3.1: USB disconnect, device number 16
> [7946053.535970] usb 3-4.3.1.1: USB disconnect, device number 21
> [7946053.536309] usb 3-4.3.1.3: USB disconnect, device number 24
> [7946053.536559] usb 3-4.3.1.4: USB disconnect, device number 27
> [7946053.536659] usb 3-4.3.1.5: USB disconnect, device number 30
> [7946053.537003] usb 3-4.3.7: USB disconnect, device number 20
> [7946053.539933] usb 3-4.4: USB disconnect, device number 13
> [7946053.539938] usb 3-4.4.1: USB disconnect, device number 18
> [7946053.539941] usb 3-4.4.1.1: USB disconnect, device number 23
> [7946053.539944] usb 3-4.4.1.1.5: USB disconnect, device number 28
> [7946053.542235] usb 3-4.4.1.5: USB disconnect, device number 25
> [7946053.542711] usb 3-4.4.1.7: USB disconnect, device number 29
> [7946053.543885] usb 3-4.4.2: USB disconnect, device number 22
> [7946053.543890] usb 3-4.4.2.1: USB disconnect, device number 26
> [7946053.546309] usb 3-5: USB disconnect, device number 6
> [7946053.546968] usb 3-7: USB disconnect, device number 8
> [7946053.613004] xhci_hcd :00:14.0: USB bus 3 deregistered
> 
> 
> 
> I see the following with lsusb after unbinding:
> 
> # lsusb
> Bus 002 Device 002: ID 8087:8000 Intel Corp.
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 002: ID 8087:8008 Intel Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> - Un/plugging devices appears to have no effect:
> 
> - Binding enables all external ports again without un/plugging.
> 
> Does this behavior suggest that even if I disable xHCI at BIOS level I may
> not be able to use the eHCI controllers stand alone on this machine or is
> there something else I can tweak at the system level?

I can't tell.  The easiest way to find out is to try it and see what 
happens.

As far as I can see there's nothing left in the kernel for you to
tweak, aside perhaps from building a kernel with no xHCI support at
all.

Alan Stern

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

Re: [Linux USB] enable/disable individual ports

[Alan Stern]

On Mon, 23 Nov 2015, Peter Stuge wrote:

> Alan Stern wrote:
> > > > > It does print out a message, though not a big one.  Would you like it
> > > > > to do something more specific?  A more verbose "usage" message,
> > > > > perhaps?
> > > > 
> > > > That's a good idea, and additionally I think it would be important to
> > > > print (much) more information if the ioctl() fails.
> > > 
> > > I agree.
> > 
> > What more is there to print?  If the ioctl fails, all the program gets
> > back from the kernel is an error code, which it already prints out.  I
> > wouldn't mind adding something else, if anybody can suggest what it
> > might be.
> 
> Information about possible reasons for failure, in particular
> that this operation may simply not be supported by the hardware.
> 
> Ideally even have a special case for that, with overly clear text,
> if it is indeed possible to determine from the error code that this
> is the cause.

USB hardware always supports reset.  Any device that didn't support it 
would be unusable.

The very first thing that Linux does when it detects a new device has 
been plugged into a port is issue a reset.  The same is true for 
Windows.

Now, lots of other things can go wrong.  For example, it may not be
possible to disable Link Power Management prior to doing the reset.  
Or the device's descriptors may change because a firmware update was
installed and activated by the reset.  Or it may even be something as
simple as the device disconnecting from the bus before or during the
reset.

The error codes don't distinguish among all of these possibilities.  
Still, I'll see what I can do.

Alan Stern

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

Re: [PATCH] USB: quirks: Fix another ELAN touchscreen

[Jiri Kosina]

On Sat, 21 Nov 2015, Adrien Vergé wrote:

> Like other buggy models that had their fixes [1], the touchscreen with
> id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
> quirk. Otherwise, it fails to respond, blocks the boot for a random
> amount of time and pollutes dmesg with:
> 
> [ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
> [ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
> [ 2889.502005] usb 1-5: can't read configurations, error -71
> [ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
> [ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
> [ 2891.783443] usb 1-5: can't read configurations, error -71

The drivers/hid part is

Acked-by: Jiri Kosina 

Makes one wonder however whether we shouldn't be applying ALWAYS_POLL to 
all ELAN devices by default anyway.

> [1]: See commits c68929f, 876af5d, d749947, a32c99e and dc703ec.
> 
> Tested-by: Adrien Vergé 

You need signoff here as well so that the patch can be applied.

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
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] ARM: tegra: select USB_ULPI from EHCI rather than platform

[Thierry Reding]

On Mon, Nov 23, 2015 at 02:51:29PM +0100, Arnd Bergmann wrote:
> For historic reasons, the tegra platform selects USB_ULPI from architecture
> code, but that hasn't really made sense for a long time, as the only
> user of that code is the Tegra EHCI driver that has its own Kconfig
> symbol.
> 
> This removes the 'select' statements from mach-tegra and drivers/soc/tegra
> and adds them with the device driver that actually needs them.
> 
> Signed-off-by: Arnd Bergmann 
> ---
> Tegra maintainers, can you pick this up for 4.5? There is no real bug here,
> but I found this when looking at something else in drivers/usb/phy.

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: Not enough host controller resources for new device state

[Mathias Nyman]

On 23.11.2015 04:31, Alan Stern wrote:

On Sun, 22 Nov 2015, Peter Stuge wrote:


Patrick Shirkey wrote:

if the kernel does have support for xHCI, we assume that
the user will prefer xHCI over EHCI if the motherboard has xHCI.


Obviously the solution above should suffice for my purposes but out
of interest is it viable to make the switch accessible to run time
configuration?


I don't think it makes sense to expose the port routing to user
space, but I think it would make sense to route ports to the EHCI HC(s)
when xhci-hcd is unbound, and vice versa.

I'm not sure what the best implementation for this would be. Would it
be possible for ehci-hcd to call into xhci-hcd code, even if xhci-hcd
is not currently bound anywhere?

One possibility is to add code to both drivers which gets called on
unbind and which routes ports to the respective other controller type,
but that doesn't really seem like a great solution. It would be nicer
to have a single entry point for the (re)routing.

Alan, what are your thoughts on that?


In general it's best not to make things too complicated.  Perhaps the
switch could be changed at runtime, say whenever xhci-hcd binds to or
unbinds from the motherboard's controller.  But this could have
undesirable consequences.

For example, if xhci-hcd is a little slow to load (say because it's in
a loadable module that takes some time to install), a USB-3 disk drive
might start out connecting to the EHCI controller and being mounted.
Then when the switch setting is changed, the disk would be forcibly
disconnected from EHCI, which could mess up any writes that were in
progress, not to mention causing a number of alarming messages to show
up in the system log.

I'd like to hear what Mathias says before making any definite
suggestions.



Port switching is done in xHCI PCI config space.
The current implementation is a pci hook in pci-quirks.c that once a Intel xHCI 
controller is found
will switch over the ports from EHCI to xHCI if:

  a) there is also a Intel EHCI controller present
  b) there is a driver available for the xHCI controller (xhci-hcd)

This is done before ehci-hcd and xhci-hcd are loaded, so they don't need to 
worry about
disappearing, or magically appearing ports.

I'm not sure how ehci-hcd will handle sudden new ports if we switch ports from 
xHCI to EHCI at xhci-hcd unbind.
Also, as Alan said, the other way around can cause issues. Switching a port to 
xHCI if it has a device working under
EHCI can cause corruption etc.

Trying to make a automatic runtime port switching based on ehci and xhci 
bind/unbind can become complicated
Maybe instead a manual crank to switch ports, but only when both xhci and ehci 
are unbound

-Mathias

   


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

[PATCH] usb: phy: allow modular build of DT helper

[Arnd Bergmann]

This one is a curious Kbuild glitch: The drivers/usb/phy/of.o file
is currently always built-in if CONFIG_OF is set, independent of
whether USB is modular or not.

For the case of CONFIG_USB=m && CONFIG_USB_GADGET=m && CONFIG_USB_PHY=n,
however the file is not built at all, because drivers/Makefile only
looks in drivers/usb/ for modules and not for built-in code. This
results in a link error with in the chipidea module:

ERROR: of_usb_get_phy_mode [drivers/usb/chipidea/ci_hdrc.ko] undefined!

To work around this behavior, this changes the usb-phy Makefile to
create a module named usb-phy-of.ko for this one file whenever
both CONFIG_USB and CONFIG_USB_GADGET are set to 'm'. This seems
to be the correct behavior as it also avoids unnecessary built-in
code when everything else related to USB is a module, and it nicely
avoids the link error.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 19c0dccbb116..4367fbc1870b 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -2,7 +2,11 @@
 # Makefile for physical layer USB drivers
 #
 obj-$(CONFIG_USB_PHY)  += phy.o
-obj-$(CONFIG_OF)   += of.o
+
+ifdef CONFIG_OF
+usb-phy-of-objs:= of.o
+obj-$(CONFIG_USB_COMMON)   += usb-phy-of.o
+endif
 
 # transceiver drivers, keep the list sorted
 

--
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] ARM: tegra: select USB_ULPI from EHCI rather than platform

[Arnd Bergmann]

For historic reasons, the tegra platform selects USB_ULPI from architecture
code, but that hasn't really made sense for a long time, as the only
user of that code is the Tegra EHCI driver that has its own Kconfig
symbol.

This removes the 'select' statements from mach-tegra and drivers/soc/tegra
and adds them with the device driver that actually needs them.

Signed-off-by: Arnd Bergmann 
---
Tegra maintainers, can you pick this up for 4.5? There is no real bug here,
but I found this when looking at something else in drivers/usb/phy.

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 11963667c6a9..32239aff1051 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -12,7 +12,5 @@ menuconfig ARCH_TEGRA
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
-   select USB_ULPI if USB_PHY
-   select USB_ULPI_VIEWPORT if USB_PHY
help
  This enables support for NVIDIA Tegra based systems.
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 7e35dfe52af5..d0c3c3e085e3 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -57,8 +57,6 @@ if ARM64
 config ARCH_TEGRA_132_SOC
bool "NVIDIA Tegra132 SoC"
select PINCTRL_TEGRA124
-   select USB_ULPI if USB_PHY
-   select USB_ULPI_VIEWPORT if USB_PHY
help
  Enable support for NVIDIA Tegra132 SoC, based on the Denver
  ARMv8 CPU.  The Tegra132 SoC is similar to the Tegra124 SoC,
@@ -68,8 +66,6 @@ config ARCH_TEGRA_132_SOC
 config ARCH_TEGRA_210_SOC
bool "NVIDIA Tegra210 SoC"
select PINCTRL_TEGRA210
-   select USB_ULPI if USB_PHY
-   select USB_ULPI_VIEWPORT if USB_PHY
help
  Enable support for the NVIDIA Tegra210 SoC. Also known as Tegra X1,
  the Tegra210 has four Cortex-A57 cores paired with four Cortex-A53
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3bb08870148f..95e72d75e0a0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -220,6 +220,8 @@ config USB_EHCI_TEGRA
depends on ARCH_TEGRA
select USB_EHCI_ROOT_HUB_TT
select USB_PHY
+   select USB_ULPI
+   select USB_ULPI_VIEWPORT
help
  This driver enables support for the internal USB Host Controllers
  found in NVIDIA Tegra SoCs. The controllers are EHCI compliant.

--
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] net: cdc_ncm: fix NULL pointer deref in cdc_ncm_bind_common

[Bjørn Mork]

Commit 77b0a099674a ("cdc-ncm: use common parser") added a dangerous
new trust in the CDC functional descriptors presented by the device,
unconditionally assuming that any device handled by the driver has
a CDC Union descriptor.

This descriptor is required by the NCM and MBIM specs, but crashing
on non-compliant devices is still unacceptable. Not only will that
allow malicious devices to crash the kernel, but in this case it is
also well known that there are non-compliant real devices on the
market - as shown by the comment accompanying the IAD workaround
in the same function.

The Sierra Wireless EM7305 is an example of such device, having
a CDC header and a CDC MBIM descriptor but no CDC Union:

Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   12
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass 14
  bInterfaceProtocol  0
  iInterface  0
  CDC Header:
bcdCDC   1.10
  CDC MBIM:
bcdMBIMVersion   1.00
wMaxControlMessage   4096
bNumberFilters   16
bMaxFilterSize   128
wMaxSegmentSize  4064
bmNetworkCapabilities 0x20
  8-byte ntb input size
  Endpoint Descriptor:
..

The conversion to a common parser also left the local cdc_union
variable untouched.  This caused the IAD workaround code to be applied
to all devices with an IAD descriptor, which was never intended.  Finish
the conversion by testing for hdr.usb_cdc_union_desc instead.

Cc: Oliver Neukum 
Fixes: 77b0a099674a ("cdc-ncm: use common parser")
Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/cdc_ncm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index a187f08113ec..3b1ba8237768 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -691,7 +691,6 @@ static void cdc_ncm_free(struct cdc_ncm_ctx *ctx)
 
 int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 
data_altsetting, int drvflags)
 {
-   const struct usb_cdc_union_desc *union_desc = NULL;
struct cdc_ncm_ctx *ctx;
struct usb_driver *driver;
u8 *buf;
@@ -725,15 +724,16 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
usb_interface *intf, u8 data_
/* parse through descriptors associated with control interface */
cdc_parse_cdc_header(&hdr, intf, buf, len);
 
-   ctx->data = usb_ifnum_to_if(dev->udev,
-   hdr.usb_cdc_union_desc->bSlaveInterface0);
+   if (hdr.usb_cdc_union_desc)
+   ctx->data = usb_ifnum_to_if(dev->udev,
+   
hdr.usb_cdc_union_desc->bSlaveInterface0);
ctx->ether_desc = hdr.usb_cdc_ether_desc;
ctx->func_desc = hdr.usb_cdc_ncm_desc;
ctx->mbim_desc = hdr.usb_cdc_mbim_desc;
ctx->mbim_extended_desc = hdr.usb_cdc_mbim_extended_desc;
 
/* some buggy devices have an IAD but no CDC Union */
-   if (!union_desc && intf->intf_assoc && 
intf->intf_assoc->bInterfaceCount == 2) {
+   if (!hdr.usb_cdc_union_desc && intf->intf_assoc && 
intf->intf_assoc->bInterfaceCount == 2) {
ctx->data = usb_ifnum_to_if(dev->udev, 
intf->cur_altsetting->desc.bInterfaceNumber + 1);
dev_dbg(&intf->dev, "CDC Union missing - got slave from IAD\n");
}
-- 
2.1.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: Not enough host controller resources for new device state

[Oliver Neukum]

On Sun, 2015-11-22 at 21:31 -0500, Alan Stern wrote:
> In general it's best not to make things too complicated.  Perhaps the
> switch could be changed at runtime, say whenever xhci-hcd binds to or
> unbinds from the motherboard's controller.  But this could have
> undesirable consequences.

I am afraid you are fighting a losing battle. The prototypes I am
seeing are in the majority XHCI only.

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: WARNING: CPU: 0 PID: 4139 at fs/sysfs/group.c:224 sysfs_remove_group+0x93/0xa0() occured when I remove USB Logitech HD Webcam C270

[Михаил Гаврилов]

This occured when I remove USB Logitech HD Webcam C270




--
Best Regards,
Mike Gavrilov.


2015-11-23 14:30 GMT+05:00 Михаил Гаврилов :
> [   98.627543] usb 1-9.1.5: reset high-speed USB device number 9 using 
> xhci_hcd
> [  100.985706] usb 1-9.1.3: ep 0x82 - rounding interval to 64
> microframes, ep desc says 80 microframes
> [  101.960934] tun: Universal TUN/TAP device driver, 1.6
> [  101.960938] tun: (C) 1999-2004 Max Krasnyansky 
> [  101.998027] device virbr0-nic entered promiscuous mode
> [  102.164853] virbr0: port 1(virbr0-nic) entered listening state
> [  102.164868] virbr0: port 1(virbr0-nic) entered listening state
> [  102.216523] virbr0: port 1(virbr0-nic) entered disabled state
> [  102.538955] usb 1-9.1.3: ep 0x82 - rounding interval to 64
> microframes, ep desc says 80 microframes
> [  102.628882] usb 1-9.1.3: ep 0x82 - rounding interval to 64
> microframes, ep desc says 80 microframes
> [  108.885013] usb 1-9.1.3: ep 0x82 - rounding interval to 64
> microframes, ep desc says 80 microframes
> [  109.004965] usb 1-9.1.5: reset high-speed USB device number 9 using 
> xhci_hcd
> [  132.422743] DMA-API: debugging out of memory - disabling
> [  152.047039] usb 1-9.1.5: USB disconnect, device number 9
> [  152.062093] [ cut here ]
> [  152.062098] WARNING: CPU: 0 PID: 4139 at fs/sysfs/group.c:224
> sysfs_remove_group+0x93/0xa0()
> [  152.062100] sysfs group 81eed4e0 not found for kobject 'event18'
> [  152.062100] Modules linked in: xt_CHECKSUM ipt_MASQUERADE
> nf_nat_masquerade_ipv4 tun nls_utf8 isofs rfcomm fuse
> nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter
> ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge
> ebtable_filter ebtable_nat ebtables ip6table_raw ip6table_mangle
> ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
> nf_nat_ipv6 ip6table_filter ip6_tables iptable_raw iptable_mangle
> iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 nf_nat nf_conntrack bnep hid_logitech_hidpp
> hid_logitech_dj iTCO_wdt iTCO_vendor_support snd_usb_audio
> snd_usbmidi_lib ppdev snd_rawmidi uvcvideo videobuf2_vmalloc
> videobuf2_core videobuf2_memops v4l2_common vfat btrfs fat intel_rapl
> gspca_zc3xx btusb btrtl btbcm gspca_main btintel iosf_mbi videodev
> bluetooth
> [  152.062138]  media xor rfkill x86_pkg_temp_thermal
> snd_hda_codec_realtek snd_hda_codec_generic coretemp kvm_intel joydev
> kvm raid6_pq snd_hda_codec_hdmi snd_hda_codec_ca0132 crct10dif_pclmul
> crc32_pclmul snd_hda_intel crc32c_intel snd_hda_codec snd_hda_core
> snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer mei_me lpc_ich snd
> mei shpchp soundcore i2c_i801 parport_pc tpm_infineon parport tpm_tis
> tpm nfsd auth_rpcgss binfmt_misc nfs_acl lockd grace sunrpc uas
> usb_storage i915 8021q garp stp llc serio_raw i2c_algo_bit mrp
> drm_kms_helper drm r8169 mii video
> [  152.062164] CPU: 0 PID: 4139 Comm: cheese Not tainted
> 4.2.6-300.fc23.x86_64+debug #1
> [  152.062165] Hardware name: Gigabyte Technology Co., Ltd.
> Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014
> [  152.062166]   7d055486 8807714ebb88
> 81869b26
> [  152.062168]   8807714ebbe0 8807714ebbc8
> 810ac456
> [  152.062170]  8807714ebbb8  81eed4e0
> 8807f9fa51b8
> [  152.062171] Call Trace:
> [  152.062174]  [] dump_stack+0x4c/0x65
> [  152.062177]  [] warn_slowpath_common+0x86/0xc0
> [  152.062179]  [] warn_slowpath_fmt+0x55/0x70
> [  152.062181]  [] ? kernfs_find_and_get_ns+0x4e/0x60
> [  152.062183]  [] sysfs_remove_group+0x93/0xa0
> [  152.062185]  [] dpm_sysfs_remove+0x57/0x60
> [  152.062187]  [] device_del+0x58/0x270
> [  152.062189]  [] evdev_disconnect+0x27/0x60
> [  152.062191]  [] __input_unregister_device+0xb0/0x160
> [  152.062192]  [] input_unregister_device+0x4f/0x80
> [  152.062196]  [] uvc_status_cleanup+0x46/0x50 [uvcvideo]
> [  152.062197]  [] uvc_delete+0x18/0x150 [uvcvideo]
> [  152.062199]  [] uvc_release+0x23/0x30 [uvcvideo]
> [  152.062202]  [] v4l2_device_release+0xd8/0x110 [videodev]
> [  152.062203]  [] device_release+0x36/0xa0
> [  152.062206]  [] kobject_release+0x7a/0x190
> [  152.062207]  [] kobject_put+0x2f/0x60
> [  152.062208]  [] put_device+0x17/0x20
> [  152.062210]  [] v4l2_release+0x4d/0x80 [videodev]
> [  152.062212]  [] __fput+0xf5/0x200
> [  152.062214]  [] fput+0xe/0x10
> [  152.062216]  [] task_work_run+0x8d/0xc0
> [  152.062218]  [] do_notify_resume+0x8d/0x90
> [  152.062221]  [] int_signal+0x12/0x17
> [  152.06] ---[ end trace 24afe6926e4cae74 ]---
> [  152.077087] [ cut here ]
> [  152.077092] WARNING: CPU: 2 PID: 4139 at fs/sysfs/group.c:224
> sysfs_remove_group+0x93/0xa0()
> [  152.077093] sysfs group 81eed4e0 not found for kobject 'input21'
> [  152.077094] Modules linked in: xt_CHECKSUM ipt_MASQUERADE
> nf_nat_masquerade_ipv4 tun nls_utf8 isofs rfcomm fuse
> nf_conntrack_netbios_ns nf_con

Re: Udoo support for chipidea

[Peter Chen]

On Fri, Nov 20, 2015 at 11:13:00AM -0500, Alan Stern wrote:
> On Fri, 20 Nov 2015, Peter Chen wrote:
> 
> > > > > Hi Alan, we have several designs that the on-board HUB need to
> > > > > be reset by gpio pin and its clock is also from the board or
> > > > > the SoC. Any suggestions how to add these platform information
> > > > > for HUB device?
> > > > 
> > > > How about putting it in the device tree?
> > > > http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> > > > clocks and reset-gpios properties could be added to the USB hub node.
> > > 
> > > Something like this is necessary.  Instead of making the hub driver
> > > take care of the reset gpio and the clock, I suggest you make the host
> > > controller's platform driver do these things.
> > > 
> > > This is because USB hubs are generic devices, not specific to any 
> > > platform and (usually) hot-pluggable.  Associating platform-specific 
> > > data with a hub is out of the ordinary, and it deserves to be handled 
> > > by platform-specific code -- there is no such code in the hub driver.
> > > 
> > 
> > If this on-board HUB is special, its reset pin needs to be toggled
> > after power on, no matter for Intel or ARM platforms, how we handle
> > it? It is not feasible we add this for all platform drivers.
> 
> I don't know.  Probably it should be handled the same way as any other 
> hardware with special requirements.
> 
> Are you saying that it would be better to modify the hub driver than to 
> modify all the platform drivers?  If you can figure out a way to make 
> it work, then maybe -- I don't see how to do it.
> 

Yes, changing hub.c is hard, I am think if we can have a device driver
for it, and this driver can be probed through special pid/vid, but I
can't find a way to describe one USB device (eg, its external
pins/clocks) through platform code, eg, dts or acpi.

-- 

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

Re: [PATCH] USB: serial: cp210x: Remove CP2110 ID from compatibility list

[Johan Hovold]

On Tue, Nov 10, 2015 at 04:40:13PM -0600, Konstantin Shkolnyy wrote:
> CP2110 ID (0x10c4, 0xea80) doesn't belong here because it's a HID
> and completely different from CP210x devices.
> 
> Signed-off-by: Konstantin Shkolnyy 

Now 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

WARNING: CPU: 0 PID: 4139 at fs/sysfs/group.c:224 sysfs_remove_group+0x93/0xa0() occured when I remove USB Logitech HD Webcam C270

[Михаил Гаврилов]

[   98.627543] usb 1-9.1.5: reset high-speed USB device number 9 using xhci_hcd
[  100.985706] usb 1-9.1.3: ep 0x82 - rounding interval to 64
microframes, ep desc says 80 microframes
[  101.960934] tun: Universal TUN/TAP device driver, 1.6
[  101.960938] tun: (C) 1999-2004 Max Krasnyansky 
[  101.998027] device virbr0-nic entered promiscuous mode
[  102.164853] virbr0: port 1(virbr0-nic) entered listening state
[  102.164868] virbr0: port 1(virbr0-nic) entered listening state
[  102.216523] virbr0: port 1(virbr0-nic) entered disabled state
[  102.538955] usb 1-9.1.3: ep 0x82 - rounding interval to 64
microframes, ep desc says 80 microframes
[  102.628882] usb 1-9.1.3: ep 0x82 - rounding interval to 64
microframes, ep desc says 80 microframes
[  108.885013] usb 1-9.1.3: ep 0x82 - rounding interval to 64
microframes, ep desc says 80 microframes
[  109.004965] usb 1-9.1.5: reset high-speed USB device number 9 using xhci_hcd
[  132.422743] DMA-API: debugging out of memory - disabling
[  152.047039] usb 1-9.1.5: USB disconnect, device number 9
[  152.062093] [ cut here ]
[  152.062098] WARNING: CPU: 0 PID: 4139 at fs/sysfs/group.c:224
sysfs_remove_group+0x93/0xa0()
[  152.062100] sysfs group 81eed4e0 not found for kobject 'event18'
[  152.062100] Modules linked in: xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 tun nls_utf8 isofs rfcomm fuse
nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge
ebtable_filter ebtable_nat ebtables ip6table_raw ip6table_mangle
ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_filter ip6_tables iptable_raw iptable_mangle
iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack bnep hid_logitech_hidpp
hid_logitech_dj iTCO_wdt iTCO_vendor_support snd_usb_audio
snd_usbmidi_lib ppdev snd_rawmidi uvcvideo videobuf2_vmalloc
videobuf2_core videobuf2_memops v4l2_common vfat btrfs fat intel_rapl
gspca_zc3xx btusb btrtl btbcm gspca_main btintel iosf_mbi videodev
bluetooth
[  152.062138]  media xor rfkill x86_pkg_temp_thermal
snd_hda_codec_realtek snd_hda_codec_generic coretemp kvm_intel joydev
kvm raid6_pq snd_hda_codec_hdmi snd_hda_codec_ca0132 crct10dif_pclmul
crc32_pclmul snd_hda_intel crc32c_intel snd_hda_codec snd_hda_core
snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer mei_me lpc_ich snd
mei shpchp soundcore i2c_i801 parport_pc tpm_infineon parport tpm_tis
tpm nfsd auth_rpcgss binfmt_misc nfs_acl lockd grace sunrpc uas
usb_storage i915 8021q garp stp llc serio_raw i2c_algo_bit mrp
drm_kms_helper drm r8169 mii video
[  152.062164] CPU: 0 PID: 4139 Comm: cheese Not tainted
4.2.6-300.fc23.x86_64+debug #1
[  152.062165] Hardware name: Gigabyte Technology Co., Ltd.
Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014
[  152.062166]   7d055486 8807714ebb88
81869b26
[  152.062168]   8807714ebbe0 8807714ebbc8
810ac456
[  152.062170]  8807714ebbb8  81eed4e0
8807f9fa51b8
[  152.062171] Call Trace:
[  152.062174]  [] dump_stack+0x4c/0x65
[  152.062177]  [] warn_slowpath_common+0x86/0xc0
[  152.062179]  [] warn_slowpath_fmt+0x55/0x70
[  152.062181]  [] ? kernfs_find_and_get_ns+0x4e/0x60
[  152.062183]  [] sysfs_remove_group+0x93/0xa0
[  152.062185]  [] dpm_sysfs_remove+0x57/0x60
[  152.062187]  [] device_del+0x58/0x270
[  152.062189]  [] evdev_disconnect+0x27/0x60
[  152.062191]  [] __input_unregister_device+0xb0/0x160
[  152.062192]  [] input_unregister_device+0x4f/0x80
[  152.062196]  [] uvc_status_cleanup+0x46/0x50 [uvcvideo]
[  152.062197]  [] uvc_delete+0x18/0x150 [uvcvideo]
[  152.062199]  [] uvc_release+0x23/0x30 [uvcvideo]
[  152.062202]  [] v4l2_device_release+0xd8/0x110 [videodev]
[  152.062203]  [] device_release+0x36/0xa0
[  152.062206]  [] kobject_release+0x7a/0x190
[  152.062207]  [] kobject_put+0x2f/0x60
[  152.062208]  [] put_device+0x17/0x20
[  152.062210]  [] v4l2_release+0x4d/0x80 [videodev]
[  152.062212]  [] __fput+0xf5/0x200
[  152.062214]  [] fput+0xe/0x10
[  152.062216]  [] task_work_run+0x8d/0xc0
[  152.062218]  [] do_notify_resume+0x8d/0x90
[  152.062221]  [] int_signal+0x12/0x17
[  152.06] ---[ end trace 24afe6926e4cae74 ]---
[  152.077087] [ cut here ]
[  152.077092] WARNING: CPU: 2 PID: 4139 at fs/sysfs/group.c:224
sysfs_remove_group+0x93/0xa0()
[  152.077093] sysfs group 81eed4e0 not found for kobject 'input21'
[  152.077094] Modules linked in: xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 tun nls_utf8 isofs rfcomm fuse
nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge
ebtable_filter ebtable_nat ebtables ip6table_raw ip6table_mangle
ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_filter ip6_tables iptable_raw iptable_mangle
iptable_security iptable_nat nf_

Re: [PATCH v3 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Johan Hovold]

On Sun, Nov 22, 2015 at 11:47:17AM +0100, Jonas Jonsson wrote:
> Some modems, such as the Telit UE910, are using an Infineon Flash Loader
> utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
> Data). The latter can be used as a serial interface to upgrade the
> firmware of the modem. However, that isn't possible when the cdc-acm
> driver takes control of the device.
> 
> The following is an explanation of the behaviour by Daniele Palmas during
> discussion on linux-usb.
> 
> "This is what happens when the device is turned on (without modifying
> the drivers):
> 
> [155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci
> [155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint 0x81 has 
> an invalid bInterval 255, changing to 11
> [155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041
> [155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0, 
> SerialNumber=0
> [155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
> 
> This is the flashing device that is caught by the cdc-acm driver. Once
> the ttyACM appears, the application starts sending a magic string
> (simple write on the file descriptor) to keep the device in flashing
> mode. If this magic string is not properly received in a certain time
> interval, the modem goes on in normal operative mode:
> 
> [155493.748094] usb 1-3: USB disconnect, device number 27
> [155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci
> [155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021
> [155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM
> [155495.059989] usb 1-3: Manufacturer: Telit
> [155495.059992] usb 1-3: SerialNumber: 359658044004697
> [155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
> [155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device
> [155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device
> [155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device
> [155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device
> [155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device
> [155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at 
> usb-:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14
> 
> Using the cdc-acm driver, the string, though being sent in the same way
> than using the usb-serial-simple driver (I can confirm that the data is
> passing properly since I used an hw usb sniffer), does not make the
> device to stay in flashing mode."
> 
> Signed-off-by: Jonas Jonsson 
> Tested-by: Daniele Palmas 

Thanks for the update, these both look good to me now.

Greg, hope you don't mind if I take also the cdc-acm patch through my
tree?

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

[PATCH v7 3/4] usb: gadget: udc-core: remove unused usb_udc_attach_driver()

[Marek Szyprowski]

From: Ruslan Bilovol 

Now when last user of usb_udc_attach_driver() is switched
to passing UDC name via usb_gadget_driver struct, it's safe
to remove this function

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/udc/udc-core.c | 26 --
 include/linux/usb/gadget.h|  2 --
 2 files changed, 28 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 429d64e..f76ebc8 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -520,32 +520,6 @@ err1:
return ret;
 }
 
-int usb_udc_attach_driver(const char *name, struct usb_gadget_driver *driver)
-{
-   struct usb_udc *udc = NULL;
-   int ret = -ENODEV;
-
-   mutex_lock(&udc_lock);
-   list_for_each_entry(udc, &udc_list, list) {
-   ret = strcmp(name, dev_name(&udc->dev));
-   if (!ret)
-   break;
-   }
-   if (ret) {
-   ret = -ENODEV;
-   goto out;
-   }
-   if (udc->driver) {
-   ret = -EBUSY;
-   goto out;
-   }
-   ret = udc_bind_to_driver(udc, driver);
-out:
-   mutex_unlock(&udc_lock);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
-
 int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
 {
struct usb_udc  *udc = NULL;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 63963c2..ce2188d 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1121,8 +1121,6 @@ extern int usb_add_gadget_udc_release(struct device 
*parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
 extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget 
*gadget);
 extern void usb_del_gadget_udc(struct usb_gadget *gadget);
-extern int usb_udc_attach_driver(const char *name,
-   struct usb_gadget_driver *driver);
 
 /*-*/
 
-- 
1.9.2

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

[PATCH v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Marek Szyprowski]

From: Ruslan Bilovol 

Change behavior during registration of gadgets and
gadget drivers in udc-core. Instead of previous
approach when for successful probe of usb gadget driver
at least one usb gadget should be already registered
use another one where gadget drivers and gadgets
can be registered in udc-core independently.

Independent registration of gadgets and gadget drivers
is useful for built-in into kernel gadget and gadget
driver case - because it's possible that gadget is
really probed only on late_init stage (due to deferred
probe) whereas gadget driver's probe is silently failed
on module_init stage due to no any UDC added.

Also it is useful for modules case - now there is no
difference what module to insert first: gadget module
or gadget driver one.

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
[simplified code as requested by Alan Stern and Felipe Balbi,
 fixed checkpatch issues]
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/udc/udc-core.c | 41 ++-
 include/linux/usb/gadget.h|  2 ++
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index f76ebc8..fd73a3e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -51,8 +51,12 @@ struct usb_udc {
 
 static struct class *udc_class;
 static LIST_HEAD(udc_list);
+static LIST_HEAD(gadget_driver_pending_list);
 static DEFINE_MUTEX(udc_lock);
 
+static int udc_bind_to_driver(struct usb_udc *udc,
+   struct usb_gadget_driver *driver);
+
 /* - */
 
 #ifdef CONFIG_HAS_DMA
@@ -356,6 +360,7 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
void (*release)(struct device *dev))
 {
struct usb_udc  *udc;
+   struct usb_gadget_driver *driver;
int ret = -ENOMEM;
 
udc = kzalloc(sizeof(*udc), GFP_KERNEL);
@@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
 
+   /* pick up one of pending gadget drivers */
+   list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
+   if (!driver->udc_name || strcmp(driver->udc_name,
+   dev_name(&udc->dev)) == 0) {
+   ret = udc_bind_to_driver(udc, driver);
+   if (ret)
+   goto err4;
+   list_del(&driver->pending);
+   break;
+   }
+   }
+
mutex_unlock(&udc_lock);
 
return 0;
@@ -473,10 +490,14 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
 
mutex_lock(&udc_lock);
list_del(&udc->list);
-   mutex_unlock(&udc_lock);
 
-   if (udc->driver)
+   if (udc->driver) {
+   struct usb_gadget_driver *driver = udc->driver;
+
usb_gadget_remove_driver(udc);
+   list_add(&driver->pending, &gadget_driver_pending_list);
+   }
+   mutex_unlock(&udc_lock);
 
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
flush_work(&gadget->work);
@@ -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, &udc_list, list) {
@@ -549,9 +566,11 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
*driver)
}
}
 
-   pr_debug("couldn't find an available UDC\n");
+   list_add_tail(&driver->pending, &gadget_driver_pending_list);
+   pr_info("udc-core: couldn't find an available UDC - added [%s] to list 
of pending drivers\n",
+   driver->function);
mutex_unlock(&udc_lock);
-   return ret;
+   return 0;
 found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
@@ -577,6 +596,10 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver 
*driver)
break;
}
 
+   if (ret) {
+   list_del(&driver->pending);
+   ret = 0;
+   }
mutex_unlock(&udc_lock);
return ret;
 }
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index ce2188d..92467ee 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1014,6 +1014,7 @@ static inline int usb_gadget_activate(struct usb_gadget 
*gadget)
  * @driver: Driver model state for this 

[PATCH v7 0/4] usb/gadget: independent registration of gadgets and gadget drivers

[Marek Szyprowski]

Hello,

This is a resurrection of the patches initially submitted by Ruslan
Bilovol in the following thread: https://lkml.org/lkml/2015/6/22/554

The changes since the original submission (v5) includes rebase onto
latest linux-next branch, simplification of the code requested by Alan
Stern and Felipe Balbi, removal of a patch, which deleted __init/__exit
attributes (this change has been already merged) and fixes of the
checkpatch issues.

This feature is urgently needed, because it is not longer possible to
use workaround to avoid deferred probe in UDC drivers due to
not-yet-probed i2c regulator drivers (for more information see
https://lkml.org/lkml/2015/10/30/374 ).

This patchset has been successfully tested on Odroid XU3 boards with
DWC3 UDC driver being deferred by missing regulator drivers.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Patch summary:

Ruslan Bilovol (4):
  usb: gadget: bind UDC by name passed via usb_gadget_driver structure
  usb: gadget: configfs: pass UDC name via usb_gadget_driver struct
  usb: gadget: udc-core: remove unused usb_udc_attach_driver()
  usb: gadget: udc-core: independent registration of gadgets and gadget
drivers

 drivers/usb/gadget/configfs.c | 29 +++---
 drivers/usb/gadget/udc/udc-core.c | 79 ++-
 include/linux/usb/gadget.h|  8 +++-
 3 files changed, 67 insertions(+), 49 deletions(-)

-- 
1.9.2

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

[PATCH v7 2/4] usb: gadget: configfs: pass UDC name via usb_gadget_driver struct

[Marek Szyprowski]

From: Ruslan Bilovol 

Now when udc-core supports binding to specific UDC by passing
its name via 'udc_name' member of usb_gadget_driver struct,
switch to this generic approach.

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
[rebased and fixed checkpatch issues]
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/configfs.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 163d305..590c449 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -56,7 +56,6 @@ struct gadget_info {
struct list_head string_list;
struct list_head available_func;
 
-   const char *udc_name;
struct usb_composite_driver composite;
struct usb_composite_dev cdev;
bool use_os_desc;
@@ -233,21 +232,23 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct 
config_item *item,
 
 static ssize_t gadget_dev_desc_UDC_show(struct config_item *item, char *page)
 {
-   return sprintf(page, "%s\n", to_gadget_info(item)->udc_name ?: "");
+   char *udc_name = to_gadget_info(item)->composite.gadget_driver.udc_name;
+
+   return sprintf(page, "%s\n", udc_name ?: "");
 }
 
 static int unregister_gadget(struct gadget_info *gi)
 {
int ret;
 
-   if (!gi->udc_name)
+   if (!gi->composite.gadget_driver.udc_name)
return -ENODEV;
 
ret = usb_gadget_unregister_driver(&gi->composite.gadget_driver);
if (ret)
return ret;
-   kfree(gi->udc_name);
-   gi->udc_name = NULL;
+   kfree(gi->composite.gadget_driver.udc_name);
+   gi->composite.gadget_driver.udc_name = NULL;
return 0;
 }
 
@@ -271,14 +272,16 @@ static ssize_t gadget_dev_desc_UDC_store(struct 
config_item *item,
if (ret)
goto err;
} else {
-   if (gi->udc_name) {
+   if (gi->composite.gadget_driver.udc_name) {
ret = -EBUSY;
goto err;
}
-   ret = usb_udc_attach_driver(name, &gi->composite.gadget_driver);
-   if (ret)
+   gi->composite.gadget_driver.udc_name = name;
+   ret = usb_gadget_probe_driver(&gi->composite.gadget_driver);
+   if (ret) {
+   gi->composite.gadget_driver.udc_name = NULL;
goto err;
-   gi->udc_name = name;
+   }
}
mutex_unlock(&gi->lock);
return len;
@@ -427,9 +430,9 @@ static int config_usb_cfg_unlink(
 * remove the function.
 */
mutex_lock(&gi->lock);
-   if (gi->udc_name)
+   if (gi->composite.gadget_driver.udc_name)
unregister_gadget(gi);
-   WARN_ON(gi->udc_name);
+   WARN_ON(gi->composite.gadget_driver.udc_name);
 
list_for_each_entry(f, &cfg->func_list, list) {
if (f->fi == fi) {
@@ -873,10 +876,10 @@ static int os_desc_unlink(struct config_item *os_desc_ci,
struct usb_composite_dev *cdev = &gi->cdev;
 
mutex_lock(&gi->lock);
-   if (gi->udc_name)
+   if (gi->composite.gadget_driver.udc_name)
unregister_gadget(gi);
cdev->os_desc_config = NULL;
-   WARN_ON(gi->udc_name);
+   WARN_ON(gi->composite.gadget_driver.udc_name);
mutex_unlock(&gi->lock);
return 0;
 }
-- 
1.9.2

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

[PATCH v7 1/4] usb: gadget: bind UDC by name passed via usb_gadget_driver structure

[Marek Szyprowski]

From: Ruslan Bilovol 

Introduce new 'udc_name' member to usb_gadget_driver structure.
The 'udc_name' is a name of UDC that usb_gadget_driver should
be bound to. If udc_name is NULL, it will be bound to any
available UDC.

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/udc/udc-core.c | 24 +++-
 include/linux/usb/gadget.h|  4 
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index f660afb..429d64e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -549,21 +549,35 @@ EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
 int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
 {
struct usb_udc  *udc = NULL;
-   int ret;
+   int ret = -ENODEV;
 
if (!driver || !driver->bind || !driver->setup)
return -EINVAL;
 
mutex_lock(&udc_lock);
-   list_for_each_entry(udc, &udc_list, list) {
-   /* For now we take the first one */
-   if (!udc->driver)
+   if (driver->udc_name) {
+   list_for_each_entry(udc, &udc_list, list) {
+   ret = strcmp(driver->udc_name, dev_name(&udc->dev));
+   if (!ret)
+   break;
+   }
+   if (ret)
+   ret = -ENODEV;
+   else if (udc->driver)
+   ret = -EBUSY;
+   else
goto found;
+   } else {
+   list_for_each_entry(udc, &udc_list, list) {
+   /* For now we take the first one */
+   if (!udc->driver)
+   goto found;
+   }
}
 
pr_debug("couldn't find an available UDC\n");
mutex_unlock(&udc_lock);
-   return -ENODEV;
+   return ret;
 found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..63963c2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1012,6 +1012,8 @@ static inline int usb_gadget_activate(struct usb_gadget 
*gadget)
  * @reset: Invoked on USB bus reset. It is mandatory for all gadget drivers
  * and should be called in_interrupt.
  * @driver: Driver model state for this driver.
+ * @udc_name: A name of UDC this driver should be bound to. If udc_name is 
NULL,
+ * this driver will be bound to any available UDC.
  *
  * Devices are disabled till a gadget driver successfully bind()s, which
  * means the driver will handle setup() requests needed to enumerate (and
@@ -1072,6 +1074,8 @@ struct usb_gadget_driver {
 
/* FIXME support safe rmmod */
struct device_driverdriver;
+
+   char*udc_name;
 };
 
 
-- 
1.9.2

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

Re: [PATCH v4 3/3] usb: chipidea: register driver as a peripheral with the phy

[Peter Chen]

On Fri, Nov 20, 2015 at 03:47:20PM -0800, Tim Bird wrote:
> Register the chipidea driver with the phy, so that the phy
> driver can kick the gadget driver when it resumes from low power.
> The phy-msm-usb (Qualcomm) driver requires this in order to
> recover gadget operation after you disconnect the USB cable
> and reconnect it.
> 
> Signed-off-by: Tim Bird 
> ---
>  drivers/usb/chipidea/udc.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 8223fe7..06234cd 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
>  
>   ci->gadget.ep0 = &ci->ep0in->ep;
>  
> + if (ci->usb_phy) {
> + retval = otg_set_peripheral(ci->usb_phy->otg, &ci->gadget);
> + if (retval)
> + goto destroy_eps;
> + }
> +
>   retval = usb_add_gadget_udc(dev, &ci->gadget);
>   if (retval)
>   goto destroy_eps;

Hi Tim,

I am afraid it can't work for current chipidea framework (find this
problem after testing), the chipidea core manages its host and device
function using its own API start/stop, it does not define struct usb_otg
APIs. In fact, it is not reasonable control host and device function
at PHY driver.

-- 

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

Re: [PATCHv3 00/14] Equivalent of tcm_usb_gadget with configfs

[Andrzej Pietrasiewicz]

W dniu 15.11.2015 o 00:27, Nicholas A. Bellinger pisze:

Hi Andrzej & Co,









Ok, I've added both series into target-pending/queue-next so kbuild can
give it a first pass.

We'll need to get Jlbec's ACK on the configfs parts, and Sebastian's ACK
on this series ahead of getting them into next as v4.5-rc code.



@Joel, @Sebastian: Guys, any comments?

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