Re: [PATCHv2 3/4] usb: gadget: uvc: use explicit type instead of void *

[Andrzej Pietrasiewicz]

W dniu 19.01.2015 o 22:30, Laurent Pinchart pisze:

Hi Andrzej,

On Monday 19 January 2015 23:27:28 Laurent Pinchart wrote:

On Monday 19 January 2015 13:52:57 Andrzej Pietrasiewicz wrote:

The first parameter of __uvcg_iter_strm_cls() is always used in
the context of struct uvcg_streaming_header, so change the
function prototype accordingly.

Signed-off-by: Andrzej Pietrasiewicz 


Acked-by: Laurent Pinchart 


I spoke too fast. Shouldn't the first argument of the callback function be a
struct uvcg_streaming_header * as well ?



Both __uvcg_count_strm() and __uvcg_fill_strm() use their 1st parameter
in different contexts, depending whether they are called at the
streaming header, format or frame level. That is why originally
the 1st parameter of __uvcg_iter_strm_cls() was a void * - to emphasize
the fact that what is propagated to the callbacks as the 1st parameter
is not always the same type of thing.

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

Re: [PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

[Kristian Evensen]

On Mon, Jan 19, 2015 at 11:49 PM, Greg KH  wrote:
> That would be great, send it to the hid maintainer and cc the list
> (using scripts/get_maintainer.pl should tell you the proper people to
> send it to.)

Thanks for the pointer. Will update the patch and submit a new one tonight.

> If you can run a bash script, you should be able to run a tiny binary as
> well that handles this type of thing.  We don't like adding custom,
> non-documented apis to the kernel like this if at all possible,
> especially ones that can be handled with userspace programs instead.

FWIW and for future reference if anyone else finds this thread, the
API is well-documented in the product manual for the YKUSH
(https://www.yepkit.com/uploads/documents/dc8ab_YKRUD_ProductManual_v1.1.pdf).

Thanks again or the help :)

-Kristian
--
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: UDC core: add device_del() call to error pathway

[Peter Chen]

On Fri, Jan 16, 2015 at 11:32:51AM -0500, Alan Stern wrote:
> This patch fixes a bug in the error pathway of
> usb_add_gadget_udc_release() in udc-core.c.  If the udc registration
> fails, the gadget registration is not fully undone; there's a
> put_device(&gadget->dev) call but no device_del().
> 
> Signed-off-by: Alan Stern 
> CC: 
> 
> ---
> 
> 
> [as1772]
> 
> 
>  drivers/usb/gadget/udc/udc-core.c |1 +
>  1 file changed, 1 insertion(+)
> 
> Index: usb-3.19/drivers/usb/gadget/udc/udc-core.c
> ===
> --- usb-3.19.orig/drivers/usb/gadget/udc/udc-core.c
> +++ usb-3.19/drivers/usb/gadget/udc/udc-core.c
> @@ -298,6 +298,7 @@ err4:
>  
>  err3:
>   put_device(&udc->dev);
> + device_del(&gadget->dev);
>  
>  err2:
>   put_device(&gadget->dev);
> 

Acked-by: Peter Chen 

-- 

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 0/2] usb: dwc2: fix the uncompleted requests problem

[Robert Baldyga]

Hi Felipe,

I can't see these patches in your tree. I see only "usb: dwc2: gadget:
kill requests with 'force' in s3c_hsotg_udc_stop()", which doesn't fix
the bug completely. I was sure that my the final patch was in your tree,
so what happened? Can you apply these patches to fix this problem?

On 01/05/2015 10:31 AM, Robert Baldyga wrote:
> Hi Felipe,
> 
> I prepared this patchset in response to our discussion:
> https://lkml.org/lkml/2014/12/29/193
> 
> It reverts of unproper patch and adds working solution of the problem
> described in commit messages.
> 
> Best regards,
> Robert Baldyga
> 
> Robert Baldyga (2):
>   Revert "usb: dwc2: gadget: kill requests with 'force' in
> s3c_hsotg_udc_stop()"
>   drivers: usb: dwc2: remove 'force' parameter from kill_all_requests()
> 
>  drivers/usb/dwc2/gadget.c | 31 ++-
>  1 file changed, 10 insertions(+), 21 deletions(-)
> 

Best regards,
Robert Baldyga
--
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 1/3] usb: udc: add usb_gadget_find_udc

[Peter Chen]

On Mon, Jan 19, 2015 at 11:29:22AM -0500, Alan Stern wrote:
> On Mon, 19 Jan 2015, Peter Chen wrote:
> 
> > > > An idea just struck me...  Instead of looping through all the udc's to
> > > > find the right one, why not simply store a pointer to the udc in struct
> > > > usb_gadget?
> > > > 
> > 
> > We still have code to find usb_gadget_driver to iterate udc_list, it
> > is better to change all, we need to have solution to consolidate
> > struct usb_udc, struct usb_gadget, and struct usb_gadget_drver.
> > I have no good solution now.
> 
> I think it's okay to iterate through the list to find a 
> usb_gadget_driver.  But it's silly to iterate to find the usb_udc 
> corresponding to a usb_gadget.

Felipe, what's your opinion?

> 
> > > > Also, it looks like there's a bug in usb_add_gadget_udc_release() in 
> > > > udc-core.c.  The error pathway (between err3 and err2) does not undo 
> > > > the
> > > > 
> > > > ret = device_register(&gadget->dev);
> > > > 
> > > > call.  There's a put_device() call but no device_del().
> > > 
> > > good point :-) Do you want to send a patch for that ?
> > > 
> > 
> > It looks like there is another issue in error pathway, the
> > put_device(&udc->dev) at err3 should be moved to err4 since
> > the get_device is called at device_add.
> 
> No, the get_device is done by device_initialize, so the code is correct 
> as it stands.  See the kerneldoc for device_initialize() in 
> drivers/base/core.c.
> 
> Alan Stern
> 

Yes, you are right, just device_initialize calls kobject_init to
set refcount as 1, not call get_device directly.
-- 

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 net-next 1/7] r8152: adjust rx_bottom

[Hayes Wang]

 David Miller [mailto:da...@davemloft.net] 
> Sent: Tuesday, January 20, 2015 10:52 AM
[...]
> agg->list is not local, you have to use a spinlock to protect
> modifications to it, some other sites which modify agg->list do take
> the lock properly.
> 
> You cannot modify a list like agg->list without proper locking.

Excuse me. I don't understand.

Before step1
   tp_rx_done->listA->listB->listC->listD->...
   rx_queue->
Because the other function would chage tp->rx_done,
I need move the lists with spin lock.

After step1
   tp_rx_done->
   rx_queue->listA->listB->listC->listD->...

Now I dequeue one of the lists from the list_head and
deal with it.
   tp_rx_done->
   rx_queue->listA->listC->listD->...
listB

Then, if I want to put it back to rx_queue, I have to
use spin lock. Why? No other function would chage
rx_queue and the items in it.
 
Best Regards,
Hayes
--
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 net-next 1/7] r8152: adjust rx_bottom

[David Miller]

From: Hayes Wang 
Date: Tue, 20 Jan 2015 02:48:50 +

>> >> +   urb->actual_length = 0;
>> >> +   list_add_tail(&agg->list, next);
>> > 
>> > Do you need a spin_lock_irqsave(&tp->rx_lock, flags) around this?
>> 
>> Indeed, and rtl_start_rx() seems to also access agg->list without
>> proper locking.
> 
> It is unnecessary because I deal with them in a local list_head. My steps are
>1. Move the whole list from tp->rx_done to local rx_queue. (with spin lock)
>2. dequeue/enqueue the lists in rx_queue.
>3. Move the lists in rx_queue to tp->rx_done if it is necessary. (spin 
> lock)
> For step 2, it wouldn't have race, because the list_head is local and no other
> function would change it. Therefore, I don't think it needs the spin lock.
> 
> The rtl_start_rx() also uses the similar way.

agg->list is not local, you have to use a spinlock to protect
modifications to it, some other sites which modify agg->list do take
the lock properly.

You cannot modify a list like agg->list without proper locking.

--
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 net-next 1/7] r8152: adjust rx_bottom

[Hayes Wang]

 David Miller [mailto:da...@davemloft.net] 
> Sent: Tuesday, January 20, 2015 5:14 AM
[...]
> >> -   r8152_submit_rx(tp, agg, GFP_ATOMIC);
> >> +   if (!ret) {
> >> +   ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
> >> +   } else {
> >> +   urb->actual_length = 0;
> >> +   list_add_tail(&agg->list, next);
> > 
> > Do you need a spin_lock_irqsave(&tp->rx_lock, flags) around this?
> 
> Indeed, and rtl_start_rx() seems to also access agg->list without
> proper locking.

It is unnecessary because I deal with them in a local list_head. My steps are
   1. Move the whole list from tp->rx_done to local rx_queue. (with spin lock)
   2. dequeue/enqueue the lists in rx_queue.
   3. Move the lists in rx_queue to tp->rx_done if it is necessary. (spin lock)
For step 2, it wouldn't have race, because the list_head is local and no other
function would change it. Therefore, I don't think it needs the spin lock.

The rtl_start_rx() also uses the similar way.
 
Best Regards,
Hayes
--
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: 3.18 regression: Error while assigning device slot ID, USB3 devices not detected

[Robert Hancock]

On Mon, Jan 19, 2015 at 9:40 AM, Josh Boyer  wrote:
> On Mon, Jan 19, 2015 at 9:57 AM, Mathias Nyman
>  wrote:
>> On 19.01.2015 15:47, Josh Boyer wrote:
>>> On Mon, Jan 19, 2015 at 8:33 AM, Greg KH  wrote:
 On Mon, Jan 19, 2015 at 08:28:19AM -0500, Josh Boyer wrote:
> On Sun, Jan 18, 2015 at 1:25 AM, Greg KH  
> wrote:
>> On Sun, Jan 18, 2015 at 12:08:18AM -0600, Robert Hancock wrote:
>>> I've got an Intel Haswell-based system with a Gigabyte Z87X-D3H 
>>> motherboard
>>> under Fedora 21. After updating to the 3.18.2-200 Fedora kernel, I 
>>> noticed
>>> some errors in dmesg and at least some of my USB3 ports don't recognize 
>>> any
>>> USB3 devices plugged into them:
>>>
>>> [0.560838] xhci_hcd :00:14.0: Error while assigning device slot 
>>> ID
>>> [0.560912] xhci_hcd :00:14.0: Max number of devices this xHCI 
>>> host
>>> supports is 32.
>>> [0.560990] usb usb2-port2: couldn't allocate usb_device
>>> [0.561098] xhci_hcd :00:14.0: Error while assigning device slot 
>>> ID
>>> [0.561163] xhci_hcd :00:14.0: Max number of devices this xHCI 
>>> host
>>> supports is 32.
>>> [0.561239] usb usb2-port5: couldn't allocate usb_device
>>> [0.561344] xhci_hcd :00:14.0: Error while assigning device slot 
>>> ID
>>> [0.561409] xhci_hcd :00:14.0: Max number of devices this xHCI 
>>> host
>>> supports is 32.
>>> [0.561484] usb usb2-port6: couldn't allocate usb_device
>>>
>>> This worked fine under 3.17. Is this a known problem?
>>
>> Yes it is, should be fixed in Linus's tree now and will be backported to
>> the latest 3.18-stable tree in a week or so.
>
> Do you happen to know the commit id?

 f161ead70fa6a62e432dff6e9dab8e3cfbeabea6
>>>
>>> Thanks!
>>>
>>
>> Tell me if this fixed the issue.
>> I got this gut feeling this might be something else.
>> It should have failed in 3.17 as well
>
> OK.  We're tracking this in the bug Robert filed here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1183289
>
> The patch should be in the next Fedora kernel build, so hopefully we
> can get back to you soon.

The patched build seems to fix the problem with the ports not
recognizing SuperSpeed devices. I do get these errors in dmesg now
though, which also weren't in 3.17:

[0.881967] usb: failed to peer 1-9-port1 and 2-5-port1 by location
(1-9-port1:none) (2-5-port1:usb1-port11)
[0.881968] usb 1-9-port1: failed to peer to 2-5-port1 (-16)
[0.881969] usb: port power management may be unreliable
[0.881993] usb: failed to peer 1-9-port2 and 2-5-port2 by location
(1-9-port2:none) (2-5-port2:usb1-port12)
[0.881994] usb 1-9-port2: failed to peer to 2-5-port2 (-16)
[0.882015] usb: failed to peer 1-9-port3 and 2-5-port3 by location
(1-9-port3:none) (2-5-port3:usb1-port13)
[0.882016] usb 1-9-port3: failed to peer to 2-5-port3 (-16)
[0.882037] usb: failed to peer 1-9-port4 and 2-5-port4 by location
(1-9-port4:none) (2-5-port4:usb1-port14)
[0.882038] usb 1-9-port4: failed to peer to 2-5-port4 (-16)

Full dmesg is attached to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1183289
--
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

[PATCHv3 2/2] usb: ohci-platform: add support for multiple phys per controller

[arun.ramamurthy]

From: Arun Ramamurthy 

Added support for cases where one controller is connected
to multiple phys

Signed-off-by: Arun Ramamurthy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Tested-by: Scott Branden 
---
 drivers/usb/host/ohci-platform.c | 82 +---
 1 file changed, 60 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index b81d202..613d54e 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -38,7 +38,8 @@
 struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
struct reset_control *rst;
-   struct phy *phy;
+   struct phy **phys;
+   int num_phys;
 };
 
 static const char hcd_name[] = "ohci-platform";
@@ -47,7 +48,7 @@ static int ohci_platform_power_on(struct platform_device *dev)
 {
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
-   int clk, ret;
+   int clk, ret, phy_num;
 
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++) {
ret = clk_prepare_enable(priv->clks[clk]);
@@ -55,20 +56,28 @@ static int ohci_platform_power_on(struct platform_device 
*dev)
goto err_disable_clks;
}
 
-   if (priv->phy) {
-   ret = phy_init(priv->phy);
-   if (ret)
-   goto err_disable_clks;
-
-   ret = phy_power_on(priv->phy);
-   if (ret)
-   goto err_exit_phy;
+   for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+   if (priv->phys[phy_num]) {
+   ret = phy_init(priv->phys[phy_num]);
+   if (ret)
+   goto err_exit_phy;
+   ret = phy_power_on(priv->phys[phy_num]);
+   if (ret) {
+   phy_exit(priv->phys[phy_num]);
+   goto err_exit_phy;
+   }
+   }
}
 
return 0;
 
 err_exit_phy:
-   phy_exit(priv->phy);
+   while (--phy_num >= 0) {
+   if (priv->phys[phy_num]) {
+   phy_power_off(priv->phys[phy_num]);
+   phy_exit(priv->phys[phy_num]);
+   }
+   }
 err_disable_clks:
while (--clk >= 0)
clk_disable_unprepare(priv->clks[clk]);
@@ -80,11 +89,13 @@ static void ohci_platform_power_off(struct platform_device 
*dev)
 {
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
-   int clk;
+   int clk, phy_num;
 
-   if (priv->phy) {
-   phy_power_off(priv->phy);
-   phy_exit(priv->phy);
+   for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+   if (priv->phys[phy_num]) {
+   phy_power_off(priv->phys[phy_num]);
+   phy_exit(priv->phys[phy_num]);
+   }
}
 
for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
@@ -112,7 +123,8 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
-   int err, irq, clk = 0;
+   const char *phy_name;
+   int err, irq, phy_num, clk = 0;
 
if (usb_disabled())
return -ENODEV;
@@ -160,12 +172,38 @@ static int ohci_platform_probe(struct platform_device 
*dev)
of_property_read_u32(dev->dev.of_node, "num-ports",
 &ohci->num_ports);
 
-   priv->phy = devm_phy_get(&dev->dev, "usb");
-   if (IS_ERR(priv->phy)) {
-   err = PTR_ERR(priv->phy);
-   if (err == -EPROBE_DEFER)
-   goto err_put_hcd;
-   priv->phy = NULL;
+   priv->num_phys = of_count_phandle_with_args(dev->dev.of_node,
+   "phys", "#phy-cells");
+   priv->num_phys = priv->num_phys > 0 ? priv->num_phys : 1;
+
+   priv->phys = devm_kcalloc(&dev->dev, priv->num_phys,
+   sizeof(struct phy *), GFP_KERNEL);
+   if (!priv->phys)
+   return -ENOMEM;
+
+   for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+   err = of_property_read_string_index(
+   dev->dev.of_node,
+   "phy-names", phy_num,
+   &phy_name);
+
+   if (err < 0) {
+   if (priv->num_phys > 1) {
+   dev_err(&dev->dev, "phy-names 
not provid

[PATCHv3 1/2] usb: ehci-platform: add support for multiple phys per controller

[arun.ramamurthy]

From: Arun Ramamurthy 

Added support for cases where one controller is connected
to multiple phys.

Signed-off-by: Arun Ramamurthy 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Tested-by: Scott Branden 
---
 drivers/usb/host/ehci-platform.c | 82 +---
 1 file changed, 60 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 8557803..6b4978a 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -43,7 +43,8 @@
 struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
struct reset_control *rst;
-   struct phy *phy;
+   struct phy **phys;
+   int num_phys;
 };
 
 static const char hcd_name[] = "ehci-platform";
@@ -78,7 +79,7 @@ static int ehci_platform_power_on(struct platform_device *dev)
 {
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
-   int clk, ret;
+   int clk, ret, phy_num;
 
for (clk = 0; clk < EHCI_MAX_CLKS && priv->clks[clk]; clk++) {
ret = clk_prepare_enable(priv->clks[clk]);
@@ -86,20 +87,28 @@ static int ehci_platform_power_on(struct platform_device 
*dev)
goto err_disable_clks;
}
 
-   if (priv->phy) {
-   ret = phy_init(priv->phy);
-   if (ret)
-   goto err_disable_clks;
-
-   ret = phy_power_on(priv->phy);
-   if (ret)
-   goto err_exit_phy;
+   for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+   if (priv->phys[phy_num]) {
+   ret = phy_init(priv->phys[phy_num]);
+   if (ret)
+   goto err_exit_phy;
+   ret = phy_power_on(priv->phys[phy_num]);
+   if (ret) {
+   phy_exit(priv->phys[phy_num]);
+   goto err_exit_phy;
+   }
+   }
}
 
return 0;
 
 err_exit_phy:
-   phy_exit(priv->phy);
+   while (--phy_num >= 0) {
+   if (priv->phys[phy_num]) {
+   phy_power_off(priv->phys[phy_num]);
+   phy_exit(priv->phys[phy_num]);
+   }
+   }
 err_disable_clks:
while (--clk >= 0)
clk_disable_unprepare(priv->clks[clk]);
@@ -111,11 +120,13 @@ static void ehci_platform_power_off(struct 
platform_device *dev)
 {
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
-   int clk;
+   int clk, phy_num;
 
-   if (priv->phy) {
-   phy_power_off(priv->phy);
-   phy_exit(priv->phy);
+   for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+   if (priv->phys[phy_num]) {
+   phy_power_off(priv->phys[phy_num]);
+   phy_exit(priv->phys[phy_num]);
+   }
}
 
for (clk = EHCI_MAX_CLKS - 1; clk >= 0; clk--)
@@ -143,7 +154,8 @@ static int ehci_platform_probe(struct platform_device *dev)
struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
-   int err, irq, clk = 0;
+   const char *phy_name;
+   int err, irq, phy_num, clk = 0;
 
if (usb_disabled())
return -ENODEV;
@@ -185,12 +197,38 @@ static int ehci_platform_probe(struct platform_device 
*dev)
if (of_property_read_bool(dev->dev.of_node, "big-endian"))
ehci->big_endian_mmio = ehci->big_endian_desc = 1;
 
-   priv->phy = devm_phy_get(&dev->dev, "usb");
-   if (IS_ERR(priv->phy)) {
-   err = PTR_ERR(priv->phy);
-   if (err == -EPROBE_DEFER)
-   goto err_put_hcd;
-   priv->phy = NULL;
+   priv->num_phys = of_count_phandle_with_args(dev->dev.of_node,
+   "phys", "#phy-cells");
+   priv->num_phys = priv->num_phys > 0 ? priv->num_phys : 1;
+
+   priv->phys = devm_kcalloc(&dev->dev, priv->num_phys,
+   sizeof(struct phy *), GFP_KERNEL);
+   if (!priv->phys)
+   return -ENOMEM;
+
+   for (phy_num = 0; phy_num < priv->num_phys; phy_num++) {
+   err = of_property_read_string_index(
+   dev->dev.of_node,
+   "phy-names", phy_num,
+   &phy_name);
+
+   if (err < 0) {
+   if (priv->num_phys > 1) {
+   dev_err(&dev

[PATCHv3 0/2] Added Multiple Phy support for ehci and ohci drivers

[arun.ramamurthy]

From: Arun Ramamurthy 

Broadcom has a chip where one ehci and ohci controller are connected
to three separate phys. This patch allows each phy to be controlled
separately.

Changes in v2:
- removed x character mistakenly introduced by manual edit of diff file 

Changes in v3:
- Addressed Alan Stern's commnents on support for non-dt cases

Arun Ramamurthy (1):
  usb: ehci-platform: add support for multiple phys per controller

 drivers/usb/host/ehci-platform.c | 82 +---
 1 file changed, 60 insertions(+), 22 deletions(-)

-- 
2.2.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: Issues with commit 34b48db6 ("block: remove artifical max_hw_sectors cap")

[Kenneth R. Crudup]

On Mon, 19 Jan 2015, Alan Stern wrote:

> Are you certain the patch had been applied to the kernel you were testing?

Yeah, I definitely remember the result of "git status" having the patch
ready for commit at the time of build. I'll test it again later tonight.

> Maybe you can add a printk statement to scsiglue.c:slave_configure() 

Yeah, I'll add this too.

-Kenny

-- 
Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Silicon Valley
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

[Greg KH]

On Mon, Jan 19, 2015 at 10:54:48PM +0100, Kristian Evensen wrote:
> Hi,
> 
> On Mon, Jan 19, 2015 at 10:38 PM, Greg KH  wrote:
> > That's great, and the hid parts of the patch makes sense, keeping the
> > HID driver from binding to it, but for the rest, shouldn't that just be
> > a simple userspace program instead?  We don't like to add kernel drivers
> > that can be done in userspace, and using usbfs/libusb should be really
> > simple for this device from what the driver looks like.
> >
> > So, care to slim down the patch a bunch and resend?
> 
> Sure, no problem. You want a patch containing only the HID-parts?

That would be great, send it to the hid maintainer and cc the list
(using scripts/get_maintainer.pl should tell you the proper people to
send it to.)

> My reason for adding this as a kernel driver was to ease usage of the
> device in scenarios where using libusb is not possible or desirable.
> For example embedded devices with space constraints or being able to
> restart USB ports from Bash-scripts. One use-case I have had for the
> driver is a script which monitors AT-modems by sending "AT" to the
> serial device, and restart the port by pipeing a value into portX if
> no reply has been received for a certain amount of time.

If you can run a bash script, you should be able to run a tiny binary as
well that handles this type of thing.  We don't like adding custom,
non-documented apis to the kernel like this if at all possible,
especially ones that can be handled with userspace programs instead.

thanks,

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

Re: [PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

[Kristian Evensen]

Hi,

On Mon, Jan 19, 2015 at 10:38 PM, Greg KH  wrote:
> That's great, and the hid parts of the patch makes sense, keeping the
> HID driver from binding to it, but for the rest, shouldn't that just be
> a simple userspace program instead?  We don't like to add kernel drivers
> that can be done in userspace, and using usbfs/libusb should be really
> simple for this device from what the driver looks like.
>
> So, care to slim down the patch a bunch and resend?

Sure, no problem. You want a patch containing only the HID-parts?

My reason for adding this as a kernel driver was to ease usage of the
device in scenarios where using libusb is not possible or desirable.
For example embedded devices with space constraints or being able to
restart USB ports from Bash-scripts. One use-case I have had for the
driver is a script which monitors AT-modems by sending "AT" to the
serial device, and restart the port by pipeing a value into portX if
no reply has been received for a certain amount of time.

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

Re: [PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

[Greg KH]

On Mon, Jan 19, 2015 at 08:32:26PM +0100, Kristian Evensen wrote:
> The Yepkit YKUSH  is a three-port
> switchable USB hub. In addition the to actual hub device, an HID device is
> exported (VID 0x04D8 PID 0x0042). By sending specific commands to the HID
> device, it is possible to power up/down the three ports separately or all 
> ports
> together. Commands 0x01-0x03 is used to power down ports 1-3, while 0x0A is 
> used
> to power down all ports. In order to power up a port (or all ports), the 
> command
> is OR'd with 0x10.

That's great, and the hid parts of the patch makes sense, keeping the
HID driver from binding to it, but for the rest, shouldn't that just be
a simple userspace program instead?  We don't like to add kernel drivers
that can be done in userspace, and using usbfs/libusb should be really
simple for this device from what the driver looks like.

So, care to slim down the patch a bunch 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 v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[Andrew Lunn]

On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote:
> Hi all,
> 
> This serie enables the Armada 385 AP XHCI controller.
> 
> Since the controller uses a GPIO-controlled VBUS, we used the
> phy-generic driver, and made the needed additions to the xhci-plat
> driver to retrieve a USB phy.
> 
> Unfortunately, some glitches were also found along the way, mostly
> because of the probe deferring that was introduced by this phy
> retrieval.
> 
> Since the introduction of the Armada 38x support in 3.16, the driver
> was attempting to write into registers while the clock wasn't enabled
> yet. This was working because the bootloader left it enabled, but in
> the case of a deferred probing, the clock would have been disabled by
> the error path of our driver, and this would fail. This should go in
> 3.19, and any stable kernel for 3.16+.
> 
> The two patches remaining are "regular" patches, and are aimed at
> 3.20. The last patch depend on my previous serie to introduce support
> for the the A385 AP board.

Hi Maxime

I assume you want me to take 3/3? Any other route is not simple, since
this file only exists in mvebu/dt and maybe a staging branch of
arm-soc.

What route do you think the other patches will take?

Thanks

Andrew
--
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: [PATCHv2 3/4] usb: gadget: uvc: use explicit type instead of void *

[Laurent Pinchart]

Hi Andrzej,

On Monday 19 January 2015 23:27:28 Laurent Pinchart wrote:
> On Monday 19 January 2015 13:52:57 Andrzej Pietrasiewicz wrote:
> > The first parameter of __uvcg_iter_strm_cls() is always used in
> > the context of struct uvcg_streaming_header, so change the
> > function prototype accordingly.
> > 
> > Signed-off-by: Andrzej Pietrasiewicz 
> 
> Acked-by: Laurent Pinchart 

I spoke too fast. Shouldn't the first argument of the callback function be a 
struct uvcg_streaming_header * as well ?

> > ---
> > 
> >  drivers/usb/gadget/function/uvc_configfs.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> > b/drivers/usb/gadget/function/uvc_configfs.c index 49f25e8..51d8e9e 100644
> > --- a/drivers/usb/gadget/function/uvc_configfs.c
> > +++ b/drivers/usb/gadget/function/uvc_configfs.c
> > @@ -1918,10 +1918,10 @@ enum uvcg_strm_type {
> > UVCG_FRAME
> >  };
> > 
> > -static int __uvcg_iter_strm_cls(void *priv1, void *priv2, void *priv3,
> > +static int __uvcg_iter_strm_cls(struct uvcg_streaming_header *h,
> > +   void *priv2, void *priv3,
> > int (*fun)(void *, void *, void *, int, enum uvcg_strm_type type))
> >  {
> > -   struct uvcg_streaming_header *h = priv1;
> > struct uvcg_format_ptr *f;
> > struct config_group *grp;
> > struct config_item *item;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCHv2 3/4] usb: gadget: uvc: use explicit type instead of void *

[Laurent Pinchart]

Hi Andrzej,

Thank you for the patch.

On Monday 19 January 2015 13:52:57 Andrzej Pietrasiewicz wrote:
> The first parameter of __uvcg_iter_strm_cls() is always used in
> the context of struct uvcg_streaming_header, so change the
> function prototype accordingly.
> 
> Signed-off-by: Andrzej Pietrasiewicz 

Acked-by: Laurent Pinchart 

> ---
>  drivers/usb/gadget/function/uvc_configfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> b/drivers/usb/gadget/function/uvc_configfs.c index 49f25e8..51d8e9e 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -1918,10 +1918,10 @@ enum uvcg_strm_type {
>   UVCG_FRAME
>  };
> 
> -static int __uvcg_iter_strm_cls(void *priv1, void *priv2, void *priv3,
> +static int __uvcg_iter_strm_cls(struct uvcg_streaming_header *h,
> + void *priv2, void *priv3,
>   int (*fun)(void *, void *, void *, int, enum uvcg_strm_type type))
>  {
> - struct uvcg_streaming_header *h = priv1;
>   struct uvcg_format_ptr *f;
>   struct config_group *grp;
>   struct config_item *item;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH net 0/2] r8152: couldn't read OCP_SRAM_DATA

[David Miller]

From: Hayes Wang 
Date: Mon, 19 Jan 2015 17:02:44 +0800

> Read OCP_SRAM_DATA would read additional bytes and may let
> the hw abnormal.

Series applied, thanks.
--
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 net-next 1/7] r8152: adjust rx_bottom

[David Miller]

From: Scott Feldman 
Date: Mon, 19 Jan 2015 00:03:42 -0800

> On Sun, Jan 18, 2015 at 11:13 PM, Hayes Wang  wrote:
>> @@ -1746,7 +1746,18 @@ find_next_rx:
>> }
>>
>>  submit:
>> -   r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> +   if (!ret) {
>> +   ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> +   } else {
>> +   urb->actual_length = 0;
>> +   list_add_tail(&agg->list, next);
> 
> Do you need a spin_lock_irqsave(&tp->rx_lock, flags) around this?

Indeed, and rtl_start_rx() seems to also access agg->list without
proper locking.
--
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 2/2] USB: gadget: atmel_usba_udc: Enable/disable USB PLL on Vbus change

[Boris Brezillon]

On Mon, 19 Jan 2015 18:46:31 +0100
Sylvain Rochet  wrote:

> Hello Nicolas,
> 
> 
> On Mon, Jan 19, 2015 at 05:55:18PM +0100, Nicolas Ferre wrote:
> > Le 18/01/2015 18:24, Sylvain Rochet a écrit :
> > > Prepare_enable on rising edge, disable_unprepare on falling edge. Reduce
> >
> > Please re-write which "edge" we are talking about: "... falling edge of
> > the Vbus signal" for example.
> >
> > > power consumption if USB PLL is not already necessary for OHCI or EHCI.
> >
> > Is a verb missing in the previous sentence?
> >
> > > If USB host is not connected we can sleep with USB PLL stopped.
> > >
> > > This driver does not support suspend/resume yet, not suspending if we
> > > are still attached to an USB host is fine for what I need, this patch
> > > allow suspending with USB PLL stopped when USB device is not currently
> > > used.
> >
> > Can you please make it more clear. Several separated sentences seem
> > necessary here.
> 
> Maybe :)
> 
> 
> Proposal:
> 
> Start clocks on rising edge of the Vbus signal, stop clocks on 
> falling edge of the Vbus signal.
> 
> If USB PLL is not necessary for other USB drivers (e.g. OHCI and EHCI) 
> it will reduce power consumption by switching off the USB PLL if no USB 
> Host is currently connected to this USB Device.
> 
> We are using Vbus GPIO signal to detect Host presence. If Vbus signal is 
> not available then the device stay continuously clocked.
> 
> Note this driver does not support suspend/resume yet, it may stay 
> clocked if USB Host is still connected when suspending. For what I need, 
> forbidding suspend from userland if we are still attached to an USB host 
> is fine, but we might as well add suspend/resume to this driver in the 
> future.
> 
> 
> 
> > >   /* May happen if Vbus pin toggles during probe() */
> > > - if (!udc->driver)
> > > + spin_lock_irqsave(&udc->lock, flags);
> > > + if (!udc->driver) {
> > > + spin_unlock_irqrestore(&udc->lock, flags);
> > >   goto out;
> > > + }
> > > + spin_unlock_irqrestore(&udc->lock, flags);
> > 
> > I'm not sure that the protection by spin_lock is needed above.
> 
> I'm not sure too, it was already in a spinlock area, I obviously kept it 
> because it was not the purpose of this patch.

According to the comment placed above this test it's here to prevent
any action triggered by the vbus pin irq while the driver is not
properly probed yet.
You could use:

set_irq_flags(vbus_irq, IRQF_NOAUTOEN);

before calling devm_request_threaded_irq.
This will keep the irq disabled instead of enabling it at request time.
Moreover, this simplify the vbus_irq request code (which disables the
irq just after requesting it).

> 
> This seem to be in mirror of atmel_usba_start() which does:
> 
>   spin_lock_irqsave(&udc->lock, flags);
>   udc->devstatus = 1 << USB_DEVICE_SELF_POWERED;
>   udc->driver = driver;
>   spin_unlock_irqrestore(&udc->lock, flags);
> 
> … but vbus_pin IRQ is not yet enabled.
> 
> 
> Same for atmel_usba_stop() which disable vbus_pin IRQ before setting 
> udc->driver to NULL, but without spinlock this time (why?, this should 
> be consistent IMHO).
> 
> 
> I don't know if it is guaranteed that IRQ does not fire nor continue to 
> run after disable_irq() returns, especially for threaded IRQ.

And yes, disable_irq waits for all irq handler termination, including
threaded irqs: see [1], [2]. 

> 
> 
> If the following sequence might happen:
>   atmel_usba_stop()
> disable_irq(vbus)
>   usba_vbus_irq_thread() called lately
> check for (!udc->driver) and continue
> udc->driver = NULL;
> if (udc->driver->disconnect)
>  *CRASH*
> 
> Then the patch should be modified to protect udc->driver with the vbus 
> mutex.
> 
> In this case the previous implementation wasn't perfect too, the 
> atmel_usba_stop() does not lock around the NULLification of driver, 
> 
> Moreover the spinlock is (and was) unlocked in VBUS interrupt just 
> before calling udc->driver->disconnect, which makes udc->driver actually 
> not locked anywere.
> 
> If the previous sequence possible ?  If no, udc->driver does not need 
> locking, if yes, it is currently not locked enough.

If you rework the vbus_irq request as I suggested I think you can get
rid of this !udc->driver test, and thus drop the locking around it ;-).

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/kernel/irq/manage.c#L432
[2]http://lxr.free-electrons.com/source/kernel/irq/manage.c#L92



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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: Control message failures kill entire XHCI stack

[Devin Heitmueller]

Hi Mathias,

Thanks for getting back to me.

> There are a couple of xhci bugs triggered by dvb devices:
> https://bugzilla.kernel.org/show_bug.cgi?id=75521
> https://bugzilla.kernel.org/show_bug.cgi?id=65021
>
> The first one (75521) I believe is mostly fixed by patches in 3.18 and early
> 3.19-rc, so work on a 3.19-rc kernel to eliminate those issues.

Yeah, I'm already running 3.19-rc1 so I should be in good shape for
the first issue (and I've never seen any errors that resemble those in
the bug report).

> The second bug (65021) looks more like your case, it queues two stop_endpoints
> commands almost simultaneously, which end up never completing, ->timeout and 
> tear down xhci.
> That bug has a debug patch for command ring status, you could try it out to 
> check if
> the command queue is running among other details.

The second bug definitely looks like what I'm seeing.  I'll try your
tree and report back my findings.

> A verbose xhci dmesg log log using:
> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
> could give some insight to what's happening

Just to be clear, the log I provided in my original email actually was
with "xhci_hcd +p", but I'm assuming you mean to provide that log
output after loading up your "for-usb-next-test" tree.

I'm happy to ship you a device if you want to reproduce the issue
locally.  On my 2014 Macbook Pro all I have to do is plug in the
device and run the tvtime application that ships with most distros,
and it fails 100% of the time within 5 seconds (you don't actually
need a DVB or analog TV source connected to hit the bug).  Just email
me your shipping info off-list if you're interested.

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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 v2 2/5] usb: dwc3: add revision number DWC3_REVISION_300A

[Felipe Balbi]

On Mon, Jan 19, 2015 at 07:45:31PM +, John Youn wrote:
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Monday, January 19, 2015 6:47 AM
> > 
> > looking at Synopsys Solvnet for this IP, it shows that current version
> > is 2.90a. There's no 3.00a. Paul, John, is there a 3.00a version of the
> > DWC USB3 IP ?
> 
> Yes there is, but it has not been released yet, thus it's not in Solvnet.

alright, in that case, Sneeker, can you update this patch to add 2.90a
and 3.00a macros ?

Thanks

-- 
balbi


signature.asc
Description: Digital signature

RE: [PATCH v2 2/5] usb: dwc3: add revision number DWC3_REVISION_300A

[John Youn]

> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Monday, January 19, 2015 6:47 AM
>   
> looking at Synopsys Solvnet for this IP, it shows that current version
> is 2.90a. There's no 3.00a. Paul, John, is there a 3.00a version of the
> DWC USB3 IP ?

Yes there is, but it has not been released yet, thus it's not in Solvnet.

John


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

Re: [PATCH 5/5] ARM: omap2plus_defconfig: Enable PCF857X and EXTCON_GPIO_USB

[Tony Lindgren]

* Tony Lindgren  [150119 10:52]:
> * Roger Quadros  [150119 09:55]:
> > Both are needed for USB cable type detection on dra7-evm.
> > 
> > Signed-off-by: Roger Quadros 
> > ---
> >  arch/arm/configs/omap2plus_defconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm/configs/omap2plus_defconfig 
> > b/arch/arm/configs/omap2plus_defconfig
> > index c2c3a85..bc23b90 100644
> > --- a/arch/arm/configs/omap2plus_defconfig
> > +++ b/arch/arm/configs/omap2plus_defconfig
> > @@ -203,6 +203,7 @@ CONFIG_SPI_OMAP24XX=y
> >  CONFIG_PINCTRL_SINGLE=y
> >  CONFIG_DEBUG_GPIO=y
> >  CONFIG_GPIO_SYSFS=y
> > +CONFIG_GPIO_PCF857X=y
> >  CONFIG_GPIO_TWL4030=y
> >  CONFIG_W1=y
> >  CONFIG_BATTERY_BQ27x00=m
> 
> Looks like I have this too but as a loadable module :) So I'll keep
> that one.
> 
> > @@ -326,6 +327,7 @@ CONFIG_DMADEVICES=y
> >  CONFIG_TI_EDMA=y
> >  CONFIG_DMA_OMAP=y
> >  CONFIG_EXTCON=y
> > +CONFIG_EXTCON_GPIO_USB=y
> >  CONFIG_EXTCON_PALMAS=y
> >  CONFIG_PWM=y
> >  CONFIG_PWM_TIECAP=y
> 
> I'll apply this part into omap-for-v3.20/defconfig but make it into =m
> instead of =y.

Oh but this depends on the driver being added, so not applying.
Can you please repost a patch adding CONFIG_EXTCON_GPIO_USB=m
once the driver is merged?

Regards,

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

[PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

[Kristian Evensen]

The Yepkit YKUSH  is a three-port
switchable USB hub. In addition the to actual hub device, an HID device is
exported (VID 0x04D8 PID 0x0042). By sending specific commands to the HID
device, it is possible to power up/down the three ports separately or all ports
together. Commands 0x01-0x03 is used to power down ports 1-3, while 0x0A is used
to power down all ports. In order to power up a port (or all ports), the command
is OR'd with 0x10.

Signed-off-by: Kristian Evensen 
---
 drivers/hid/hid-core.c|   1 +
 drivers/hid/hid-ids.h |   1 +
 drivers/usb/misc/Kconfig  |  11 +++
 drivers/usb/misc/Makefile |   1 +
 drivers/usb/misc/ykush.c  | 176 ++
 5 files changed, 190 insertions(+)
 create mode 100644 drivers/usb/misc/ykush.c

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8b63879..77afffc 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2328,6 +2328,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1208LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT2) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICK16F1454) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NATIONAL_SEMICONDUCTOR, 
USB_DEVICE_ID_N_S_HARMONY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100 + 
20) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9243359..8df4744 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -638,6 +638,7 @@
 #define USB_DEVICE_ID_PICKIT2  0x0033
 #define USB_DEVICE_ID_PICOLCD  0xc002
 #define USB_DEVICE_ID_PICOLCD_BOOTLOADER   0xf002
+#define USB_DEVICE_ID_PICK16F1454  0x0042
 
 #define USB_VENDOR_ID_MICROSOFT0x045e
 #define USB_DEVICE_ID_SIDEWINDER_GV0x003b
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 76d7720..4476d1d 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -255,3 +255,14 @@ config USB_LINK_LAYER_TEST
  This driver is for generating specific traffic for Super Speed Link
  Layer Test Device. Say Y only when you want to conduct USB Super Speed
  Link Layer Test for host controllers.
+
+config USB_YKUSH
+   tristate "USB Yepkit YKUSH driver"
+   help
+ Yepkit YKUSH is a three-port switchable USB hub (see
+ ).  Say Y here if you want to
+ add support for the switching part of the hub.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ykush.
+
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 65b0402..1dc17fe 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_USB_HSIC_USB3503)+= usb3503.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
+obj-$(CONFIG_USB_YKUSH)+= ykush.o
diff --git a/drivers/usb/misc/ykush.c b/drivers/usb/misc/ykush.c
new file mode 100644
index 000..0278796
--- /dev/null
+++ b/drivers/usb/misc/ykush.c
@@ -0,0 +1,176 @@
+/*
+ * Yepkit YKUSH driver
+ *
+ * Copyright (C) 2015 Kristian Evensen (kristian.even...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define DRIVER_AUTHOR "Kristian Evensen, kristian.even...@gmail.com"
+#define DRIVER_DESC "Yepkit YKUSH driver"
+
+#define CMD_PORT_1 0x01
+#define CMD_PORT_2 0x02
+#define CMD_PORT_3 0x03
+#define CMD_PORT_ALL   0x0A
+
+static const struct usb_device_id id_table[] = {
+   { USB_DEVICE(0x04d8, 0x0042) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table);
+
+struct ykush_hub {
+   struct usb_device *udev;
+   u8 port1;
+   u8 port2;
+   u8 port3;
+   u8 all;
+};
+
+static void send_port_cmd(struct ykush_hub *hub, u8 cmd)
+{
+   int retval = 0, actlength;
+   u8 *buffer = kmalloc(6, GFP_KERNEL);
+
+   if (!buffer) {
+   dev_err(&hub->udev->dev, "out of memory\n");
+   return;
+   }
+
+   buffer[0] = cmd;
+   buffer[1] = cmd;
+
+   retval = usb_interrupt_msg(hub->udev,
+  usb_sndctrlpipe(hub->udev, 1),
+  buffer,
+  6,
+  &actlength,
+  5000);
+
+   if (retval)
+   pr_info("retval = %d\n

Re: [PATCH] usb: gadget: composite: Provide list of registered functions

[Felipe Balbi]

On Mon, Jan 19, 2015 at 02:17:19PM +0100, Krzysztof Opasiak wrote:
> Driver which provides implementation of some USB functions
> registers usb_function_driver structure in composite framework.
> Function drivers are identifed using registered name.
> 
> When gadget is composed using configfs user must know what
> names has been registered. If function is compiled as a module
> this information can be found in modules.alias file. If
> function is compiled-in, there is no way to discover what
> usb functions are available in currently running kernel.
> 
> Such situation is nothing new for linux kernel.
> Similar situation is with file systems. While mounting user
> can provide an fs type argument using -t option in mount.
> Those type names are registered by drivers. To make those names
> discoverable there is a /proc/filesystems which
> exports the list of currently registered file systems.
> 
> This patch adds /proc/usb-functions attribute which exports
> the list of currently registered function drivers.
> This allows user to discover list of both compiled-in functions
> and from loaded kernel modules.
> 
> Signed-off-by: Krzysztof Opasiak 

you need to document the new file under Documentation/ABI/

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCHv2 1/4] Revert "usb: gadget: uvc: cleanup __uvcg_fill_strm()"

[Felipe Balbi]

On Mon, Jan 19, 2015 at 01:52:55PM +0100, Andrzej Pietrasiewicz wrote:
> This reverts commit c8dba1896595 ("usb: gadget: uvc: cleanup 
> __uvcg_fill_strm()").
> __uvcg_fill_stream() during its execution uses priv2 as a pointer
> to a pointer, because it advances the current position by the amount
> of data taken by each processed descriptor and the advanced position
> should be visible outside this function, so that the next time it is
> called, the current position corresponds to the place where it was
> the last time rather than again at the beginning of some block of data.
> In other words priv2 is an "out" parameter.
> 
> Signed-off-by: Andrzej Pietrasiewicz 

there's no need to revert it, I've dropped the commit from testing/next.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCHv3 1/2] USB: gadget: atmel_usba_udc: Fixed vbus_prev initial state

[Felipe Balbi]

On Mon, Jan 19, 2015 at 03:09:44PM +0100, Nicolas Ferre wrote:
> Le 18/01/2015 18:24, Sylvain Rochet a écrit :
> > If vbus gpio is high at init, we should set vbus_prev to true
> > accordingly to the current vbus state. Without that, we skip the first
> > vbus interrupt because the saved vbus state is not consistent.
> > 
> > Signed-off-by: Sylvain Rochet 
> 
> Indeed:
> Acked-by: Nicolas Ferre 
> 
> We can also add the following tags:
> Fixes: 914a3f3b3754 ("USB: add atmel_usba_udc driver")
> Cc:  # 2.6.x-ish

Please resend with the proper stable format. Also, this 2.6.x-ish should
be 2.6.24+, git describe helps a lot figuring these out.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/3] Revert "usb: gadget: uvc: cleanup __uvcg_fill_strm()"

[Felipe Balbi]

On Mon, Jan 19, 2015 at 01:42:24PM +0200, Laurent Pinchart wrote:
> Hi Andrzej,
> 
> On Monday 19 January 2015 12:23:38 Andrzej Pietrasiewicz wrote:
> > W dniu 19.01.2015 o 01:05, Laurent Pinchart pisze:
> > > Hi Andrzej,
> > > 
> > > Thank you for the patch.
> > > 
> > > On Friday 16 January 2015 15:14:26 Andrzej Pietrasiewicz wrote:
> > >> This reverts commit c0b53cb16250 ("usb: gadget: uvc: cleanup
> > >> __uvcg_fill_strm()").
> > > 
> > > I can't find that commit in Linus' master, next/master or Felipe's next
> > > branch. If the patch hasn't been applied there's no need to revert it :-)
> > 
> > I (used to) have it in Felipe's testing/next.
> > But now the commit is visible as
> > 
> > c8dba18965954e7e9439376e0aa40fb5bb4c67e3.
> 
> OK. That commit is in Felipe's testing/next branch, and I don't expect Felipe 
> to merge it in next. The revert is thus not needed for mainline.

testing/next is not immutable and I can drop that commit which I just
did.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 5/5] ARM: omap2plus_defconfig: Enable PCF857X and EXTCON_GPIO_USB

[Tony Lindgren]

* Roger Quadros  [150119 09:55]:
> Both are needed for USB cable type detection on dra7-evm.
> 
> Signed-off-by: Roger Quadros 
> ---
>  arch/arm/configs/omap2plus_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig 
> b/arch/arm/configs/omap2plus_defconfig
> index c2c3a85..bc23b90 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -203,6 +203,7 @@ CONFIG_SPI_OMAP24XX=y
>  CONFIG_PINCTRL_SINGLE=y
>  CONFIG_DEBUG_GPIO=y
>  CONFIG_GPIO_SYSFS=y
> +CONFIG_GPIO_PCF857X=y
>  CONFIG_GPIO_TWL4030=y
>  CONFIG_W1=y
>  CONFIG_BATTERY_BQ27x00=m

Looks like I have this too but as a loadable module :) So I'll keep
that one.

> @@ -326,6 +327,7 @@ CONFIG_DMADEVICES=y
>  CONFIG_TI_EDMA=y
>  CONFIG_DMA_OMAP=y
>  CONFIG_EXTCON=y
> +CONFIG_EXTCON_GPIO_USB=y
>  CONFIG_EXTCON_PALMAS=y
>  CONFIG_PWM=y
>  CONFIG_PWM_TIECAP=y

I'll apply this part into omap-for-v3.20/defconfig but make it into =m
instead of =y.

Regards,

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

Re: ohci: sporadic crash/lockup in ohci-hcd io_watchdog_func()

[Heiko Przybyl]

On Monday 19 January 2015 11:17:59 Alan Stern wrote:
> On Mon, 19 Jan 2015, Heiko Przybyl wrote:
> > It seems to be related to keyboard input (at least it happens when using
> > the keyboard), without relation to system load. Can happen within a day
> > after boot or after several days of hibernated uptime. Unfortunately, I
> > haven't found a way to reliably reproduce the issue, yet.
> > 
> > [..]
> > 
> > My (pretty wild) guess is, that the corruption happens through a race in
> > the interrupt handler ohci_irq(), which calls ohci_work(), which calls
> > finish_urb(), which states:
> > " * PRECONDITION:  ohci lock held, irqs blocked"
> > 
> > But ohci_irq() seems to only spin_[un]lock(), not spin_[un]lock_irq[save|
> > restore](). All other functions that call ohci_work() do at least
> > spin_[un]lock_irq. So irqs could still be enabled and possibly the event
> > triggered twice, thus the double list add?
> 
> That's easy enough to test.  All you have to do is change the
> spin_lock/unlock statements to their irq_save/restore variants.

Well, thought about that as well, but I'm not sure when to take it as fixed and 
when to take it as issue-just-didn't-happen-yet, because of the not-so-
deterministic occurrence of the error. But I can try it out anyway, just 
wanted to have some feedback before trying.

> 
> ohci_irq() is an interrupt handler.  In the absence of threaded IRQs,
> he kernel should always call interrupt handlers with interrupts
> disabled.  Do you specify "threadirqs" on your boot command line?
> 

Never used "threadirqs".

# cat /proc/cmdline 
BOOT_IMAGE=/boot/gentoo root=/dev/sda2 ro rootfstype=ext4 resume=/dev/sda3 
init=/usr/lib/systemd/systemd quiet libahci.ignore_sss=1 i8042.nopnp 
crashkernel=64M

> If that's not the explanation then we'll have to dig deeper.

I can still work on a saved vmcore dump of a crash. Btw. using crash(1) and 
its command `bt -E`shows two kernel mode exceptions. Though, I can't figure out 
where the first one originates from

CPU 3 IRQ STACK:
  KERNEL-MODE EXCEPTION FRAME AT: 88022ecc3638
[exception RIP: _raw_spin_unlock_irqrestore+9]
RIP: 814774b9  RSP: 88022ecc36e8  RFLAGS: 0202
RAX: 88022ecc36a8  RBX: 88022ecc36b0  RCX: 81290279
RDX: 2dff  RSI:   RDI: 88022ecc3788
RBP: 88022ecc36e8   R8: 0080   R9: 0023
R10: 813e6407  R11: ea000863ad80  R12: 88022ecc3658
R13: 81478b2a  R14: 88022ecc36e8  R15: 0001
ORIG_RAX: 81471cfd  CS: 0010  SS: 0018

0x814774b9 <+9>: decl   %gs:0xa860

CPU 5 IRQ STACK:
  KERNEL-MODE EXCEPTION FRAME AT: 88022ed43d98
[exception RIP: io_watchdog_func+112]
RIP: 81394b80  RSP: 88022ed43e48  RFLAGS: 00010006
RAX: 8800cb8aa598  RBX: 0296  RCX: 8800cbaa8030
RDX: dead00100100  RSI: cbaa91e0  RDI: 8800cbaa8030
RBP: 88022ed43e88   R8: 8800cbaa7fe8   R9: 0205
R10: 8800cbaa8030  R11: 8800cb8aa5a0  R12: dead001000c0
R13: 8800cb8aa248  R14: 8800cb8aa5b8  R15: 
ORIG_RAX:   CS: 0010  SS: 


> Alan Stern

Kind regards,

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

[PATCH][RESEND] storage: Revise/fix quirk for 04E6:000F SCM USB-SCSI converter

[Mark Knibbs]

I recently posted a patch ("storage: Add quirk for another SCM-based
USB-SCSI converter") to add a quirk for the converter with ID 04E6:000F,
which is listed along with 04E6:000B in the Windows INF file for the
Startech ICUSBSCSI2 as "eUSB SCSI Adapter (Bus Powered)".

The already-present quirk for 04E6:000B has USB_SC_SCSI/USB_PR_BULK, not
USB_SC_DEVICE/USB_PR_DEVICE. Change the 04E6:000F quirk to match that,
since it will probably be required.

Signed-off-by: Mark Knibbs 

---
Resending with tabs intact this time.

While I don't have one to check, later SCM converters probably use
vendor-specific class and protocol, thus specifying USB_SC_SCSI/USB_PR_BULK
is necessary. Some speculation as to the reason for the difference...

I'm not sure whether the change was for all later products, or is related
to the later products being bus-powered. Windows 98 was the current
mainstream OS when the eUSCSI converter was first introduced. That OS
didn't ship with a USB mass storage driver, thus in order to use the
converter the SCM driver had to be installed.

Later Windows 2000 was released, which included a USB mass storage driver.
If the user were to connect the converter before installing the SCM driver,
Windows would install its default mass storage driver which only works with
the SCSI device at ID 0. Perhaps SCM changed to a vendor-specific class/
protocol to prevent the Windows generic driver binding to it, and reduce
driver-related technical support issues?

Patch is based on 3.19-rc4.

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index 11c7a96..bfc4a6a 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -507,7 +507,7 @@ UNUSUAL_DEV(  0x04e6, 0x000c, 0x0100, 0x0100,
 UNUSUAL_DEV(  0x04e6, 0x000f, 0x, 0x,
"SCM Microsystems",
"eUSB SCSI Adapter (Bus Powered)",
-   USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
+   USB_SC_SCSI, USB_PR_BULK, usb_stor_euscsi_init,
US_FL_SCM_MULT_TARG ),
 
 UNUSUAL_DEV(  0x04e6, 0x0101, 0x0200, 0x0200,
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] extcon: gpio-usb: Introduce gpio usb extcon driver

[Roger Quadros]

This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.

The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.

For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)

This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.

Signed-off-by: Roger Quadros 
---
 .../devicetree/bindings/extcon/extcon-usb.txt  |  20 ++
 drivers/extcon/Kconfig |   7 +
 drivers/extcon/Makefile|   1 +
 drivers/extcon/extcon-gpio-usb.c   | 225 +
 4 files changed, 253 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb.txt
 create mode 100644 drivers/extcon/extcon-gpio-usb.c

diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb.txt 
b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
new file mode 100644
index 000..171c5a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
@@ -0,0 +1,20 @@
+USB Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be "linux,extcon-usb"
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+   extcon_usb1 {
+   compatible = "linux,extcon-usb";
+   id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+   }
+
+   usb@1 {
+   ...
+   extcon = <&extcon_usb1>;
+   ...
+   };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..8106a83 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -35,6 +35,13 @@ config EXTCON_GPIO
  Say Y here to enable GPIO based extcon support. Note that GPIO
  extcon supports single state per extcon instance.
 
+config EXTCON_GPIO_USB
+   tristate "USB GPIO extcon support"
+   depends on GPIOLIB
+   help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
 config EXTCON_MAX14577
tristate "MAX14577/77836 EXTCON Support"
depends on MFD_MAX14577
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..bae594b 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
 obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
 obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_GPIO_USB)  += extcon-gpio-usb.o
diff --git a/drivers/extcon/extcon-gpio-usb.c b/drivers/extcon/extcon-gpio-usb.c
new file mode 100644
index 000..aeb2298
--- /dev/null
+++ b/drivers/extcon/extcon-gpio-usb.c
@@ -0,0 +1,225 @@
+/**
+ * drivers/extcon/extcon_gpio_usb.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Roger Quadros 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB_GPIO_DEBOUNCE_MS   20  /* ms */
+
+struct usb_extcon_info {
+   struct device *dev;
+   struct extcon_dev *edev;
+
+   struct gpio_desc *id_gpiod;
+   int id_irq;
+
+   unsigned long debounce_jiffies;
+   struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+   EXTCON_CABLE_USB = 0,
+   EXTCON_CABLE_USB_HOST,
+
+   EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+   [EXTCON_CABLE_USB] = "USB",
+   [EXTCON_CABLE_USB_HOST] = "USB-Host",
+   NULL,
+};
+
+static void usb_extcon_detect_cable(struct work_struct *work)
+{
+   int id;
+   struct usb_extcon_info *info;
+   const char **cable_names;
+
+   info  = container_of(to_delayed_work(work), struct usb_extcon_info,
+wq_detcable);
+   cable_names = info->edev->supported_cable;
+
+   /* check ID and update cable state */
+   id = gpiod_get_value_cansleep(info->id_gpiod);
+
+   if (id) {
+   /*
+* ID = 1 means USB HOST cable detached.
+* As we don't have event for USB peripheral cable attached,
+   

[PATCH 2/5] usb: extcon: Fix USB-Host cable name

[Roger Quadros]

The recommended name for USB-Host cable state is "USB-Host" and not
"USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name.

Change all instances of "USB-HOST" to "USB-Host".

Signed-off-by: Roger Quadros 
---
 drivers/extcon/extcon-palmas.c | 18 +-
 drivers/usb/dwc3/dwc3-omap.c   |  6 +++---
 drivers/usb/phy/phy-omap-otg.c |  4 ++--
 drivers/usb/phy/phy-tahvo.c|  8 
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 11c6757..6d002c3 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -31,7 +31,7 @@
 
 static const char *palmas_extcon_cable[] = {
[0] = "USB",
-   [1] = "USB-HOST",
+   [1] = "USB-Host",
NULL,
 };
 
@@ -93,26 +93,26 @@ static irqreturn_t palmas_id_irq_handler(int irq, void 
*_palmas_usb)
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
-   extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
-   dev_info(palmas_usb->dev, "USB-HOST cable is attached\n");
+   extcon_set_cable_state(palmas_usb->edev, "USB-Host", true);
+   dev_info(palmas_usb->dev, "USB-Host cable is attached\n");
} else if ((set & PALMAS_USB_ID_INT_SRC_ID_FLOAT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_FLOAT)) {
palmas_write(palmas_usb->palmas, PALMAS_USB_OTG_BASE,
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
-   extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
-   dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
+   extcon_set_cable_state(palmas_usb->edev, "USB-Host", false);
+   dev_info(palmas_usb->dev, "USB-Host cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_ID) &&
(!(set & PALMAS_USB_ID_INT_SRC_ID_GND))) {
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
-   extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
-   dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
+   extcon_set_cable_state(palmas_usb->edev, "USB-Host", false);
+   dev_info(palmas_usb->dev, "USB-Host cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_DISCONNECT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_GND)) {
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
-   extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
-   dev_info(palmas_usb->dev, " USB-HOST cable is attached\n");
+   extcon_set_cable_state(palmas_usb->edev, "USB-Host", true);
+   dev_info(palmas_usb->dev, " USB-Host cable is attached\n");
}
 
return IRQ_HANDLED;
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 172d64e..6713ad9 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -445,14 +445,14 @@ static int dwc3_omap_extcon_register(struct dwc3_omap 
*omap)
 
omap->id_nb.notifier_call = dwc3_omap_id_notifier;
ret = extcon_register_interest(&omap->extcon_id_dev,
-  edev->name, "USB-HOST",
+  edev->name, "USB-Host",
   &omap->id_nb);
if (ret < 0)
-   dev_vdbg(omap->dev, "failed to register notifier for 
USB-HOST\n");
+   dev_vdbg(omap->dev, "failed to register notifier for 
USB-Host\n");
 
if (extcon_get_cable_state(edev, "USB") == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
-   if (extcon_get_cable_state(edev, "USB-HOST") == true)
+   if (extcon_get_cable_state(edev, "USB-Host") == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
}
 
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 56ee760..53cba3f 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -119,7 +119,7 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
 
ret = extcon_register_interest(&otg_dev->id_dev, config->extcon,
-  "USB-HOST", &otg_dev->id_nb);
+  "USB-Host", &otg_dev->id_nb);
if (ret)
return ret;
 
@@ -130,7 +130,7 @@ static int omap_otg_probe(struct platform_device *pdev)
return ret;

[PATCH 3/5] ARM: dts: dra7-evm: Add extcon nodes for USB

[Roger Quadros]

On this EVM, the USB cable state has to be determined via the
ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
to read the ID pin and the extcon framework to forward
the USB cable state information to the USB driver so the
controller can be configured in the right mode (host/peripheral).

Gets USB peripheral mode to work on this EVM.

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra7-evm.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 10b725c..47d9a06 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -26,6 +26,16 @@
regulator-max-microvolt = <330>;
};
 
+   extcon_usb1: extcon_usb1 {
+   compatible = "linux,extcon-usb";
+   id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   extcon_usb2: extcon_usb2 {
+   compatible = "linux,extcon-usb";
+   id-gpio = <&pcf_gpio_21 2 GPIO_ACTIVE_HIGH>;
+   };
+
vtt_fixed: fixedregulator-vtt {
compatible = "regulator-fixed";
regulator-name = "vtt_fixed";
@@ -391,6 +401,19 @@
};
};
};
+
+   pcf_gpio_21: gpio@21 {
+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   lines-initial-states = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
 };
 
 &i2c2 {
@@ -520,6 +543,14 @@
};
 };
 
+&omap_dwc3_1 {
+   extcon = <&extcon_usb1>;
+};
+
+&omap_dwc3_2 {
+   extcon = <&extcon_usb2>;
+};
+
 &usb1 {
dr_mode = "peripheral";
pinctrl-names = "default";
-- 
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

[PATCH 5/5] ARM: omap2plus_defconfig: Enable PCF857X and EXTCON_GPIO_USB

[Roger Quadros]

Both are needed for USB cable type detection on dra7-evm.

Signed-off-by: Roger Quadros 
---
 arch/arm/configs/omap2plus_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index c2c3a85..bc23b90 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -203,6 +203,7 @@ CONFIG_SPI_OMAP24XX=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_PCF857X=y
 CONFIG_GPIO_TWL4030=y
 CONFIG_W1=y
 CONFIG_BATTERY_BQ27x00=m
@@ -326,6 +327,7 @@ CONFIG_DMADEVICES=y
 CONFIG_TI_EDMA=y
 CONFIG_DMA_OMAP=y
 CONFIG_EXTCON=y
+CONFIG_EXTCON_GPIO_USB=y
 CONFIG_EXTCON_PALMAS=y
 CONFIG_PWM=y
 CONFIG_PWM_TIECAP=y
-- 
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

[PATCH 0/5] extcon: usb: Introduce USB GPIO extcon driver. Fix DRA7 USB.

[Roger Quadros]

Hi,

On DRA7 EVMs the USB ID pin is connected to a GPIO line. The USB drivers
(dwc3 + dwc3-omap) depend on extcon framework to get the USB cable state
(USB or USB-Host) to put the controller in the right mode.

There were earlier attempts [1] to get this working by trying to patch up
the existing GPIO extcon driver.

This series attemts to take a different approach by introducing a new
USB specific extcon driver to handle the USB ID GPIO pin and
interpret a right USB cable state.

The reasoning to introduce this new driver is:
1) The existing GPIO extcon driver doesn't understand USB cable states
and it can't handle more than one cable per instance.
   
For the USB case we need to handle at least 2 cable states.
a) USB (attach/detach)
b) USB-Host (attach/detach)
and could possible include more states like
c) Fast-charger (attach/detach)
d) Slow-charger (attach/detach)

2) This USB specific driver can be easily updated in the future to
handle VBUS events, or charger detect events, in case it happens
to be available on GPIO for any platform.

3) The DT implementation is very easy. You just need one extcon node per USB
instead of one extcon node per cable state as in case of [1].

4) The cable state string doesn't need to be encoded in the device tree
as in case of [1].

5) With only ID event available, you can simulate a USB-peripheral attach
when USB-Host is detacted instead of hacking the USB driver to do the same.

Tested on DRA7-evm and DRA72-evm.

cheers,
-roger
[1] - https://lkml.org/lkml/2014/11/3/513

Roger Quadros (5):
  extcon: gpio-usb: Introduce gpio usb extcon driver
  usb: extcon: Fix USB-Host cable name
  ARM: dts: dra7-evm: Add extcon nodes for USB
  ARM: dts: dra72-evm: Add extcon nodes for USB
  ARM: omap2plus_defconfig: Enable PCF857X and EXTCON_GPIO_USB

 .../devicetree/bindings/extcon/extcon-usb.txt  |  20 ++
 arch/arm/boot/dts/dra7-evm.dts |  31 +++
 arch/arm/boot/dts/dra72-evm.dts|  31 +++
 arch/arm/configs/omap2plus_defconfig   |   2 +
 drivers/extcon/Kconfig |   7 +
 drivers/extcon/Makefile|   1 +
 drivers/extcon/extcon-gpio-usb.c   | 225 +
 drivers/extcon/extcon-palmas.c |  18 +-
 drivers/usb/dwc3/dwc3-omap.c   |   6 +-
 drivers/usb/phy/phy-omap-otg.c |   4 +-
 drivers/usb/phy/phy-tahvo.c|   8 +-
 11 files changed, 335 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb.txt
 create mode 100644 drivers/extcon/extcon-gpio-usb.c

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

[PATCH 4/5] ARM: dts: dra72-evm: Add extcon nodes for USB

[Roger Quadros]

On this EVM, the USB cable state has to be determined via the
ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
to read the ID pin and the extcon framework to forward
the USB cable state information to the USB driver so the
controller can be configured in the right mode (host/peripheral).

Gets USB peripheral mode to work on this EVM.

Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra72-evm.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 89085d0..d93a98f 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -8,6 +8,7 @@
 /dts-v1/;
 
 #include "dra72x.dtsi"
+#include 
 
 / {
model = "TI DRA722";
@@ -24,6 +25,16 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+   extcon_usb1: extcon_usb1 {
+   compatible = "linux,extcon-usb";
+   id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   extcon_usb2: extcon_usb2 {
+   compatible = "linux,extcon-usb";
+   id-gpio = <&pcf_gpio_21 2 GPIO_ACTIVE_HIGH>;
+   };
 };
 
 &dra7_pmx_core {
@@ -243,6 +254,18 @@
ti,palmas-long-press-seconds = <6>;
};
};
+
+   pcf_gpio_21: gpio@21 {
+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   lines-initial-states = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
 };
 
 &uart1 {
@@ -345,6 +368,14 @@
phy-supply = <&ldo4_reg>;
 };
 
+&omap_dwc3_1 {
+   extcon = <&extcon_usb1>;
+};
+
+&omap_dwc3_2 {
+   extcon = <&extcon_usb2>;
+};
+
 &usb1 {
dr_mode = "peripheral";
pinctrl-names = "default";
-- 
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: [PATCHv3 2/2] USB: gadget: atmel_usba_udc: Enable/disable USB PLL on Vbus change

[Sylvain Rochet]

Hello Nicolas,


On Mon, Jan 19, 2015 at 05:55:18PM +0100, Nicolas Ferre wrote:
> Le 18/01/2015 18:24, Sylvain Rochet a écrit :
> > Prepare_enable on rising edge, disable_unprepare on falling edge. Reduce
>
> Please re-write which "edge" we are talking about: "... falling edge of
> the Vbus signal" for example.
>
> > power consumption if USB PLL is not already necessary for OHCI or EHCI.
>
> Is a verb missing in the previous sentence?
>
> > If USB host is not connected we can sleep with USB PLL stopped.
> >
> > This driver does not support suspend/resume yet, not suspending if we
> > are still attached to an USB host is fine for what I need, this patch
> > allow suspending with USB PLL stopped when USB device is not currently
> > used.
>
> Can you please make it more clear. Several separated sentences seem
> necessary here.

Maybe :)


Proposal:

Start clocks on rising edge of the Vbus signal, stop clocks on 
falling edge of the Vbus signal.

If USB PLL is not necessary for other USB drivers (e.g. OHCI and EHCI) 
it will reduce power consumption by switching off the USB PLL if no USB 
Host is currently connected to this USB Device.

We are using Vbus GPIO signal to detect Host presence. If Vbus signal is 
not available then the device stay continuously clocked.

Note this driver does not support suspend/resume yet, it may stay 
clocked if USB Host is still connected when suspending. For what I need, 
forbidding suspend from userland if we are still attached to an USB host 
is fine, but we might as well add suspend/resume to this driver in the 
future.



> > /* May happen if Vbus pin toggles during probe() */
> > -   if (!udc->driver)
> > +   spin_lock_irqsave(&udc->lock, flags);
> > +   if (!udc->driver) {
> > +   spin_unlock_irqrestore(&udc->lock, flags);
> > goto out;
> > +   }
> > +   spin_unlock_irqrestore(&udc->lock, flags);
> 
> I'm not sure that the protection by spin_lock is needed above.

I'm not sure too, it was already in a spinlock area, I obviously kept it 
because it was not the purpose of this patch.

This seem to be in mirror of atmel_usba_start() which does:

  spin_lock_irqsave(&udc->lock, flags);
  udc->devstatus = 1 << USB_DEVICE_SELF_POWERED;
  udc->driver = driver;
  spin_unlock_irqrestore(&udc->lock, flags);

… but vbus_pin IRQ is not yet enabled.


Same for atmel_usba_stop() which disable vbus_pin IRQ before setting 
udc->driver to NULL, but without spinlock this time (why?, this should 
be consistent IMHO).


I don't know if it is guaranteed that IRQ does not fire nor continue to 
run after disable_irq() returns, especially for threaded IRQ.


If the following sequence might happen:
  atmel_usba_stop()
disable_irq(vbus)
  usba_vbus_irq_thread() called lately
check for (!udc->driver) and continue
udc->driver = NULL;
if (udc->driver->disconnect)
 *CRASH*

Then the patch should be modified to protect udc->driver with the vbus 
mutex.

In this case the previous implementation wasn't perfect too, the 
atmel_usba_stop() does not lock around the NULLification of driver, 

Moreover the spinlock is (and was) unlocked in VBUS interrupt just 
before calling udc->driver->disconnect, which makes udc->driver actually 
not locked anywere.

If the previous sequence possible ?  If no, udc->driver does not need 
locking, if yes, it is currently not locked enough.


Sylvain
--
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/6] usb: gadget: uvc: cleanup __uvcg_fill_strm()

[Dan Carpenter]

On Mon, Jan 19, 2015 at 10:09:44AM -0600, Felipe Balbi wrote:
> On Fri, Jan 16, 2015 at 01:44:44PM +0100, Andrzej Pietrasiewicz wrote:
> > W dniu 16.01.2015 o 13:12, Dan Carpenter pisze:
> > >Oh, yeah.  You're right.  I should have been more careful and I should
> > >have seen that.  Sorry.  But the problem is the original code is still a
> > >bit buggy.
> > >
> > >We call:
> > >
> > >   data = kzalloc();
> > >
> > >Inside __uvcg_fill_strm() we do "data += something;"
> > >
> > >   kfree(data);
> > >
> > >We should save the orignal data pointer so that we can free it
> > >correctly at the end in uvcg_streaming_class_allow_link().
> > >
> > Yeah, right. Thank you for spotting this. The kfree() is called
> > only if __uvcg_fill_strm() fails, though. But of course this needs
> > to be fixed.
> 
> so, should I wait for another version of $subject ?
> 

My patch should just be reverted.  It was totally wrong.  There is a bug
"in theory, but not in reality" that Andrzej should fix as well.

regards,
dan carpenter

--
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 2/2] USB: gadget: atmel_usba_udc: Enable/disable USB PLL on Vbus change

[Nicolas Ferre]

Le 18/01/2015 18:24, Sylvain Rochet a écrit :
> Prepare_enable on rising edge, disable_unprepare on falling edge. Reduce

Please re-write which "edge" we are talking about: "... falling edge of
the Vbus signal" for example.

> power consumption if USB PLL is not already necessary for OHCI or EHCI.

Is a verb missing in the previous sentence?

> If USB host is not connected we can sleep with USB PLL stopped.
> 
> This driver does not support suspend/resume yet, not suspending if we
> are still attached to an USB host is fine for what I need, this patch
> allow suspending with USB PLL stopped when USB device is not currently
> used.

Can you please make it more clear. Several separated sentences seem
necessary here.

> Signed-off-by: Sylvain Rochet 
> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 96 
> -
>  drivers/usb/gadget/udc/atmel_usba_udc.h |  4 ++
>  2 files changed, 74 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index e207d75..9cce50a 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -315,6 +315,38 @@ static inline void usba_cleanup_debugfs(struct usba_udc 
> *udc)
>  }
>  #endif
>  
> +static int start_clock(struct usba_udc *udc)
> +{
> + int ret;
> +
> + if (udc->clocked)
> + return 0;
> +
> + ret = clk_prepare_enable(udc->pclk);
> + if (ret)
> + return ret;
> + ret = clk_prepare_enable(udc->hclk);
> + if (ret) {
> + clk_disable_unprepare(udc->pclk);
> + return ret;
> + }
> +
> + udc->clocked = true;
> + return ret;
> +}
> +
> +static int stop_clock(struct usba_udc *udc)
> +{
> + if (!udc->clocked)
> + return 0;
> +
> + clk_disable_unprepare(udc->hclk);
> + clk_disable_unprepare(udc->pclk);
> +
> + udc->clocked = false;
> + return 0;
> +}
> +
>  static int vbus_is_present(struct usba_udc *udc)
>  {
>   if (gpio_is_valid(udc->vbus_pin))
> @@ -1719,42 +1751,56 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
>   return IRQ_HANDLED;
>  }
>  
> -static irqreturn_t usba_vbus_irq(int irq, void *devid)
> +static irqreturn_t usba_vbus_irq_thread(int irq, void *devid)
>  {
>   struct usba_udc *udc = devid;
>   int vbus;
> + int ret;
> + unsigned long flags;
>  
>   /* debounce */
>   udelay(10);
>  
> - spin_lock(&udc->lock);
> + mutex_lock(&udc->vbus_mutex);
>  
>   /* May happen if Vbus pin toggles during probe() */
> - if (!udc->driver)
> + spin_lock_irqsave(&udc->lock, flags);
> + if (!udc->driver) {
> + spin_unlock_irqrestore(&udc->lock, flags);
>   goto out;
> + }
> + spin_unlock_irqrestore(&udc->lock, flags);

I'm not sure that the protection by spin_lock is needed above.

>  
>   vbus = vbus_is_present(udc);
>   if (vbus != udc->vbus_prev) {
>   if (vbus) {
> + ret = start_clock(udc);
> + if (ret)
> + goto out;
> +
> + spin_lock_irqsave(&udc->lock, flags);
>   toggle_bias(1);
>   usba_writel(udc, CTRL, USBA_ENABLE_MASK);
>   usba_writel(udc, INT_ENB, USBA_END_OF_RESET);
> + spin_unlock_irqrestore(&udc->lock, flags);
>   } else {
> + spin_lock_irqsave(&udc->lock, flags);
>   udc->gadget.speed = USB_SPEED_UNKNOWN;
>   reset_all_endpoints(udc);
>   toggle_bias(0);
>   usba_writel(udc, CTRL, USBA_DISABLE_MASK);
> - if (udc->driver->disconnect) {
> - spin_unlock(&udc->lock);
> + spin_unlock_irqrestore(&udc->lock, flags);
> +
> + stop_clock(udc);
> +
> + if (udc->driver->disconnect)
>   udc->driver->disconnect(&udc->gadget);
> - spin_lock(&udc->lock);
> - }
>   }
>   udc->vbus_prev = vbus;
>   }
>  
>  out:
> - spin_unlock(&udc->lock);
> + mutex_unlock(&udc->vbus_mutex);
>  
>   return IRQ_HANDLED;
>  }
> @@ -1762,7 +1808,7 @@ out:
>  static int atmel_usba_start(struct usb_gadget *gadget,
>   struct usb_gadget_driver *driver)
>  {
> - int ret;
> + int ret = 0;
>   struct usba_udc *udc = container_of(gadget, struct usba_udc, gadget);
>   unsigned long flags;
>  
> @@ -1772,31 +1818,29 @@ static int atmel_usba_start(struct usb_gadget *gadget,
>   udc->driver = driver;
>   spin_unlock_irqrestore(&udc->lock, flags);
>  
> - ret = clk_prepare_enable(udc->pclk);
> - if (ret)
> - return ret;
> - ret = clk_prepare_enable(udc->hclk);
> - if (ret) {

Re: [PATCHv6 0/6] USB: host: Atmel OHCI and EHCI drivers improvements

[Alan Stern]

On Mon, 19 Jan 2015, Sylvain Rochet wrote:

> USB: host: Atmel OHCI and EHCI drivers improvements
> 
> Suspend/resume support for EHCI.
> struct dev_pm_ops for OHCI.
> Removed global variables from both.
> Fixed OHCI wake up support for STANDBY(wake-up enabled) and MEM(wake-up
> disabled) sleep targets.
> 
> Changes since v5:
>   * Don't overwrite device wakeup flag with device_init_wakeup(),
> now using a private wakeup bool instead.
> 
> Changes since v4:
>   * Re-add at91_suspend_entering_slow_clock() to OHCI, we can't naively
> remove this one, this device needs to be continuously clocked to
> provide wake up support.
> The removal of at91_suspend_entering_slow_clock() actually lighted up
> an issue on wake up support, which is now fixed.
> 
> Changes since v3:
>   * Using struct dev_pm_ops instead of static struct platform_driver
> resume and suspend bindings for both EHCI and OHCI
>   * Fixed inconsistency in patch subjects, _ intead of - for file names
>   * Patch cleaning with the help of checkpatch.pl, fixed lines over
> 80 characters
> 
> Changes since v2:
>   * Added patchs from an other submission, because this series
> depended on this one
> * EHCI: Move global variables to private struct
> * OHCI: Move global variables to private struct
>   * Using ohci->priv and ehci->priv instead of hcd->hcd_priv,
> which were not the right way to do that
> 
> Changes since v1:
>   * Don't use at91_suspend_entering_slow_clock() on EHCI,
> we are trying to get read of this of this function
>   * Removed at91_suspend_entering_slow_clock() from OHCI
> 
> Sylvain Rochet (6):
>   USB: host: ehci-atmel: Add suspend/resume support
>   USB: host: ohci-at91: Use struct dev_pm_ops instead of struct
> platform_driver
>   USB: host: ehci-atmel: Move global variables to private struct
>   USB: host: ohci-at91: Move global variables to private struct
>   USB: host: ohci-at91: usb_hcd_at91_probe(), remove useless stack
> initialisation
>   USB: host: ohci-at91: Fix wake-up support
> 
>  drivers/usb/host/ehci-atmel.c | 102 +-
>  drivers/usb/host/ohci-at91.c  | 126 
> ++
>  2 files changed, 154 insertions(+), 74 deletions(-)

For all 6 patches:

Acked-by: Alan Stern 

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: XHCI,

[Hans-Peter Jansen]

Mathias Nyman  writes:

> 
> To me it looked like the issue was fixes for several people by updating
the system,
> and I didn't follow up on this issue that much.

Not to my knowledge. Those, that suffered from this still do!
 
> I'm stating to abandon the microframe interval theory and think this is
related
> to endpoint halting or toggle bit status.
> 
> checking the usbmon output it looks like scanner code regularly does a 
> clear_feature[endpoint halt].
> 
> Many changes were done in 3.18 and 3.19-rc release regarding to how we handle 
> halted and stopped endpoints, Can you test if that fixes your issues? 
> preferably with a 3.19-rc kernel

Well, I've tested 3.18.2 now with the same result.
Will test a more current kernel soon.

Pete

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

[discuss] [cdc_ncm] Refactoring cdc_ncm

[Enrico Mioso]

Hi guys.
I am noticing that in kernel 3.19rc4, the driver from huawei,
hw_cdc_driver
is not able to perform the call to
netif_msg_ifup anymore (receives error -13).
This to say that it would be very important to continue the work on refactoring 
cdc_ncm.c driver to let it work with newer huawei devices such as the E3372 
even at full rates.
I received some acks regarding the patches I sent last time - and I am grateful 
to you all maintainers / reviewers. I have actually not received acks for all 
the patches so I preferred waiting and not continously re-sending again.

This also happened due to me getting very busy lately with studying.
So the situation is getting complicated.
I sent this mail to everyone just to keep you up-to-date. Don't worry.
Any help from any developer interested would be very apreciated.
I would need some mentoring or help in general with coding.

Thank you all very much.

Sincerely.

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

Re: [PATCH 00/23] Use USB_CHAR_* in the host drivers

[Alan Stern]

On Mon, 19 Jan 2015, Sergei Shtylyov wrote:

> Hello.
> 
>Here's a set of 23 patches against the 'usb-next' branch of Greg KH's
> 'usb.git' repo plus 2 FHCI patches I posted a week ago. It's to replace the
> use of the hex numbers where the USB_CHAR_* #define's should have been used.
> 
> [01/23] ehci-hub: use HUB_CHAR_*
> [02/23] fhci-hub: use HUB_CHAR_*
> [03/23] fotg210-hcd: use HUB_CHAR_*
> [04/23] fusbh200-hcd: use HUB_CHAR_*
> [05/23] imx21-hcd: use HUB_CHAR_*
> [06/23] isp116x-hcd: use HUB_CHAR_*
> [07/23] isp1362-hcd: use HUB_CHAR_*
> [08/23] isp1760-hcd: use HUB_CHAR_*
> [09/23] max3421-hcd: use HUB_CHAR_*
> [10/23] ohci-at91: use HUB_CHAR_*
> [11/23] ohci-hub: use HUB_CHAR_*
> [12/23] ohci-s3c2410: use HUB_CHAR_*
> [13/23] oxu210hp-hcd: use HUB_CHAR_*
> [14/23] r8a66597-hcd: use HUB_CHAR_*
> [15/23] sl811-hcd: use HUB_CHAR_*
> [16/23] u132-hcd: use HUB_CHAR_*
> [17/23] uhci-hub: use HUB_CHAR_*
> [18/23] dwc2: hcd: use HUB_CHAR_*
> [19/23] dummy_hcd: use HUB_CHAR_*
> [20/23] musb_virthub: use HUB_CHAR_*
> [21/23] renesas_usbhs: mod_host: use HUB_CHAR_*
> [22/23] usbip: vhci_hcd: use HUB_CHAR_*
> [23/23] wusbcore: rh: use HUB_CHAR_*

Apart from one minor change in uhci-hub.c,

Acked-by: Alan Stern 

for all the EHCI, OHCI, UHCI, and dummy-hcd changes.

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 17/23] uhci-hub: use HUB_CHAR_*

[Alan Stern]

On Mon, 19 Jan 2015, Sergei Shtylyov wrote:

> Fix  using the  bare number  to set the 'wHubCharacteristics' field of the Hub
> Descriptor while the values are #define'd in .
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  drivers/usb/host/uhci-hub.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Index: usb/drivers/usb/host/uhci-hub.c
> ===
> --- usb.orig/drivers/usb/host/uhci-hub.c
> +++ usb/drivers/usb/host/uhci-hub.c
> @@ -17,8 +17,9 @@ static const __u8 root_hub_hub_des[] =
>   0x09,   /*  __u8  bLength; */
>   0x29,   /*  __u8  bDescriptorType; Hub-descriptor */
>   0x02,   /*  __u8  bNbrPorts; */
> - 0x0a,   /* __u16  wHubCharacteristics; */
> - 0x00,   /*   (per-port OC, no power switching) */
> + HUB_CHAR_NO_LPSM |  /* __u16  wHubCharacteristics; */
> + HUB_CHAR_INDV_PORT_OCPM, /* (per-port OC, no power switching) */

I'd prefer to see the second line indented more, even if it means the 
comment has to spill over to a third line.

> + 0x00,
>   0x01,   /*  __u8  bPwrOn2pwrGood; 2ms */
>   0x00,   /*  __u8  bHubContrCurrent; 0 mA */
>   0x00,   /*  __u8  DeviceRemovable; *** 7 Ports max */

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: phy: never defer probe in non-OF case

[Felipe Balbi]

On Fri, Jan 16, 2015 at 04:10:31PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 1/16/2015 11:30 AM, Heikki Krogerus wrote:
> 
> >In practice failure to find phy when requested in non-OF
> >case means it will never become available, so
> >__usb_find_phy() must return -ENODEV and not -EPROBE_DEFER.
> 
> >This fixes a regression caused by commit
> >9c9d82492b73991e8e13a6c0af06e44816c31438, where the USB
> 
>Please also specify that commit's summary in parens.

I'll fix when applying.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 1/3] usb: udc: add usb_gadget_find_udc

[Alan Stern]

On Mon, 19 Jan 2015, Peter Chen wrote:

> > > An idea just struck me...  Instead of looping through all the udc's to
> > > find the right one, why not simply store a pointer to the udc in struct
> > > usb_gadget?
> > > 
> 
> We still have code to find usb_gadget_driver to iterate udc_list, it
> is better to change all, we need to have solution to consolidate
> struct usb_udc, struct usb_gadget, and struct usb_gadget_drver.
> I have no good solution now.

I think it's okay to iterate through the list to find a 
usb_gadget_driver.  But it's silly to iterate to find the usb_udc 
corresponding to a usb_gadget.

> > > Also, it looks like there's a bug in usb_add_gadget_udc_release() in 
> > > udc-core.c.  The error pathway (between err3 and err2) does not undo 
> > > the
> > > 
> > >   ret = device_register(&gadget->dev);
> > > 
> > > call.  There's a put_device() call but no device_del().
> > 
> > good point :-) Do you want to send a patch for that ?
> > 
> 
> It looks like there is another issue in error pathway, the
> put_device(&udc->dev) at err3 should be moved to err4 since
> the get_device is called at device_add.

No, the get_device is done by device_initialize, so the code is correct 
as it stands.  See the kerneldoc for device_initialize() in 
drivers/base/core.c.

Alan Stern

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

Re: [PATCH v3 3/3] usb: udc: add usb_udc_activation_handler

[Alan Stern]

On Mon, 19 Jan 2015, Peter Chen wrote:

> On Fri, Jan 16, 2015 at 11:11:56AM -0500, Alan Stern wrote:
> > On Fri, 16 Jan 2015, Peter Chen wrote:
> > 
> > > During this API, the deactivation count will be update, and it
> > > will try to connect or disconnect gadget. It can be used to
> > > enable functions for gadget.
> > > 
> > > Signed-off-by: Peter Chen 
> > > ---
> > >  drivers/usb/gadget/udc/udc-core.c | 28 +++-
> > >  include/linux/usb/gadget.h|  5 +
> > >  2 files changed, 32 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/usb/gadget/udc/udc-core.c 
> > > b/drivers/usb/gadget/udc/udc-core.c
> > > index 9396a86..86d4d19 100644
> > > --- a/drivers/usb/gadget/udc/udc-core.c
> > > +++ b/drivers/usb/gadget/udc/udc-core.c
> > > @@ -37,6 +37,7 @@
> > >   * @list - for use by the udc class driver
> > >   * @vbus - for udcs who care about vbus status, this value is real vbus 
> > > status;
> > >   * for udcs who do not care about vbus status, this value is always true
> > > + * @deactivations - the deactivation count to connect or disconnect 
> > > gadget
> > 
> > How will this field get initialized?
> > 
> 
> Thanks, Alan.
> 
> The function driver will be deactivated default, the patch likes below:
> 
> http://permalink.gmane.org/gmane.linux.usb.general/112747
> 
> (Call usb_udc_activation_handler instead of usb_function_deactivate)
> 
> The function driver can activate itself at the .bind or on the demand.
> 
> http://permalink.gmane.org/gmane.linux.usb.general/112748
> http://permalink.gmane.org/gmane.linux.usb.general/112752

Okay, then I have no objections.

Acked-by: Alan Stern 

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

Re: ohci: sporadic crash/lockup in ohci-hcd io_watchdog_func()

[Alan Stern]

On Mon, 19 Jan 2015, Heiko Przybyl wrote:

> Hi all,
> 
> been redirected here from bug #91511 [1].
> 
> I'm getting sporadic crashes in io_watchdog_func() in drivers/usb/host/ohci-
> hcd.c:761:
> "
> list_for_each_entry(ed, &ohci->eds_in_use, in_use_list) {
> if (ed->pending_td) {
> "
> with the in_use list getting corrupted:
> 
> from ohci_urb_enqueue():
> [43656.918055] list_add double add: new=8800cbaa8040, 
> prev=8800cb8aa5b8, 
> next=8800cbaa8040.
> from ohci_work.part():
> [43656.920980] list_del corruption. next->prev should be 8800cbaa8040, 
> but 
> was 8800cb8aa5b8
> 
> One or both set the pointer to 0xdead00100100 and 0xdead001000c0, 
> where io_watchdog_func() chokes on [2].

That is indeed a bad bug.

> It seems to be related to keyboard input (at least it happens when using the 
> keyboard), without relation to system load. Can happen within a day after 
> boot 
> or after several days of hibernated uptime. Unfortunately, I haven't found a 
> way to reliably reproduce the issue, yet.
> 
> The box is a "Gigabyte GA-78LMT-USB3" with "AMD FX(tm)-6300 Six-Core 
> Processor" and "[AMD/ATI] SB7x0 USB OHCI1 Controller".
> 
> For more info including crash trace, just have a look at the bug report [1]
> 
> 
> My (pretty wild) guess is, that the corruption happens through a race in the 
> interrupt handler ohci_irq(), which calls ohci_work(), which calls 
> finish_urb(), which states:
> " * PRECONDITION:  ohci lock held, irqs blocked"
> 
> But ohci_irq() seems to only spin_[un]lock(), not spin_[un]lock_irq[save|
> restore](). All other functions that call ohci_work() do at least 
> spin_[un]lock_irq. So irqs could still be enabled and possibly the event 
> triggered twice, thus the double list add?

That's easy enough to test.  All you have to do is change the 
spin_lock/unlock statements to their irq_save/restore variants.

ohci_irq() is an interrupt handler.  In the absence of threaded IRQs,
he kernel should always call interrupt handlers with interrupts 
disabled.  Do you specify "threadirqs" on your boot command line?

If that's not the explanation then we'll have to dig deeper.

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 2/6] usb: gadget: uvc: cleanup __uvcg_fill_strm()

[Felipe Balbi]

On Fri, Jan 16, 2015 at 01:44:44PM +0100, Andrzej Pietrasiewicz wrote:
> W dniu 16.01.2015 o 13:12, Dan Carpenter pisze:
> >Oh, yeah.  You're right.  I should have been more careful and I should
> >have seen that.  Sorry.  But the problem is the original code is still a
> >bit buggy.
> >
> >We call:
> >
> > data = kzalloc();
> >
> >Inside __uvcg_fill_strm() we do "data += something;"
> >
> > kfree(data);
> >
> >We should save the orignal data pointer so that we can free it
> >correctly at the end in uvcg_streaming_class_allow_link().
> >
> Yeah, right. Thank you for spotting this. The kfree() is called
> only if __uvcg_fill_strm() fails, though. But of course this needs
> to be fixed.

so, should I wait for another version of $subject ?

-- 
balbi


signature.asc
Description: Digital signature

Re: XHCI, "brain-dead scanner", and microframe rounding

[steve]

Any progress on this one?

Quite a bunch of people, that try to use a scanner on a xhci port gets
bitten by this issue. Given, that modern haswell mainboards tend to only
support xhci ports anymore, this is a real showstopper and kind of
regression from users POV.

https://bugzilla.novell.com/show_bug.cgi?id=856794
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102797

Would be nice to cc me on answers in order to relay results to other
suffering people.


To me it looked like the issue was fixes for several people by updating the 
system,
and I didn't follow up on this issue that much.

I'm stating to abandon the microframe interval theory and think this is related
to endpoint halting or toggle bit status.

checking the usbmon output it looks like scanner code regularly does a
clear_feature[endpoint halt].

Many changes were done in 3.18 and 3.19-rc release regarding to how we handle
halted and stopped endpoints, Can you test if that fixes your issues?
preferably with a 3.19-rc kernel

If that still doesn't do it then you might be one hitting this issue in xchi.c:

/*
  * We might need to implement the config ep cmd in xhci 4.8.1 note:
  * The Reset Endpoint Command may only be issued to endpoints in the
  * Halted state. If software wishes reset the Data Toggle or Sequence
  * Number of an endpoint that isn't in the Halted state, then software
  * may issue a Configure Endpoint Command with the Drop and Add bits set
  * for the target endpoint. that is in the Stopped state.
  */
  
Which is not implemented yet


-Mathias


I am running 3.18 and have a brain dead Fujitsu scanner
it doesn't work. i mistakenly submitted a no subject post about 4 wks ago
I have enough knowledge to up load and test the fixes but not the 
knowledge to write the code.


I filed a bug on bugs.launchpad.net on kernel 3.18
04c5:11fc [System76 gazp9b] Excuting scanimage -L finds Fujitsu 6110 
Scanner but if repeated does not


with url
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402335

-steve

--
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: Issues with commit 34b48db6 ("block: remove artifical max_hw_sectors cap")

[Alan Stern]

On Mon, 19 Jan 2015, Kenneth R. Crudup wrote:

> Sorry for taking so long to get back to you guys about this (the 3.19-rc 
> series has been
> problematic for me in a couple of areas, so I'd let it go for a while):
> 
> On Mon, 5 Jan 2015, Alan Stern wrote:
> 
> > The patch I posted sets a general limit of 32 MB for USB drives that
> > don't have a quirk flag for a smaller limit.
> > Kenneth, have you tried that patch?  Does it fix your problem?
> 
> No, it fails in the same way (applied to 3.19-rc5):
> 
> 
> Jan 19 01:38:16 tosh-p75a kernel: [  268.606258] sd 5:0:0:0: [sdc] FAILED 
> Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
> Jan 19 01:38:16 tosh-p75a kernel: [  268.606262] sd 5:0:0:0: [sdc] CDB:
> Jan 19 01:38:16 tosh-p75a kernel: [  268.606263] Write(10): 2a 00 0f e8 e0 40 
> 00 3c 00 00
> Jan 19 01:38:16 tosh-p75a kernel: [  268.606268] blk_update_request: I/O 
> error, dev sdc, sector 213536
> Jan 19 01:38:16 tosh-p75a kernel: [  268.839597] sd 5:0:0:0: [sdc] FAILED 
> Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
> Jan 19 01:38:16 tosh-p75a kernel: [  268.839603] sd 5:0:0:0: [sdc] CDB:
> Jan 19 01:38:16 tosh-p75a kernel: [  268.839605] Write(10): 2a 00 0f e9 68 40 
> 00 3c 00 00
> Jan 19 01:38:16 tosh-p75a kernel: [  268.839615] blk_update_request: I/O 
> error, dev sdc, sector 2135638528
> 
> Jan 19 01:38:47 tosh-p75a kernel: [  300.103494] usb 2-4.2: reset SuperSpeed 
> USB device number 3 using xhci_hcd
> Jan 19 01:38:47 tosh-p75a kernel: [  300.115145] xhci_hcd :00:14.0: xHCI 
> xhci_drop_endpoint called with disabled ep 880448c9bf00
> Jan 19 01:38:47 tosh-p75a kernel: [  300.115150] xhci_hcd :00:14.0: xHCI 
> xhci_drop_endpoint called with disabled ep 880448c9bf48
> Jan 19 01:38:48 tosh-p75a kernel: [  300.443729] INFO: task kworker/u16:6:197 
> blocked for more than 30 seconds.
> 
> 
> FWIW, my quick fix gets me going again:
> 
> 
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index 6ed2cbe..3a10bf6 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -257,7 +257,8 @@ void blk_limits_max_hw_sectors(struct queue_limits 
> *limits, unsigned int max_hw_
>__func__, max_hw_sectors);
> }
> 
> -   limits->max_sectors = limits->max_hw_sectors = max_hw_sectors;
> +   limits->max_sectors = limits->max_hw_sectors =
> +   min_t(unsigned int, max_hw_sectors, 65535);
>  }
>  EXPORT_SYMBOL(blk_limits_max_hw_sectors);

Are you certain the patch had been applied to the kernel you were 
testing?  The patch adds a line that calls blk_queue_max_hw_sectors() 
with max_hw_sectors set to 65535, so it should have the same effect as 
your quick fix.

Maybe you can add a printk statement to scsiglue.c:slave_configure() in 
drivers/usb/storage to make sure that the patch's call really does take 
place as intended.

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: [PATCHv5 0/6] USB: host: Atmel OHCI and EHCI drivers improvements

[Alan Stern]

On Mon, 19 Jan 2015, Nicolas Ferre wrote:

> Alan,
> It seems that Boris and Alexandre also add their tag to the series
> already. Do you want us to collect them in a new series sent to you?

Sylvain has already sent a new series, v6.  I suppose it would make 
life a little easier for Greg KH (who will do the actual merge) if the 
patches are resent with all the relevant tags, after I have a chance to 
look through them in detail.

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: Difference between run time and normal suspend

[Alan Stern]

On Mon, 19 Jan 2015, vichy wrote:

> I have several questions:
> a.
> in ehci-pci driver, the runtime suspend is register in the driver
> structure, driver->pm, like below.
> static struct pci_driver ehci_pci_driver = {
> ...
> .probe =usb_hcd_pci_probe,
> .remove =usb_hcd_pci_remove,
> .shutdown = usb_hcd_pci_shutdown,
> 
> #ifdef CONFIG_PM_SLEEP
> .driver ={
> .pm =&usb_hcd_pci_pm_ops
> },
> #endif
> };
> 
> But rpm_suspend search runtime suspend from device structure.
> like dev->pm_domain, dev->type, dev->class, dev->bus, etc.
> 
> Why hcd_pci_runtime_suspend will be called?

We are talking about a PCI implementation of EHCI, so dev->type is
pci_bus_type.  In drivers/pci/pci-driver.c, pci_bus_type.pm is set to
pci_dev_pm_ops.

The .runtime_suspend member of pci_dev_pm_ops is set to
pci_pm_runtime_suspend.  That routine calls
dev->driver->pm->runtime_suspend.

For ehci-pci, dev->driver is ehci_pci_driver.driver and its .pm field
is &usb_hcd_pci_pm_ops.  Therefore hcd_pci_runtime_suspend will be 
called.

> b.
> Contrary to pci system, in ehci-platfomr.c, there is no any runtime
> suspend call back register in ehci_platform_pm_ops.
> Could we get the conclusion that ehci controller will NOT be suspended
> when all device on the root hub and root hub are suspended?

That's right.  The ehci-platform driver does not support runtime 
suspend of the controller.  It doesn't support hibernation either.

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: 3.18 regression: Error while assigning device slot ID, USB3 devices not detected

[Josh Boyer]

On Mon, Jan 19, 2015 at 9:57 AM, Mathias Nyman
 wrote:
> On 19.01.2015 15:47, Josh Boyer wrote:
>> On Mon, Jan 19, 2015 at 8:33 AM, Greg KH  wrote:
>>> On Mon, Jan 19, 2015 at 08:28:19AM -0500, Josh Boyer wrote:
 On Sun, Jan 18, 2015 at 1:25 AM, Greg KH  
 wrote:
> On Sun, Jan 18, 2015 at 12:08:18AM -0600, Robert Hancock wrote:
>> I've got an Intel Haswell-based system with a Gigabyte Z87X-D3H 
>> motherboard
>> under Fedora 21. After updating to the 3.18.2-200 Fedora kernel, I 
>> noticed
>> some errors in dmesg and at least some of my USB3 ports don't recognize 
>> any
>> USB3 devices plugged into them:
>>
>> [0.560838] xhci_hcd :00:14.0: Error while assigning device slot 
>> ID
>> [0.560912] xhci_hcd :00:14.0: Max number of devices this xHCI 
>> host
>> supports is 32.
>> [0.560990] usb usb2-port2: couldn't allocate usb_device
>> [0.561098] xhci_hcd :00:14.0: Error while assigning device slot 
>> ID
>> [0.561163] xhci_hcd :00:14.0: Max number of devices this xHCI 
>> host
>> supports is 32.
>> [0.561239] usb usb2-port5: couldn't allocate usb_device
>> [0.561344] xhci_hcd :00:14.0: Error while assigning device slot 
>> ID
>> [0.561409] xhci_hcd :00:14.0: Max number of devices this xHCI 
>> host
>> supports is 32.
>> [0.561484] usb usb2-port6: couldn't allocate usb_device
>>
>> This worked fine under 3.17. Is this a known problem?
>
> Yes it is, should be fixed in Linus's tree now and will be backported to
> the latest 3.18-stable tree in a week or so.

 Do you happen to know the commit id?
>>>
>>> f161ead70fa6a62e432dff6e9dab8e3cfbeabea6
>>
>> Thanks!
>>
>
> Tell me if this fixed the issue.
> I got this gut feeling this might be something else.
> It should have failed in 3.17 as well

OK.  We're tracking this in the bug Robert filed here:

https://bugzilla.redhat.com/show_bug.cgi?id=1183289

The patch should be in the next Fedora kernel build, so hopefully we
can get back to you soon.

josh
--
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: Fatal Exception on device when Hotsyncing Palm in linux

[Johan Hovold]

[ Please try not to top-post. ]

On Mon, Jan 19, 2015 at 12:37:00PM +0100, Henri Manson wrote:
> Enclosed the dmesg outputs from 9.04 and 10.04.4. I booted both
> kernels with usbserial.debug=1 and loaded module visor.ko with
> parameter debug=1

> >> out-crash: debug output form Ubuntu 14.04.1 which causes the Palm m505 to 
> >> crash
> >> out: debug output form Ubuntu 9.04 which works fine
> >>
> >> probe string on 9.04 and 14.04 is different:
> >>
> >> 9.04:
> >> [  640.784916] usb 2-2: palm_os_4_probe - length = 20, data = 01 00 00
> >> 00 63 6e 79 73 02 00 00 00 00 03 f3 5c 05 03 00 03
> >>
> >> 14.04.1:
> >> [ 1685.194594] usb 8-2: palm_os_4_probe - length = 20, data = 01 00 00
> >> 00 63 6e 79 73 02 00 00 00 01 36 00 5c 00 00 00 09
> >
> > It would be better if you could compare output from 9.04 and the first
> > Ubuntu version that broke (i.e. with the 2.6.32 kernel).

Are you saying that syncing works with 9.04? The log you provided
suggests otherwise as the ports do not even seem to get opened.

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 v3 0/2] DLN2 fixes related to suspend/resume

[Johan Hovold]

On Mon, Jan 19, 2015 at 01:51:34PM +0200, Octavian Purdila wrote:
> Hi Lee,
> 
> Here is the 3rd version of the patch-set against for-mfd-next branch
> with the Reviewed-by tags from Johan. Note that I dropped the two GPIO
> patches as they were already merged by Linus W in the GPIO tree.
> 
> Thanks,
> Tavi
> 
> Changes since v2:
> 
>  * Dropped the GPIO fixes from this series as they were merged in the
>GPIO tree
> 
>  * Removed a stray newline
> 
>  * Updated the resume / suspend patch commit with more information
>about which cases it fixes and which it does not

Update looks good too.

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] Added PIDs for Actisense USB Devices

[Johan Hovold]

On Thu, Jan 15, 2015 at 08:34:34AM +, Mark Glover wrote:
> From: Mark Glover 
> 
> Signed-off-by: Mark Glover 

Thanks for the patch and for addressing Peter's comments.

A couple of minor nits: Please use a subsystem prefix for your patch
summary, for example:

"USB: ftdi_sio: add PIDs for Actisense devices"

You should also include a commit message (e.g. your current subject)
even if this is a simple patch.

You are adding both Actisense and Chetco product ids. How are these
related? Shouldn't the Chetco be under it's own heading (and be
mentioned in the commit log)?

And when resending, please include a "PATCH v4" prefix to make it easy
to track patch revisions.

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

ohci: sporadic crash/lockup in ohci-hcd io_watchdog_func()

[Heiko Przybyl]

Hi all,

been redirected here from bug #91511 [1].

I'm getting sporadic crashes in io_watchdog_func() in drivers/usb/host/ohci-
hcd.c:761:
"
list_for_each_entry(ed, &ohci->eds_in_use, in_use_list) {
if (ed->pending_td) {
"
with the in_use list getting corrupted:

from ohci_urb_enqueue():
[43656.918055] list_add double add: new=8800cbaa8040, 
prev=8800cb8aa5b8, 
next=8800cbaa8040.
from ohci_work.part():
[43656.920980] list_del corruption. next->prev should be 8800cbaa8040, but 
was 8800cb8aa5b8

One or both set the pointer to 0xdead00100100 and 0xdead001000c0, 
where io_watchdog_func() chokes on [2].

It seems to be related to keyboard input (at least it happens when using the 
keyboard), without relation to system load. Can happen within a day after boot 
or after several days of hibernated uptime. Unfortunately, I haven't found a 
way to reliably reproduce the issue, yet.

The box is a "Gigabyte GA-78LMT-USB3" with "AMD FX(tm)-6300 Six-Core 
Processor" and "[AMD/ATI] SB7x0 USB OHCI1 Controller".

For more info including crash trace, just have a look at the bug report [1]


My (pretty wild) guess is, that the corruption happens through a race in the 
interrupt handler ohci_irq(), which calls ohci_work(), which calls 
finish_urb(), which states:
" * PRECONDITION:  ohci lock held, irqs blocked"

But ohci_irq() seems to only spin_[un]lock(), not spin_[un]lock_irq[save|
restore](). All other functions that call ohci_work() do at least 
spin_[un]lock_irq. So irqs could still be enabled and possibly the event 
triggered twice, thus the double list add?


If you need more information just let me know (per the bug [1] or CC, since 
I'm not subscribed to this list).


Kind regards,

Heiko


[1] https://bugzilla.kernel.org/show_bug.cgi?id=91511
[2] https://bugzilla.kernel.org/attachment.cgi?id=163721

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

Re: [PATCH][V2] drivers/usb/serial/mos7840.c: remove unused code

[Johan Hovold]

On Mon, Jan 19, 2015 at 01:32:58PM +, Colin King wrote:
> From: Colin Ian King 
> 
> There is old, unused code that is #defined out by the
> use of NOTMOS7840 and NOTMCS7840 - these are not
> defined anywhere.
> 
> If NOTMOS7840 is defined then the code will break on null
> pointer dereferences on mos7840_port.  So the code is
> currently unused, and broken anyway, so why not just
> remove it.
> 
> Signed-off-by: Colin Ian King 

Thanks for the update. Applied for next now.

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: 3.18 regression: Error while assigning device slot ID, USB3 devices not detected

[Mathias Nyman]

On 19.01.2015 15:47, Josh Boyer wrote:
> On Mon, Jan 19, 2015 at 8:33 AM, Greg KH  wrote:
>> On Mon, Jan 19, 2015 at 08:28:19AM -0500, Josh Boyer wrote:
>>> On Sun, Jan 18, 2015 at 1:25 AM, Greg KH  wrote:
 On Sun, Jan 18, 2015 at 12:08:18AM -0600, Robert Hancock wrote:
> I've got an Intel Haswell-based system with a Gigabyte Z87X-D3H 
> motherboard
> under Fedora 21. After updating to the 3.18.2-200 Fedora kernel, I noticed
> some errors in dmesg and at least some of my USB3 ports don't recognize 
> any
> USB3 devices plugged into them:
>
> [0.560838] xhci_hcd :00:14.0: Error while assigning device slot ID
> [0.560912] xhci_hcd :00:14.0: Max number of devices this xHCI host
> supports is 32.
> [0.560990] usb usb2-port2: couldn't allocate usb_device
> [0.561098] xhci_hcd :00:14.0: Error while assigning device slot ID
> [0.561163] xhci_hcd :00:14.0: Max number of devices this xHCI host
> supports is 32.
> [0.561239] usb usb2-port5: couldn't allocate usb_device
> [0.561344] xhci_hcd :00:14.0: Error while assigning device slot ID
> [0.561409] xhci_hcd :00:14.0: Max number of devices this xHCI host
> supports is 32.
> [0.561484] usb usb2-port6: couldn't allocate usb_device
>
> This worked fine under 3.17. Is this a known problem?

 Yes it is, should be fixed in Linus's tree now and will be backported to
 the latest 3.18-stable tree in a week or so.
>>>
>>> Do you happen to know the commit id?
>>
>> f161ead70fa6a62e432dff6e9dab8e3cfbeabea6
> 
> Thanks!
> 

Tell me if this fixed the issue.
I got this gut feeling this might be something else.
It should have failed in 3.17 as well

-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 v2 4/5] xhci: Platform: Set Synopsis device disconnection quirk based on platform data

[Felipe Balbi]

On Mon, Jan 19, 2015 at 03:56:48PM +0800, Sneeker Yeh wrote:
> If an xhci platform has Synopsis device disconnection errata then enable
> XHCI_DISCONNECT_QUIRK quirk flag.
> 
> Signed-off-by: Sneeker Yeh 
> ---
>  drivers/usb/host/xhci-plat.c |3 +++
>  include/linux/usb/xhci_pdriver.h |4 
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 08d402b..40beb95 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
>   (pdata && pdata->usb3_lpm_capable))
>   xhci->quirks |= XHCI_LPM_SUPPORT;
> +
> + if (pdata && pdata->delay_portcsc_clear)
> + xhci->quirks |= XHCI_DISCONNECT_QUIRK;
>   /*
>* Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
>* is called by usb_add_hcd().
> diff --git a/include/linux/usb/xhci_pdriver.h 
> b/include/linux/usb/xhci_pdriver.h
> index 376654b..a37a3a5 100644
> --- a/include/linux/usb/xhci_pdriver.h
> +++ b/include/linux/usb/xhci_pdriver.h
> @@ -18,10 +18,14 @@
>   *
>   * @usb3_lpm_capable:determines if this xhci platform supports USB3
>   *   LPM capability
> + * @delay_portcsc_clear: determines if Synopsis USB3 core has errata in
> + *   "DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1" hardware
> + *   configuration.
>   *
>   */
>  struct usb_xhci_pdata {
>   unsignedusb3_lpm_capable:1;
> + unsigneddelay_portcsc_clear:1;

previous patch won't build before this is applied. That's a problem.
Please shuffle things around so that each and every patch builds and
works on its own.

We cannot break bisectability ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 3/5] usb: dwc3: Add quirk for Synopsis device disconnection errata

[Felipe Balbi]

Hi,

On Mon, Jan 19, 2015 at 03:56:47PM +0800, Sneeker Yeh wrote:
> Synopsis Designware USB3 IP earlier than v3.00a which is configured in silicon
> with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to 
> prevent
> xhci host controller from dying when device is disconnected.
> 
> Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP configuration whose state
> cannot be checked from software in runtime, it has to be enabled via platform
> data or device tree.
> 
> Signed-off-by: Sneeker Yeh 
> ---
>  Documentation/devicetree/bindings/usb/dwc3.txt |   17 +
>  drivers/usb/dwc3/core.c|6 ++
>  drivers/usb/dwc3/core.h|1 +
>  drivers/usb/dwc3/host.c|4 
>  drivers/usb/dwc3/platform_data.h   |1 +
>  5 files changed, 29 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> index cd7f045..1b78b29 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -37,6 +37,23 @@ Optional properties:
>   - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
>   utmi_l1_suspend_n, false when asserts utmi_sleep_n
>   - snps,hird-threshold: HIRD threshold
> + - snps,has_suspend_on_disconnect: true when IP is configured in silicon with
> + DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, it can inject a
> + specific quirk to prevent xhci host controller from
> + dying when usb device is disconnected from root hub.
> + Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP
> + configuration whose state cannot be checked from
> + software in runtime, it has to be enabled via platform
> + data or device tree.
> +
> + xhci host dying symptom here is caused by that
> + DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
> + configuration makes IP auto-suspended after PORTCSC is
> + cleared when usb device detached, then an asynchronous
> + disconnection procedure might fail using endpoint
> + command that suspened IP won't have any response to.
> +
> + this issue is fixed when IP version >= 3.00a.
>  
>  This is usually a subnode to DWC3 glue to which it is connected.
>  
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 25ddc39..fbceab1 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -838,6 +838,9 @@ static int dwc3_probe(struct platform_device *pdev)
>   "snps,tx_de_emphasis_quirk");
>   of_property_read_u8(node, "snps,tx_de_emphasis",
>   &tx_de_emphasis);
> +
> + dwc->suspend_on_disconnect_quirk = of_property_read_bool(node,
> + "snps,has_suspend_on_disconnect");
>   } else if (pdata) {
>   dwc->maximum_speed = pdata->maximum_speed;
>   dwc->has_lpm_erratum = pdata->has_lpm_erratum;
> @@ -864,6 +867,9 @@ static int dwc3_probe(struct platform_device *pdev)
>   dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
>   if (pdata->tx_de_emphasis)
>   tx_de_emphasis = pdata->tx_de_emphasis;
> +
> + dwc->suspend_on_disconnect_quirk =
> + pdata->has_suspend_on_disconnect;
>   }
>  
>   /* default to superspeed if no maximum_speed passed */
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 8090249..d7458ff 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -832,6 +832,7 @@ struct dwc3 {
>  
>   unsignedtx_de_emphasis_quirk:1;
>   unsignedtx_de_emphasis:2;
> + unsignedsuspend_on_disconnect_quirk:1;

you're missing the comment on the structure and these should be
alphabetically sorted.

> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index 12bfd3c..9c42074 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -53,6 +53,10 @@ int dwc3_host_init(struct dwc3 *dwc)
>   pdata.usb3_lpm_capable = 1;
>  #endif
>  
> + if ((dwc->revision < DWC3_REVISION_300A) &&
> + dwc->suspend_on_disconnect_quirk)
> + pdata.delay_portcsc_clear = 1;
> +
>   ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
>   if (ret) {
>   dev_err(dwc->dev, "couldn't add platform data to xHCI 
> device\n");
> diff --git a/drivers/usb/dwc3/platform_data.h 
> b/drivers/usb/dwc3/platform_data.h
> index a3a3b6d..69562f1 100644
> --- a/drivers/usb/dwc3/platform_data.h
> +++ b/drivers/usb/dwc3/platform_data.h
> @@ -44,4 +44,5 @@ struct dwc3_platform_data {
>  
> 

Re: [PATCH v2 1/5] usb: dwc3: add Fujitsu Specific Glue layer

[Felipe Balbi]

On Mon, Jan 19, 2015 at 03:56:45PM +0800, Sneeker Yeh wrote:
> This patch adds support for Synopsis DesignWare USB3 IP Core found
> on Fujitsu Socs.
> 
> Signed-off-by: Sneeker Yeh 

if this is moved after patch 3, you don't need to patch it again to add
the quirk ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: XHCI, "brain-dead scanner", and microframe rounding

[Mathias Nyman]

> 
> Any progress on this one?
> 
> Quite a bunch of people, that try to use a scanner on a xhci port gets
> bitten by this issue. Given, that modern haswell mainboards tend to only
> support xhci ports anymore, this is a real showstopper and kind of
> regression from users POV.
> 
> https://bugzilla.novell.com/show_bug.cgi?id=856794
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102797
> 
> Would be nice to cc me on answers in order to relay results to other
> suffering people.
> 

To me it looked like the issue was fixes for several people by updating the 
system,
and I didn't follow up on this issue that much.

I'm stating to abandon the microframe interval theory and think this is related
to endpoint halting or toggle bit status.

checking the usbmon output it looks like scanner code regularly does a 
clear_feature[endpoint halt].

Many changes were done in 3.18 and 3.19-rc release regarding to how we handle 
halted and stopped endpoints, Can you test if that fixes your issues? 
preferably with a 3.19-rc kernel

If that still doesn't do it then you might be one hitting this issue in xchi.c:

/*
 * We might need to implement the config ep cmd in xhci 4.8.1 note:
 * The Reset Endpoint Command may only be issued to endpoints in the
 * Halted state. If software wishes reset the Data Toggle or Sequence
 * Number of an endpoint that isn't in the Halted state, then software
 * may issue a Configure Endpoint Command with the Drop and Add bits set
 * for the target endpoint. that is in the Stopped state.
 */
 
Which is not implemented yet

-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 v2 2/5] usb: dwc3: add revision number DWC3_REVISION_300A

[Felipe Balbi]

Hi,

On Mon, Jan 19, 2015 at 03:56:46PM +0800, Sneeker Yeh wrote:
> Add the contstant for v3.00a dwc3 IP detection
> 
> Signed-off-by: Sneeker Yeh 
> ---
>  drivers/usb/dwc3/core.h |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 4bb9aa6..8090249 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -776,6 +776,7 @@ struct dwc3 {
>  #define DWC3_REVISION_260A   0x5533260a
>  #define DWC3_REVISION_270A   0x5533270a
>  #define DWC3_REVISION_280A   0x5533280a
> +#define DWC3_REVISION_300A   0x5533300a

looking at Synopsys Solvnet for this IP, it shows that current version
is 2.90a. There's no 3.00a. Paul, John, is there a 3.00a version of the
DWC USB3 IP ?

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb: dwc2: rework initialization of host and gadget in dual-role mode

[Marek Szyprowski]

If device is configured to work only in HOST or DEVICE mode, there is
no point in initializing both subdrivers. This patch also fixes
resource leakage if host subdriver fails to initialize.

Signed-off-by: Marek Szyprowski 
---
 drivers/usb/dwc2/core.h |  2 ++
 drivers/usb/dwc2/platform.c | 29 +
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7a70a1349334..f93b06daef97 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -570,6 +570,8 @@ struct dwc2_hsotg {
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
enum usb_dr_mode dr_mode;
+   unsigned int hcd_enabled:1;
+   unsigned int gadget_enabled:1;
 
struct phy *phy;
struct usb_phy *uphy;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa2ff05..ee0b0b06d0fc 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -121,8 +121,10 @@ static int dwc2_driver_remove(struct platform_device *dev)
 {
struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
 
-   dwc2_hcd_remove(hsotg);
-   s3c_hsotg_remove(hsotg);
+   if (hsotg->hcd_enabled)
+   dwc2_hcd_remove(hsotg);
+   if (hsotg->gadget_enabled)
+   s3c_hsotg_remove(hsotg);
 
return 0;
 }
@@ -214,12 +216,23 @@ static int dwc2_driver_probe(struct platform_device *dev)
 
spin_lock_init(&hsotg->lock);
mutex_init(&hsotg->init_mutex);
-   retval = dwc2_gadget_init(hsotg, irq);
-   if (retval)
-   return retval;
-   retval = dwc2_hcd_init(hsotg, irq, params);
-   if (retval)
-   return retval;
+
+   if (hsotg->dr_mode != USB_DR_MODE_HOST) {
+   retval = dwc2_gadget_init(hsotg, irq);
+   if (retval)
+   return retval;
+   hsotg->gadget_enabled = 1;
+   }
+
+   if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
+   retval = dwc2_hcd_init(hsotg, irq, params);
+   if (retval) {
+   if (hsotg->gadget_enabled)
+   s3c_hsotg_remove(hsotg);
+   return retval;
+   }
+   hsotg->hcd_enabled = 1;
+   }
 
platform_set_drvdata(dev, hsotg);
 
-- 
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] ARM: DTS: Exynos: add 'dr_mode' property to hsotg devices

[Marek Szyprowski]

All currently supported boards use hsotg/dwc2 controller in device
('peripheral') mode, so add property which sets correct operation mode.
This patch fixes support in recent changes in dwc2 driver, which added
support for dual-role devices.

Suggested-by: Paul Zimmerman 
Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos3250-monk.dts   | 1 +
 arch/arm/boot/dts/exynos3250-rinato.dts | 1 +
 arch/arm/boot/dts/exynos4210-trats.dts  | 1 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 1 +
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
 arch/arm/boot/dts/exynos4412-trats2.dts | 1 +
 arch/arm/boot/dts/s5pv210-aquila.dts| 1 +
 arch/arm/boot/dts/s5pv210-goni.dts  | 1 +
 arch/arm/boot/dts/s5pv210-smdkv210.dts  | 1 +
 9 files changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 5e4a471faee1..683596844ef3 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -140,6 +140,7 @@
 &hsotg {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
+   dr_mode = "peripheral";
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index c7f4fab6dfd9..5121954579ad 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -131,6 +131,7 @@
 &hsotg {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
+   dr_mode = "peripheral";
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 720836205546..1c0c7be02616 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -91,6 +91,7 @@
hsotg@1248 {
vusb_d-supply = <&vusb_reg>;
vusb_a-supply = <&vusbdac_reg>;
+   dr_mode = "peripheral";
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 01f7d3cfdd02..1d7643288569 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -71,6 +71,7 @@
hsotg@1248 {
vusb_d-supply = <&ldo3_reg>;
vusb_a-supply = <&ldo8_reg>;
+   dr_mode = "peripheral";
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 4a11e84b036e..9329135342a6 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -401,6 +401,7 @@
};
 
hsotg@1248 {
+   dr_mode = "peripheral";
status = "okay";
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b452643..c81c4769411d 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -845,6 +845,7 @@
hsotg@1248 {
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
+   dr_mode = "peripheral";
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/s5pv210-aquila.dts 
b/arch/arm/boot/dts/s5pv210-aquila.dts
index aa31b84a707a..f00cea7aca2f 100644
--- a/arch/arm/boot/dts/s5pv210-aquila.dts
+++ b/arch/arm/boot/dts/s5pv210-aquila.dts
@@ -355,6 +355,7 @@
 &hsotg {
vusb_a-supply = <&ldo3_reg>;
vusb_d-supply = <&ldo8_reg>;
+   dr_mode = "peripheral";
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/s5pv210-goni.dts 
b/arch/arm/boot/dts/s5pv210-goni.dts
index 6387c77a6f7b..a3d4643b202e 100644
--- a/arch/arm/boot/dts/s5pv210-goni.dts
+++ b/arch/arm/boot/dts/s5pv210-goni.dts
@@ -333,6 +333,7 @@
 &hsotg {
vusb_a-supply = <&ldo3_reg>;
vusb_d-supply = <&ldo8_reg>;
+   dr_mode = "peripheral";
status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/s5pv210-smdkv210.dts 
b/arch/arm/boot/dts/s5pv210-smdkv210.dts
index cb8521899ec8..da7d210df670 100644
--- a/arch/arm/boot/dts/s5pv210-smdkv210.dts
+++ b/arch/arm/boot/dts/s5pv210-smdkv210.dts
@@ -181,6 +181,7 @@
 };
 
 &hsotg {
+   dr_mode = "peripheral";
status = "okay";
 };
 
-- 
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 00/11] scsi: fix module reference mismatch for scsi host

[Tejun Heo]

On Mon, Jan 19, 2015 at 12:05:58AM +0900, Akinobu Mita wrote:
> While accessing a scsi_device, the use count of the underlying LLDD
> module is incremented.  The module reference is retrieved through
> .module field of struct scsi_host_template.
> 
> This mapping between scsi_device and underlying LLDD module works well
> except some drivers which consist with the core driver and the actual
> LLDDs and scsi_host_template is defined in the core driver.  In these
> cases, the actual LLDDs can be unloaded even if the scsi_device is
> being accessed.
> 
> This patch series fixes the module reference mismatch problem for
> ufs, usb-storage, esp_scsi, ahci_platform, and pata_platform drivers
> by moving owner module reference field from struct scsi_host_template
> to struct Scsi_Host and allowing the LLDDs to set their correct module
> reference.

Hmmm, can't we just move sht definitions to actual LLDDs?  libata can
do that easily.  sht, as its name implies, is the template for
creating the scsi_hosts of a given type.  We're now just moving module
ownership from sht definition site to whatever callsite the actual
instance is being created which can also be wrapped in a separate
layer requiring explicit propagation.  Why not just propagate sht's
directly?  What's the difference?

Thanks.

-- 
tejun
--
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 1/2] USB: gadget: atmel_usba_udc: Fixed vbus_prev initial state

[Nicolas Ferre]

Le 18/01/2015 18:24, Sylvain Rochet a écrit :
> If vbus gpio is high at init, we should set vbus_prev to true
> accordingly to the current vbus state. Without that, we skip the first
> vbus interrupt because the saved vbus state is not consistent.
> 
> Signed-off-by: Sylvain Rochet 

Indeed:
Acked-by: Nicolas Ferre 

We can also add the following tags:
Fixes: 914a3f3b3754 ("USB: add atmel_usba_udc driver")
Cc:  # 2.6.x-ish

Bye,


> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index ce88237..e207d75 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1791,6 +1791,8 @@ static int atmel_usba_start(struct usb_gadget *gadget,
>   toggle_bias(1);
>   usba_writel(udc, CTRL, USBA_ENABLE_MASK);
>   usba_writel(udc, INT_ENB, USBA_END_OF_RESET);
> +
> + udc->vbus_prev = 1;
>   }
>   spin_unlock_irqrestore(&udc->lock, flags);
>  
> 


-- 
Nicolas Ferre
--
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: 3.18 regression: Error while assigning device slot ID, USB3 devices not detected

[Josh Boyer]

On Mon, Jan 19, 2015 at 8:33 AM, Greg KH  wrote:
> On Mon, Jan 19, 2015 at 08:28:19AM -0500, Josh Boyer wrote:
>> On Sun, Jan 18, 2015 at 1:25 AM, Greg KH  wrote:
>> > On Sun, Jan 18, 2015 at 12:08:18AM -0600, Robert Hancock wrote:
>> >> I've got an Intel Haswell-based system with a Gigabyte Z87X-D3H 
>> >> motherboard
>> >> under Fedora 21. After updating to the 3.18.2-200 Fedora kernel, I noticed
>> >> some errors in dmesg and at least some of my USB3 ports don't recognize 
>> >> any
>> >> USB3 devices plugged into them:
>> >>
>> >> [0.560838] xhci_hcd :00:14.0: Error while assigning device slot ID
>> >> [0.560912] xhci_hcd :00:14.0: Max number of devices this xHCI host
>> >> supports is 32.
>> >> [0.560990] usb usb2-port2: couldn't allocate usb_device
>> >> [0.561098] xhci_hcd :00:14.0: Error while assigning device slot ID
>> >> [0.561163] xhci_hcd :00:14.0: Max number of devices this xHCI host
>> >> supports is 32.
>> >> [0.561239] usb usb2-port5: couldn't allocate usb_device
>> >> [0.561344] xhci_hcd :00:14.0: Error while assigning device slot ID
>> >> [0.561409] xhci_hcd :00:14.0: Max number of devices this xHCI host
>> >> supports is 32.
>> >> [0.561484] usb usb2-port6: couldn't allocate usb_device
>> >>
>> >> This worked fine under 3.17. Is this a known problem?
>> >
>> > Yes it is, should be fixed in Linus's tree now and will be backported to
>> > the latest 3.18-stable tree in a week or so.
>>
>> Do you happen to know the commit id?
>
> f161ead70fa6a62e432dff6e9dab8e3cfbeabea6

Thanks!

josh
--
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: [PATCHv5 0/6] USB: host: Atmel OHCI and EHCI drivers improvements

[Sylvain Rochet]

Hello Nicolas,


On Mon, Jan 19, 2015 at 02:34:20PM +0100, Nicolas Ferre wrote:
> Le 18/01/2015 23:25, Sylvain Rochet a écrit :
> > USB: host: Atmel OHCI and EHCI drivers improvements
> > 
> > Suspend/resume support for EHCI.
> > struct dev_pm_ops for OHCI.
> > Removed global variables from both.
> > Fixed OHCI wake up support for STANDBY(wake-up enabled) and MEM(wake-up 
> > disabled) sleep targets.
> 
> I'm okay with the whole series:
> Acked-by: Nicolas Ferre 

Oops, you missed that, but there is a v6 I sent this morning, which 
fixes a small mistake I made in v5.


> Alan, It seems that Boris and Alexandre also add their tag to the 
> series already. Do you want us to collect them in a new series sent to 
> you?
> 
> Sylvain,
> Thanks a lot for this nice series built at a high pace ;-)

Yeah, I have the feeling I messed up a "little" :-)

Anyway, v6 is fine, I hope.


> Even if I'm not sure to keep the separation between "slow clock" PM and
> "normal" PM on AT91 but more likely to use the "slow clock" for all the
> PM modes, let's go forward with this step for now. I mean, we will
> certainly rework this at91_suspend_entering_slow_clock() aspect in the
> future.

I agree, I discussed privately with Boris about that, this require a 
larger rework, lets only fix the OHCI wakeup bug for now.


Sylvain
--
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: 3.18 regression: Error while assigning device slot ID, USB3 devices not detected

[Greg KH]

On Mon, Jan 19, 2015 at 08:28:19AM -0500, Josh Boyer wrote:
> On Sun, Jan 18, 2015 at 1:25 AM, Greg KH  wrote:
> > On Sun, Jan 18, 2015 at 12:08:18AM -0600, Robert Hancock wrote:
> >> I've got an Intel Haswell-based system with a Gigabyte Z87X-D3H motherboard
> >> under Fedora 21. After updating to the 3.18.2-200 Fedora kernel, I noticed
> >> some errors in dmesg and at least some of my USB3 ports don't recognize any
> >> USB3 devices plugged into them:
> >>
> >> [0.560838] xhci_hcd :00:14.0: Error while assigning device slot ID
> >> [0.560912] xhci_hcd :00:14.0: Max number of devices this xHCI host
> >> supports is 32.
> >> [0.560990] usb usb2-port2: couldn't allocate usb_device
> >> [0.561098] xhci_hcd :00:14.0: Error while assigning device slot ID
> >> [0.561163] xhci_hcd :00:14.0: Max number of devices this xHCI host
> >> supports is 32.
> >> [0.561239] usb usb2-port5: couldn't allocate usb_device
> >> [0.561344] xhci_hcd :00:14.0: Error while assigning device slot ID
> >> [0.561409] xhci_hcd :00:14.0: Max number of devices this xHCI host
> >> supports is 32.
> >> [0.561484] usb usb2-port6: couldn't allocate usb_device
> >>
> >> This worked fine under 3.17. Is this a known problem?
> >
> > Yes it is, should be fixed in Linus's tree now and will be backported to
> > the latest 3.18-stable tree in a week or so.
> 
> Do you happen to know the commit id?

f161ead70fa6a62e432dff6e9dab8e3cfbeabea6
--
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: [PATCHv5 0/6] USB: host: Atmel OHCI and EHCI drivers improvements

[Nicolas Ferre]

Le 18/01/2015 23:25, Sylvain Rochet a écrit :
> USB: host: Atmel OHCI and EHCI drivers improvements
> 
> Suspend/resume support for EHCI.
> struct dev_pm_ops for OHCI.
> Removed global variables from both.
> Fixed OHCI wake up support for STANDBY(wake-up enabled) and MEM(wake-up 
> disabled) sleep targets.

I'm okay with the whole series:
Acked-by: Nicolas Ferre 

Alan,
It seems that Boris and Alexandre also add their tag to the series
already. Do you want us to collect them in a new series sent to you?

Sylvain,
Thanks a lot for this nice series built at a high pace ;-)
Even if I'm not sure to keep the separation between "slow clock" PM and
"normal" PM on AT91 but more likely to use the "slow clock" for all the
PM modes, let's go forward with this step for now. I mean, we will
certainly rework this at91_suspend_entering_slow_clock() aspect in the
future.

Bye,

> Changes since v4:
>   * Re-add at91_suspend_entering_slow_clock() to OHCI, we can't naively
> remove this one, this device needs to be continuously clocked to
> provide wake up support.
> The removal of at91_suspend_entering_slow_clock() actually lighted up
> an issue on wake up support, which is now fixed.
> 
> Changes since v3:
>   * Using struct dev_pm_ops instead of static struct platform_driver
> resume and suspend bindings for both EHCI and OHCI
>   * Fixed inconsistency in patch subjects, _ intead of - for file names
>   * Patch cleaning with the help of checkpatch.pl, fixed lines over
> 80 characters
> 
> Changes since v2:
>   * Added patchs from an other submission, because this series
> depended on this one
> * EHCI: Move global variables to private struct
> * OHCI: Move global variables to private struct
>   * Using ohci->priv and ehci->priv instead of hcd->hcd_priv,
> which were not the right way to do that
> 
> Changes since v1:
>   * Don't use at91_suspend_entering_slow_clock() on EHCI,
> we are trying to get read of this of this function
>   * Removed at91_suspend_entering_slow_clock() from OHCI
> 
> Sylvain Rochet (6):
>   USB: host: ehci-atmel: Add suspend/resume support
>   USB: host: ohci-at91: Use struct dev_pm_ops instead of struct
> platform_driver
>   USB: host: ehci-atmel: Move global variables to private struct
>   USB: host: ohci-at91: Fix wake-up support
>   USB: host: ohci-at91: Move global variables to private struct
>   USB: host: ohci-at91: usb_hcd_at91_probe(), remove useless stack
> initialisation
> 
>  drivers/usb/host/ehci-atmel.c | 102 ++-
>  drivers/usb/host/ohci-at91.c  | 120 
> +-
>  2 files changed, 150 insertions(+), 72 deletions(-)
> 


-- 
Nicolas Ferre
--
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] drivers/usb/serial/mos7840.c: remove unused code

[Colin King]

From: Colin Ian King 

There is old, unused code that is #defined out by the
use of NOTMOS7840 and NOTMCS7840 - these are not
defined anywhere.

If NOTMOS7840 is defined then the code will break on null
pointer dereferences on mos7840_port.  So the code is
currently unused, and broken anyway, so why not just
remove it.

Signed-off-by: Colin Ian King 
---
 drivers/usb/serial/mos7840.c | 60 
 1 file changed, 60 deletions(-)

diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 220b4be..e4473a9 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -1309,35 +1309,6 @@ static int mos7840_write(struct tty_struct *tty, struct 
usb_serial_port *port,
const unsigned char *current_position = data;
unsigned char *data1;
 
-#ifdef NOTMOS7840
-   Data = 0x00;
-   status = mos7840_get_uart_reg(port, LINE_CONTROL_REGISTER, &Data);
-   mos7840_port->shadowLCR = Data;
-   dev_dbg(&port->dev, "%s: LINE_CONTROL_REGISTER is %x\n", __func__, 
Data);
-   dev_dbg(&port->dev, "%s: mos7840_port->shadowLCR is %x\n", __func__, 
mos7840_port->shadowLCR);
-
-   /* Data = 0x03; */
-   /* status = mos7840_set_uart_reg(port,LINE_CONTROL_REGISTER,Data); */
-   /* mos7840_port->shadowLCR=Data;//Need to add later */
-
-   Data |= SERIAL_LCR_DLAB;/* data latch enable in LCR 0x80 */
-   status = mos7840_set_uart_reg(port, LINE_CONTROL_REGISTER, Data);
-
-   /* Data = 0x0c; */
-   /* status = mos7840_set_uart_reg(port,DIVISOR_LATCH_LSB,Data); */
-   Data = 0x00;
-   status = mos7840_get_uart_reg(port, DIVISOR_LATCH_LSB, &Data);
-   dev_dbg(&port->dev, "%s: DLL value is %x\n", __func__, Data);
-
-   Data = 0x0;
-   status = mos7840_get_uart_reg(port, DIVISOR_LATCH_MSB, &Data);
-   dev_dbg(&port->dev, "%s: DLM value is %x\n", __func__, Data);
-
-   Data = Data & ~SERIAL_LCR_DLAB;
-   dev_dbg(&port->dev, "%s: mos7840_port->shadowLCR is %x\n", __func__, 
mos7840_port->shadowLCR);
-   status = mos7840_set_uart_reg(port, LINE_CONTROL_REGISTER, Data);
-#endif
-
if (mos7840_port_paranoia_check(port, __func__))
return -1;
 
@@ -1614,37 +1585,6 @@ static int mos7840_calc_baud_rate_divisor(struct 
usb_serial_port *port,
*clk_sel_val = 0x70;
}
return 0;
-
-#ifdef NOTMCS7840
-
-   for (i = 0; i < ARRAY_SIZE(mos7840_divisor_table); i++) {
-   if (mos7840_divisor_table[i].BaudRate == baudrate) {
-   *divisor = mos7840_divisor_table[i].Divisor;
-   return 0;
-   }
-   }
-
-   /* After trying for all the standard baud rates*
-* Try calculating the divisor for this baud rate  */
-
-   if (baudrate > 75 && baudrate < 230400) {
-   /* get the divisor */
-   custom = (__u16) (230400L / baudrate);
-
-   /* Check for round off */
-   round1 = (__u16) (2304000L / baudrate);
-   round = (__u16) (round1 - (custom * 10));
-   if (round > 4)
-   custom++;
-   *divisor = custom;
-
-   dev_dbg(&port->dev, " Baud %d = %d\n", baudrate, custom);
-   return 0;
-   }
-
-   dev_dbg(&port->dev, "%s", " Baud calculation Failed...\n");
-   return -1;
-#endif
 }
 
 /*
-- 
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: 3.18 regression: Error while assigning device slot ID, USB3 devices not detected

[Josh Boyer]

On Sun, Jan 18, 2015 at 1:25 AM, Greg KH  wrote:
> On Sun, Jan 18, 2015 at 12:08:18AM -0600, Robert Hancock wrote:
>> I've got an Intel Haswell-based system with a Gigabyte Z87X-D3H motherboard
>> under Fedora 21. After updating to the 3.18.2-200 Fedora kernel, I noticed
>> some errors in dmesg and at least some of my USB3 ports don't recognize any
>> USB3 devices plugged into them:
>>
>> [0.560838] xhci_hcd :00:14.0: Error while assigning device slot ID
>> [0.560912] xhci_hcd :00:14.0: Max number of devices this xHCI host
>> supports is 32.
>> [0.560990] usb usb2-port2: couldn't allocate usb_device
>> [0.561098] xhci_hcd :00:14.0: Error while assigning device slot ID
>> [0.561163] xhci_hcd :00:14.0: Max number of devices this xHCI host
>> supports is 32.
>> [0.561239] usb usb2-port5: couldn't allocate usb_device
>> [0.561344] xhci_hcd :00:14.0: Error while assigning device slot ID
>> [0.561409] xhci_hcd :00:14.0: Max number of devices this xHCI host
>> supports is 32.
>> [0.561484] usb usb2-port6: couldn't allocate usb_device
>>
>> This worked fine under 3.17. Is this a known problem?
>
> Yes it is, should be fixed in Linus's tree now and will be backported to
> the latest 3.18-stable tree in a week or so.

Do you happen to know the commit id?

josh
--
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: gadget: composite: Provide list of registered functions

[Krzysztof Opasiak]

Driver which provides implementation of some USB functions
registers usb_function_driver structure in composite framework.
Function drivers are identifed using registered name.

When gadget is composed using configfs user must know what
names has been registered. If function is compiled as a module
this information can be found in modules.alias file. If
function is compiled-in, there is no way to discover what
usb functions are available in currently running kernel.

Such situation is nothing new for linux kernel.
Similar situation is with file systems. While mounting user
can provide an fs type argument using -t option in mount.
Those type names are registered by drivers. To make those names
discoverable there is a /proc/filesystems which
exports the list of currently registered file systems.

This patch adds /proc/usb-functions attribute which exports
the list of currently registered function drivers.
This allows user to discover list of both compiled-in functions
and from loaded kernel modules.

Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/configfs.c  |   53 
 drivers/usb/gadget/configfs.h  |2 ++
 drivers/usb/gadget/functions.c |   13 ++
 3 files changed, 68 insertions(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 7564814..275d7d0 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "configfs.h"
 #include "u_f.h"
 #include "u_os_desc.h"
@@ -1558,13 +1559,63 @@ void unregister_gadget_item(struct config_item *item)
 }
 EXPORT_SYMBOL_GPL(unregister_gadget_item);
 
+#ifdef CONFIG_PROC_FS
+#define PROC_ATTR_NAME "usb-functions"
+
+static int functions_proc_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, functions_proc_show, NULL);
+}
+
+static const struct file_operations functions_proc_fops = {
+   .owner  = THIS_MODULE,
+   .open   = functions_proc_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static inline int proc_attr_init(void)
+{
+   struct proc_dir_entry *entry;
+
+   entry = proc_create(PROC_ATTR_NAME, 0, NULL, &functions_proc_fops);
+   return entry != NULL ? 0 : -EINVAL;
+}
+
+static inline void proc_attr_cleanup(void)
+{
+   remove_proc_entry(PROC_ATTR_NAME, NULL);
+}
+
+#else
+
+static inline int proc_attr_init(void)
+{
+   return 0;
+}
+
+static inline void proc_attr_cleanup(void)
+{
+   return;
+}
+
+#endif
+
 static int __init gadget_cfs_init(void)
 {
int ret;
 
config_group_init(&gadget_subsys.su_group);
 
+   ret = proc_attr_init();
+   if (ret)
+   return ret;
+
ret = configfs_register_subsystem(&gadget_subsys);
+   if (ret)
+   proc_attr_cleanup();
+
return ret;
 }
 module_init(gadget_cfs_init);
@@ -1572,5 +1623,7 @@ module_init(gadget_cfs_init);
 static void __exit gadget_cfs_exit(void)
 {
configfs_unregister_subsystem(&gadget_subsys);
+   proc_attr_cleanup();
 }
 module_exit(gadget_cfs_exit);
+
diff --git a/drivers/usb/gadget/configfs.h b/drivers/usb/gadget/configfs.h
index 36c468c..2af1e39 100644
--- a/drivers/usb/gadget/configfs.h
+++ b/drivers/usb/gadget/configfs.h
@@ -16,4 +16,6 @@ static inline struct usb_os_desc *to_usb_os_desc(struct 
config_item *item)
return container_of(to_config_group(item), struct usb_os_desc, group);
 }
 
+int functions_proc_show(struct seq_file *m, void *v);
+
 #endif /*  USB__GADGET__CONFIGFS__H */
diff --git a/drivers/usb/gadget/functions.c b/drivers/usb/gadget/functions.c
index b13f839..95f08a4 100644
--- a/drivers/usb/gadget/functions.c
+++ b/drivers/usb/gadget/functions.c
@@ -114,3 +114,16 @@ void usb_function_unregister(struct usb_function_driver 
*fd)
mutex_unlock(&func_lock);
 }
 EXPORT_SYMBOL_GPL(usb_function_unregister);
+
+int functions_proc_show(struct seq_file *m, void *v)
+{
+   struct usb_function_driver *fd;
+
+   mutex_lock(&func_lock);
+   list_for_each_entry(fd, &func_list, list)
+   seq_printf(m, "%s\n", fd->name);
+
+   mutex_unlock(&func_lock);
+   return 0;
+}
+
-- 
1.7.9.5

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

[PATCH] usb: gadget: composite: Provide list of registered functions

[Krzysztof Opasiak]

This is a respin of previously discussed RFC patch[1].

*Why?*

USB gadget can be composed from userspace using ConfigFS. During
gadget composition user has to create at least one instance of
function. Instance is being created using

cd /usb-gadget/
mkdir functions/.

Where:
instance - unique name for instance of function of given type
type - name registered by USB function driver during it's module
init

Instance is a string which allow to identify instance if we have for
example two acm functions in one gadget. Type is a USB function driver
identifier registered by driver during module init. This string is
also a part of USB function module alias. User has to know that
functionfs module is identifed using ffs and source sink is identified
by SourceSink.

When function is compiled as a module user may read module.alias file
and get those names form module alias. When function is compiled-in
kernel it doesn't provide entry in module.alias file and currently
there is no way to learn what functions are available.

*Does similar problem exist in other place?*

Yes, similar problem is with file systems. Each module which provides
file system implementation registers some file system name which can
be used during mounting (-t option). User may also check the
module.alias file to find fs types available as modules. To discover
what fs types has been compiled-in kernel there is a /proc/filesystems
file which exports names of all fs types currently registered in
framework.

*How to solve this?*

This patch solves our problem by adding /proc/usb-functions file which
exports to userspace list of all currently registered USB function
drivers. This is similar solution as one used by file systems.

I'm aware that adding new files to proc is not very well welcome.
I have looked for some other more suitable location for this list
but didn't find any, so suggestions are very welcome.

Footnotes:
1 - http://www.spinics.net/lists/linux-usb/msg115872.html


Best regards,
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Krzysztof Opasiak (1):
  usb: gadget: composite: Provide list of registered functions

 drivers/usb/gadget/configfs.c  |   53 
 drivers/usb/gadget/configfs.h  |2 ++
 drivers/usb/gadget/functions.c |   13 ++
 3 files changed, 68 insertions(+)

-- 
1.7.9.5

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

Re: Control message failures kill entire XHCI stack

[Mathias Nyman]

Hi

On 18.01.2015 22:55, Devin Heitmueller wrote:
> Hello,
> 
> I'm debugging some issues on a couple of different USB TV tuners which
> boil down to the following error:
> 
> xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command.
> 
> This is followed by the XHCI driver disconnecting *all* USB devices
> from the controller.
> 
> I've done a bit of debugging, and the root of the issue appears to be
> an intermittent control message timing out, and then the call to
> usb_kill_urb() that occurs inside of usb_control_msg() when the
> timeout expires is what causes the disconnect.  Specifically, it would
> appear that xhci_urb_dequeue tries to stop the endpoint using
> xhci_queue_stop_endpoint(), the command gets queued but the IRQ never
> fires to perform the TRB_STOP_RING completion code. The function
> xhci_stop_endpoint_command_watchdog() fires after five seconds, which
> tears down the entire driver.
> 
> Below is the dmesg output with the xhci_hcd debugging enabled.  The
> dump_stack() call is something I added (i.e. it's not an OOPS) so I
> could see which code path was making the usb_kill_urb() call that was
> failing.  Note that the caller is using usb_control_msg() with 1000ms
> timeout, and we can see from the timestamps that the timer expires
> which is what causes the call to usb_kill_urb().
> 
> I would imagine that explicitly killing URBs is a pretty uncommon task
> for control endpoint messages (compared to ISOC or BULK endpoints
> where it's done regularly).  Is it possible a exception case has been
> missed?
> 
> Independent of the usb_kill_urb() killing the entire stack, I still
> don't really understand yet why the control message failed in the
> first place.  This is a well-exercised code path in the au0828 driver
> (related to I2C transfers) and I've never seen this when using the
> EHCI driver.  My assumption is that either the HCD is getting sick
> which is causing both the control message to fail as well as putting
> it into an inconsistent state such that we never get the TRB_STOP_RING
> IRQ, or we've got two separate bugs - the control message failing for
> some "legitimate" reason (i.e. I screwed something up in my au0828
> driver), followed by the usb_kill_urb() error simply not handling
> killing of URBs on a control endpoint (which causes the entire stack
> to go down).
> 
> Thoughts/suggestions/recommendations are welcome.
> 

There are a couple of xhci bugs triggered by dvb devices:
https://bugzilla.kernel.org/show_bug.cgi?id=75521
https://bugzilla.kernel.org/show_bug.cgi?id=65021

The first one (75521) I believe is mostly fixed by patches in 3.18 and early
3.19-rc, so work on a 3.19-rc kernel to eliminate those issues.

The second bug (65021) looks more like your case, it queues two stop_endpoints 
commands almost simultaneously, which end up never completing, ->timeout and 
tear down xhci.
That bug has a debug patch for command ring status, you could try it out to 
check if
the command queue is running among other details.

A verbose xhci dmesg log log using: 
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
could give some insight to what's happening

-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 v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP

[Maxime Ripard]

Hi all,

This serie enables the Armada 385 AP XHCI controller.

Since the controller uses a GPIO-controlled VBUS, we used the
phy-generic driver, and made the needed additions to the xhci-plat
driver to retrieve a USB phy.

Unfortunately, some glitches were also found along the way, mostly
because of the probe deferring that was introduced by this phy
retrieval.

Since the introduction of the Armada 38x support in 3.16, the driver
was attempting to write into registers while the clock wasn't enabled
yet. This was working because the bootloader left it enabled, but in
the case of a deferred probing, the clock would have been disabled by
the error path of our driver, and this would fail. This should go in
3.19, and any stable kernel for 3.16+.

The two patches remaining are "regular" patches, and are aimed at
3.20. The last patch depend on my previous serie to introduce support
for the the A385 AP board.

Thanks,
Maxime

Changes from v1:
  - Removed the patch 1 that fixes the deferred probing that was
merged
  - Fixed the error path of the mvebu quirks code to avoid leaking a
clock reference and the main HCD.
  - Removed the extra PHY field private to the struct xhci, and used
the usb_phy field in the main HCD instead
  - Fixed the error path of the phy retrieval code in order to avoid
leaving the phy up if an error was to happen, or the remove
callback to be called.

Maxime Ripard (3):
  usb: XHCI: platform: Move the Marvell quirks after the enabling the
clocks
  usb: xhci: plat: Add USB phy support
  ARM: mvebu: armada-385-ap: Enable USB3 port

 arch/arm/boot/dts/armada-385-db-ap.dts | 28 +
 drivers/usb/host/xhci-plat.c   | 38 --
 2 files changed, 55 insertions(+), 11 deletions(-)

-- 
2.2.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 v2 2/3] usb: xhci: plat: Add USB phy support

[Maxime Ripard]

The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.

Add a call to retrieve a USB PHY to XHCI plat in order to support this.

Signed-off-by: Maxime Ripard 
---
 drivers/usb/host/xhci-plat.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 0e11d61408ff..783e819139a7 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -155,12 +156,27 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
+   hcd->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
+   if (IS_ERR(hcd->usb_phy)) {
+   ret = PTR_ERR(hcd->usb_phy);
+   if (ret == -EPROBE_DEFER)
+   goto put_usb3_hcd;
+   hcd->usb_phy = NULL;
+   } else {
+   ret = usb_phy_init(hcd->usb_phy);
+   if (ret)
+   goto put_usb3_hcd;
+   }
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
-   goto put_usb3_hcd;
+   goto disable_usb_phy;
 
return 0;
 
+disable_usb_phy:
+   usb_phy_shutdown(hcd->usb_phy);
+
 put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
 
@@ -184,6 +200,7 @@ static int xhci_plat_remove(struct platform_device *dev)
struct clk *clk = xhci->clk;
 
usb_remove_hcd(xhci->shared_hcd);
+   usb_phy_shutdown(hcd->usb_phy);
usb_put_hcd(xhci->shared_hcd);
 
usb_remove_hcd(hcd);
-- 
2.2.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 v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

[Maxime Ripard]

The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
VBUS line. Enable the needed drivers to support this.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/armada-385-db-ap.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts 
b/arch/arm/boot/dts/armada-385-db-ap.dts
index 3a51531eb37b..b891b4c897f5 100644
--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -98,6 +98,13 @@
status = "okay";
};
 
+   pinctrl@18000 {
+   xhci0_vbus_pins: xhci0-vbus-pins {
+   marvell,pins = "mpp44";
+   marvell,function = "gpio";
+   };
+   };
+
ethernet@3 {
status = "okay";
phy = <&phy2>;
@@ -122,6 +129,11 @@
phy = <&phy0>;
phy-mode = "rgmii-id";
};
+
+   usb3@f {
+   status = "okay";
+   usb-phy = <&usb3_phy>;
+   };
};
 
pcie-controller {
@@ -147,4 +159,20 @@
};
};
};
+
+   usb3_phy: usb3_phy {
+   compatible = "usb-nop-xceiv";
+   vcc-supply = <®_xhci0_vbus>;
+   };
+
+   reg_xhci0_vbus: xhci0-vbus {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <&xhci0_vbus_pins>;
+   regulator-name = "xhci0-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   enable-active-high;
+   gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+   };
 };
-- 
2.2.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 v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Maxime Ripard]

The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.

However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.

Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.

Fix this by running the quirks after the clock has been enabled by the driver.

Signed-off-by: Maxime Ripard 
Cc:  # v3.16+
---
 drivers/usb/host/xhci-plat.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b15482..0e11d61408ff 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -83,16 +83,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
 
-
-   if (of_device_is_compatible(pdev->dev.of_node,
-   "marvell,armada-375-xhci") ||
-   of_device_is_compatible(pdev->dev.of_node,
-   "marvell,armada-380-xhci")) {
-   ret = xhci_mvebu_mbus_init_quirk(pdev);
-   if (ret)
-   return ret;
-   }
-
/* Initialize dma_mask and coherent_dma_mask to 32-bits */
ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
@@ -127,6 +117,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
 
+   if (of_device_is_compatible(pdev->dev.of_node,
+   "marvell,armada-375-xhci") ||
+   of_device_is_compatible(pdev->dev.of_node,
+   "marvell,armada-380-xhci")) {
+   ret = xhci_mvebu_mbus_init_quirk(pdev);
+   if (ret)
+   goto disable_clk;
+   }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
-- 
2.2.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

[PATCHv2 1/4] Revert "usb: gadget: uvc: cleanup __uvcg_fill_strm()"

[Andrzej Pietrasiewicz]

This reverts commit c8dba1896595 ("usb: gadget: uvc: cleanup 
__uvcg_fill_strm()").
__uvcg_fill_stream() during its execution uses priv2 as a pointer
to a pointer, because it advances the current position by the amount
of data taken by each processed descriptor and the advanced position
should be visible outside this function, so that the next time it is
called, the current position corresponds to the place where it was
the last time rather than again at the beginning of some block of data.
In other words priv2 is an "out" parameter.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/uvc_configfs.c | 39 +++---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index 8a6cd61..cc2a613 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -2000,27 +2000,28 @@ static int __uvcg_cnt_strm(void *priv1, void *priv2, 
void *priv3, int n,
return 0;
 }
 
-static int __uvcg_fill_strm(void *priv1, void *dest, void *priv3, int n,
+static int __uvcg_fill_strm(void *priv1, void *priv2, void *priv3, int n,
enum uvcg_strm_type type)
 {
+   void **dest = priv2;
struct uvc_descriptor_header ***array = priv3;
size_t sz;
 
-   **array = dest;
+   **array = *dest;
++*array;
 
switch (type) {
case UVCG_HEADER: {
-   struct uvc_input_header_descriptor *ihdr = dest;
+   struct uvc_input_header_descriptor *ihdr = *dest;
struct uvcg_streaming_header *h = priv1;
struct uvcg_format_ptr *f;
 
-   memcpy(dest, &h->desc, sizeof(h->desc));
-   dest += sizeof(h->desc);
+   memcpy(*dest, &h->desc, sizeof(h->desc));
+   *dest += sizeof(h->desc);
sz = UVCG_STREAMING_CONTROL_SIZE;
list_for_each_entry(f, &h->formats, entry) {
-   memcpy(dest, f->fmt->bmaControls, sz);
-   dest += sz;
+   memcpy(*dest, f->fmt->bmaControls, sz);
+   *dest += sz;
}
ihdr->bLength = sizeof(h->desc) + h->num_fmt * sz;
ihdr->bNumFormats = h->num_fmt;
@@ -2030,22 +2031,22 @@ static int __uvcg_fill_strm(void *priv1, void *dest, 
void *priv3, int n,
struct uvcg_format *fmt = priv1;
 
if (fmt->type == UVCG_UNCOMPRESSED) {
-   struct uvc_format_uncompressed *unc = dest;
+   struct uvc_format_uncompressed *unc = *dest;
struct uvcg_uncompressed *u =
container_of(fmt, struct uvcg_uncompressed,
 fmt);
 
-   memcpy(dest, &u->desc, sizeof(u->desc));
-   dest += sizeof(u->desc);
+   memcpy(*dest, &u->desc, sizeof(u->desc));
+   *dest += sizeof(u->desc);
unc->bNumFrameDescriptors = fmt->num_frames;
unc->bFormatIndex = n + 1;
} else if (fmt->type == UVCG_MJPEG) {
-   struct uvc_format_mjpeg *mjp = dest;
+   struct uvc_format_mjpeg *mjp = *dest;
struct uvcg_mjpeg *m =
container_of(fmt, struct uvcg_mjpeg, fmt);
 
-   memcpy(dest, &m->desc, sizeof(m->desc));
-   dest += sizeof(m->desc);
+   memcpy(*dest, &m->desc, sizeof(m->desc));
+   *dest += sizeof(m->desc);
mjp->bNumFrameDescriptors = fmt->num_frames;
mjp->bFormatIndex = n + 1;
} else {
@@ -2055,15 +2056,15 @@ static int __uvcg_fill_strm(void *priv1, void *dest, 
void *priv3, int n,
break;
case UVCG_FRAME: {
struct uvcg_frame *frm = priv1;
-   struct uvc_descriptor_header *h = dest;
+   struct uvc_descriptor_header *h = *dest;
 
sz = sizeof(frm->frame);
-   memcpy(dest, &frm->frame, sz);
-   dest += sz;
+   memcpy(*dest, &frm->frame, sz);
+   *dest += sz;
sz = frm->frame.b_frame_interval_type *
sizeof(*frm->dw_frame_interval);
-   memcpy(dest, frm->dw_frame_interval, sz);
-   dest += sz;
+   memcpy(*dest, frm->dw_frame_interval, sz);
+   *dest += sz;
if (frm->fmt_type == UVCG_UNCOMPRESSED)
h->bLength = UVC_DT_FRAME_UNCOMPRESSED_SIZE(
frm->frame.b_frame_interval_type);
@@ -2126,7 +2127,7 @@ static int uvcg_streaming_class_allow_link(struct 
config_item *src,
   

[PATCHv2 0/4] Fixes for configfs support in uvc

[Andrzej Pietrasiewicz]

This short series reverts a commit which, at a first glance,
simplifies the code but in fact makes it not work correctly.
The series applies small fixes and adds some comments to functions.
This is an updated series after Laurent's comments - thank you,
Laurent.

@Felipe: The first patch of the series should be applied
only if the patch being reverted is already in your tree.
If it is not, feel free to apply only patches 2..4.

v1..v2:

- Updated the commit log of the reverted commit - used
the correct hash-id of the reverted commit in the log
- Used explicit type instead of void * where it can be used

Andrzej Pietrasiewicz (4):
  Revert "usb: gadget: uvc: cleanup __uvcg_fill_strm()"
  usb: gadget: uvc: preserve the address passed to kfree()
  usb: gadget: uvc: use explicit type instead of void *
  usb: gadget: uvc: comments for iterating over streaming hierarchy

 drivers/usb/gadget/function/uvc_configfs.c | 87 +-
 1 file changed, 63 insertions(+), 24 deletions(-)

-- 
1.9.1

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

[PATCHv2 2/4] usb: gadget: uvc: preserve the address passed to kfree()

[Andrzej Pietrasiewicz]

__uvcg_fill_strm() called from __uvcg_iter_stream_cls()
might have advanced the "data" even if __uvcg_iter_stream_cls()
returns an error, so use a backup copy as an argument to kfree().

Signed-off-by: Andrzej Pietrasiewicz 
Acked-by: Laurent Pinchart 
---
 drivers/usb/gadget/function/uvc_configfs.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index cc2a613..49f25e8 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -2086,7 +2086,7 @@ static int uvcg_streaming_class_allow_link(struct 
config_item *src,
struct mutex *su_mutex = &src->ci_group->cg_subsys->su_mutex;
struct uvc_descriptor_header ***class_array, **cl_arr;
struct uvcg_streaming_header *target_hdr;
-   void *data;
+   void *data, *data_save;
size_t size = 0, count = 0;
int ret = -EINVAL;
 
@@ -2119,7 +2119,7 @@ static int uvcg_streaming_class_allow_link(struct 
config_item *src,
goto unlock;
}
 
-   data = kzalloc(size, GFP_KERNEL);
+   data = data_save = kzalloc(size, GFP_KERNEL);
if (!data) {
kfree(*class_array);
*class_array = NULL;
@@ -2132,7 +2132,11 @@ static int uvcg_streaming_class_allow_link(struct 
config_item *src,
if (ret) {
kfree(*class_array);
*class_array = NULL;
-   kfree(data);
+   /*
+* __uvcg_fill_strm() called from __uvcg_iter_stream_cls()
+* might have advanced the "data", so use a backup copy
+*/
+   kfree(data_save);
goto unlock;
}
*cl_arr = (struct uvc_descriptor_header *)&opts->uvc_color_matching;
-- 
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

[PATCHv2 3/4] usb: gadget: uvc: use explicit type instead of void *

[Andrzej Pietrasiewicz]

The first parameter of __uvcg_iter_strm_cls() is always used in
the context of struct uvcg_streaming_header, so change the
function prototype accordingly.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/uvc_configfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index 49f25e8..51d8e9e 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -1918,10 +1918,10 @@ enum uvcg_strm_type {
UVCG_FRAME
 };
 
-static int __uvcg_iter_strm_cls(void *priv1, void *priv2, void *priv3,
+static int __uvcg_iter_strm_cls(struct uvcg_streaming_header *h,
+   void *priv2, void *priv3,
int (*fun)(void *, void *, void *, int, enum uvcg_strm_type type))
 {
-   struct uvcg_streaming_header *h = priv1;
struct uvcg_format_ptr *f;
struct config_group *grp;
struct config_item *item;
-- 
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

[PATCHv2 4/4] usb: gadget: uvc: comments for iterating over streaming hierarchy

[Andrzej Pietrasiewicz]

The purpose of the functions and their parametrs might not be obvious
to the reader, so explain it.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/uvc_configfs.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index 51d8e9e..3c0467b 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -1918,6 +1918,25 @@ enum uvcg_strm_type {
UVCG_FRAME
 };
 
+/*
+ * Iterate over a hierarchy of streaming descriptors' config items.
+ * The items are created by the user with configfs.
+ *
+ * It "processes" the header pointed to by @priv1, then for each format
+ * that follows the header "processes" the format itself and then for
+ * each frame inside a format "processes" the frame.
+ *
+ * As a "processing" function the @fun is used.
+ *
+ * __uvcg_iter_strm_cls() is used in two context: first, to calculate
+ * the amount of memory needed for an array of streaming descriptors
+ * and second, to actually fill the array.
+ *
+ * @h: streaming header pointer
+ * @priv2: an "inout" parameter (the caller might want to see the changes to 
it)
+ * @priv3: an "inout" parameter (the caller might want to see the changes to 
it)
+ * @fun: callback function for processing each level of the hierarchy
+ */
 static int __uvcg_iter_strm_cls(struct uvcg_streaming_header *h,
void *priv2, void *priv3,
int (*fun)(void *, void *, void *, int, enum uvcg_strm_type type))
@@ -1951,6 +1970,14 @@ static int __uvcg_iter_strm_cls(struct 
uvcg_streaming_header *h,
return ret;
 }
 
+/*
+ * Count how many bytes are needed for an array of streaming descriptors.
+ *
+ * @priv1: pointer to a header, format or frame
+ * @priv2: inout parameter, accumulated size of the array
+ * @priv3: inout parameter, accumulated number of the array elements
+ * @n: unused, this function's prototype must match @fun in 
__uvcg_iter_strm_cls
+ */
 static int __uvcg_cnt_strm(void *priv1, void *priv2, void *priv3, int n,
   enum uvcg_strm_type type)
 {
@@ -2000,6 +2027,13 @@ static int __uvcg_cnt_strm(void *priv1, void *priv2, 
void *priv3, int n,
return 0;
 }
 
+/*
+ * Fill an array of streaming descriptors.
+ *
+ * @priv1: pointer to a header, format or frame
+ * @priv2: inout parameter, pointer into a block of memory
+ * @priv3: inout parameter, pointer to a 2-dimensional array
+ */
 static int __uvcg_fill_strm(void *priv1, void *priv2, void *priv3, int n,
enum uvcg_strm_type type)
 {
-- 
1.9.1

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

Re: [PATCH 1/2] Add hub port switchable when checking port power

[vichy]

2015-01-19 1:04 GMT+08:00 Alan Stern :
> On Sun, 18 Jan 2015, Chechun Kuo wrote:
>
>> In check_port_resume_type, we will check port power status to determine 
>> whether the status should change to -ENODEV.
>> If all ports power control of the hub are handled at once, the port power 
>> status may not represent the real case and cause resume fail.
>> At this patch, we add hub_is_port_power_switchable as well as checking the 
>> port power.
>
> I don't understand the reason for this patch.
>
> Are you saying that the PORT POWER bit in the port status will be wrong
> (that is, will be 0) if the hub doesn't support power switching?
> According to section 11.24.2.7.1.6 of the USB-2 spec:
>
> This bit is implemented on all ports whether or not actual
> port power switching devices are present.
>
> So why is this patch needed?  Does it fix any real problems?

this patch fixed the failure of runtime suspend happened on my host
controller root hub.
After reading what you point out above and ehci spec, I found it is
our HW's issue for handling PP when PPC is zero.
I am really sorry to make you confused ^^

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

Re: [PATCH 2/2] Add HCS_PPC when getting root hub status

[vichy]

hi alan

2015-01-19 1:06 GMT+08:00 Alan Stern :
> On Sun, 18 Jan 2015, Chechun Kuo wrote:
>
>> for some platform ehci controller, it is possible there is no port power 
>> control capability in the root hub.
>> And we add port power control determination when getting root hub port 
>> status.
>
> Why do you need to do this?  Doesn't the current code always give the
> right result?

My host controller doesn't support PPC, and the PORT_POWER bit will
not be one even when device is powered up.
After I checking the ehci spec, it should be HW's issue, since spec
say PP should be one even when PPC is zero.
Sorry to make you confuse ^^
--
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: Difference between run time and normal suspend

[vichy]

hi Alan:

2015-01-19 0:49 GMT+08:00 Alan Stern :
> On Sun, 18 Jan 2015, vichy wrote:
>
>> after tracing the source, I only can find the ehci_suspend is called
>> when system hibernate/suspend.
>> rpm_suspend use below method to find out suspend callback
>> if (dev->pm_domain)
>> callback = dev->pm_domain->ops.runtime_suspend;
>> else if (dev->type && dev->type->pm)
>> callback = dev->type->pm->runtime_suspend;
>> else if (dev->class && dev->class->pm)
>> callback = dev->class->pm->runtime_suspend;
>> else if (dev->bus && dev->bus->pm)
>> callback = dev->bus->pm->runtime_suspend;
>> else
>> callback = NULL;
>>
>> ehci_suspend doesn't register any one of above function.
>
> ehci_pci_init() in ehci_pci.c stores ehci_suspend in
> ehci_pci_hc_driver.pci_suspend.  That pointer is called by
> suspend_common() in hcd-pci.c, which is called by both
> hcd_pci_suspend() and hcd_pci_runtime_suspend().
I have several questions:
a.
in ehci-pci driver, the runtime suspend is register in the driver
structure, driver->pm, like below.
static struct pci_driver ehci_pci_driver = {
...
.probe =usb_hcd_pci_probe,
.remove =usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,

#ifdef CONFIG_PM_SLEEP
.driver ={
.pm =&usb_hcd_pci_pm_ops
},
#endif
};

But rpm_suspend search runtime suspend from device structure.
like dev->pm_domain, dev->type, dev->class, dev->bus, etc.

Why hcd_pci_runtime_suspend will be called?

b.
Contrary to pci system, in ehci-platfomr.c, there is no any runtime
suspend call back register in ehci_platform_pm_ops.
Could we get the conclusion that ehci controller will NOT be suspended
when all device on the root hub and root hub are suspended?

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

[PATCH v3 0/2] DLN2 fixes related to suspend/resume

[Octavian Purdila]

Hi Lee,

Here is the 3rd version of the patch-set against for-mfd-next branch
with the Reviewed-by tags from Johan. Note that I dropped the two GPIO
patches as they were already merged by Linus W in the GPIO tree.

Thanks,
Tavi

Changes since v2:

 * Dropped the GPIO fixes from this series as they were merged in the
   GPIO tree

 * Removed a stray newline

 * Updated the resume / suspend patch commit with more information
   about which cases it fixes and which it does not

Changes since v1:

 * Fix an issue introduced by v1 where we can get a use after free in
   the error path of probe

 * Add start/stop RX URBs helpers

 * move the suspend/resume routines above the module device table

 * used GFP_NOIO in resume

Octavian Purdila (2):
  mfd: dln2: add start/stop RX URBs helpers
  mfd: dln2: add suspend/resume functionality

 drivers/mfd/dln2.c | 71 ++
 1 file changed, 61 insertions(+), 10 deletions(-)

-- 
1.9.1

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

[PATCH v3 1/2] mfd: dln2: add start/stop RX URBs helpers

[Octavian Purdila]

This is in preparation for adding suspend / resume support.

Signed-off-by: Octavian Purdila 
Reviewed-by: Johan Hovold 
---
 drivers/mfd/dln2.c | 51 +--
 1 file changed, 41 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index 6d49685..8311820 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -587,12 +587,19 @@ static void dln2_free_rx_urbs(struct dln2_dev *dln2)
int i;
 
for (i = 0; i < DLN2_MAX_URBS; i++) {
-   usb_kill_urb(dln2->rx_urb[i]);
usb_free_urb(dln2->rx_urb[i]);
kfree(dln2->rx_buf[i]);
}
 }
 
+static void dln2_stop_rx_urbs(struct dln2_dev *dln2)
+{
+   int i;
+
+   for (i = 0; i < DLN2_MAX_URBS; i++)
+   usb_kill_urb(dln2->rx_urb[i]);
+}
+
 static void dln2_free(struct dln2_dev *dln2)
 {
dln2_free_rx_urbs(dln2);
@@ -604,9 +611,7 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
  struct usb_host_interface *hostif)
 {
int i;
-   int ret;
const int rx_max_size = DLN2_RX_BUF_SIZE;
-   struct device *dev = &dln2->interface->dev;
 
for (i = 0; i < DLN2_MAX_URBS; i++) {
dln2->rx_buf[i] = kmalloc(rx_max_size, GFP_KERNEL);
@@ -620,8 +625,19 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
usb_fill_bulk_urb(dln2->rx_urb[i], dln2->usb_dev,
  usb_rcvbulkpipe(dln2->usb_dev, dln2->ep_in),
  dln2->rx_buf[i], rx_max_size, dln2_rx, dln2);
+   }
+
+   return 0;
+}
 
-   ret = usb_submit_urb(dln2->rx_urb[i], GFP_KERNEL);
+static int dln2_start_rx_urbs(struct dln2_dev *dln2, gfp_t gfp)
+{
+   struct device *dev = &dln2->interface->dev;
+   int ret;
+   int i;
+
+   for (i = 0; i < DLN2_MAX_URBS; i++) {
+   ret = usb_submit_urb(dln2->rx_urb[i], gfp);
if (ret < 0) {
dev_err(dev, "failed to submit RX URB: %d\n", ret);
return ret;
@@ -665,9 +681,8 @@ static const struct mfd_cell dln2_devs[] = {
},
 };
 
-static void dln2_disconnect(struct usb_interface *interface)
+static void dln2_stop(struct dln2_dev *dln2)
 {
-   struct dln2_dev *dln2 = usb_get_intfdata(interface);
int i, j;
 
/* don't allow starting new transfers */
@@ -696,6 +711,15 @@ static void dln2_disconnect(struct usb_interface 
*interface)
/* wait for transfers to end */
wait_event(dln2->disconnect_wq, !dln2->active_transfers);
 
+   dln2_stop_rx_urbs(dln2);
+}
+
+static void dln2_disconnect(struct usb_interface *interface)
+{
+   struct dln2_dev *dln2 = usb_get_intfdata(interface);
+
+   dln2_stop(dln2);
+
mfd_remove_devices(&interface->dev);
 
dln2_free(dln2);
@@ -738,23 +762,30 @@ static int dln2_probe(struct usb_interface *interface,
 
ret = dln2_setup_rx_urbs(dln2, hostif);
if (ret)
-   goto out_cleanup;
+   goto out_free;
+
+   ret = dln2_start_rx_urbs(dln2, GFP_KERNEL);
+   if (ret)
+   goto out_stop_rx;
 
ret = dln2_hw_init(dln2);
if (ret < 0) {
dev_err(dev, "failed to initialize hardware\n");
-   goto out_cleanup;
+   goto out_stop_rx;
}
 
ret = mfd_add_hotplug_devices(dev, dln2_devs, ARRAY_SIZE(dln2_devs));
if (ret != 0) {
dev_err(dev, "failed to add mfd devices to core\n");
-   goto out_cleanup;
+   goto out_stop_rx;
}
 
return 0;
 
-out_cleanup:
+out_stop_rx:
+   dln2_stop_rx_urbs(dln2);
+
+out_free:
dln2_free(dln2);
 
return ret;
-- 
1.9.1

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

[PATCH v3 2/2] mfd: dln2: add suspend/resume functionality

[Octavian Purdila]

Without suspend/resume functionality in the USB driver the USB core
will disconnect and reconnect the DLN2 port and because the GPIO
framework does not yet support removal of an in-use controller a
suspend/resume operation will result in a crash.

This patch provides suspend and resume functions for the DLN2 driver
so that the above scenario is avoided, if the host controller does not
drop VBUS during suspend, since in this case the device state is
preserved.

We chose not implemented reset_resume so that if the host controller
does drop VBUS the resume path will go through above the
disconnect/reconnect process since it is probably better to fix the
GPIO framework disconnect issue then to save and restore the device
state for every driver.

Signed-off-by: Octavian Purdila 
Reviewed-by: Johan Hovold 
---
 drivers/mfd/dln2.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index 8311820..1be9bd1 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -791,6 +791,24 @@ out_free:
return ret;
 }
 
+static int dln2_suspend(struct usb_interface *iface, pm_message_t message)
+{
+   struct dln2_dev *dln2 = usb_get_intfdata(iface);
+
+   dln2_stop(dln2);
+
+   return 0;
+}
+
+static int dln2_resume(struct usb_interface *iface)
+{
+   struct dln2_dev *dln2 = usb_get_intfdata(iface);
+
+   dln2->disconnect = false;
+
+   return dln2_start_rx_urbs(dln2, GFP_NOIO);
+}
+
 static const struct usb_device_id dln2_table[] = {
{ USB_DEVICE(0xa257, 0x2013) },
{ }
@@ -803,6 +821,8 @@ static struct usb_driver dln2_driver = {
.probe = dln2_probe,
.disconnect = dln2_disconnect,
.id_table = dln2_table,
+   .suspend = dln2_suspend,
+   .resume = dln2_resume,
 };
 
 module_usb_driver(dln2_driver);
-- 
1.9.1

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

Re: [PATCH 1/3] Revert "usb: gadget: uvc: cleanup __uvcg_fill_strm()"

[Laurent Pinchart]

Hi Andrzej,

On Monday 19 January 2015 12:23:38 Andrzej Pietrasiewicz wrote:
> W dniu 19.01.2015 o 01:05, Laurent Pinchart pisze:
> > Hi Andrzej,
> > 
> > Thank you for the patch.
> > 
> > On Friday 16 January 2015 15:14:26 Andrzej Pietrasiewicz wrote:
> >> This reverts commit c0b53cb16250 ("usb: gadget: uvc: cleanup
> >> __uvcg_fill_strm()").
> > 
> > I can't find that commit in Linus' master, next/master or Felipe's next
> > branch. If the patch hasn't been applied there's no need to revert it :-)
> 
> I (used to) have it in Felipe's testing/next.
> But now the commit is visible as
> 
> c8dba18965954e7e9439376e0aa40fb5bb4c67e3.

OK. That commit is in Felipe's testing/next branch, and I don't expect Felipe 
to merge it in next. The revert is thus not needed for mainline.

> Anyway, I will post a modified v2 series including changes resulting
> from your comments.

Thank you.

-- 
Regards,

Laurent Pinchart

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

Re: Fatal Exception on device when Hotsyncing Palm in linux

[Henri Manson]

Dear Johan,

Enclosed the dmesg outputs from 9.04 and 10.04.4. I booted both
kernels with usbserial.debug=1 and loaded module visor.ko with
parameter debug=1

Kind regards,

Henri

On Mon, Jan 19, 2015 at 11:56 AM, Johan Hovold  wrote:
> On Sat, Jan 17, 2015 at 12:06:59AM +0100, Henri Manson wrote:
>> I figured out how to get debug output, enclosed the results. How can I
>> get usbserial debug output on Ubuntu 9.04? It appears it wasn't a
>> module yet back then.
>
> Try passing usbserial.debug=1 as a kernel parameter from the bootloader.
>
>> out-crash: debug output form Ubuntu 14.04.1 which causes the Palm m505 to 
>> crash
>> out: debug output form Ubuntu 9.04 which works fine
>>
>> probe string on 9.04 and 14.04 is different:
>>
>> 9.04:
>> [  640.784916] usb 2-2: palm_os_4_probe - length = 20, data = 01 00 00
>> 00 63 6e 79 73 02 00 00 00 00 03 f3 5c 05 03 00 03
>>
>> 14.04.1:
>> [ 1685.194594] usb 8-2: palm_os_4_probe - length = 20, data = 01 00 00
>> 00 63 6e 79 73 02 00 00 00 01 36 00 5c 00 00 00 09
>
> It would be better if you could compare output from 9.04 and the first
> Ubuntu version that broke (i.e. with the 2.6.32 kernel).
>
> Thanks,
> Johan


out9.04
Description: Binary data


out10.0.4.4
Description: Binary data

Re: [PATCH 1/3] Revert "usb: gadget: uvc: cleanup __uvcg_fill_strm()"

[Andrzej Pietrasiewicz]

W dniu 19.01.2015 o 01:05, Laurent Pinchart pisze:

Hi Andrzej,

Thank you for the patch.

On Friday 16 January 2015 15:14:26 Andrzej Pietrasiewicz wrote:

This reverts commit c0b53cb16250 ("usb: gadget: uvc: cleanup
__uvcg_fill_strm()").


I can't find that commit in Linus' master, next/master or Felipe's next
branch. If the patch hasn't been applied there's no need to revert it :-)


I (used to) have it in Felipe's testing/next.
But now the commit is visible as

c8dba18965954e7e9439376e0aa40fb5bb4c67e3.

Anyway, I will post a modified v2 series including changes resulting
from your 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