Re: cdc_ncm driver padding problem

[Bjørn Mork]

> ==From: Marek Brudka 
..
> ==The bad thing is DHCP. It seems, that cdc_ncm driver somehow consumes DHCP
> ==replies. I had to manually setup wwan0 interface as well as routing
> ==using the result
> ==of Hayes command
> ==
> ==AT^DHCP?
> ==^DHCP:
> ==EC684764,F8FF,E9684764,E9684764,356002D4,366002D4,4320,4320
> ==OK


Are we sure that this firmware supports DHCP?  It's not uncommon for
modem firmwares to lack such support, and I find this a much more likely
explanation than the driver somehow messing up the DHCP replies while
letting other packets through.

Unfortunately there is no easy way to tell for sure if a specific
feature is enabled or not in a specific firmware.  Is it possible to get
a snoop from Windows while connecting, using the modem in the same mode?
That would tell us whether the Windows software depends on DHCP or is
using the AT^DHCP command.



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

[PATCH 1/1] ARM: imx53: configure imx for ULPI phy

[Fabien Lahoudere]

In order to use ULPI phy with usb host 2 and 3, we need to configure
controller register to enable ULPI features.

Signed-off-by: Fabien Lahoudere 
---
 drivers/usb/chipidea/ci_hdrc_imx.c |  5 +++
 drivers/usb/chipidea/ci_hdrc_imx.h |  1 +
 drivers/usb/chipidea/usbmisc_imx.c | 81 +++---
 3 files changed, 72 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 0991794..96c0e33 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "ci.h"
@@ -146,6 +147,10 @@ static struct imx_usbmisc_data 
*usbmisc_get_init_data(struct device *dev)
if (of_find_property(np, "external-vbus-divider", NULL))
data->evdo = 1;
 
+
+   if (of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI)
+   data->ulpi = 1;
+
return data;
 }
 
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h 
b/drivers/usb/chipidea/ci_hdrc_imx.h
index 409aa5ca8..d666c9f 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.h
+++ b/drivers/usb/chipidea/ci_hdrc_imx.h
@@ -19,6 +19,7 @@ struct imx_usbmisc_data {
unsigned int disable_oc:1; /* over current detect disabled */
unsigned int oc_polarity:1; /* over current polarity if oc enabled */
unsigned int evdo:1; /* set external vbus divider option */
+   unsigned int ulpi:1; /* connected to an ULPI phy */
 };
 
 int imx_usbmisc_init(struct imx_usbmisc_data *);
diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index 20d02a5..5472900 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -46,11 +46,20 @@
 
 #define MX53_USB_OTG_PHY_CTRL_0_OFFSET 0x08
 #define MX53_USB_OTG_PHY_CTRL_1_OFFSET 0x0c
+#define MX53_USB_CTRL_1_OFFSET 0x10
+#define MX53_USB_CTRL_1_H2_XCVR_CLK_SEL_MASK (0x11 << 2)
+#define MX53_USB_CTRL_1_H2_XCVR_CLK_SEL_ULPI BIT(2)
+#define MX53_USB_CTRL_1_H3_XCVR_CLK_SEL_MASK (0x11 << 6)
+#define MX53_USB_CTRL_1_H3_XCVR_CLK_SEL_ULPI BIT(6)
 #define MX53_USB_UH2_CTRL_OFFSET   0x14
 #define MX53_USB_UH3_CTRL_OFFSET   0x18
 #define MX53_BM_OVER_CUR_DIS_H1BIT(5)
 #define MX53_BM_OVER_CUR_DIS_OTG   BIT(8)
 #define MX53_BM_OVER_CUR_DIS_UHx   BIT(30)
+#define MX53_USB_CTRL_1_UH2_ULPI_ENBIT(26)
+#define MX53_USB_CTRL_1_UH3_ULPI_ENBIT(27)
+#define MX53_USB_UHx_CTRL_WAKE_UP_EN   BIT(7)
+#define MX53_USB_UHx_CTRL_ULPI_INT_EN  BIT(8)
 #define MX53_USB_PHYCTRL1_PLLDIV_MASK  0x3
 #define MX53_USB_PLL_DIV_24_MHZ0x01
 
@@ -199,31 +208,73 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data 
*data)
val |= MX53_USB_PLL_DIV_24_MHZ;
writel(val, usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
 
-   if (data->disable_oc) {
-   spin_lock_irqsave(>lock, flags);
-   switch (data->index) {
+   spin_lock_irqsave(>lock, flags);
+
+   switch (data->index) {
case 0:
-   reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
-   val = readl(reg) | MX53_BM_OVER_CUR_DIS_OTG;
+   if (data->disable_oc) {
+   reg = usbmisc->base + 
MX53_USB_OTG_PHY_CTRL_0_OFFSET;
+   val = readl(reg) | MX53_BM_OVER_CUR_DIS_OTG;
+   if (reg && val)
+   writel(val, reg);
+   }
break;
case 1:
-   reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
-   val = readl(reg) | MX53_BM_OVER_CUR_DIS_H1;
+   if (data->disable_oc) {
+   reg = usbmisc->base + 
MX53_USB_OTG_PHY_CTRL_0_OFFSET;
+   val = readl(reg) | MX53_BM_OVER_CUR_DIS_H1;
+   if (reg && val)
+   writel(val, reg);
+   }
break;
case 2:
-   reg = usbmisc->base + MX53_USB_UH2_CTRL_OFFSET;
-   val = readl(reg) | MX53_BM_OVER_CUR_DIS_UHx;
+   if (data->ulpi) {
+   /* set USBH2 into ULPI-mode. */
+   reg = usbmisc->base + MX53_USB_CTRL_1_OFFSET;
+   val = readl(reg) | MX53_USB_CTRL_1_UH2_ULPI_EN;
+   /* select ULPI clock */
+   val &= ~MX53_USB_CTRL_1_H2_XCVR_CLK_SEL_MASK;
+   val |= MX53_USB_CTRL_1_H2_XCVR_CLK_SEL_ULPI;
+   writel(val, reg);
+   /* Set interrupt wake up enable */
+   reg = usbmisc->base + 

[PATCH 1/1] ARM: imx53: Add binding to disable USB 60Mhz clock

[Fabien Lahoudere]

This binding allow to disable the internal 60Mhz clock for USB host2 and
host3.

Signed-off-by: Fabien Lahoudere 
---
 drivers/usb/chipidea/ci_hdrc_imx.c |  2 ++
 drivers/usb/chipidea/ci_hdrc_imx.h |  1 +
 drivers/usb/chipidea/usbmisc_imx.c | 17 +
 3 files changed, 20 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 96c0e33..89a9d98 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -147,6 +147,8 @@ static struct imx_usbmisc_data 
*usbmisc_get_init_data(struct device *dev)
if (of_find_property(np, "external-vbus-divider", NULL))
data->evdo = 1;
 
+   if (of_find_property(np, "disable-int60ck", NULL))
+   data->disable_int60ck = 1;
 
if (of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI)
data->ulpi = 1;
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h 
b/drivers/usb/chipidea/ci_hdrc_imx.h
index d666c9f..43bafae 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.h
+++ b/drivers/usb/chipidea/ci_hdrc_imx.h
@@ -20,6 +20,7 @@ struct imx_usbmisc_data {
unsigned int oc_polarity:1; /* over current polarity if oc enabled */
unsigned int evdo:1; /* set external vbus divider option */
unsigned int ulpi:1; /* connected to an ULPI phy */
+   unsigned int disable_int60ck:1; /* disable 60 MHZ clock */
 };
 
 int imx_usbmisc_init(struct imx_usbmisc_data *);
diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index 5472900..bffc667 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -53,6 +53,9 @@
 #define MX53_USB_CTRL_1_H3_XCVR_CLK_SEL_ULPI BIT(6)
 #define MX53_USB_UH2_CTRL_OFFSET   0x14
 #define MX53_USB_UH3_CTRL_OFFSET   0x18
+#define MX53_USB_CLKONOFF_CTRL_OFFSET  0x24
+#define MX53_USB_CLKONOFF_CTRL_H2_INT60CKOFF BIT(21)
+#define MX53_USB_CLKONOFF_CTRL_H3_INT60CKOFF BIT(22)
 #define MX53_BM_OVER_CUR_DIS_H1BIT(5)
 #define MX53_BM_OVER_CUR_DIS_OTG   BIT(8)
 #define MX53_BM_OVER_CUR_DIS_UHx   BIT(30)
@@ -242,6 +245,13 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data 
*data)
| MX53_USB_UHx_CTRL_ULPI_INT_EN;
writel(val, reg);
}
+   if (data->disable_int60ck) {
+   reg = usbmisc->base +
+   MX53_USB_CLKONOFF_CTRL_OFFSET;
+   val = readl(reg)
+   | MX53_USB_CLKONOFF_CTRL_H2_INT60CKOFF;
+   writel(val, reg);
+   }
if (data->disable_oc) {
reg = usbmisc->base + MX53_USB_UH2_CTRL_OFFSET;
val = readl(reg) | MX53_BM_OVER_CUR_DIS_UHx;
@@ -264,6 +274,13 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data 
*data)
| MX53_USB_UHx_CTRL_ULPI_INT_EN;
writel(val, reg);
}
+   if (data->disable_int60ck) {
+   reg = usbmisc->base +
+   MX53_USB_CLKONOFF_CTRL_OFFSET;
+   val = readl(reg)
+   | MX53_USB_CLKONOFF_CTRL_H3_INT60CKOFF;
+   writel(val, reg);
+   }
if (data->disable_oc) {
reg = usbmisc->base + MX53_USB_UH3_CTRL_OFFSET;
val = readl(reg) | MX53_BM_OVER_CUR_DIS_UHx;
-- 
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: ULPI phy issue with

[Fabien Lahoudere]

Hi,

I have splitted the patch to submit only imx53 configuration. I will 
follow Stephen submission to test it with my board and add needed code 
to solve my clock issue.


Thanks

Fabien


On 14/09/16 12:14, Peter Chen wrote:

On Tue, Sep 13, 2016 at 08:05:32PM +0200, Fabien Lahoudere wrote:

Hi Peter,



This is our device tree imx-ppd.dts:


I may know the reason why you meet hang at current flow, you are using
generic phy driver, and the PHY clock is enabled at phy_init which is
called later than setting portsc.pts. The current flow to enable ULPI
phy is like below:


This explains why the patch works if USBPHY_INTERFACE_MODE_ULPI works as
USBPHY_INTERFACE_MODE_UTMI. because _ci_usb_phy_init(ci) initialise clock
and generator.


Yes.





1. Enable ULPI and choose its clock select at usbmisc, which you have
already done.
2. Enable the input clock for ULPI


This is done by _ci_usb_phy_init(ci); and this function only do this so I
think we should have in ci_usb_phy_init(ci);:
case USBPHY_INTERFACE_MODE_ULPI:
ret = _ci_usb_phy_init(ci);
if (!ret)
hw_wait_phy_stable();
else
return ret;

3. set portsc.pts


hw_phymode_configure(ci);
ci_ulpi_phy_init(ci); // to init ULPI specific config once 
portsc.pts is
enabled
break;


You may need to have a ULPI PHY driver which do some power sequence
(clock, regulator, etc) before setting portsc.pts and visit ULPI
register.

This is already done by _ci_usb_phy_init(ci);

In conclusion, I think USBPHY_INTERFACE_MODE_ULPI should work as
USBPHY_INTERFACE_MODE_UTMI but with an extra function to visit ULPI register
(ci_ulpi_phy_init(ci);).
Am I wrong?


Currently, you are using generic PHY driver which does not intends for
ULPI PHY uses, looks at usb/phy/phy-upi.c and usb/common/ulpi.c, both
need to read id at its initialization.





I am also a little confused how Stephen Boyd's ULPI driver for qualcomm
platform, I will cc on discussion.


As you ask me earlier maybe he init clock from bootloader.


Yes, his PHY input clock is always on.

Stephen boyd's ulpi support at chipidea is the correct way. For your
case, you can create a generic ULPI PHY driver, and registered it on
ulpi bus, but you still need power sequence for your case.

I am afraid you may use your hack temporarily at local, once Stephen's patch
and power sequence patch set are queued, you can submit your changes.


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

Re: [PATCH 3/3] usb: gadget: default U1/U2 exit latencies to maximum

[Felipe Balbi]

Hi John,

John Youn  writes:
>> John Youn  writes:
> John Youn  writes:
>> On 8/31/2016 2:38 AM, Felipe Balbi wrote:
>>> If we don't know what are the actual U1/U2 exit
>>> latencies from the UDC, we're better off using
>>> maximum latencies as default. This should avoid
>>> any problems with too frequent U1/U2 entry.
>>>
>>> Signed-off-by: Felipe Balbi 
>>> ---
>>>  include/linux/usb/gadget.h | 12 ++--
>>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>>> index 3667d667cab1..20cb590c658e 100644
>>> --- a/include/linux/usb/gadget.h
>>> +++ b/include/linux/usb/gadget.h
>>> @@ -276,11 +276,19 @@ static inline void usb_ep_fifo_flush(struct 
>>> usb_ep *ep)
>>>  
>>>  
>>> /*-*/
>>>  
>>> +/**
>>> + * struct usb_dcd_config_params - Default U1/U2 exit latencies
>>> + * @bU1DevExitLat: U1 Exit Latency in us
>>> + * @bU2DevExitLat: U2 Exit Latency in us
>>> + *
>>> + * Note that we will be setting U1/U2 exit latencies to their maximum
>>> + * by default if no value is passed by the UDC Driver.
>>> + */
>>>  struct usb_dcd_config_params {
>>> __u8  bU1DevExitLat;/* U1 Device exit Latency */
>>> -#define USB_DEFAULT_U1_DEV_EXIT_LAT0x01/* Less then 1 microsec 
>>> */
>>> +#define USB_DEFAULT_U1_DEV_EXIT_LAT10 /* us */
>>> __le16 wU2DevExitLat;   /* U2 Device exit Latency */
>>> -#define USB_DEFAULT_U2_DEV_EXIT_LAT0x1F4   /* Less then 500 
>>> microsec */
>>> +#define USB_DEFAULT_U2_DEV_EXIT_LAT2047 /* us */
>>>  };
>>>  
>>>  
>>>
>>
>> Hi Felipe,
>>
>> Speaking of this, how would you feel about adding module parameters in
>> the dwc3-pci to set these? And we also have several more settings in
>> our internal tree that we need for IP validation and debugging.
>>
>> As you know the IP is highly configurable, and we do much of the
>> testing against these configurations via software settings. And our
>> validation platform is not a typical platform. Basically we have a
>> single platform, but the instantiated IP and PHY could be configured
>> in any way so it could need different values passed in for
>> testing. Like the U1/U2 exit latencies, LPM NYET threshold, HIRD,
>> USB2/3 SUSPHY, LPM sleep mode, GFLADJ, etc.
>>
>> And some things that are automatically detected we need to restrict or
>> disable to get full coverage. Such as disabling U1/U2 and LPM, maximum
>> speed, dr_mode, NUMP, RX thresholding, RX thresholding packet count.
>>
>> I know module parameters are typically frowned upon so do you
>> recommend another approach?
>
> I completely understand the situation. Module parameters are, well,
> rather unsophisticated. FPGA validation is, however, a 'peculiar' use
> case.
>
> I want to avoid module parameters as much as possible, but apart from
> module parameters, the only thing I can think of is a specific
> sub-directory on debugfs which only gets compile if EXPERT &&
> DWC3_VALIDATION_MODE or whatever.
>
> Would debugfs work for you? The only problem is for things which get
> discovered during probe()

 Yes that's the problem, otherwise I'd be fine with debugfs. Almost
 everything we need is initialized on probe. I thought of maybe
 refactoring the dwc3 code so that this doesn't have to happen on probe
 and we can trigger a "module reset" or something. But that is not
 exactly clean either.

 Regards,
 John

>>>
>>> Does it seem reasonable to add module params to the PCI driver for
>>> this use case? At least until/if there is some better solution. We can
>>> guard it with a config option if necessary.
>> 
>> module parameters are user-space ABI. Once added, we can't easily
>> remove. I've been considering if kprobes could be used to change stuff
>> like this.
>> 
>> module parameters also feel like a big, big hammer to hit a tiny nail
>> head. I don't want to add any module parameters for stuff like this. And
>> since you've been pushing for them for a while, it only shows that
>> you're only concerned about your use case ;-)
>
> Maybe so, but module params are the easiest, workable solution. It

It might be easy to implement but it becomes a pain as time
passes. I can give you a concrete example (using device properties to
illustrate):

We introduced way back a property for platform code to tell us that
$this dwc3 instance needed the driver to resize FIFOs. The only reason
for this was because OMAP5 ES1.0 had default FIFO sizes which were less
than a full bulk USB 3.0 

Re: [PATCH] usb: gadget: udc: atmel: fix endpoint name

[Nicolas Ferre]

Le 15/09/2016 à 17:07, Alexandre Belloni a écrit :
> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
> atmel_usba_udc fails with:
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
> ecm_do_notify+0x188/0x1a0
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
> Hardware name: Atmel SAMA5
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (__warn+0xe4/0xfc)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (ecm_do_notify+0x188/0x1a0)
> [] (ecm_do_notify) from [] (ecm_set_alt+0x74/0x1ac)
> [] (ecm_set_alt) from [] (composite_setup+0xfc0/0x19f8)
> [] (composite_setup) from [] (usba_udc_irq+0x8f4/0xd9c)
> [] (usba_udc_irq) from [] 
> (handle_irq_event_percpu+0x9c/0x158)
> [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x28/0x3c)
> [] (handle_irq_event) from [] 
> (handle_fasteoi_irq+0xa0/0x168)
> [] (handle_fasteoi_irq) from [] 
> (generic_handle_irq+0x24/0x34)
> [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x54/0xa8)
> [] (__handle_domain_irq) from [] (__irq_svc+0x54/0x70)
> [] (__irq_svc) from [] (arch_cpu_idle+0x38/0x3c)
> [] (arch_cpu_idle) from [] (cpu_startup_entry+0x9c/0xdc)
> [] (cpu_startup_entry) from [] (start_kernel+0x354/0x360)
> [] (start_kernel) from [<20008078>] (0x20008078)
> ---[ end trace e7cf9dcebf4815a6 ]---
> 
> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
> Reported-by: Richard Genoud 
> Signed-off-by: Alexandre Belloni 

Acked-by: Nicolas Ferre 

Felipe, Greg,
It is clearly a regression and material for 4.8-fixes. But I do know
that we are very late in the process :-(
Please do what you can to make it progress before 4.8-final but I'm
truly aware of the challenge.

Thanks to Richard for finding this and Alexandre for the quick correction.

Bye,

> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index bb1f6c8f0f01..45bc997d0711 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1978,7 +1978,7 @@ static struct usba_ep * atmel_udc_of_init(struct 
> platform_device *pdev,
>   dev_err(>dev, "of_probe: name error(%d)\n", ret);
>   goto err;
>   }
> - ep->ep.name = name;
> + ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
>  
>   ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
>   ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
> 


-- 
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: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Kishon Vijay Abraham I]

Hi,

On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman  wrote:
>> However, the problem with all of the solutions proposed (runtime PM ones
>> included) is that we're forcing a board-specific design issue (2 devices
>> sharing a reset line) into a driver that should not have any
>> board-specific assumptions in it.
>>
>> For example, if this driver is used on another platform where different
>> PHYs have different reset lines, then one of them (the unlucky one who
>> is not probed first) will never get reset.  So any form of per-device
>> ref-counting is not a portable solution.
> maybe we should also consider Ben's solution: he played with the USB
> PHY on his Meson8b board. His approach was to have only one USB PHY
> driver instance which exposes two PHYs.
> The downside of this: the driver would have to know the offset of the
> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
> the reset using runtime PM without any hacks.

I think the offset information can come from the devicetree too. The phy can be
modeled something like below.

usb-phys@c000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
reg = <0x0 0xc000 0x0 0x40>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc000 0x0 0x40>;
resets = < 34>;

usb0_phy: usb_phy@0 {
#phy-cells = <0>;
reg = <0x0 0x0 0x0 0x20>;
clocks = < CLKID_USB  CLKID_USB0>;
clock-names = "usb_general", "usb";
status = "disabled";
};

usb1_phy: usb_phy@20 {
#phy-cells = <0>;
reg = <0x0 0x20 0x0 0x20>;
clocks = < CLKID_USB  CLKID_USB1>;
clock-names = "usb_general", "usb";
status = "disabled";
};
};

This way the driver will be probed only once (the reset can be done during
probe). The phy driver should scan the dt node and for every sub-node it
invokes phy_create?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe 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 v1 2/3] usb: gadget: NCM: link socket buffers to the device for received packets

[Harish Jenny K N]

> On Thursday 15 September 2016 08:35 PM, Yauheni Kaliuta wrote:

>Is subject a bit misleading, it's more generic, then NCM?

Agreed. I will submit v2 patchset.

WBR,
Harish Jenny K N
--
To unsubscribe from this list: send the line "unsubscribe 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/4] staging: vt6655: Fix checkpatch issues

[Namrata A Shettar]

Fix multiple checkpatch issues.


Namrata A Shettar (4):
  staging: vt6655: Replace NULL comparison
  staging: vt6655: Replace NULL comparison
  staging: vt6655: Break multiple assignments
  staging: vt6655: Break multiple assignments

 drivers/staging/vt6655/card.c| 6 --
 drivers/staging/vt6655/device_main.c | 7 ---
 2 files changed, 8 insertions(+), 5 deletions(-)

-- 
2.7.4

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

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

[Pavel Machek]

On Thu 2016-09-15 15:33:19, Rafał Miłecki wrote:
> On 15 September 2016 at 14:56, Pavel Machek  wrote:
> > On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote:
> >> On 9 September 2016 at 13:05, Greg KH  wrote:
> >> > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote:
> >> >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote:
> >> >> > From: Rafał Miłecki 
> >> >> >
> >> >> > This commit adds a new trigger responsible for turning on LED when USB
> >> >> > device gets connected to the selected USB port. This can can useful 
> >> >> > for
> >> >> > various home routers that have USB port(s) and a proper LED telling 
> >> >> > user
> >> >> > a device is connected.
> >> >> >
> >> >> > The trigger gets its documentation file but basically it just requires
> >> >> > enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).
> >> >> >
> >> >> > There was a long discussion on design of this driver. Its current 
> >> >> > state
> >> >> > is a result of picking them most adjustable solution as others 
> >> >> > couldn't
> >> >> > handle all cases.
> >> >> >
> >> >> > 1) It wasn't possible for the driver to register separated trigger for
> >> >> >each USB port. Some physical USB ports are handled by more than one
> >> >> >controller and so by more than one USB port. E.g. USB 2.0 physical
> >> >> >port may be handled by OHCI's port and EHCI's port.
> >> >> >It's also not possible to assign more than 1 trigger to a single 
> >> >> > LED
> >> >> >and implementing such feature would be tricky due to syncing 
> >> >> > triggers
> >> >> >and sysfs conflicts with old triggers.
> >> >> >
> >> >> > 2) Another idea was to register trigger per USB hub. This wouldn't 
> >> >> > allow
> >> >> >handling devices with multiple USB LEDs and controllers (hubs)
> >> >> >controlling more than 1 physical port. It's common for hubs to have
> >> >> >few ports and each may have its own LED.
> >> >> >
> >> >> > This final trigger is highly flexible. It allows selecting any USB 
> >> >> > ports
> >> >> > for any LED. It was also modified (compared to the initial version) to
> >> >> > allow choosing ports rather than having user /guess/ proper names. It
> >> >> > was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
> >> >> > 2 physical ports and 3 controllers.
> >> >> >
> >> >> > Another planned feature is support for LED reacting to the USB 
> >> >> > activity.
> >> >> > This can be implemented with another sysfs file for setting mode. The
> >> >> > default mode wouldn't change so there won't be ABI breakage and such
> >> >> > feature can be safely implemented later.
> >> >> >
> >> >>
> >> >> It has such driver at: drivers/usb/common/led.c
> >> >
> >> > Ugh, I thought I had seen something like this before...
> >> >
> >> > Rafał, can you just use this in-kernel code instead?
> >>
> >> I really don't think I can because of all the reasons I carefully
> >> listed in the commit message.
> >>
> >> Have you took a look at that simple driver? It does nothing I need.
> >> Its design doesn't allow implementing features I clearly listed in the
> >> commit message.
> >
> > In any case, the new driver should probably go near the old one, at
> > the very least.
> 
> I can do that. Anyone objects?

I did not have time to study your patches in detail. IIRC there was
something like "directory full of usb IDs". I'm not sure that's a way
to go.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]

[Alan Stern]

On Fri, 16 Sep 2016, Ritesh Raj Sarraf wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello Ulf and Alan,
> 
> On Thu, 2016-09-15 at 10:16 -0400, Alan Stern wrote:
> > > ---
> > >  drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
> > > b/drivers/mmc/host/rtsx_usb_sdmmc.c
> > > index 6c71fc9..a59c7fa 100644
> > > --- a/drivers/mmc/host/rtsx_usb_sdmmc.c
> > > +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
> > > @@ -1314,6 +1314,7 @@ static void rtsx_usb_update_led(struct work_struct
> > *work)
> > > container_of(work, struct rtsx_usb_sdmmc, led_work);
> > > struct rtsx_ucr *ucr = host->ucr;
> > > 
> > > +   pm_runtime_get_sync(sdmmc_dev(host));
> > > mutex_lock(>dev_mutex);
> > > 
> > > if (host->led.brightness == LED_OFF)
> > > @@ -1322,6 +1323,7 @@ static void rtsx_usb_update_led(struct work_struct
> > *work)
> > > rtsx_usb_turn_on_led(ucr);
> > > 
> > > mutex_unlock(>dev_mutex);
> > > +   pm_runtime_put(sdmmc_dev(host));
> > >  }
> > >  #endif
> > > 
> > > -- 
> > > 
> > > Although, I doubt the above is the main reason to the issues we see.
> > 
> > I don't know -- it could well be the reason.  The symptoms are 
> > definitely what you would expect to see if some thread was doing I/O 
> > without calling the pm_runtime_* routines.

> I was able to hit it again. Please find the usbmon trace at:
> https://people.debian.org/~rrs/tmp/usb-4.8.0-rc6ulf1+.log.gz

 
We're still getting runtime suspends, but now at 2-second intervals.   
This is partly because the driver isn't calling
pm_runtime_mark_last_busy(), but there may be more to it.  The 2-second 
period is the default autosuspend timeout for USB devices.  However, I 
don't see the activity that rtsx_usb_get_card_status() should produce 
when rtsx_usb_suspend() runs; I don't know why not.

We're also getting occasional I/O attempts while the device is
suspended.  They must be on some other pathway, not the one fixed by
the patch above.  Let's see if we can find out just where they come
from.

Ritesh, please try applying this patch on top of the previous one.  It 
will produce output in the kernel log whenever these bad I/O attempts 
occur.  Also, enable dynamic debugging for the rtsx_usb driver:

echo 'module rtsx_usb =p' >/sys/kernel/debug/dynamic_debug/control

before starting the test.  (You may need to mount a debugfs filesystem 
on /sys/kernel/debug first.)

Alan Stern



Index: usb-4.x/drivers/usb/core/hcd.c
===
--- usb-4.x.orig/drivers/usb/core/hcd.c
+++ usb-4.x/drivers/usb/core/hcd.c
@@ -1647,6 +1647,8 @@ int usb_hcd_submit_urb (struct urb *urb,
status = map_urb_for_dma(hcd, urb, mem_flags);
if (likely(status == 0)) {
status = hcd->driver->urb_enqueue(hcd, urb, mem_flags);
+   if (status == -EHOSTUNREACH)
+   dump_stack();
if (unlikely(status))
unmap_urb_for_dma(hcd, urb);
}


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

[PATCH] usb: musb: fix error handling message in probe

[Arnd Bergmann]

We print an error message when platform_device_register_full()
fails, but the initialization of the argument has been removed,
as shown in this warning:

drivers/usb/musb/da8xx.c: In function 'da8xx_probe':
drivers/usb/musb/da8xx.c:521:3: error: 'ret' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

This modifies the function to assign the return code before
checking it, and does uses the same method in the check for
usb_phy_generic_register() as well.

Fixes: 947c49afe41f ("usb: musb: da8xx: Remove mach code")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/musb/da8xx.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 2358f636e48c..210b7e43a6fd 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -462,7 +462,6 @@ static int da8xx_probe(struct platform_device *pdev)
 {
struct resource musb_resources[2];
struct musb_hdrc_platform_data  *pdata = dev_get_platdata(>dev);
-   struct platform_device  *musb;
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
struct clk  *clk;
@@ -490,9 +489,10 @@ static int da8xx_probe(struct platform_device *pdev)
pdata->platform_ops = _ops;
 
glue->usb_phy = usb_phy_generic_register();
-   if (IS_ERR(glue->usb_phy)) {
+   ret = PTR_ERR_OR_ZERO(glue->usb_phy);
+   if (ret) {
dev_err(>dev, "failed to register usb_phy\n");
-   return PTR_ERR(glue->usb_phy);
+   return ret;
}
platform_set_drvdata(pdev, glue);
 
@@ -516,14 +516,14 @@ static int da8xx_probe(struct platform_device *pdev)
pinfo.data = pdata;
pinfo.size_data = sizeof(*pdata);
 
-   glue->musb = musb = platform_device_register_full();
-   if (IS_ERR(musb)) {
+   glue->musb = platform_device_register_full();
+   ret = PTR_ERR_OR_ZERO(glue->musb);
+   if (ret) {
dev_err(>dev, "failed to register musb device: %d\n", 
ret);
usb_phy_generic_unregister(glue->usb_phy);
-   return PTR_ERR(musb);
}
 
-   return 0;
+   return ret;
 }
 
 static int da8xx_remove(struct platform_device *pdev)
-- 
2.9.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: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

[Peter Chen]

On Thu, Sep 15, 2016 at 06:16:38PM -0700, Stephen Boyd wrote:
> 
> > For #3, it is not the
> > use case for this design. #3 is usually used for the single port which
> > needs to support switching role on the fly without disconnection.
> > So, you may only need to consider #2, you can't use extcon-usb-gpio.c
> > directly since you need to set one gpio to mux the dp/dm, Baolu Lu had
> > USB MUX patch set before which may satisfy your requirement. [1]
> 
> Ok. Did the usb mux patches go anywhere? It seemed to get tangled up in
> DRD framework and I haven't been following along. I'll look into these
> patches more.

DRD framework is denied by Felipe due to only one user can be benefit
from it (chipidea OTG), I don't know the further status of USB MUX,
maybe you can ask for it.

-- 

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: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

[Peter Chen]

On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> Quoting Stephen Boyd (2016-09-13 18:42:46)
> > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > board to mux the D+/D- lines from the SoC between a micro usb
> > "device" port and a USB hub for "host" roles. Upon a role switch,
> > we need to change this mux to forward the D+/D- lines to either
> > the port or the hub. Therefore, introduce a driver for this
> > device that intercepts extcon USB_HOST events and logically
> > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > attached. When the cable goes away, it will logically deassert
> > the gpio and mux the "device" lines.
> > 
> > [1] 
> > https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > 
> > Cc: MyungJoo Ham 
> > Cc: Chanwoo Choi 
> > Cc: 
> > Signed-off-by: Stephen Boyd 
> > ---
> > 
> > Should I make the extcon part optional? I could see a case where there are 
> > two
> > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > software may want to mux between them at runtime. If we mandate an extcon,
> > that won't be possible to support. Perhaps it would be better to have
> > the node, but connect it to the usb controller with a phandle (maybe 
> > of_graph
> > endpoints would be useful too) so that when the controller wants to mux over
> > a port it can do so.
> 
> Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> haven't written any code around it, but the idea is to allow the binding
> to specify how the mux is connected to upstream and downstream D+/D-
> lines. This way, we can do some dt parsing of the endpoints and their
> parent nodes to figure out if the mux needs to be set high or low to use
> a device connector or a usb hub based on if the id cable is present.
> Maybe I'm over thinking things though and we could just have a DT
> property for that.
> 
>   soc {
>   usb@78d9000 {
>   extcon = <_id>, <_id>;

Why you have two same extcon phandler? From my mind, one should id,
another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
vbus support, how you support vbus detection for
connection/disconnection with PC for your chipidea msm patch set?

>   usb-controller; // needed?

Not needed. You only need to describe controller, mux ic, and hub 
(if you need platform stuffs the driver needs to know).

Peter
> 
>   ports {
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   port@0 {
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0>;
> 
>   usb_output: endpoint@0 { // USB D+/D-
>   reg = <0>;
>   remote-endpoint = 
> <_switch_input>;
>   };
>   };
>   };
>   };
>   };
> 
>   usb2513 {
>   compatible = "smsc,usb3503";
>   reset-gpios = <_gpios 3 GPIO_ACTIVE_LOW>;
>   initial-mode = <1>;
>   usb-hub; // indicate this is a hub
> 
>   ports {
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   port@0 {
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0>;
> 
>   usb_hub_input: endpoint@0 { // USB{DP,DM}_UP
>   reg = <0>;
>   remote-endpoint = <_switch_hub_ep>;
>   };
> 
>   usb_hub_output1: endpoint@1 { // USB{DP,DM}_DN1
>   reg = <1>;
>   remote-endpoint = <_a2_connector>;
>   };
> 
>   usb_hub_output2: endpoint@2 { // USB{DP,DM}_DN2
>   reg = <2>;
>   remote-endpoint = <_a1_connector>;
>   };
> 
>   usb_hub_output3: endpoint@3 { // USB{DP,DM}_DN3
>   reg = <3>;
>   // goes to expansion connector
>   };
>   };
>   };
>   };
> 
>   usb_id: usb-id {
>   compatible = "linux,extcon-usb-gpio";
>   id-gpio = < 121 GPIO_ACTIVE_HIGH>;
>   pinctrl-names = "default";

[PATCH] usb: musb: Fix tusb6010 compile error on blackfin

[Bin Liu]

From: Tony Lindgren 

We have CONFIG_BLACKFIN ifdef redefining all musb registers in
musb_regs.h and tusb6010.h is never included causing a build
error with blackfin-allmodconfig and COMPILE_TEST.

Let's fix the issue by not building tusb6010 if CONFIG_BLACKFIN
is selected.

Reported-by: kbuild test robot 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 886526b..73cfa13 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -87,7 +87,7 @@ config USB_MUSB_DA8XX
 config USB_MUSB_TUSB6010
tristate "TUSB6010"
depends on HAS_IOMEM
-   depends on ARCH_OMAP2PLUS || COMPILE_TEST
+   depends on (ARCH_OMAP2PLUS || COMPILE_TEST) && !BLACKFIN
depends on NOP_USB_XCEIV = USB_MUSB_HDRC # both built-in or both modules
 
 config USB_MUSB_OMAP2PLUS
-- 
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: mceusb xhci issue?

[Alan Stern]

On Thu, 15 Sep 2016, Wade Berrier wrote:

> On Thu Sep 15 15:13, Alan Stern wrote:
> > On Sat, 10 Sep 2016, Wade Berrier wrote:
> > 
> > > On Thu Aug 11 16:18, Alan Stern wrote:
> > > > I never received any replies to this message.  Should the patch I 
> > > > suggested be merged?
> > > >
> > > 
> > > Hello,
> > > 
> > > I applied this updated patch to the fedora23 4.7.2 kernel and the mceusb
> > > transceiver works as expected.
> > 
> > Thank you for testing.  Can you provide the "lsusb -v" output for the
> > troublesome IR transceiver?
> > 
> 
> Here's the output:
> 
> Bus 001 Device 006: ID 1784:0006 TopSeed Technology Corp. eHome Infrared 
> Transceiver
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass0 
>   bDeviceSubClass 0 
>   bDeviceProtocol 0 
>   bMaxPacketSize0 8
>   idVendor   0x1784 TopSeed Technology Corp.
>   idProduct  0x0006 eHome Infrared Transceiver
>   bcdDevice1.02
>   iManufacturer   1 TopSeed Technology Corp.
>   iProduct2 eHome Infrared Transceiver
>   iSerial 3 TS004RrP
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   32
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0 
> bmAttributes 0xa0
>   (Bus Powered)
>   Remote Wakeup
> MaxPower  100mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass   255 Vendor Specific Class
>   bInterfaceSubClass255 Vendor Specific Subclass
>   bInterfaceProtocol255 Vendor Specific Protocol
>   iInterface  0 
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x01  EP 1 OUT
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0020  1x 32 bytes
> bInterval   0

And there's the problem.  0 is an invalid bInterval value for an 
Interrupt endpoint.

>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0020  1x 32 bytes
> bInterval   0

Here too.

> Device Status: 0x0001
>   Self Powered
> 
> Wade

Thank you.  The patch has been submitted.

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

[PATCH] musb-fixes for v4.8-rc7

[Bin Liu]

Hi Greg,

Here is one patch for musb to fix a build error reported by kbuild test robot.
If it is too late for v4.8, I think it is okay to merge it to v4.9-rc. Please
let me know if any change is needed.

Thanks,
-Bin.
---

Tony Lindgren (1):
  usb: musb: Fix tusb6010 compile error on blackfin

 drivers/usb/musb/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
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 V6] usb: core: Introduce a USB port LED trigger

[Rafał Miłecki]

From: Rafał Miłecki 

This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the selected USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.

The trigger gets its documentation file but basically it just requires
enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).

There was a long discussion on design of this driver. Its current state
is a result of picking them most adjustable solution as others couldn't
handle all cases.

1) It wasn't possible for the driver to register separated trigger for
   each USB port. Some physical USB ports are handled by more than one
   controller and so by more than one USB port. E.g. USB 2.0 physical
   port may be handled by OHCI's port and EHCI's port.
   It's also not possible to assign more than 1 trigger to a single LED
   and implementing such feature would be tricky due to syncing triggers
   and sysfs conflicts with old triggers.

2) Another idea was to register trigger per USB hub. This wouldn't allow
   handling devices with multiple USB LEDs and controllers (hubs)
   controlling more than 1 physical port. It's common for hubs to have
   few ports and each may have its own LED.

This final trigger is highly flexible. It allows selecting any USB ports
for any LED. It was also modified (comparing to the initial version) to
allow choosing ports rather than having user /guess/ proper names. It
was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
2 physical ports and 3 controllers.

It was noted USB subsystem already has usb-gadget and usb-host triggers
but they are pretty trivial ones. They indicate activity only and can't
have ports specified.

In future it may be good idea to consider adding activity support to
usbport as well. This should allow switching to this more generic driver
and maybe marking old ones as obsolete.
This can be implemented with another sysfs file for setting mode. The
default mode wouldn't change so there won't be ABI breakage and so such
feature can be safely implemented later.

There was also an idea of supporting other devices (PCI, SDIO, etc.) but
as this driver already contains some USB specific code (and will get
more) these should be probably separated drivers (triggers).

Signed-off-by: Rafał Miłecki 
---
V2: Trying to add DT support, idea postponed as it will take more time
to discuss the bindings.
V3: Fix typos in commit and Documentation (thanks Jacek!)
Use "ports" sysfs file for adding and removing USB ports (thx Jacek)
Check if there is USB device connected after adding new USB port
Fix memory leak or two
V3.5: Fix e-mail address (thanks Matthias)
  Simplify conditions in usbport_trig_notify (thx Matthias)
  Make "ports" a subdirectory with file per port, to match one value
  per file sysfs rule (thanks Greg)
  As "ports" couldn't be used for adding and removing ports anymore,
  there are now "new_port" and "remove_port". Having them makes this
  API also common with e.g. pci and usb buses.
V4: Add Documentation/ABI/testing/sysfs-class-led-trigger-usbport and
reference it in Documentation/leds/ledtrig-usbport.txt to avoid doc
duplication.
V5: Update commit message to explain driver design & Documentation
Avoid specifying ports manually and dummy files (chmod )
Don't use kobject_create_and_add but a struct attribute_group
Fix typo, improve comments, update Date
V6: Move code to USB subsystem (thx Peter and Pavel)
Rebase on top of usb-next branch
Describe relation to existing USB triggers in commit message
Switch to GPL v2 (I just prefer it after reading Linus's arguments)

Can someone from LED subsystem (Jacek? Richard?) give an Ack, if this
patch looks OK to you, please? I hope it could help Greg taking it into
usb-next.
---
 .../ABI/testing/sysfs-class-led-trigger-usbport|  12 +
 Documentation/leds/ledtrig-usbport.txt |  41 +++
 drivers/usb/core/Kconfig   |   8 +
 drivers/usb/core/Makefile  |   2 +
 drivers/usb/core/ledtrig-usbport.c | 314 +
 5 files changed, 377 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-usbport
 create mode 100644 Documentation/leds/ledtrig-usbport.txt
 create mode 100644 drivers/usb/core/ledtrig-usbport.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-usbport 
b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport
new file mode 100644
index 000..f440e69
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-usbport
@@ -0,0 +1,12 @@
+What:  /sys/class/leds//ports/
+Date:  September 2016
+KernelVersion: 4.9
+Contact:   linux-l...@vger.kernel.org
+   linux-usb@vger.kernel.org
+Description:
+   Every dir entry represents a single USB port 

Re: [PATCHv3] usb: musb: Fix unbalanced platform_disable

[Bin Liu]

Hi,

On Wed, Sep 14, 2016 at 11:10:19AM -0700, Tony Lindgren wrote:
> Commit a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling
> for 2430 glue layer") moved PHY enable/disable calls to happen from
> omap2430_musb_enable/disable(). That broke enumeration for several
> devices as PM runtime in the PHY will never enable it.
> 
> The root cause of the problem is unpaired calls from musb_core.c to
> musb_platform_enable/disable in musb_core.c as reported by
> Andreas Kemnade .
> 
> As musb_platform_enable/disable are being called from various functions,
> let's not attempt to make them paiered immediately. This would require
> fixing all the callers like musb_remove.
> 
> Instead, let's first fix the regression in a minimal way by removing
> the initial call to musb_platform_disable. To do that in a safe way,
> we need to call the glue specific *_musb_disable() directly in the
> glue layer *_musb_init() as noted by Bin Liu .
> 
> AFAIK the initial musb_platform_disable call has always been just an
> attempted workaround for the 2430 glue layer announcing itself too
> early before the gadgets are configured. And that issue finally
> got fixed with commit a118df07f5b1 ("usb: musb: Don't set d+ high
> before enable for 2430 glue layer").
> 
> Further, most of the glue layers already do a reset of the musb
> controller in the *_musb_init(), so later on we may want to
> consider removing the calls to *__musb_disable() where a reset is
> already done.
> 
> Note that we now also need to fix the twl4030-phy accordingly making
> it's PM runtime call only needed in twl4030_phy_power_on and have it
> autosuspend. The cable state will keep the phy active when connected.
> 
> Cc: Hans de Goede 
> Cc: Kishon Vijay Abraham I 
> Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling
> for 2430 glue layer")
> Reported-by: Andreas Kemnade 
> Acked-by: Andreas Kemnade 
> Reported-by: Laurent Pinchart 
> Tested-by: Laurent Pinchart 
> Acked-by: Laurent Pinchart 
> Signed-off-by: Tony Lindgren 
> ---

If Kishon wants to take it, here is my

Acked-by: Bin Liu 

Regards
-Bin.

> 
> I've kept the 2430 glue layer related acks as those parts did
> not change. For the glue layers doing things in *_musb_disable(),
> I've tested da8xx, am35x and musb_dsps glue layers.
> 
> Changes since v2:
> 
> - Added glue layer calls to *_musb_disable() from *_musb_init()
>   where needed as suggested by Bin
> 
> ---
>  drivers/phy/phy-twl4030-usb.c | 4 ++--
>  drivers/usb/musb/am35x.c  | 1 +
>  drivers/usb/musb/da8xx.c  | 1 +
>  drivers/usb/musb/davinci.c| 1 +
>  drivers/usb/musb/musb_core.c  | 1 -
>  drivers/usb/musb/musb_dsps.c  | 1 +
>  drivers/usb/musb/sunxi.c  | 3 +++
>  drivers/usb/musb/tusb6010.c   | 1 +
>  8 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
> --- a/drivers/phy/phy-twl4030-usb.c
> +++ b/drivers/phy/phy-twl4030-usb.c
> @@ -447,8 +447,6 @@ static int twl4030_phy_power_off(struct phy *phy)
>   struct twl4030_usb *twl = phy_get_drvdata(phy);
>  
>   dev_dbg(twl->dev, "%s\n", __func__);
> - pm_runtime_mark_last_busy(twl->dev);
> - pm_runtime_put_autosuspend(twl->dev);
>  
>   return 0;
>  }
> @@ -465,6 +463,8 @@ static int twl4030_phy_power_on(struct phy *phy)
>   twl4030_i2c_access(twl, 0);
>   twl->linkstat = MUSB_UNKNOWN;
>   schedule_delayed_work(>id_workaround_work, HZ);
> + pm_runtime_mark_last_busy(twl->dev);
> + pm_runtime_put_autosuspend(twl->dev);
>  
>   return 0;
>  }
> diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
> --- a/drivers/usb/musb/am35x.c
> +++ b/drivers/usb/musb/am35x.c
> @@ -381,6 +381,7 @@ static int am35x_musb_init(struct musb *musb)
>  
>   msleep(5);
>  
> + am35x_musb_disable(musb);
>   musb->isr = am35x_musb_interrupt;
>  
>   /* clear level interrupt */
> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> --- a/drivers/usb/musb/da8xx.c
> +++ b/drivers/usb/musb/da8xx.c
> @@ -440,6 +440,7 @@ static int da8xx_musb_init(struct musb *musb)
>rev, __raw_readl(CFGCHIP2),
>musb_readb(reg_base, DA8XX_USB_CTRL_REG));
>  
> + da8xx_musb_disable(musb);
>   musb->isr = da8xx_musb_interrupt;
>   return 0;
>  fail:
> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
> --- a/drivers/usb/musb/davinci.c
> +++ b/drivers/usb/musb/davinci.c
> @@ -432,6 +432,7 @@ static int davinci_musb_init(struct musb *musb)
>   revision, __raw_readl(USB_PHY_CTRL),
>   musb_readb(tibase, DAVINCI_USB_CTRL_REG));
>  
> + davinci_musb_disable(musb);
>   musb->isr = 

Re: [PATCH v4 21/22] phy: Add support for Qualcomm's USB HSIC phy

[Rob Herring]

On Wed, Sep 07, 2016 at 02:35:18PM -0700, Stephen Boyd wrote:
> The HSIC USB controller on qcom SoCs has an integrated all
> digital phy controlled via the ULPI viewport.
> 
> Cc: Kishon Vijay Abraham I 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +

Acked-by: Rob Herring 

>  drivers/phy/Kconfig|   7 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-qcom-usb-hsic.c| 160 
> +
>  4 files changed, 233 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hsic.c
--
To unsubscribe from this list: send the line "unsubscribe 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: change bInterval default to 10 ms

[Alan Stern]

Some full-speed mceusb infrared transceivers contain invalid endpoint
descriptors for their interrupt endpoints, with bInterval set to 0.
In the past they have worked out okay with the mceusb driver, because
the driver sets the bInterval field in the descriptor to 1,
overwriting whatever value may have been there before.  However, this
approach was never sanctioned by the USB core, and in fact it does not
work with xHCI controllers, because they use the bInterval value that
was present when the configuration was installed.

Currently usbcore uses 32 ms as the default interval if the value in
the endpoint descriptor is invalid.  It turns out that these IR
transceivers don't work properly unless the interval is set to 10 ms
or below.  To work around this mceusb problem, this patch changes the
endpoint-descriptor parsing routine, making the default interval value
be 10 ms rather than 32 ms.

Signed-off-by: Alan Stern 
Tested-by: Wade Berrier 
CC: 

---


[as1812]


 drivers/usb/core/config.c |   28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

Index: usb-4.x/drivers/usb/core/config.c
===
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -240,8 +240,10 @@ static int usb_parse_endpoint(struct dev
memcpy(>desc, d, n);
INIT_LIST_HEAD(>urb_list);
 
-   /* Fix up bInterval values outside the legal range. Use 32 ms if no
-* proper value can be guessed. */
+   /*
+* Fix up bInterval values outside the legal range.
+* Use 10 or 8 ms if no proper value can be guessed.
+*/
i = 0;  /* i = min, j = max, n = default */
j = 255;
if (usb_endpoint_xfer_int(d)) {
@@ -250,13 +252,15 @@ static int usb_parse_endpoint(struct dev
case USB_SPEED_SUPER_PLUS:
case USB_SPEED_SUPER:
case USB_SPEED_HIGH:
-   /* Many device manufacturers are using full-speed
+   /*
+* Many device manufacturers are using full-speed
 * bInterval values in high-speed interrupt endpoint
-* descriptors. Try to fix those and fall back to a
-* 32 ms default value otherwise. */
+* descriptors. Try to fix those and fall back to an
+* 8-ms default value otherwise.
+*/
n = fls(d->bInterval*8);
if (n == 0)
-   n = 9;  /* 32 ms = 2^(9-1) uframes */
+   n = 7;  /* 8 ms = 2^(7-1) uframes */
j = 16;
 
/*
@@ -271,10 +275,12 @@ static int usb_parse_endpoint(struct dev
}
break;
default:/* USB_SPEED_FULL or _LOW */
-   /* For low-speed, 10 ms is the official minimum.
+   /*
+* For low-speed, 10 ms is the official minimum.
 * But some "overclocked" devices might want faster
-* polling so we'll allow it. */
-   n = 32;
+* polling so we'll allow it.
+*/
+   n = 10;
break;
}
} else if (usb_endpoint_xfer_isoc(d)) {
@@ -282,10 +288,10 @@ static int usb_parse_endpoint(struct dev
j = 16;
switch (to_usb_device(ddev)->speed) {
case USB_SPEED_HIGH:
-   n = 9;  /* 32 ms = 2^(9-1) uframes */
+   n = 7;  /* 8 ms = 2^(7-1) uframes */
break;
default:/* USB_SPEED_FULL */
-   n = 6;  /* 32 ms = 2^(6-1) frames */
+   n = 4;  /* 8 ms = 2^(4-1) frames */
break;
}
}

--
To unsubscribe from this list: send the line "unsubscribe 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 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Arnd Bergmann]

On Friday, September 16, 2016 1:49:59 PM CEST Kishon Vijay Abraham I wrote:
> 
> I think the offset information can come from the devicetree too. The phy can 
> be
> modeled something like below.
> 
> usb-phys@c000 {
> compatible = "amlogic,meson-gxbb-usb2-phy";
> reg = <0x0 0xc000 0x0 0x40>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xc000 0x0 0x40>;
> resets = < 34>;
> 
> usb0_phy: usb_phy@0 {
> #phy-cells = <0>;
> reg = <0x0 0x0 0x0 0x20>;
> clocks = < CLKID_USB  CLKID_USB0>;
> clock-names = "usb_general", "usb";
> status = "disabled";
> };
> 
> usb1_phy: usb_phy@20 {
> #phy-cells = <0>;
> reg = <0x0 0x20 0x0 0x20>;
> clocks = < CLKID_USB  CLKID_USB1>;
> clock-names = "usb_general", "usb";
> status = "disabled";
> };
> };
> 
> This way the driver will be probed only once (the reset can be done during
> probe). The phy driver should scan the dt node and for every sub-node it
> invokes phy_create?

Why not just use #phy-cells=<1> and pass the phy number as an argument
in the reference?

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

Re: [PATCH v2 3/6] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Kishon Vijay Abraham I]

Hi Kevin,

On Wednesday 14 September 2016 09:36 PM, Kevin Hilman wrote:
> Kishon,
> 
> Martin Blumenstingl  writes:
> 
>> This is a new driver for the USB PHY found in Meson8b and GXBB SoCs.
>>
>> Signed-off-by: Martin Blumenstingl 
>> Signed-off-by: Jerome Brunet 
>> Tested-by: Kevin Hilman 
> 
> Will you be picking this up for v4.9?

It's already late for 4.9. Generally send pull request to Greg around -rc6.
This can go only in 4.10.

Thanks
Kishon

> 
> Kevin
> 
>> ---
>>  drivers/phy/Kconfig  |  11 ++
>>  drivers/phy/Makefile |   1 +
>>  drivers/phy/phy-meson-usb2.c | 280 
>> +++
>>  3 files changed, 292 insertions(+)
>>  create mode 100644 drivers/phy/phy-meson-usb2.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 19bff3a..6ad87ec 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -453,4 +453,15 @@ config PHY_NS2_PCIE
>>  help
>>Enable this to support the Broadcom Northstar2 PCIe PHY.
>>If unsure, say N.
>> +
>> +config PHY_MESON_USB2
>> +tristate "Meson USB2 PHY driver"
>> +default ARCH_MESON
>> +depends on OF && (ARCH_MESON || COMPILE_TEST)
>> +select GENERIC_PHY
>> +help
>> +  Enable this to support the Meson USB2 PHYs found in Meson8b
>> +  and GXBB SoCs.
>> +  If unsure, say N.
>> +
>>  endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 90ae198..dd507ac 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -56,3 +56,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB)+= 
>> phy-pistachio-usb.o
>>  obj-$(CONFIG_PHY_CYGNUS_PCIE)   += phy-bcm-cygnus-pcie.o
>>  obj-$(CONFIG_ARCH_TEGRA) += tegra/
>>  obj-$(CONFIG_PHY_NS2_PCIE)  += phy-bcm-ns2-pcie.o
>> +obj-$(CONFIG_PHY_MESON_USB2)+= phy-meson-usb2.o
>> diff --git a/drivers/phy/phy-meson-usb2.c b/drivers/phy/phy-meson-usb2.c
>> new file mode 100644
>> index 000..eece521
>> --- /dev/null
>> +++ b/drivers/phy/phy-meson-usb2.c
>> @@ -0,0 +1,280 @@
>> +/*
>> + * Meson USB2 PHY driver
>> + *
>> + * Copyright (C) 2016 Martin Blumenstingl 
>> 
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define REG_CONFIG  0x00
>> +#define REG_CONFIG_CLK_EN   BIT(0)
>> +#define REG_CONFIG_CLK_SEL_MASK GENMASK(3, 1)
>> +#define REG_CONFIG_CLK_DIV_MASK GENMASK(10, 4)
>> +#define REG_CONFIG_CLK_32k_ALTSEL   BIT(15)
>> +#define REG_CONFIG_TEST_TRIGBIT(31)
>> +
>> +#define REG_CTRL0x04
>> +#define REG_CTRL_SOFT_PRST  BIT(0)
>> +#define REG_CTRL_SOFT_HRESETBIT(1)
>> +#define REG_CTRL_SS_SCALEDOWN_MODE_MASK GENMASK(3, 2)
>> +#define REG_CTRL_CLK_DET_RSTBIT(4)
>> +#define REG_CTRL_INTR_SEL   BIT(5)
>> +#define REG_CTRL_CLK_DETECTED   BIT(8)
>> +#define REG_CTRL_SOF_SENT_RCVD_TGL  BIT(9)
>> +#define REG_CTRL_SOF_TOGGLE_OUT BIT(10)
>> +#define REG_CTRL_POWER_ON_RESET BIT(15)
>> +#define REG_CTRL_SLEEPM BIT(16)
>> +#define REG_CTRL_TX_BITSTUFF_ENN_H  BIT(17)
>> +#define REG_CTRL_TX_BITSTUFF_ENNBIT(18)
>> +#define REG_CTRL_COMMON_ON  BIT(19)
>> +#define REG_CTRL_REF_CLK_SEL_MASK   GENMASK(21, 20)
>> +#define REG_CTRL_REF_CLK_SEL_SHIFT  20
>> +#define REG_CTRL_FSEL_MASK  GENMASK(24, 22)
>> +#define REG_CTRL_FSEL_SHIFT 22
>> +#define REG_CTRL_PORT_RESET BIT(25)
>> +#define REG_CTRL_THREAD_ID_MASK GENMASK(31, 26)
>> +
>> +#define REG_ENDP_INTR   0x08
>> +
>> +/* bits [31:26], [24:21] and [15:3] seem to be read-only */
>> +#define REG_ADP_BC  0x0c
>> +#define REG_ADP_BC_VBUS_VLD_EXT_SEL BIT(0)
>> +#define REG_ADP_BC_VBUS_VLD_EXT BIT(1)
>> +#define REG_ADP_BC_OTG_DISABLE  BIT(2)
>> +#define REG_ADP_BC_ID_PULLUPBIT(3)
>> +#define REG_ADP_BC_DRV_VBUS

Gadget regression with u_ether in Linux next

[Tony Lindgren]

Hi,

Looks like commit c9ffc78745f8 ("usb: gadget: NCM: Protect dev->port_usb
using dev->lock") causes hangs for me with Linux next.

Reverting c9ffc78745f8 makes the issues go away, some more info below.

Regards,

Tony

8< 
With gadgets configured and after connecting the cable:

configfs-gadget gadget: high-speed config #1: c
configfs-gadget gadget: init ecm
configfs-gadget gadget: notify connect false
configfs-gadget gadget: reset acm ttyGS0
configfs-gadget gadget: activate acm ttyGS0
gserial_connect: start ttyGS0
configfs-gadget gadget: acm ttyGS0 serial state 0003
configfs-gadget gadget: notify speed 425984000
configfs-gadget gadget: activate ecm
usb0: qlen 10
configfs-gadget gadget: ecm_open
usb0: eth_start
configfs-gadget gadget: packet filter 0c
configfs-gadget gadget: ecm req21.43 v000c i l0
configfs-gadget gadget: acm ttyGS0 req21.20 v i0002 l7
IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
configfs-gadget gadget: packet filter 0e
configfs-gadget gadget: ecm req21.43 v000e i l0
configfs-gadget gadget: notify connect true
configfs-gadget gadget: notify speed 425984000
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
 lock: 0xdd4f7e00, .magic: dead4ead, .owner: /-1, .owner_cpu: -1
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6-next-20160915+ #608
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb0/0xe4)
[] (dump_stack) from [] (do_raw_spin_lock+0x114/0x1b8)
[] (do_raw_spin_lock) from [] 
(_raw_spin_lock_irqsave+0x40/0x4c)
[] (_raw_spin_lock_irqsave) from [] (rx_submit+0x14/0x1a0 
[u_ether])
[] (rx_submit [u_ether]) from [] 
(usb_gadget_giveback_request+0x64/0)
[] (usb_gadget_giveback_request [udc_core]) from [] 
(musb_g_giveback)
[] (musb_g_giveback [musb_hdrc]) from [] 
(musb_interrupt+0x174/0x30c)
[] (musb_interrupt [musb_hdrc]) from [] 
(omap2430_musb_interrupt+0x8)
[] (omap2430_musb_interrupt [omap2430]) from [] 
(__handle_irq_event_)
[] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x1c)
[] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x38/0x5c)
[] (handle_irq_event) from [] (handle_level_irq+0xb8/0x144)
[] (handle_level_irq) from [] (generic_handle_irq+0x20/0x34)
[] (generic_handle_irq) from [] 
(__handle_domain_irq+0x64/0xdc)
[] (__handle_domain_irq) from [] (__irq_svc+0x70/0x98)
[] (__irq_svc) from [] (cpuidle_enter_state+0xb8/0x3c4)
[] (cpuidle_enter_state) from [] 
(cpu_startup_entry+0x130/0x220)
[] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
--
To unsubscribe from this list: send the line "unsubscribe 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 problem? [was Re: Erratic USB device behavior and device loss]

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Ulf and Alan,

On Thu, 2016-09-15 at 10:16 -0400, Alan Stern wrote:
> > ---
> >  drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
> > b/drivers/mmc/host/rtsx_usb_sdmmc.c
> > index 6c71fc9..a59c7fa 100644
> > --- a/drivers/mmc/host/rtsx_usb_sdmmc.c
> > +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
> > @@ -1314,6 +1314,7 @@ static void rtsx_usb_update_led(struct work_struct
> *work)
> > container_of(work, struct rtsx_usb_sdmmc, led_work);
> > struct rtsx_ucr *ucr = host->ucr;
> > 
> > +   pm_runtime_get_sync(sdmmc_dev(host));
> > mutex_lock(>dev_mutex);
> > 
> > if (host->led.brightness == LED_OFF)
> > @@ -1322,6 +1323,7 @@ static void rtsx_usb_update_led(struct work_struct
> *work)
> > rtsx_usb_turn_on_led(ucr);
> > 
> > mutex_unlock(>dev_mutex);
> > +   pm_runtime_put(sdmmc_dev(host));
> >  }
> >  #endif
> > 
> > -- 
> > 
> > Although, I doubt the above is the main reason to the issues we see.
> 
> I don't know -- it could well be the reason.  The symptoms are 
> definitely what you would expect to see if some thread was doing I/O 
> without calling the pm_runtime_* routines.
> 
> > Instead I think somehow the parent device (usb device) isn't being
> > properly managed through runtime PM, but not due to wrong deployment
> > in the mmc core nor in the rtsx_usb_driver, but at some place else.
> > :-)
> > 
> > I started looking for calls to pm_suspend_ignore_children(dev, true),
> > which would decouple the usb device from the mmc platform device from
> > a runtime PM point of view. I found one suspicious case!
> > 
> > drivers/usb/storage/realtek_cr.c:
> > pm_suspend_ignore_children(>pusb_intf->dev, true);
> > 
> > As I am not so familiar with USB, I can't really tell why the above
> > exists, although perhaps just removing that line would be worth a
> > try!?
> 
> No, the realtek_cr driver has no connection with this.  It's a
> sub-module of the usb_storage driver; it uses the SCSI interface,
> not the MMC interface.
> 
> > If neither of the above works, the next step could be to start
> > checking error codes in the mmc core and in the rtsx_usb_sdmmc driver,
> > from the calls to pm_runtime_get|put() and pm_runtime_enable().
> 
> Let's see what this patch does.

I was able to hit it again. Please find the usbmon trace at:
https://people.debian.org/~rrs/tmp/usb-4.8.0-rc6ulf1+.log.gz


- -- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX3BLOAAoJEKY6WKPy4XVpXMgP/jTyKOX/SYCPTU9twYldY7LQ
f64hpiWqXOUs+jFYM+BcrF5B5DuXiB1Wm4F3+Xm/QBN3grJD7yBq1nrhv/mAhCr3
y1gFRIbeKfZsEp1vdBov9m1jQCZzzIZlFXPmRGT/8uC/GZTHlgIeSLqBntpq9+yL
MQSE91tLVayVgaOQxpPz+uZ4PTAom19sU21Haa90ECHLKAUTJ9WncQFecjPLHMjb
4SUvgq53V2s1Yo1E85RhtgR6Nrk/Bh7qZEC1NyeganLazGbbsz9YnRcGy58x9Jiq
xmfURTtvG834CnGcGuzcRU09FGPMtXx/u57EYC6mdEMWhSglo0h6YhVxcUOtAhRD
s1gs+a6ToKTDLn6qr0cnIwG27ALyLh41QmzxEpiaZiugIEBzZ/uK3TBjzcul4Huj
v0+x2fSC0SXwGo4P3GAOnHuWUjgj3C1wElP1R3brXfO0aayESUNKzE8V7RbQIWiC
mHewSlKTiPwCr/lchaINTt2TyFcHJWOx90iV10GO5TpMyqho4AzpBpoimItrbx2t
qQJCvGzDLPjr0tPvpeWyJSfBnqCDqbJ44CY3nCFgKhTd3BXp4fDj09eBtNmSiuvu
UdZZxm84FD3BDSNX8k2W9CF81jML/4lzwliJge3uIPrXNDqGSZMxDSpd0u1EFNHf
rEQ/kP1WlArvqButQ5ZN
=fiWV
-END PGP SIGNATURE-

--
To unsubscribe from this list: send the line "unsubscribe 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] musb: Export musb_root_disconnect for use in modules

[Greg Kroah-Hartman]

On Fri, Sep 16, 2016 at 04:59:36PM +0200, Hans de Goede wrote:
> Export musb_root_disconnect for use in modules, so that musb glue
> code build as module can use it.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/usb/musb/musb_virthub.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
> index fe08e77..61b5f1c 100644
> --- a/drivers/usb/musb/musb_virthub.c
> +++ b/drivers/usb/musb/musb_virthub.c
> @@ -245,6 +245,7 @@ void musb_root_disconnect(struct musb *musb)
>   usb_otg_state_string(musb->xceiv->otg->state));
>   }
>  }
> +EXPORT_SYMBOL_GPL(musb_root_disconnect);
>  
>  
>  /*-*/

Does this fix a build error somehow?  Who reported it?


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

Re: [PATCH] musb: Export musb_root_disconnect for use in modules

[Mark Brown]

On Fri, Sep 16, 2016 at 05:47:01PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 16, 2016 at 04:59:36PM +0200, Hans de Goede wrote:

> > +EXPORT_SYMBOL_GPL(musb_root_disconnect);

> Does this fix a build error somehow?  Who reported it?

Yes, the sunxi driver uses this symbol and the build bots reported it
yesterday.


signature.asc
Description: PGP signature

Re: [PATCH] musb: Export musb_root_disconnect for use in modules

[Greg Kroah-Hartman]

On Fri, Sep 16, 2016 at 04:53:17PM +0100, Mark Brown wrote:
> On Fri, Sep 16, 2016 at 05:47:01PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Sep 16, 2016 at 04:59:36PM +0200, Hans de Goede wrote:
> 
> > > +EXPORT_SYMBOL_GPL(musb_root_disconnect);
> 
> > Does this fix a build error somehow?  Who reported it?
> 
> Yes, the sunxi driver uses this symbol and the build bots reported it
> yesterday.

then all of that should have been in this patch :(

So much for me trying to be subtle...

--
To unsubscribe from this list: send the line "unsubscribe 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: change bInterval default to 10 ms

[Mauro Carvalho Chehab]

Em Fri, 16 Sep 2016 10:24:26 -0400 (EDT)
Alan Stern  escreveu:

> Some full-speed mceusb infrared transceivers contain invalid endpoint
> descriptors for their interrupt endpoints, with bInterval set to 0.
> In the past they have worked out okay with the mceusb driver, because
> the driver sets the bInterval field in the descriptor to 1,
> overwriting whatever value may have been there before.  However, this
> approach was never sanctioned by the USB core, and in fact it does not
> work with xHCI controllers, because they use the bInterval value that
> was present when the configuration was installed.
> 
> Currently usbcore uses 32 ms as the default interval if the value in
> the endpoint descriptor is invalid.  It turns out that these IR
> transceivers don't work properly unless the interval is set to 10 ms
> or below.  To work around this mceusb problem, this patch changes the
> endpoint-descriptor parsing routine, making the default interval value
> be 10 ms rather than 32 ms.
> 
> Signed-off-by: Alan Stern 
> Tested-by: Wade Berrier 
> CC: 

Acked-by: Mauro Carvalho Chehab 

> 
> ---
> 
> 
> [as1812]
> 
> 
>  drivers/usb/core/config.c |   28 +---
>  1 file changed, 17 insertions(+), 11 deletions(-)
> 
> Index: usb-4.x/drivers/usb/core/config.c
> ===
> --- usb-4.x.orig/drivers/usb/core/config.c
> +++ usb-4.x/drivers/usb/core/config.c
> @@ -240,8 +240,10 @@ static int usb_parse_endpoint(struct dev
>   memcpy(>desc, d, n);
>   INIT_LIST_HEAD(>urb_list);
>  
> - /* Fix up bInterval values outside the legal range. Use 32 ms if no
> -  * proper value can be guessed. */
> + /*
> +  * Fix up bInterval values outside the legal range.
> +  * Use 10 or 8 ms if no proper value can be guessed.
> +  */
>   i = 0;  /* i = min, j = max, n = default */
>   j = 255;
>   if (usb_endpoint_xfer_int(d)) {
> @@ -250,13 +252,15 @@ static int usb_parse_endpoint(struct dev
>   case USB_SPEED_SUPER_PLUS:
>   case USB_SPEED_SUPER:
>   case USB_SPEED_HIGH:
> - /* Many device manufacturers are using full-speed
> + /*
> +  * Many device manufacturers are using full-speed
>* bInterval values in high-speed interrupt endpoint
> -  * descriptors. Try to fix those and fall back to a
> -  * 32 ms default value otherwise. */
> +  * descriptors. Try to fix those and fall back to an
> +  * 8-ms default value otherwise.
> +  */
>   n = fls(d->bInterval*8);
>   if (n == 0)
> - n = 9;  /* 32 ms = 2^(9-1) uframes */
> + n = 7;  /* 8 ms = 2^(7-1) uframes */
>   j = 16;
>  
>   /*
> @@ -271,10 +275,12 @@ static int usb_parse_endpoint(struct dev
>   }
>   break;
>   default:/* USB_SPEED_FULL or _LOW */
> - /* For low-speed, 10 ms is the official minimum.
> + /*
> +  * For low-speed, 10 ms is the official minimum.
>* But some "overclocked" devices might want faster
> -  * polling so we'll allow it. */
> - n = 32;
> +  * polling so we'll allow it.
> +  */
> + n = 10;
>   break;
>   }
>   } else if (usb_endpoint_xfer_isoc(d)) {
> @@ -282,10 +288,10 @@ static int usb_parse_endpoint(struct dev
>   j = 16;
>   switch (to_usb_device(ddev)->speed) {
>   case USB_SPEED_HIGH:
> - n = 9;  /* 32 ms = 2^(9-1) uframes */
> + n = 7;  /* 8 ms = 2^(7-1) uframes */
>   break;
>   default:/* USB_SPEED_FULL */
> - n = 6;  /* 32 ms = 2^(6-1) frames */
> + n = 4;  /* 8 ms = 2^(4-1) frames */
>   break;
>   }
>   }
> 



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

[GIT PULL] USB-serial updates for v4.9-rc1

[Johan Hovold]

Hi Greg,

Here's are my updates for 4.9. All have been in linux-next for quite
some time.

Thanks,
Johan


The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:

  Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)

are available in the git repository at:

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

for you to fetch changes up to 61fc51366b395f1441c7cd3615fb18837a4fa2f8:

  USB: serial: ti_usb_3410_5052: remove unused variables (2016-08-23 10:12:19 
+0200)


USB-serial updates for v4.9-rc1

More clean ups, including a second set of changes from Mathieu as part
of a major overhaul of the ti_usb_3410_5052 driver.

Signed-off-by: Johan Hovold 


Javier Martinez Canillas (1):
  USB: serial: use IS_ENABLED() instead of checking for built-in or module

Mathieu OTHACEHE (5):
  USB: serial: ti_usb_3410_5052: do not use __uX types
  USB: serial: ti_usb_3410_5052: remove useless dev_dbg messages
  USB: serial: ti_usb_3410_5052: remove useless NULL-testing
  USB: serial: ti_usb_3410_5052: use C_X macros
  USB: serial: ti_usb_3410_5052: remove unused variables

 drivers/usb/serial/keyspan_pda.c  |   4 +-
 drivers/usb/serial/ti_usb_3410_5052.c | 171 --
 2 files changed, 60 insertions(+), 115 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

[Rob Herring]

On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> The high-speed phy on qcom SoCs is controlled via the ULPI
> viewport.
> 
> Cc: Kishon Vijay Abraham I 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>  drivers/phy/Kconfig|   8 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-qcom-usb-hs.c  | 289 
> +
>  4 files changed, 381 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> new file mode 100644
> index ..d7eacd63d06b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> @@ -0,0 +1,83 @@
> +Qualcomm's USB HS PHY
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
> of the
> +following:
> +
> +"qcom,usb-hs-phy-apq8064"
> +"qcom,usb-hs-phy-msm8916"
> +"qcom,usb-hs-phy-msm8974"

This is fine, but things are usually named -.

> +
> +- #phy-cells:
> +Usage: required
> +Value type: 
> +Definition: Should contain 0
> +
> +- clocks:
> +Usage: required
> +Value type: 
> +Definition: Should contain clock specifier for the reference and sleep
> +clocks
> +
> +- clock-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "ref" and "sleep" for the reference and sleep
> +clocks respectively
> +
> +- resets:
> +Usage: required
> +Value type: 
> +Definition: Should contain the phy and POR resets
> +
> +- reset-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain "phy" and "por" for the phy and POR resets
> +respectively
> +
> +- v3p3-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 3.3V supply
> +
> +- v1p8-supply:
> +Usage: required
> +Value type: 
> +Definition: Should contain a reference to the 1.8V supply
> +
> +- extcon:

I don't recommend using extcon binding. It needs some work to put it 
nicely.

> +Usage: optional
> +Value type: 
> +Definition: Should contain the vbus and ID extcons in the first and 
> second
> +cells respectively
> +
> +- qcom,init-seq:
> +Usage: optional
> +Value type: 
> +Definition: Should contain a sequence of ULPI register and address pairs 
> to
> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
> related
> +to Device Mode Eye Diagram test.

We generally nak this type of property. For 1 register I don't care so 
much. For 100, that would be another story.

Is this value per unit, per board, per SoC? Can you limit it to certain 
registers?

> +
> +EXAMPLE
> +
> +otg: usb-controller {
> + ulpi {
> + phy {
> + compatible = "qcom,usb-hs-phy-msm8974", 
> "qcom,usb-hs-phy";
> + #phy-cells = <0>;
> + clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
> + clock-names = "ref", "sleep";
> + resets = < GCC_USB2A_PHY_BCR>, < 0>;
> + reset-names = "phy", "por";
> + v3p3-supply = <_l24>;
> + v1p8-supply = <_l6>;
> + extcon = <>, <_id>;
> + qcom,init-seq = /bits/ 8 <0x81 0x63>;
> + };
> + };
> +};
--
To unsubscribe from this list: send the line "unsubscribe 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: [GIT PULL] USB-serial fixes for v4.8-rc7

[Greg Kroah-Hartman]

On Fri, Sep 16, 2016 at 05:03:00PM +0200, Johan Hovold wrote:
> Hi Greg,
> 
> Here's another device id for 4.8 unless you prefer holding off for 4.9.
> 
> Has been in linux-next.
> 
> Thanks,
> Johan
> 
> 
> The following changes since commit 9395452b4aab7bc2475ef8935b4a4fb99d778d70:
> 
>   Linux 4.8-rc6 (2016-09-11 20:02:25 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.8-rc7
> 
> for you to fetch changes up to f190fd92458da3e869b4e2c6289e2c617490ae53:
> 
>   USB: serial: simple: add support for another Infineon flashloader 
> (2016-09-12 10:19:41 +0200)

Pulled and pushed out, 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: [GIT PULL] USB-serial updates for v4.9-rc1

[Greg Kroah-Hartman]

On Fri, Sep 16, 2016 at 05:12:05PM +0200, Johan Hovold wrote:
> Hi Greg,
> 
> Here's are my updates for 4.9. All have been in linux-next for quite
> some time.
> 
> Thanks,
> Johan
> 
> 
> The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:
> 
>   Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.9-rc1
> 
> for you to fetch changes up to 61fc51366b395f1441c7cd3615fb18837a4fa2f8:
> 
>   USB: serial: ti_usb_3410_5052: remove unused variables (2016-08-23 10:12:19 
> +0200)
> 

Pulled and pushed out, 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: next-20160915 build: 2 failures 16 warnings (next-20160915)

[Hans de Goede]

Hi,

On 15-09-16 17:41, Mark Brown wrote:

On Thu, Sep 15, 2016 at 12:43:41PM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build both arm and arm64 allmodconfigs due to:


arm64-allmodconfig
ERROR: "musb_root_disconnect" [drivers/usb/musb/sunxi.ko] undefined!



arm-allmodconfig
ERROR: "musb_root_disconnect" [drivers/usb/musb/sunxi.ko] undefined!


due to 7cba17ec9adc8cf (musb: sunxi: Add support for platform_set_mode)
which adds a call to that non-exported function to a module.


Thank you for catching / reporting this. One patch fixing this
coming up.

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe 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] musb: Export musb_root_disconnect for use in modules

[Hans de Goede]

Export musb_root_disconnect for use in modules, so that musb glue
code build as module can use it.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/musb_virthub.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index fe08e77..61b5f1c 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -245,6 +245,7 @@ void musb_root_disconnect(struct musb *musb)
usb_otg_state_string(musb->xceiv->otg->state));
}
 }
+EXPORT_SYMBOL_GPL(musb_root_disconnect);
 
 
 /*-*/
-- 
2.9.3

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

[GIT PULL] USB-serial fixes for v4.8-rc7

[Johan Hovold]

Hi Greg,

Here's another device id for 4.8 unless you prefer holding off for 4.9.

Has been in linux-next.

Thanks,
Johan


The following changes since commit 9395452b4aab7bc2475ef8935b4a4fb99d778d70:

  Linux 4.8-rc6 (2016-09-11 20:02:25 -0700)

are available in the git repository at:

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

for you to fetch changes up to f190fd92458da3e869b4e2c6289e2c617490ae53:

  USB: serial: simple: add support for another Infineon flashloader (2016-09-12 
10:19:41 +0200)


USB-serial fixes for v4.8-rc7

Here's another Infineon flashloader device id.

Signed-off-by: Johan Hovold 


Daniele Palmas (1):
  USB: serial: simple: add support for another Infineon flashloader

 drivers/usb/serial/usb-serial-simple.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe 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: mceusb xhci issue?

[Mauro Carvalho Chehab]

Em Fri, 16 Sep 2016 10:25:31 -0400 (EDT)
Alan Stern  escreveu:

> On Thu, 15 Sep 2016, Wade Berrier wrote:
> 
> > On Thu Sep 15 15:13, Alan Stern wrote:  
> > > On Sat, 10 Sep 2016, Wade Berrier wrote:
> > >   
> > > > On Thu Aug 11 16:18, Alan Stern wrote:  
> > > > > I never received any replies to this message.  Should the patch I 
> > > > > suggested be merged?
> > > > >  
> > > > 
> > > > Hello,
> > > > 
> > > > I applied this updated patch to the fedora23 4.7.2 kernel and the mceusb
> > > > transceiver works as expected.  
> > > 
> > > Thank you for testing.  Can you provide the "lsusb -v" output for the
> > > troublesome IR transceiver?
> > >   
> > 
> > Here's the output:
> > 
> > Bus 001 Device 006: ID 1784:0006 TopSeed Technology Corp. eHome Infrared 
> > Transceiver
> > Device Descriptor:
> >   bLength18
> >   bDescriptorType 1
> >   bcdUSB   2.00
> >   bDeviceClass0 
> >   bDeviceSubClass 0 
> >   bDeviceProtocol 0 
> >   bMaxPacketSize0 8
> >   idVendor   0x1784 TopSeed Technology Corp.
> >   idProduct  0x0006 eHome Infrared Transceiver
> >   bcdDevice1.02
> >   iManufacturer   1 TopSeed Technology Corp.
> >   iProduct2 eHome Infrared Transceiver
> >   iSerial 3 TS004RrP
> >   bNumConfigurations  1
> >   Configuration Descriptor:
> > bLength 9
> > bDescriptorType 2
> > wTotalLength   32
> > bNumInterfaces  1
> > bConfigurationValue 1
> > iConfiguration  0 
> > bmAttributes 0xa0
> >   (Bus Powered)
> >   Remote Wakeup
> > MaxPower  100mA
> > Interface Descriptor:
> >   bLength 9
> >   bDescriptorType 4
> >   bInterfaceNumber0
> >   bAlternateSetting   0
> >   bNumEndpoints   2
> >   bInterfaceClass   255 Vendor Specific Class
> >   bInterfaceSubClass255 Vendor Specific Subclass
> >   bInterfaceProtocol255 Vendor Specific Protocol
> >   iInterface  0 
> >   Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x01  EP 1 OUT
> > bmAttributes3
> >   Transfer TypeInterrupt
> >   Synch Type   None
> >   Usage Type   Data
> > wMaxPacketSize 0x0020  1x 32 bytes
> > bInterval   0  
> 
> And there's the problem.  0 is an invalid bInterval value for an 
> Interrupt endpoint.

Unfortunately, it is a know issue that some mceusb drivers have the
bInterval set to zero.

> > Device Status: 0x0001
> >   Self Powered
> > 
> > Wade  
> 
> Thank you.  The patch has been submitted.

Thanks!

Mauro
--
To unsubscribe from this list: send the line "unsubscribe 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: cdc_acm bug? read buffer bytes shifted

[Julio Guerra]

> On Sat, 2016-08-20 at 14:14 +0200, Julio Guerra wrote:
 Another example:
> 00 00 00 00 00 00 00 01
 ...
> 01 00 00 00 00 00 00 00
 ...
> 00 01 00 00 00 00 00 00
 ...
> 00 00 01 00 00 00 00 00
 after a random number of times, while usbmon shows the usb payload
 "00 00 00 00 00 00 00 01".
>>>
>>> Hi, how many bytes does read() return?
>>>
>>
>> Exactly 8 bytes, always. I set the tty in raw non-canonical mode with
>> vmin = 8 and vtime = 0. I also tried with vmin = 1 and did the copy of
>> exactly 8 bytes by looping in userspace, without any improvement.
>>
>> I wrote a small workaround for now that detects this problem (because I
>> exactly know what the buffer is supposed to look like) to close() and
>> re-open() the device. The next read buffer is then correct.
>>
> 
> Please activate dynamic debugging for the tty and cdc_acm driver.
> We need to know where the corruption happens.
> 

I didn't find anything helpful in /sys/kernel/debug/dynamic_debug
regarging the tty module (I enabled tty_io debugs and it doesn't appear
in the logs), but I enabled cdc_acm debugs. Nothing is observable in the
logs when the bug appears. I logged everything as a comment of the gist:
https://gist.github.com/Julio-Guerra/b6529994f814771c825649bdb8d927c2#gistcomment-1875985

Note that re-running the script restarts the underlying kernel buffer
correctly, it does not restart from its previous bugged state.

Let me know if you want other debug traces enabled.

-- 
Julio Guerra



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/3] usb: gadget: default U1/U2 exit latencies to maximum

[John Youn]

On 9/16/2016 12:55 AM, Felipe Balbi wrote:
> 
> Hi John,
> 
> John Youn  writes:
>>> John Youn  writes:
>> John Youn  writes:
>>> On 8/31/2016 2:38 AM, Felipe Balbi wrote:
 If we don't know what are the actual U1/U2 exit
 latencies from the UDC, we're better off using
 maximum latencies as default. This should avoid
 any problems with too frequent U1/U2 entry.

 Signed-off-by: Felipe Balbi 
 ---
  include/linux/usb/gadget.h | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

 diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
 index 3667d667cab1..20cb590c658e 100644
 --- a/include/linux/usb/gadget.h
 +++ b/include/linux/usb/gadget.h
 @@ -276,11 +276,19 @@ static inline void usb_ep_fifo_flush(struct 
 usb_ep *ep)
  
  
 /*-*/
  
 +/**
 + * struct usb_dcd_config_params - Default U1/U2 exit latencies
 + * @bU1DevExitLat: U1 Exit Latency in us
 + * @bU2DevExitLat: U2 Exit Latency in us
 + *
 + * Note that we will be setting U1/U2 exit latencies to their maximum
 + * by default if no value is passed by the UDC Driver.
 + */
  struct usb_dcd_config_params {
__u8  bU1DevExitLat;/* U1 Device exit Latency */
 -#define USB_DEFAULT_U1_DEV_EXIT_LAT   0x01/* Less then 1 microsec 
 */
 +#define USB_DEFAULT_U1_DEV_EXIT_LAT   10 /* us */
__le16 wU2DevExitLat;   /* U2 Device exit Latency */
 -#define USB_DEFAULT_U2_DEV_EXIT_LAT   0x1F4   /* Less then 500 
 microsec */
 +#define USB_DEFAULT_U2_DEV_EXIT_LAT   2047 /* us */
  };
  
  

>>>
>>> Hi Felipe,
>>>
>>> Speaking of this, how would you feel about adding module parameters in
>>> the dwc3-pci to set these? And we also have several more settings in
>>> our internal tree that we need for IP validation and debugging.
>>>
>>> As you know the IP is highly configurable, and we do much of the
>>> testing against these configurations via software settings. And our
>>> validation platform is not a typical platform. Basically we have a
>>> single platform, but the instantiated IP and PHY could be configured
>>> in any way so it could need different values passed in for
>>> testing. Like the U1/U2 exit latencies, LPM NYET threshold, HIRD,
>>> USB2/3 SUSPHY, LPM sleep mode, GFLADJ, etc.
>>>
>>> And some things that are automatically detected we need to restrict or
>>> disable to get full coverage. Such as disabling U1/U2 and LPM, maximum
>>> speed, dr_mode, NUMP, RX thresholding, RX thresholding packet count.
>>>
>>> I know module parameters are typically frowned upon so do you
>>> recommend another approach?
>>
>> I completely understand the situation. Module parameters are, well,
>> rather unsophisticated. FPGA validation is, however, a 'peculiar' use
>> case.
>>
>> I want to avoid module parameters as much as possible, but apart from
>> module parameters, the only thing I can think of is a specific
>> sub-directory on debugfs which only gets compile if EXPERT &&
>> DWC3_VALIDATION_MODE or whatever.
>>
>> Would debugfs work for you? The only problem is for things which get
>> discovered during probe()
>
> Yes that's the problem, otherwise I'd be fine with debugfs. Almost
> everything we need is initialized on probe. I thought of maybe
> refactoring the dwc3 code so that this doesn't have to happen on probe
> and we can trigger a "module reset" or something. But that is not
> exactly clean either.
>
> Regards,
> John
>

 Does it seem reasonable to add module params to the PCI driver for
 this use case? At least until/if there is some better solution. We can
 guard it with a config option if necessary.
>>>
>>> module parameters are user-space ABI. Once added, we can't easily
>>> remove. I've been considering if kprobes could be used to change stuff
>>> like this.
>>>
>>> module parameters also feel like a big, big hammer to hit a tiny nail
>>> head. I don't want to add any module parameters for stuff like this. And
>>> since you've been pushing for them for a while, it only shows that
>>> you're only concerned about your use case ;-)
>>
>> Maybe so, but module params are the easiest, workable solution. It
> 
> It might be easy to implement but it becomes a pain as time
> passes. I can give you a concrete example (using device properties to
> illustrate):
> 
> We introduced way back a property for platform code to tell us that
> $this