Re: [PATCH 1/2] usb: chipidea: imx: add usb support for imx7d

[Li Jun]

On Wed, Sep 09, 2015 at 10:35:59AM +0800, Peter Chen wrote:

... ...

> >  
> > +static const struct ci_hdrc_imx_platform_flag imx7d_usb_data = {
> > +   .flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
> > +   CI_HDRC_TURN_VBUS_EARLY_ON |
> > +   CI_HDRC_DISABLE_HOST_STREAMING,
> > +};
> > +
> 
> For imx7, it uses v2.5 core, we don't need to disable stream mode
> for host.
> 
> The reason for i.mx to disable host stream mode is below issue
> (see 8022d3d51c6fb14736e26fd13caca91a38e07580)
> 
> TAR 9000378958
> Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host
> to Hang on OUT Retry
> 
> At v2.5 core, this bug has fixed by IP vendor.
> 

ok, I will remove this flag.

Li Jun
--
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 07/13] usb: otg: add OTG core

[Li Jun]

On Mon, Sep 07, 2015 at 01:53:19PM +0300, Roger Quadros wrote:
> On 07/09/15 10:40, Li Jun wrote:
> > On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> >> The OTG core instantiates the OTG Finite State Machine
> >> per OTG controller and manages starting/stopping the
> >> host and gadget controllers based on the bus state.
> >>
> >> It provides APIs for the following tasks
> >>
> >> - Registering an OTG capable controller
> >> - Registering Host and Gadget controllers to OTG core
> >> - Providing inputs to and kicking the OTG state machine
> >>
> >> Signed-off-by: Roger Quadros 
> >> ---
> >>  MAINTAINERS  |4 +-
> >>  drivers/usb/Kconfig  |2 +-
> >>  drivers/usb/Makefile |1 +
> >>  drivers/usb/common/Makefile  |3 +-
> >>  drivers/usb/common/usb-otg.c | 1061 
> >> ++
> >>  drivers/usb/common/usb-otg.h |   71 +++
> >>  drivers/usb/core/Kconfig |   11 +-
> >>  include/linux/usb/otg.h  |  189 +++-
> >>  8 files changed, 1321 insertions(+), 21 deletions(-)
> >>  create mode 100644 drivers/usb/common/usb-otg.c
> >>  create mode 100644 drivers/usb/common/usb-otg.h
> >>
> > 
> > ... ...
> > 
> >> +
> >> +/**
> >> + * Get OTG device from host or gadget device.
> >> + *
> >> + * For non device tree boot, the OTG controller is assumed to be
> >> + * the parent of the host/gadget device.
> > 
> > This assumption/restriction maybe a problem, as I pointed in your previous
> > version, usb_create_hcd() use the passed dev as its dev, but,
> > usb_add_gadget_udc() use the passed dev as its parent dev, so often the
> > host and gadget don't share the same parent device, at least it doesn't
> > apply to chipidea case.
> 
> Let's provide a way for OTG driver to provide the OTG core exactly which is
> the related host/gadget device.
> 
> > 
> >> + * For device tree boot, the OTG controller is derived from the
> >> + * "otg-controller" property.
> >> + */
> >> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
> >> +{
> >> +  struct device *otg_dev;
> >> +
> >> +  if (!hcd_gcd_dev)
> >> +  return NULL;
> >> +
> >> +  if (hcd_gcd_dev->of_node) {
> >> +  struct device_node *np;
> >> +  struct platform_device *pdev;
> >> +
> >> +  np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
> >> +0);
> >> +  if (!np)
> >> +  goto legacy;/* continue legacy way */
> >> +
> >> +  pdev = of_find_device_by_node(np);
> >> +  of_node_put(np);
> >> +  if (!pdev) {
> >> +  dev_err(>dev, "couldn't get otg-controller 
> >> device\n");
> >> +  return NULL;
> >> +  }
> >> +
> >> +  otg_dev = >dev;
> >> +  return otg_dev;
> >> +  }
> >> +
> >> +legacy:
> >> +  /* otg device is parent and must be registered */
> >> +  otg_dev = hcd_gcd_dev->parent;
> >> +  if (!usb_otg_get_data(otg_dev))
> >> +  return NULL;
> >> +
> >> +  return otg_dev;
> >> +}
> >> +
> > 
> > ... ...
> > 
> >> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
> >> +{
> >> +  struct otg_fsm *fsm = >fsm;
> >> +  unsigned long tmouts[NUM_OTG_FSM_TIMERS];
> >> +  int i;
> >> +
> >> +  /* set default timeouts */
> >> +  tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
> >> +  tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
> >> +  tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
> >> +  tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
> >> +  tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
> >> +  tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
> >> +  tmouts[B_SE0_SRP] = TB_SE0_SRP;
> >> +  tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
> >> +
> >> +  /* set controller provided timeouts */
> >> +  if (timeouts) {
> >> +  for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
> >> +  if (timeouts[i])
> >> +  tmouts[i] = timeouts[i];
> >> +  }
> >> +  }
> >> +
> >> +  otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
> >> + >a_wait_vrise_tmout);
> >> +  otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
> >> + >a_wait_vfall_tmout);
> >> +  otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
> >> + >a_wait_bcon_tmout);
> >> +  otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
> >> + >a_aidl_bdis_tmout);
> >> +  otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
> >> + >a_bidl_adis_tmout);
> >> +  otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
> >> + >b_ase0_brst_tmout);
> >> +
> >> +  otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
> >> + >b_se0_srp);
> >> +  otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
> >> + >b_srp_done);
> >> +
> >> +  /* FIXME: what about A_WAIT_ENUM? */
> > 
> > Either you init it as other timers, or you remove all of it, otherwise
> > there will be 

[PATCH v3 1/2] usb: chipidea: imx: add usb support for imx7d

[Li Jun]

From: Peter Chen 

Add imx7d usb support.

Signed-off-by: Peter Chen 
Signed-off-by: Li Jun 
---
Change for v3:
- Remove CI_HDRC_DISABLE_HOST_STREAMING and CI_HDRC_TURN_VBUS_EARLY_ON
  since they are required for i.mx7d

 drivers/usb/chipidea/ci_hdrc_imx.c |5 +++
 drivers/usb/chipidea/usbmisc_imx.c |   62 
 2 files changed, 67 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 867e9f3..c038bca 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -56,12 +56,17 @@ static const struct ci_hdrc_imx_platform_flag 
imx6sx_usb_data = {
CI_HDRC_DISABLE_HOST_STREAMING,
 };
 
+static const struct ci_hdrc_imx_platform_flag imx7d_usb_data = {
+   .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
+};
+
 static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
{ .compatible = "fsl,imx28-usb", .data = _usb_data},
{ .compatible = "fsl,imx27-usb", .data = _usb_data},
{ .compatible = "fsl,imx6q-usb", .data = _usb_data},
{ .compatible = "fsl,imx6sl-usb", .data = _usb_data},
{ .compatible = "fsl,imx6sx-usb", .data = _usb_data},
+   { .compatible = "fsl,imx7d-usb", .data = _usb_data},
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index 5ddab30..f3a4753 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -72,6 +72,14 @@
 
 #define VF610_OVER_CUR_DIS BIT(7)
 
+#define MX7D_USBNC_USB_CTRL2   0x4
+#define MX7D_USB_VBUS_WAKEUP_SOURCE_MASK   0x3
+#define MX7D_USB_VBUS_WAKEUP_SOURCE(v) (v << 0)
+#define MX7D_USB_VBUS_WAKEUP_SOURCE_VBUS   MX7D_USB_VBUS_WAKEUP_SOURCE(0)
+#define MX7D_USB_VBUS_WAKEUP_SOURCE_AVALID MX7D_USB_VBUS_WAKEUP_SOURCE(1)
+#define MX7D_USB_VBUS_WAKEUP_SOURCE_BVALID MX7D_USB_VBUS_WAKEUP_SOURCE(2)
+#define MX7D_USB_VBUS_WAKEUP_SOURCE_SESS_END   MX7D_USB_VBUS_WAKEUP_SOURCE(3)
+
 struct usbmisc_ops {
/* It's called once when probe a usb device */
int (*init)(struct imx_usbmisc_data *data);
@@ -324,6 +332,55 @@ static int usbmisc_vf610_init(struct imx_usbmisc_data 
*data)
return 0;
 }
 
+static int usbmisc_imx7d_set_wakeup
+   (struct imx_usbmisc_data *data, bool enabled)
+{
+   struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
+   unsigned long flags;
+   u32 val;
+   u32 wakeup_setting = (MX6_BM_WAKEUP_ENABLE |
+   MX6_BM_VBUS_WAKEUP | MX6_BM_ID_WAKEUP);
+
+   spin_lock_irqsave(>lock, flags);
+   val = readl(usbmisc->base);
+   if (enabled) {
+   writel(val | wakeup_setting, usbmisc->base);
+   } else {
+   if (val & MX6_BM_WAKEUP_INTR)
+   dev_dbg(data->dev, "wakeup int\n");
+   writel(val & ~wakeup_setting, usbmisc->base);
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   return 0;
+}
+
+static int usbmisc_imx7d_init(struct imx_usbmisc_data *data)
+{
+   struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
+   unsigned long flags;
+   u32 reg;
+
+   if (data->index >= 1)
+   return -EINVAL;
+
+   spin_lock_irqsave(>lock, flags);
+   if (data->disable_oc) {
+   reg = readl(usbmisc->base);
+   writel(reg | MX6_BM_OVER_CUR_DIS, usbmisc->base);
+   }
+
+   reg = readl(usbmisc->base + MX7D_USBNC_USB_CTRL2);
+   reg &= ~MX7D_USB_VBUS_WAKEUP_SOURCE_MASK;
+   writel(reg | MX7D_USB_VBUS_WAKEUP_SOURCE_BVALID,
+usbmisc->base + MX7D_USBNC_USB_CTRL2);
+   spin_unlock_irqrestore(>lock, flags);
+
+   usbmisc_imx7d_set_wakeup(data, false);
+
+   return 0;
+}
+
 static const struct usbmisc_ops imx25_usbmisc_ops = {
.init = usbmisc_imx25_init,
.post = usbmisc_imx25_post,
@@ -351,6 +408,11 @@ static const struct usbmisc_ops imx6sx_usbmisc_ops = {
.init = usbmisc_imx6sx_init,
 };
 
+static const struct usbmisc_ops imx7d_usbmisc_ops = {
+   .init = usbmisc_imx7d_init,
+   .set_wakeup = usbmisc_imx7d_set_wakeup,
+};
+
 int imx_usbmisc_init(struct imx_usbmisc_data *data)
 {
struct imx_usbmisc *usbmisc;
-- 
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 v3 2/2] usb: chipidea: imx: fix a typo for imx6sx

[Li Jun]

Use imx6sx instead of imx6sl's platform flags for imx6sx.

Signed-off-by: Li Jun 
---
 drivers/usb/chipidea/ci_hdrc_imx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index c038bca..c7f127f 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -65,7 +65,7 @@ static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
{ .compatible = "fsl,imx27-usb", .data = _usb_data},
{ .compatible = "fsl,imx6q-usb", .data = _usb_data},
{ .compatible = "fsl,imx6sl-usb", .data = _usb_data},
-   { .compatible = "fsl,imx6sx-usb", .data = _usb_data},
+   { .compatible = "fsl,imx6sx-usb", .data = _usb_data},
{ .compatible = "fsl,imx7d-usb", .data = _usb_data},
{ /* sentinel */ }
 };
-- 
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: [PATCH v1] media: uvcvideo: handle urb completion in a work queue

[Laurent Pinchart]

On Wednesday 09 September 2015 10:30:12 Hans de Goede wrote:
> On 08-09-15 16:36, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Hans de Goede wrote:
> >> On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> >>> urb completion callback is executed in host controllers interrupt
> >>> context. To keep preempt disable time short, add urbs to a list on
> >>> completion and schedule work to process the list.
> >>> 
> >>> Moreover, save timestamp and sof number in the urb completion callback
> >>> to avoid any delays.
> >> 
> >> Erm, I thought that we had already moved to using threaded interrupt
> >> handling for the urb completion a while (1-2 years ?) back. Is this then
> >> still needed ?
> > 
> > We moved to handling URB completions in a tasklet, not a threaded
> > handler.
> 
> Right.
> 
> > (Similar idea, though.)  And the change was made in only one
> > or two HCDs, not in all of them.
> 
> Ah, I was under the impression this was a core change, not a per
> hcd change.

Instead of fixing the issue in the uvcvideo driver, would it then make more 
sense to fix it in the remaining hcd drivers ?

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

Maintainer of drivers/usb/serial/mos7840.c

[mar...@franksalomon.de]

Hello All,

Please, I need to know how is the maintainer of 
drivers/usb/serial/mos7840.c for kernel version 2.6.32.


Many thanks,
Frank

--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 05:21, Peter Chen wrote:
> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>
>>
>> On 08/09/15 11:31, Peter Chen wrote:
>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
 On 07/09/15 04:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> + * This is used by the USB Host stack to register the Host controller
>> + * to the OTG core. Host controller must not be started by the
>> + * caller as it is left upto the OTG state machine to do so.
>> + *
>> + * Returns: 0 on success, error value otherwise.
>> + */
>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>> + unsigned long irqflags, struct otg_hcd_ops 
>> *ops)
>> +{
>> +struct usb_otg *otgd;
>> +struct device *hcd_dev = hcd->self.controller;
>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>> +
>
> One big problem here is: there are two designs for current (IP) driver
> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> Another one doesn't do this, roothub's parent is core device (or otg 
> device
> in your patch), like chipidea and dwc2.
>
> Then, otg_dev will be glue layer device for chipidea after that.

 OK. Let's add a way for the otg controller driver to provide the host and 
 gadget
 information to the otg core for such devices like chipidea and dwc2.

>>>
>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>> hierarchy. If the host, device, and otg share the same register
>>> region, host part can't be a platform driver since we don't want
>>> to remap the same register region again.
>>>
>>> So, in the design, we may need to consider both situations, one
>>> is otg/host/device has its own register region, and host is a
>>> separate platform device (A), the other is three parts share the
>>> same register region, there is only one platform driver (B).
>>>
>>> A:
>>>
>>> IP core device 
>>> |
>>> |
>>>   |-|-|
>>>   gadget   host platform device 
>>> |
>>> roothub
>>>
>>> B:
>>>
>>> IP core device
>>> |
>>> |
>>>   |-|-|
>>>   gadget roothub
>>> 
>>>
 This API must be called before the hcd/gadget-driver is added so that the 
 otg
 core knows it's linked to an OTG controller.

 Any better idea?

>>>
>>> A flag stands for this hcd controller is the same with otg controller
>>> can be used, this flag can be stored at struct usb_otg_config.
>>
>> What if there is another architecture like so?
>>
>> C:
>>  [Parent]
>> |
>> |
>>  |--|--|
>>  [OTG core]  [gadget][host]
>>
>> We need a more flexible mechanism to link the gadget and
>> host device to the otg core for non DT case.
>>
>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>
>> e.g.
>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>
>> If otg is NULL it will try DT otg-controller property or parent to
>> get the otg controller.
> 
> How usb_otg_register_hcd get struct usb_otg, from where?

This only works when the parent driver creating the hcd has registered the
otg controller too.

> 
>>
>>>
>>> Peter
>>>
>>> P.S: I still read your code, I find not all APIs in this file are used
>>> in your dwc3 example. 
>>
>> Which ones? The ones for registering/unregistered host/gadget are used
>> by hcd/udc core as part of usb_add/remove_hcd() and
>> udc_bind_to_driver()/usb_gadget_remove_driver()
>>
> 
> Ok, now I understand your design, usb_create_hcd must be called before
> the fsm kicks off. The call flow like below:
> 
> usb_otg_register->usb_create_hcd->usb_add_hcd->usb_otg_register_hcd->
> usb_otg_start_host->usb_otg_add_hcd

Actually these are the discrete steps
- usb_otg_register
- usb_create_hcd
- usb_add_hcd->usb_otg_register_hcd  (HCD is not really added till FSM in host 
role)

Above 3 are prerequisite for FSM to start in addition to gadget controller and
driver being ready.

When FSM enters in host role
- usb_otg_start_host(true)->usb_otg_add_hcd (Now HCD is added)

When FSM exits host role
- usb_otg_start_host(false)->usb_otg_remove_hcd (Now HCD is removed, but not 
unregistered)

If HCD hardware really goes away
- usb_remove_hcd->usb_otg_unregister_hcd (Now FSM stops as host resource not 
available)

> 
> We need to make some changes to let chipidea work since usb_create_hcd
> is included at host->start.
> 

Yes, you just need to do the usb_add_hcd() in probe
and 

Re: [PATCH v1] media: uvcvideo: handle urb completion in a work queue

[Hans de Goede]

Hi,

On 08-09-15 16:36, Alan Stern wrote:

On Tue, 8 Sep 2015, Hans de Goede wrote:


Hi,

On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:

urb completion callback is executed in host controllers interrupt
context. To keep preempt disable time short, add urbs to a list on
completion and schedule work to process the list.

Moreover, save timestamp and sof number in the urb completion callback
to avoid any delays.


Erm, I thought that we had already moved to using threaded interrupt
handling for the urb completion a while (1-2 years ?) back. Is this then
still needed ?


We moved to handling URB completions in a tasklet, not a threaded
handler.


Right.


(Similar idea, though.)  And the change was made in only one
or two HCDs, not in all of them.


Ah, I was under the impression this was a core change, not a per
hcd change.

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

Re: [Bug 103461] i.MX USB runtime power management breaks the boot

[Peter Chen]

On Mon, Aug 31, 2015 at 10:11:20AM +0200, Vincent Stehlé wrote:
> On 08/28/2015 10:29 AM, Peter Chen wrote:
> ..
> > Would you supply below:
> > 1. The u-boot.bin which you use to reproduce it
> 
> Hi Peter,
> 
> Thank you for looking into this issue.
> 
> I attached u-boot.imx to the ticket for you [1].
> 
> Due to the environment boot paths being tuned to my setup I can only
> recommend that you start from sources instead.
> 
> > 2. The application used to load u-boot.bin from pc, and related
> > script
> 
> The binaries are now attached to the ticket for your convenience [3].
> 
> I fear they will incur additional issues of setting LD_LIBRARY_PATH, due
> to absolute paths in the binaries. I therefore recommend that you start
> from the sources mentioned in the ticket, in
> comment #5 [2].
> 
> > 3. Instruction how to use the tool to reproduce the failure 
> 
> This is what I do:
> 
> 1. Edit the mx6_usb_work.conf config file.
> 2. Connect the boart debug UART and USB OTG to the PC USB.
> 3. Reset the board.
> 4. Run:
> 
>   $ sudo ./output/host/usr/bin/imx_usb
> --configdir=./output/host/etc/imx-loader.d/
> 
> (You will need to adapt the paths.)
> 
> ..
> > Would you please enable chipidea debug at kernel configuration, and
> > add 'debug' at your u-boot command line to run it again, I would
> > like to see the log if possible?
> 
> Sure. I updated the log in the ticket [4].
> 
> Sadly, it seems to make the issue only worse, as the boot is now stuck
> even earlier.
> 
> Best regards,
> 
> V.
> 
> [1] https://bugzilla.kernel.org/attachment.cgi?id=186281
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=103461#c5
> [3] https://bugzilla.kernel.org/attachment.cgi?id=186291
> [4] https://bugzilla.kernel.org/attachment.cgi?id=186271
> 
> 

Hi Vincent, sorry for late, I can't to reproduce it with your u-boot
and v4.2-rc6, and track the activities at bugzilla, let's close it
here, and go on debugging this problem at bugzilla.

-- 

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 v4 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 09:20, Li Jun wrote:
> On Mon, Sep 07, 2015 at 01:53:19PM +0300, Roger Quadros wrote:
>> On 07/09/15 10:40, Li Jun wrote:
>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
 The OTG core instantiates the OTG Finite State Machine
 per OTG controller and manages starting/stopping the
 host and gadget controllers based on the bus state.

 It provides APIs for the following tasks

 - Registering an OTG capable controller
 - Registering Host and Gadget controllers to OTG core
 - Providing inputs to and kicking the OTG state machine

 Signed-off-by: Roger Quadros 
 ---
  MAINTAINERS  |4 +-
  drivers/usb/Kconfig  |2 +-
  drivers/usb/Makefile |1 +
  drivers/usb/common/Makefile  |3 +-
  drivers/usb/common/usb-otg.c | 1061 
 ++
  drivers/usb/common/usb-otg.h |   71 +++
  drivers/usb/core/Kconfig |   11 +-
  include/linux/usb/otg.h  |  189 +++-
  8 files changed, 1321 insertions(+), 21 deletions(-)
  create mode 100644 drivers/usb/common/usb-otg.c
  create mode 100644 drivers/usb/common/usb-otg.h

>>>
>>> ... ...
>>>
 +
 +/**
 + * Get OTG device from host or gadget device.
 + *
 + * For non device tree boot, the OTG controller is assumed to be
 + * the parent of the host/gadget device.
>>>
>>> This assumption/restriction maybe a problem, as I pointed in your previous
>>> version, usb_create_hcd() use the passed dev as its dev, but,
>>> usb_add_gadget_udc() use the passed dev as its parent dev, so often the
>>> host and gadget don't share the same parent device, at least it doesn't
>>> apply to chipidea case.
>>
>> Let's provide a way for OTG driver to provide the OTG core exactly which is
>> the related host/gadget device.
>>
>>>
 + * For device tree boot, the OTG controller is derived from the
 + * "otg-controller" property.
 + */
 +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
 +{
 +  struct device *otg_dev;
 +
 +  if (!hcd_gcd_dev)
 +  return NULL;
 +
 +  if (hcd_gcd_dev->of_node) {
 +  struct device_node *np;
 +  struct platform_device *pdev;
 +
 +  np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
 +0);
 +  if (!np)
 +  goto legacy;/* continue legacy way */
 +
 +  pdev = of_find_device_by_node(np);
 +  of_node_put(np);
 +  if (!pdev) {
 +  dev_err(>dev, "couldn't get otg-controller 
 device\n");
 +  return NULL;
 +  }
 +
 +  otg_dev = >dev;
 +  return otg_dev;
 +  }
 +
 +legacy:
 +  /* otg device is parent and must be registered */
 +  otg_dev = hcd_gcd_dev->parent;
 +  if (!usb_otg_get_data(otg_dev))
 +  return NULL;
 +
 +  return otg_dev;
 +}
 +
>>>
>>> ... ...
>>>
 +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
 +{
 +  struct otg_fsm *fsm = >fsm;
 +  unsigned long tmouts[NUM_OTG_FSM_TIMERS];
 +  int i;
 +
 +  /* set default timeouts */
 +  tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
 +  tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
 +  tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
 +  tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
 +  tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
 +  tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
 +  tmouts[B_SE0_SRP] = TB_SE0_SRP;
 +  tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
 +
 +  /* set controller provided timeouts */
 +  if (timeouts) {
 +  for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
 +  if (timeouts[i])
 +  tmouts[i] = timeouts[i];
 +  }
 +  }
 +
 +  otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
 + >a_wait_vrise_tmout);
 +  otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
 + >a_wait_vfall_tmout);
 +  otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
 + >a_wait_bcon_tmout);
 +  otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
 + >a_aidl_bdis_tmout);
 +  otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
 + >a_bidl_adis_tmout);
 +  otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
 + >b_ase0_brst_tmout);
 +
 +  otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
 + >b_se0_srp);
 +  otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
 + >b_srp_done);
 +
 +  /* FIXME: what about A_WAIT_ENUM? */
>>>
>>> Either you init it as other timers, or you remove all of 

[PATCH v1 05/32] usb: dwc2: host: update hcd and lx_state during start/stop callbacks

[Mian Yousaf Kaukab]

From: Gregory Herrero 

During hcd initialization, hardware accessible flag and lx_state must
be reset to the working state since controller is powered at this stage.

Same logic applied for stop callback.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index f775529..e1cf9c0 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2308,8 +2308,9 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
dev_dbg(hsotg->dev, "DWC OTG HCD START\n");
 
spin_lock_irqsave(>lock, flags);
-
+   hsotg->lx_state = DWC2_L0;
hcd->state = HC_STATE_RUNNING;
+   set_bit(HCD_FLAG_HW_ACCESSIBLE, >flags);
 
if (dwc2_is_device_mode(hsotg)) {
spin_unlock_irqrestore(>lock, flags);
@@ -2340,6 +2341,9 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
 
spin_lock_irqsave(>lock, flags);
dwc2_hcd_stop(hsotg);
+   hsotg->lx_state = DWC2_L3;
+   hcd->state = HC_STATE_HALT;
+   clear_bit(HCD_FLAG_HW_ACCESSIBLE, >flags);
spin_unlock_irqrestore(>lock, flags);
 
usleep_range(1000, 3000);
-- 
2.3.3

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

[PATCH v1 00/32] usb: dwc2: various bug fixes

[Mian Yousaf Kaukab]

Hi,
This series consists of various bug fixes for both host and gadget
sides. All patches are verified on dwc2 v3.0a with dedicated fifos.
It would be good to get some Tested-bys for other platforms.

It is based on testing/next branch in Felipe's git and depends on [1].

Thank you,

Best regards,
Yousaf

[1] http://www.spinics.net/lists/linux-usb/msg128789.html

History:
v1:
 - Fix following comments from David Cohen (received on an internal
   list):
- Fix build when "usb: dwc2: host: create a function to handle-
  port_resume" is applied.
- Take spin locks within if statements in "usb: dwc2: host: enter-
  hibernation during bus suspend"
- Remove extra 100us delay in "usb: dwc2: host: enter-
  hibernation during bus suspend"
- Fix spelling mistakes in "usb: dwc2: host: update hcd and-
  lx_state during start/stop callbacks"
- Change dev_warn to dev_dbg in "usb: dwc2: host: reset frame-
   number after suspend"
- Change mdelay to usleep_range in "usb: dwc2: host: wait 3ms for-
  controller stabilization"
 - Fix comments from Sergei Shtylyov

Gregory Herrero (22):
  usb: dwc2: host: don't clear hprt0 status bits when exiting
hibernation
  usb: dwc2: host: create a function to handle port_resume
  usb: dwc2: host: add flag to reflect bus state
  usb: dwc2: host: enter hibernation during bus suspend
  usb: dwc2: host: update hcd and lx_state during start/stop callbacks
  usb: dwc2: host: avoid resetting lx_state to L3 during disconnect
  usb: dwc2: host: ignore wakeup interrupt if hibernation supported
  usb: dwc2: host: resume only if bus is suspended
  usb: dwc2: host: reset frame number after suspend
  usb: dwc2: host: disconnect hcd prior stopping it
  usb: dwc2: host: disable interrupt during stop
  usb: dwc2: host: clear pending interrupts prior hibernation
  usb: dwc2: host: wait 3ms for controller stabilization
  usb: dwc2: host: correctly dump urb isochronous descriptors
  usb: dwc2: host: use correct frame number during qh init
  usb: dwc2: host: kill remaining urbs using -ECONNRESET status
  usb: dwc2: gadget: ensure lx_state corresponds to current state
  usb: dwc2: gadget: don't modify pullup state in host mode
  usb: dwc2: gadget: set op_state in vbus_session call
  usb: dwc2: gadget: abort core init if core_reset fails
  usb: dwc2: gadget: unmask idstschng interrupt only if controller
supports it
  usb: dwc2: gadget: exit hibernation before power down

Mian Yousaf Kaukab (10):
  usb: dwc2: host: add disconnect interrupt to host only interrupts
  usb: dwc2: gadget: initialize op_state for peripheral only
configuration
  usb: dwc2: force dr_mode in case of configuration mismatch
  usb: dwc2: gadget: ignore stall check for ep0
  usb: dwc2: gadget: print complete setup packet
  usb: dwc2: gadget: stop current transfer on dequeue
  usb: dwc2: gadget: kill ep0 requests before reinitializing core
  usb: dwc2: gadget: only reset core after addressed state
  usb: dwc2: gadget: handle reset interrupt before endpoint interrupts
  usb: dwc2: exit hibernation on session request

 drivers/usb/dwc2/core.c  |  14 ++-
 drivers/usb/dwc2/core.h  |   3 +-
 drivers/usb/dwc2/core_intr.c |  29 --
 drivers/usb/dwc2/gadget.c| 213 ++-
 drivers/usb/dwc2/hcd.c   | 190 +-
 drivers/usb/dwc2/hcd_queue.c |  11 +++
 drivers/usb/dwc2/platform.c  |  11 +++
 7 files changed, 373 insertions(+), 98 deletions(-)

-- 
2.3.3

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

[PATCH v1 02/32] usb: dwc2: host: create a function to handle port_resume

[Mian Yousaf Kaukab]

From: Gregory Herrero 

port resume sequence may be used in different places. Create a
function to handle it. Moreover, make hprt0 read-modify-write atomic.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 007a3d5..0cef770 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1484,6 +1484,27 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, 
u16 windex)
}
 }
 
+/* Must NOT be called with interrupt disabled or spinlock held */
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
+{
+   unsigned long flags;
+   u32 hprt0;
+
+   spin_lock_irqsave(>lock, flags);
+   hprt0 = dwc2_read_hprt0(hsotg);
+   hprt0 |= HPRT0_RES;
+   hprt0 &= ~HPRT0_SUSP;
+   writel(hprt0, hsotg->regs + HPRT0);
+   spin_unlock_irqrestore(>lock, flags);
+
+   msleep(USB_RESUME_TIMEOUT);
+
+   spin_lock_irqsave(>lock, flags);
+   hprt0 &= ~HPRT0_RES;
+   writel(hprt0, hsotg->regs + HPRT0);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 /* Handles hub class-specific requests */
 static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
u16 wvalue, u16 windex, char *buf, u16 wlength)
@@ -1532,14 +1553,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg 
*hsotg, u16 typereq,
writel(0, hsotg->regs + PCGCTL);
usleep_range(2, 4);
 
-   hprt0 = dwc2_read_hprt0(hsotg);
-   hprt0 |= HPRT0_RES;
-   writel(hprt0, hsotg->regs + HPRT0);
-   hprt0 &= ~HPRT0_SUSP;
-   msleep(USB_RESUME_TIMEOUT);
-
-   hprt0 &= ~HPRT0_RES;
-   writel(hprt0, hsotg->regs + HPRT0);
+   dwc2_port_resume(hsotg);
break;
 
case USB_PORT_FEAT_POWER:
-- 
2.3.3

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

[PATCH v1 03/32] usb: dwc2: host: add flag to reflect bus state

[Mian Yousaf Kaukab]

From: Gregory Herrero 

lx_state must be used to reflect controller power state only and not
bus state. Thus add a flag to track state during bus suspend.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core.h | 1 +
 drivers/usb/dwc2/hcd.c  | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9655b1e..b1e3364 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -703,6 +703,7 @@ struct dwc2_hsotg {
 
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
+   unsigned int bus_suspended:1;
 
struct workqueue_struct *wq_otg;
struct work_struct wf_otg;
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 0cef770..997f15e 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1425,6 +1425,7 @@ static void dwc2_wakeup_detected(unsigned long data)
dev_dbg(hsotg->dev, "Clear Resume: HPRT0=%0x\n",
readl(hsotg->regs + HPRT0));
 
+   hsotg->bus_suspended = 0;
dwc2_hcd_rem_wakeup(hsotg);
 
/* Change to L0 state */
@@ -1462,7 +1463,7 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, 
u16 windex)
writel(hprt0, hsotg->regs + HPRT0);
 
/* Update lx_state */
-   hsotg->lx_state = DWC2_L2;
+   hsotg->bus_suspended = 1;
 
/* Suspend the Phy Clock */
pcgctl = readl(hsotg->regs + PCGCTL);
@@ -1502,6 +1503,7 @@ static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
spin_lock_irqsave(>lock, flags);
hprt0 &= ~HPRT0_RES;
writel(hprt0, hsotg->regs + HPRT0);
+   hsotg->bus_suspended = 0;
spin_unlock_irqrestore(>lock, flags);
 }
 
-- 
2.3.3

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

[PATCH v1 01/32] usb: dwc2: host: don't clear hprt0 status bits when exiting hibernation

[Mian Yousaf Kaukab]

From: Gregory Herrero 

When entering hibernation hprt0 must be read using dwc2_read_hprt0().
Otherwise, any set hprt0 status bits will be cleared when restoring
hprt0 on exit from hibernation.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index b00fe95..1e67549 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -78,7 +78,7 @@ static int dwc2_backup_host_registers(struct dwc2_hsotg 
*hsotg)
for (i = 0; i < hsotg->core_params->host_channels; ++i)
hr->hcintmsk[i] = readl(hsotg->regs + HCINTMSK(i));
 
-   hr->hprt0 = readl(hsotg->regs + HPRT0);
+   hr->hprt0 = dwc2_read_hprt0(hsotg);
hr->hfir = readl(hsotg->regs + HFIR);
hr->valid = true;
 
-- 
2.3.3

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

[PATCH v1 04/32] usb: dwc2: host: enter hibernation during bus suspend

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Disable controller power and enter hibernation when usb bus is
suspended. A phy driver is required to disable the power of the
controller and detect remote-wakeup or disconnection since the
controller will not be able to detect these in this state.

Once the phy driver detects bus activity, it must call
usb_hcd_resume_root_hub.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 125 ++---
 1 file changed, 118 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 997f15e..f775529 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1465,11 +1465,17 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, 
u16 windex)
/* Update lx_state */
hsotg->bus_suspended = 1;
 
-   /* Suspend the Phy Clock */
-   pcgctl = readl(hsotg->regs + PCGCTL);
-   pcgctl |= PCGCTL_STOPPCLK;
-   writel(pcgctl, hsotg->regs + PCGCTL);
-   udelay(10);
+   /*
+* If hibernation is supported, Phy clock will be suspended
+* after registers are backuped.
+*/
+   if (!hsotg->core_params->hibernation) {
+   /* Suspend the Phy Clock */
+   pcgctl = readl(hsotg->regs + PCGCTL);
+   pcgctl |= PCGCTL_STOPPCLK;
+   writel(pcgctl, hsotg->regs + PCGCTL);
+   udelay(10);
+   }
 
/* For HNP the bus must be suspended for at least 200ms */
if (dwc2_host_is_b_hnp_enabled(hsotg)) {
@@ -2342,17 +2348,122 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
 static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
 {
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+   unsigned long flags;
+   int ret = 0;
+   u32 hprt0;
+
+   spin_lock_irqsave(>lock, flags);
+
+   if (hsotg->lx_state != DWC2_L0)
+   goto unlock;
+
+   if (!HCD_HW_ACCESSIBLE(hcd))
+   goto unlock;
+
+   if (!hsotg->core_params->hibernation)
+   goto skip_power_saving;
+
+   /*
+* Drive USB suspend and disable port Power
+* if usb bus is not suspended.
+*/
+   if (!hsotg->bus_suspended) {
+   hprt0 = dwc2_read_hprt0(hsotg);
+   hprt0 |= HPRT0_SUSP;
+   hprt0 &= ~HPRT0_PWR;
+   writel(hprt0, hsotg->regs + HPRT0);
+   }
+
+   /* Enter hibernation */
+   ret = dwc2_enter_hibernation(hsotg);
+   if (ret) {
+   if (ret != -ENOTSUPP)
+   dev_err(hsotg->dev,
+   "enter hibernation failed\n");
+   goto skip_power_saving;
+   }
 
+   /* Ask phy to be suspended */
+   if (!IS_ERR_OR_NULL(hsotg->uphy)) {
+   spin_unlock_irqrestore(>lock, flags);
+   usb_phy_set_suspend(hsotg->uphy, true);
+   spin_lock_irqsave(>lock, flags);
+   }
+
+   /* After entering hibernation, hardware is no more accessible */
+   clear_bit(HCD_FLAG_HW_ACCESSIBLE, >flags);
+
+skip_power_saving:
hsotg->lx_state = DWC2_L2;
-   return 0;
+unlock:
+   spin_unlock_irqrestore(>lock, flags);
+
+   return ret;
 }
 
 static int _dwc2_hcd_resume(struct usb_hcd *hcd)
 {
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+   unsigned long flags;
+   int ret = 0;
+
+   spin_lock_irqsave(>lock, flags);
+
+   if (hsotg->lx_state != DWC2_L2)
+   goto unlock;
+
+   if (!hsotg->core_params->hibernation) {
+   hsotg->lx_state = DWC2_L0;
+   goto unlock;
+   }
+
+   /*
+* Set HW accessible bit before powering on the controller
+* since an interrupt may rise.
+*/
+   set_bit(HCD_FLAG_HW_ACCESSIBLE, >flags);
+
+   /*
+* Enable power if not already done.
+* This must not be spinlocked since duration
+* of this call is unknown.
+*/
+   if (!IS_ERR_OR_NULL(hsotg->uphy)) {
+   spin_unlock_irqrestore(>lock, flags);
+   usb_phy_set_suspend(hsotg->uphy, false);
+   spin_lock_irqsave(>lock, flags);
+   }
+
+   /* Exit hibernation */
+   ret = dwc2_exit_hibernation(hsotg, true);
+   if (ret && (ret != -ENOTSUPP))
+   dev_err(hsotg->dev, "exit hibernation failed\n");
 
hsotg->lx_state = DWC2_L0;
-   return 0;
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (hsotg->bus_suspended) {
+   spin_lock_irqsave(>lock, flags);
+   hsotg->flags.b.port_suspend_change = 1;
+   spin_unlock_irqrestore(>lock, flags);
+   dwc2_port_resume(hsotg);
+   } else {
+   /*
+* Clear Port Enable and Port Status changes.
+   

Re: [PATCH v4 0/22] On-demand device probing

[Tomeu Vizoso]

On 9 September 2015 at 03:33, Rob Herring  wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring  wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso  
>>> wrote:
 Hello,

 I have a problem with the panel on my Tegra Chromebook taking longer
 than expected to be ready during boot (Stéphane Marchesin reported what
 is basically the same issue in [0]), and have looked into ordered
 probing as a better way of solving this than moving nodes around in the
 DT or playing with initcall levels and linking order.

 While reading the thread [1] that Alexander Holler started with his
 series to make probing order deterministic, it occurred to me that it
 should be possible to achieve the same by probing devices as they are
 referenced by other devices.

 This basically reuses the information that is already implicit in the
 probe() implementations, saving us from refactoring existing drivers or
 adding information to DTBs.

 During review of v1 of this series Linus Walleij suggested that it
 should be the device driver core to make sure that dependencies are
 ready before probing a device. I gave this idea a try [2] but Mark Brown
 pointed out to the logic duplication between the resource acquisition
 and dependency discovery code paths (though I think it's fairly minor).

 To address that code duplication I experimented with Arnd's devm_probe
 [3] concept of having drivers declare their dependencies instead of
 acquiring them during probe, and while it worked [4], I don't think we
 end up winning anything when compared to just probing devices on-demand
 from resource getters.

 One remaining objection is to the "sprinkling" of calls to
 of_device_probe() in the resource getters of each subsystem, but I think
 it's the right thing to do given that the storage of resources is
 currently subsystem-specific.

 We could avoid the above by moving resource storage into the core, but I
 don't think there's a compelling case for that.

 I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
 OMAP SoCs, and these patches were enough to eliminate all the deferred
 probes (except one in PandaBoard because omap_dma_system doesn't have a
 firmware node as of yet).

 Have submitted a branch [5] with only these patches on top of thursday's
 linux-next to kernelci.org and I don't see any issues that could be
 caused by them. For some reason it currently has more passes than the
 version of -next it's based on!

 With this series I get the kernel to output to the panel in 0.5s,
 instead of 2.8s.

 Regards,

 Tomeu

 [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

 [1] https://lkml.org/lkml/2014/5/12/452

 [2] https://lkml.org/lkml/2015/6/17/305

 [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

 [4] https://lkml.org/lkml/2015/7/21/441a

 [5] 
 https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6

 [6] 
 http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/

 [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/

 Changes in v4:
 - Added bus.pre_probe callback so the probes of Primecell devices can be
   deferred if their device IDs cannot be yet read because of the clock
   driver not having probed when they are registered. Maybe this goes
   overboard and the matching information should be in the DT if there is
   one.
>>>
>>> Seems overboard to me or at least a separate problem.
>>
>> It's a separate problem but this was preventing the series from
>> working on a few boards.
>
> What is the failure? Not booting? Fixing not working would certainly not
> be overboard.

On the device I was testing on (qemu's vexpress-a15 machine) the
machine booted and I was able to open a ssh session, but serial was
broken among other AMBA devices:

/memory-controller@2b0a
/memory-controller@7ffd
/dma@7ffb
/smb/motherboard/iofpga@3,/sysctl@02
/smb/motherboard/iofpga@3,/aaci@04
/smb/motherboard/iofpga@3,/mmci@05
/smb/motherboard/iofpga@3,/kmi@06
/smb/motherboard/iofpga@3,/kmi@07
/smb/motherboard/iofpga@3,/uart@09
/smb/motherboard/iofpga@3,/uart@0a
/smb/motherboard/iofpga@3,/uart@0b
/smb/motherboard/iofpga@3,/uart@0c
/smb/motherboard/iofpga@3,/wdt@0f
/smb/motherboard/iofpga@3,/timer@11
/smb/motherboard/iofpga@3,/timer@12
/smb/motherboard/iofpga@3,/rtc@17
/smb/motherboard/iofpga@3,/clcd@1f

Another way of avoiding this particular problem 

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 11:45, Peter Chen wrote:
> On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
>> On 09/09/15 11:13, Peter Chen wrote:
>>> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
 On 09/09/15 05:21, Peter Chen wrote:
> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>
>>
>> On 08/09/15 11:31, Peter Chen wrote:
>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
 On 07/09/15 04:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> + * This is used by the USB Host stack to register the Host 
>> controller
>> + * to the OTG core. Host controller must not be started by the
>> + * caller as it is left upto the OTG state machine to do so.
>> + *
>> + * Returns: 0 on success, error value otherwise.
>> + */
>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>> + unsigned long irqflags, struct otg_hcd_ops 
>> *ops)
>> +{
>> +struct usb_otg *otgd;
>> +struct device *hcd_dev = hcd->self.controller;
>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>> +
>
> One big problem here is: there are two designs for current (IP) driver
> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> Another one doesn't do this, roothub's parent is core device (or otg 
> device
> in your patch), like chipidea and dwc2.
>
> Then, otg_dev will be glue layer device for chipidea after that.

 OK. Let's add a way for the otg controller driver to provide the host 
 and gadget
 information to the otg core for such devices like chipidea and dwc2.

>>>
>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>> hierarchy. If the host, device, and otg share the same register
>>> region, host part can't be a platform driver since we don't want
>>> to remap the same register region again.
>>>
>>> So, in the design, we may need to consider both situations, one
>>> is otg/host/device has its own register region, and host is a
>>> separate platform device (A), the other is three parts share the
>>> same register region, there is only one platform driver (B).
>>>
>>> A:
>>>
>>> IP core device 
>>> |
>>> |
>>>   |-|-|
>>>   gadget   host platform device 
>>> |
>>> roothub
>>>
>>> B:
>>>
>>> IP core device
>>> |
>>> |
>>>   |-|-|
>>>   gadget roothub
>>> 
>>>
 This API must be called before the hcd/gadget-driver is added so that 
 the otg
 core knows it's linked to an OTG controller.

 Any better idea?

>>>
>>> A flag stands for this hcd controller is the same with otg controller
>>> can be used, this flag can be stored at struct usb_otg_config.
>>
>> What if there is another architecture like so?
>>
>> C:
>>  [Parent]
>> |
>> |
>>  |--|--|
>>  [OTG core]  [gadget][host]
>>
>> We need a more flexible mechanism to link the gadget and
>> host device to the otg core for non DT case.
>>
>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>
>> e.g.
>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>
>> If otg is NULL it will try DT otg-controller property or parent to
>> get the otg controller.
>
> How usb_otg_register_hcd get struct usb_otg, from where?

 This only works when the parent driver creating the hcd has registered the
 otg controller too.

>>>
>>> Sorry? So we need to find another way to solve this issue, right?
>>
>> For existing cases this is sufficient.
>> The otg device is either the one supplied during usb_otg_register_hcd
>> (cases B and C) or it is the parent device (case A).
> 
> How we differentiate case A and case B at usb_otg_register_hcd?
> Would you show me the sample code?

Case A:

hcd platform driver doesn't know about otg device so it calls

usb_add_hcd(hcd,..)->usb_otg_register_hcd(NULL, hcd,..);

Case B:

core driver knows about both otg and hcd so it calls
usb_otg_register_hcd(otg, hcd,...);

code:

usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ...)
{
if 

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Roger Quadros]

(adding back folks in cc)

On 08/09/15 20:35, Alan Stern wrote:
> On Tue, 8 Sep 2015, Roger Quadros wrote:
> 
 What if there is another architecture like so?

 C:
[Parent]
   |
   |
|--|--|
[OTG core]  [gadget][host]

 We need a more flexible mechanism to link the gadget and
 host device to the otg core for non DT case.

 How about adding struct usb_otg parameter to usb_otg_register_hcd()?

 e.g.
 int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)

 If otg is NULL it will try DT otg-controller property or parent to
 get the otg controller.
>>>
>>> This seems a lot like something Peter and I discussed recently.  See
>>>
>>> http://marc.info/?l=linux-usb=143977568021328=2
>>>
>>> and the following messages in that thread.
>>>
>>
>> If I understood right, your proposal was to add a usb_pointers data
>> struct to the device's drvdata?
> 
> Right.
> 
>> This is fine only if the otg/gadget/host share the same device.
>> It does not solve the problem where each have different platform devices.
> 
> Why not?  Each of the platform devices can store a pointer to the same 
> usb_pointers structure.  Wouldn't that be suitable?
> 

I didn't understand how all of them get the reference to the
same usb_pointer structure (or contents) when their respective platform devices
get created so that they can store it in their respective drvdata.

Worst case, the 3 devices could be totally independent of each other without a
common parent, and get registered at different times.

The common resource here is the physical USB port for which the 3 drivers
otg/host/gadget are being registered.
There should be a mechanism for each device to tell that it is part of
this particular USB port. (or usb_pointers struct)

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

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Peter Chen]

On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
> On 09/09/15 11:13, Peter Chen wrote:
> > On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
> >> On 09/09/15 05:21, Peter Chen wrote:
> >>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> 
> 
>  On 08/09/15 11:31, Peter Chen wrote:
> > On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
> >> On 07/09/15 04:23, Peter Chen wrote:
> >>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>  + * This is used by the USB Host stack to register the Host 
>  controller
>  + * to the OTG core. Host controller must not be started by the
>  + * caller as it is left upto the OTG state machine to do so.
>  + *
>  + * Returns: 0 on success, error value otherwise.
>  + */
>  +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>  + unsigned long irqflags, struct otg_hcd_ops 
>  *ops)
>  +{
>  +struct usb_otg *otgd;
>  +struct device *hcd_dev = hcd->self.controller;
>  +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>  +
> >>>
> >>> One big problem here is: there are two designs for current (IP) driver
> >>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> >>> Another one doesn't do this, roothub's parent is core device (or otg 
> >>> device
> >>> in your patch), like chipidea and dwc2.
> >>>
> >>> Then, otg_dev will be glue layer device for chipidea after that.
> >>
> >> OK. Let's add a way for the otg controller driver to provide the host 
> >> and gadget
> >> information to the otg core for such devices like chipidea and dwc2.
> >>
> >
> > Roger, not only chipidea and dwc2, I think the musb uses the same
> > hierarchy. If the host, device, and otg share the same register
> > region, host part can't be a platform driver since we don't want
> > to remap the same register region again.
> >
> > So, in the design, we may need to consider both situations, one
> > is otg/host/device has its own register region, and host is a
> > separate platform device (A), the other is three parts share the
> > same register region, there is only one platform driver (B).
> >
> > A:
> >
> > IP core device 
> > |
> > |
> >   |-|-|
> >   gadget   host platform device 
> > |
> > roothub
> >
> > B:
> >
> > IP core device
> > |
> > |
> >   |-|-|
> >   gadget roothub
> > 
> >
> >> This API must be called before the hcd/gadget-driver is added so that 
> >> the otg
> >> core knows it's linked to an OTG controller.
> >>
> >> Any better idea?
> >>
> >
> > A flag stands for this hcd controller is the same with otg controller
> > can be used, this flag can be stored at struct usb_otg_config.
> 
>  What if there is another architecture like so?
> 
>  C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
>  We need a more flexible mechanism to link the gadget and
>  host device to the otg core for non DT case.
> 
>  How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
>  e.g.
>  int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> 
>  If otg is NULL it will try DT otg-controller property or parent to
>  get the otg controller.
> >>>
> >>> How usb_otg_register_hcd get struct usb_otg, from where?
> >>
> >> This only works when the parent driver creating the hcd has registered the
> >> otg controller too.
> >>
> > 
> > Sorry? So we need to find another way to solve this issue, right?
> 
> For existing cases this is sufficient.
> The otg device is either the one supplied during usb_otg_register_hcd
> (cases B and C) or it is the parent device (case A).

How we differentiate case A and case B at usb_otg_register_hcd?
Would you show me the sample code?

> 
> It does not work when the 3 devices are totally independent and get registered
> at different times.
> I don't think there is such a case for non-DT yet, but let's not have this
> limitation. So yes, we need to look for better solution :).
> 

Yes, we need to find some places to store gadget/host/otg information,
Alan's suggestion to save them at device drvdata may be a 

[PATCH v1 21/32] usb: dwc2: gadget: don't modify pullup state in host mode

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Modifying the pullup state during host mode trig a new enumeration
of attached device. Thus, avoid modifying pullup in host mode.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6a5b611..a50962e 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3170,7 +3170,14 @@ static int dwc2_hsotg_pullup(struct usb_gadget *gadget, 
int is_on)
struct dwc2_hsotg *hsotg = to_hsotg(gadget);
unsigned long flags = 0;
 
-   dev_dbg(hsotg->dev, "%s: is_on: %d\n", __func__, is_on);
+   dev_dbg(hsotg->dev, "%s: is_on: %d op_state: %d\n", __func__, is_on,
+   hsotg->op_state);
+
+   /* Don't modify pullup state while in host mode */
+   if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
+   hsotg->enabled = is_on;
+   return 0;
+   }
 
mutex_lock(>init_mutex);
spin_lock_irqsave(>lock, flags);
-- 
2.3.3

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

[PATCH v1 14/32] usb: dwc2: host: wait 3ms for controller stabilization

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Some high speed mass storage devices fail to enumerate with following
error:

Cannot enable port %i.  Maybe the USB cable is bad?

This happens only when the device is plugged while the controller
is in hibernation state. After exiting hibernation, the controller
detects the device as a low speed device and fail to enumerate it.

Problem occurs only if HPRT0.PWR bit is programmed in a too short
delay after exiting hibernation. Dumping hprt register in
_dwc2_hcd_resume() directly after dwc2_exit_hibernation() shows that
HPRT0.LNSTS (D+/D- level) becomes valid approximately 2ms after
exiting hibernation.

Since dwc2_exit_hibernation() is called from atomic context, move the
delay out of this function.

Delay value is experimental and not mentioned in Synopsys
documentation. To be on the safe side 3ms delay is used.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 9c44c65..e263139 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2462,6 +2462,9 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
spin_unlock_irqrestore(>lock, flags);
dwc2_port_resume(hsotg);
} else {
+   /* Wait for controller to correctly update D+/D- level */
+   usleep_range(3000, 5000);
+
/*
 * Clear Port Enable and Port Status changes.
 * Enable Port Power.
@@ -2469,7 +2472,7 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
writel(HPRT0_PWR | HPRT0_CONNDET |
HPRT0_ENACHG, hsotg->regs + HPRT0);
/* Wait for controller to detect Port Connect */
-   mdelay(5);
+   usleep_range(5000, 7000);
}
 
return ret;
-- 
2.3.3

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

[PATCH v1 19/32] usb: dwc2: gadget: initialize op_state for peripheral only configuration

[Mian Yousaf Kaukab]

ID status change interrupt will not be handled in peripheral only
configuration. So initialize op_state during gadget init.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d1a2656..6a5b611 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3535,6 +3535,8 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
hsotg->gadget.name = dev_name(dev);
if (hsotg->dr_mode == USB_DR_MODE_OTG)
hsotg->gadget.is_otg = 1;
+   else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL)
+   hsotg->op_state = OTG_STATE_B_PERIPHERAL;
 
/* reset the system */
 
-- 
2.3.3

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

[PATCH v1 15/32] usb: dwc2: host: correctly dump urb isochronous descriptors

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Print urb->iso_frame_desc.status after it has been updated using
dwc2_hcd_urb_get_iso_desc_status().

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index e263139..20b81cf 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2217,11 +2217,6 @@ void dwc2_host_complete(struct dwc2_hsotg *hsotg, struct 
dwc2_qtd *qtd,
 usb_pipein(urb->pipe) ? "IN" : "OUT", status,
 urb->actual_length);
 
-   if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS && dbg_perio()) {
-   for (i = 0; i < urb->number_of_packets; i++)
-   dev_vdbg(hsotg->dev, " ISO Desc %d status %d\n",
-i, urb->iso_frame_desc[i].status);
-   }
 
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS) {
urb->error_count = dwc2_hcd_urb_get_error_count(qtd->urb);
@@ -2234,6 +2229,12 @@ void dwc2_host_complete(struct dwc2_hsotg *hsotg, struct 
dwc2_qtd *qtd,
}
}
 
+   if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS && dbg_perio()) {
+   for (i = 0; i < urb->number_of_packets; i++)
+   dev_vdbg(hsotg->dev, " ISO Desc %d status %d\n",
+i, urb->iso_frame_desc[i].status);
+   }
+
urb->status = status;
if (!status) {
if ((urb->transfer_flags & URB_SHORT_NOT_OK) &&
-- 
2.3.3

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

[PATCH v1 16/32] usb: dwc2: host: use correct frame number during qh init

[Mian Yousaf Kaukab]

From: Gregory Herrero 

On first qh initialization, hsotg->frame_number is not corresponding
to reality. So read it from host controller to get correct value.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd_queue.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index a821f19..77e4ae0 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -106,6 +106,9 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh,
USB_SPEED_HIGH : dev_speed, qh->ep_is_in,
qh->ep_type == USB_ENDPOINT_XFER_ISOC,
bytecount));
+
+   /* Ensure frame_number corresponds to the reality */
+   hsotg->frame_number = dwc2_hcd_get_frame_number(hsotg);
/* Start in a slightly future (micro)frame */
qh->sched_frame = dwc2_frame_num_inc(hsotg->frame_number,
 SCHEDULE_SLOP);
-- 
2.3.3

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

[PATCH v1 17/32] usb: dwc2: host: kill remaining urbs using -ECONNRESET status

[Mian Yousaf Kaukab]

From: Gregory Herrero 

On a disconnect, dwc2 will kill all remaining urbs from qh list.
urbs are given back to hcd with -ETIMEDOUT status.
Some usb device driver, like mass storage, will unlink all urbs
using usb_hcd_unlink_urb when receiving a negative status different
from -ECONNRESET.
The following flow will then happen:
dwc2_hcd_disconnect()
-> dwc2_kill_all_urbs() try to kill first pending urb.
-> dwc2_host_complete(-ETIMEDOUT)
-> usb_hcd_giveback_urb(-ETIMEDOUT)
-> sg_complete()
-> usb_unlink_urb()
-> usb_put_dev(urb->dev)
-> dwc2_kill_all_urbs() try to kill next pending urb.
-> dwc2_host_complete(-ETIMEDOUT)
-> usb_hcd_giveback_urb(-ETIMEDOUT)
-> NULL pointer dereferencing because urb->dev has been freed for all
urbs of this device.

The root cause of this NULL pointer is to call call usb_unlink_urb()
while we are killing all urbs. To avoid this return urb with
-ECONNRESET status

This issue usually happens while removing mass storage device during
transfer.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 20b81cf..e4fc7ec 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -134,7 +134,7 @@ static void dwc2_kill_urbs_in_qh_list(struct dwc2_hsotg 
*hsotg,
list_for_each_entry_safe(qh, qh_tmp, qh_list, qh_list_entry) {
list_for_each_entry_safe(qtd, qtd_tmp, >qtd_list,
 qtd_list_entry) {
-   dwc2_host_complete(hsotg, qtd, -ETIMEDOUT);
+   dwc2_host_complete(hsotg, qtd, -ECONNRESET);
dwc2_hcd_qtd_unlink_and_free(hsotg, qtd, qh);
}
}
-- 
2.3.3

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

[PATCH v1 18/32] usb: dwc2: gadget: ensure lx_state corresponds to current state

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Correctly update lx_state on gadget connection and disconnection.
When usb cable is disconnected, lx_state must be updated to L3 as
controller could be in power off state.
When usb cable is connected, lx_state must be updated to L0 as
controller is powered.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 2ed9ad8..d1a2656 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2189,6 +2189,7 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg)
}
 
call_gadget(hsotg, disconnect);
+   hsotg->lx_state = DWC2_L3;
 }
 
 /**
@@ -2415,6 +2416,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
mdelay(3);
 
hsotg->last_rst = jiffies;
+   hsotg->lx_state = DWC2_L0;
 }
 
 static void dwc2_hsotg_core_disconnect(struct dwc2_hsotg *hsotg)
@@ -2514,7 +2516,6 @@ irq_retry:
kill_all_requests(hsotg, hsotg->eps_out[0],
  -ECONNRESET);
 
-   hsotg->lx_state = DWC2_L0;
dwc2_hsotg_core_init_disconnected(hsotg, true);
}
}
@@ -3205,10 +3206,9 @@ static int dwc2_hsotg_vbus_session(struct usb_gadget 
*gadget, int is_active)
 * If controller is hibernated, it must exit from hibernation
 * before being initialized
 */
-   if (hsotg->lx_state == DWC2_L2) {
+   if (hsotg->lx_state == DWC2_L2)
dwc2_exit_hibernation(hsotg, false);
-   hsotg->lx_state = DWC2_L0;
-   }
+
/* Kill any ep0 requests as controller will be reinitialized */
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
dwc2_hsotg_core_init_disconnected(hsotg, false);
-- 
2.3.3

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

[PATCH v1 12/32] usb: dwc2: host: disable interrupt during stop

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Disable host interrupts before synchronising dwc2 irq.
So that interrupts are not generated once controller is stopped.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index bcae3ce..9c44c65 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2340,6 +2340,9 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
unsigned long flags;
 
+   /* Turn off all host-specific interrupts */
+   dwc2_disable_host_interrupts(hsotg);
+
/* Wait for interrupt processing to finish */
synchronize_irq(hcd->irq);
 
-- 
2.3.3

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

[PATCH v1 07/32] usb: dwc2: host: ignore wakeup interrupt if hibernation supported

[Mian Yousaf Kaukab]

From: Gregory Herrero 

If hibernation is supported, resume of devices will be handled in
bus_resume callback.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core_intr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 8c7c911..8f126f2 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -355,6 +355,10 @@ static void dwc2_handle_wakeup_detected_intr(struct 
dwc2_hsotg *hsotg)
/* Change to L0 state */
hsotg->lx_state = DWC2_L0;
} else {
+   if (hsotg->core_params->hibernation) {
+   writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
+   return;
+   }
if (hsotg->lx_state != DWC2_L1) {
u32 pcgcctl = readl(hsotg->regs + PCGCTL);
 
-- 
2.3.3

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

[PATCH v1 08/32] usb: dwc2: host: resume only if bus is suspended

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Port can be resumed in bus_resume callback.
In this case, there is no need to drive resume a second time
when hcd ask for it.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index e1cf9c0..9677908f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1561,7 +1561,8 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, 
u16 typereq,
writel(0, hsotg->regs + PCGCTL);
usleep_range(2, 4);
 
-   dwc2_port_resume(hsotg);
+   if (hsotg->bus_suspended)
+   dwc2_port_resume(hsotg);
break;
 
case USB_PORT_FEAT_POWER:
-- 
2.3.3

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

[PATCH v1 11/32] usb: dwc2: host: add disconnect interrupt to host only interrupts

[Mian Yousaf Kaukab]

GINTSTS.DisconnInt is host only interrupt and should be disable after
dwc2_disable_host_interrupts is called.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index bd6a214..ff8223b 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -857,7 +857,8 @@ void dwc2_enable_host_interrupts(struct dwc2_hsotg *hsotg)
 
/* Enable host mode interrupts without disturbing common interrupts */
intmsk = readl(hsotg->regs + GINTMSK);
-   intmsk |= GINTSTS_DISCONNINT | GINTSTS_PRTINT | GINTSTS_HCHINT;
+   intmsk |= GINTSTS_DISCONNINT | GINTSTS_PRTINT | GINTSTS_HCHINT |
+   GINTSTS_DISCONNINT;
writel(intmsk, hsotg->regs + GINTMSK);
 }
 
@@ -872,7 +873,7 @@ void dwc2_disable_host_interrupts(struct dwc2_hsotg *hsotg)
 
/* Disable host mode interrupts without disturbing common interrupts */
intmsk &= ~(GINTSTS_SOF | GINTSTS_PRTINT | GINTSTS_HCHINT |
-   GINTSTS_PTXFEMP | GINTSTS_NPTXFEMP);
+   GINTSTS_PTXFEMP | GINTSTS_NPTXFEMP | GINTSTS_DISCONNINT);
writel(intmsk, hsotg->regs + GINTMSK);
 }
 
-- 
2.3.3

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

[PATCH v1 09/32] usb: dwc2: host: reset frame number after suspend

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Frame number is reset in hardware after exiting hibernation.
Thus, reset frame_number and ensure qh are queued with correct
sched_frame.

Otherwise, qh->sched_frame may be too high compared to
current frame number (which is 0). This can delay addition of qh in
the list of transfers until frame number reaches qh->sched_frame.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core.c  | 1 +
 drivers/usb/dwc2/hcd_queue.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 1e67549..bd6a214 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -116,6 +116,7 @@ static int dwc2_restore_host_registers(struct dwc2_hsotg 
*hsotg)
 
writel(hr->hprt0, hsotg->regs + HPRT0);
writel(hr->hfir, hsotg->regs + HFIR);
+   hsotg->frame_number = 0;
 
return 0;
 }
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 3ad63d3..a821f19 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -583,6 +583,14 @@ int dwc2_hcd_qh_add(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh)
/* QH already in a schedule */
return 0;
 
+   if (!dwc2_frame_num_le(qh->sched_frame, hsotg->frame_number) &&
+   !hsotg->frame_number) {
+   dev_dbg(hsotg->dev,
+   "reset frame number counter\n");
+   qh->sched_frame = dwc2_frame_num_inc(hsotg->frame_number,
+   SCHEDULE_SLOP);
+   }
+
/* Add the new QH to the appropriate schedule */
if (dwc2_qh_is_non_per(qh)) {
/* Always start in inactive schedule */
-- 
2.3.3

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

[PATCH v1 06/32] usb: dwc2: host: avoid resetting lx_state to L3 during disconnect

[Mian Yousaf Kaukab]

From: Gregory Herrero 

When a device is disconnected, lx_state must not be changed since the
device may be disconnected whereas controller is still powered.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core_intr.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 344a859..8c7c911 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -386,9 +386,6 @@ static void dwc2_handle_disconnect_intr(struct dwc2_hsotg 
*hsotg)
if (hsotg->op_state == OTG_STATE_A_HOST)
dwc2_hcd_disconnect(hsotg);
 
-   /* Change to L3 (OFF) state */
-   hsotg->lx_state = DWC2_L3;
-
writel(GINTSTS_DISCONNINT, hsotg->regs + GINTSTS);
 }
 
-- 
2.3.3

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

[PATCH v1 10/32] usb: dwc2: host: disconnect hcd prior stopping it

[Mian Yousaf Kaukab]

From: Gregory Herrero 

In case controller is asked to stop while devices are connected,
disconnect all devices and clean up before stopping.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/hcd.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 9677908f..bcae3ce 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2340,7 +2340,12 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd)
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
unsigned long flags;
 
+   /* Wait for interrupt processing to finish */
+   synchronize_irq(hcd->irq);
+
spin_lock_irqsave(>lock, flags);
+   /* Ensure hcd is disconnected */
+   dwc2_hcd_disconnect(hsotg);
dwc2_hcd_stop(hsotg);
hsotg->lx_state = DWC2_L3;
hcd->state = HC_STATE_HALT;
-- 
2.3.3

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

[PATCH v1 13/32] usb: dwc2: host: clear pending interrupts prior hibernation

[Mian Yousaf Kaukab]

From: Gregory Herrero 

If an interrupt rises during hibernation process, dwc2 will assert
interrupt line to interrupt controller. If interrupt is level
sensitive, interrupt handler will be called in a loop because dwc2
will not be able to clear it while controller is hibernated.
Thus, clear all controller interrupts before hibernation entry.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index ff8223b..1ead3ac 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -398,6 +398,12 @@ int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg)
}
}
 
+   /*
+* Clear any pending interrupts since dwc2 will not be able to
+* clear them after entering hibernation.
+*/
+   writel(0x, hsotg->regs + GINTSTS);
+
/* Put the controller in low power state */
pcgcctl = readl(hsotg->regs + PCGCTL);
 
-- 
2.3.3

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

[PATCH v1 25/32] usb: dwc2: gadget: print complete setup packet

[Mian Yousaf Kaukab]

wIndex field was missing. Also print in natural order instead of
Req first, so that its easier to compare for example against
bus analyzer logs.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index b8eb6d8..60b50d0 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1206,9 +1206,10 @@ static void dwc2_hsotg_process_control(struct dwc2_hsotg 
*hsotg,
int ret = 0;
u32 dcfg;
 
-   dev_dbg(hsotg->dev, "ctrl Req=%02x, Type=%02x, V=%04x, L=%04x\n",
-ctrl->bRequest, ctrl->bRequestType,
-ctrl->wValue, ctrl->wLength);
+   dev_dbg(hsotg->dev,
+   "ctrl Type=%02x, Req=%02x, V=%04x, I=%04x, L=%04x\n",
+   ctrl->bRequestType, ctrl->bRequest, ctrl->wValue,
+   ctrl->wIndex, ctrl->wLength);
 
if (ctrl->wLength == 0) {
ep0->dir_in = 1;
-- 
2.3.3

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

[PATCH v1 26/32] usb: dwc2: gadget: stop current transfer on dequeue

[Mian Yousaf Kaukab]

If the request being dequeued is already started, disable endpoint
to stop the transfer and then call dwc2_hsotg_complete_request().
Endpoint will be re-enabled on next call to dwc2_hsotg_start_req().

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 77 +++
 1 file changed, 77 insertions(+)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 60b50d0..c7da6b7 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2829,6 +2829,79 @@ static bool on_list(struct dwc2_hsotg_ep *ep, struct 
dwc2_hsotg_req *test)
return false;
 }
 
+static int dwc2_hsotg_wait_bit_set(struct dwc2_hsotg *hs_otg, u32 reg,
+   u32 bit, u32 timeout)
+{
+   u32 i;
+
+   for (i = 0; i < timeout; i++) {
+   if (readl(hs_otg->regs + reg) & bit)
+   return 0;
+   udelay(1);
+   }
+
+   return -ETIMEDOUT;
+}
+
+static void dwc2_hsotg_ep_stop_xfr(struct dwc2_hsotg *hsotg,
+   struct dwc2_hsotg_ep *hs_ep)
+{
+   u32 epctrl_reg;
+   u32 epint_reg;
+
+   epctrl_reg = hs_ep->dir_in ? DIEPCTL(hs_ep->index) :
+  DOEPCTL(hs_ep->index);
+   epint_reg = hs_ep->dir_in ? DIEPINT(hs_ep->index) :
+   DOEPINT(hs_ep->index);
+
+   dev_dbg(hsotg->dev, "%s: stopping transfer on %s\n", __func__,
+   hs_ep->name);
+   if (hs_ep->dir_in) {
+   __orr32(hsotg->regs + epctrl_reg, DXEPCTL_SNAK);
+   /* Wait for Nak effect */
+   if (dwc2_hsotg_wait_bit_set(hsotg, epint_reg,
+   DXEPINT_INEPNAKEFF, 100))
+   dev_warn(hsotg->dev,
+   "%s: timeout DIEPINT.NAKEFF\n", __func__);
+   } else {
+   /* Clear any pending nak effect interrupt */
+   writel(GINTSTS_GINNAKEFF, hsotg->regs + GINTSTS);
+
+   __orr32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
+
+   /* Wait for global nak to take effect */
+   if (dwc2_hsotg_wait_bit_set(hsotg, GINTSTS,
+   GINTSTS_GINNAKEFF, 100))
+   dev_warn(hsotg->dev,
+   "%s: timeout GINTSTS.GINNAKEFF\n", __func__);
+   }
+
+   /* Disable ep */
+   __orr32(hsotg->regs + epctrl_reg, DXEPCTL_EPDIS | DXEPCTL_SNAK);
+
+   /* Wait for ep to be disabled */
+   if (dwc2_hsotg_wait_bit_set(hsotg, epint_reg, DXEPINT_EPDISBLD, 100))
+   dev_warn(hsotg->dev,
+   "%s: timeout DOEPCTL.EPDisable\n", __func__);
+
+   if (hs_ep->dir_in) {
+   if (hsotg->dedicated_fifos) {
+   writel(GRSTCTL_TXFNUM(hs_ep->fifo_index) |
+   GRSTCTL_TXFFLSH, hsotg->regs + GRSTCTL);
+   /* Wait for fifo flush */
+   if (dwc2_hsotg_wait_bit_set(hsotg, GRSTCTL,
+   GRSTCTL_TXFFLSH, 100))
+   dev_warn(hsotg->dev,
+   "%s: timeout flushing fifos\n",
+   __func__);
+   }
+   /* TODO: Flush shared tx fifo */
+   } else {
+   /* Remove global NAKs */
+   __bic32(hsotg->regs + DCTL, DCTL_SGNPINNAK);
+   }
+}
+
 /**
  * dwc2_hsotg_ep_dequeue - dequeue given endpoint
  * @ep: The endpoint to dequeue.
@@ -2850,6 +2923,10 @@ static int dwc2_hsotg_ep_dequeue(struct usb_ep *ep, 
struct usb_request *req)
return -EINVAL;
}
 
+   /* Dequeue already started request */
+   if (req == _ep->req->req)
+   dwc2_hsotg_ep_stop_xfr(hs, hs_ep);
+
dwc2_hsotg_complete_request(hs, hs_ep, hs_req, -ECONNRESET);
spin_unlock_irqrestore(>lock, flags);
 
-- 
2.3.3

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

[PATCH v1 27/32] usb: dwc2: gadget: kill ep0 requests before reinitializing core

[Mian Yousaf Kaukab]

Make sure there are no requests pending on ep0 before reinitializing
core. Otherwise, dwc2_hsotg_enqueue_setup will fail afterwards.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c7da6b7..a6a1a6a 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2287,6 +2287,9 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
 {
u32 val;
 
+   /* Kill any ep0 requests as controller will be reinitialized */
+   kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
+
if (!is_usb_reset)
if (dwc2_hsotg_corereset(hsotg))
goto core_init_abort;
@@ -2518,9 +2521,6 @@ irq_retry:
if (time_after(jiffies, hsotg->last_rst +
   msecs_to_jiffies(200))) {
 
-   kill_all_requests(hsotg, hsotg->eps_out[0],
- -ECONNRESET);
-
dwc2_hsotg_core_init_disconnected(hsotg, true);
}
}
@@ -3299,8 +3299,6 @@ static int dwc2_hsotg_vbus_session(struct usb_gadget 
*gadget, int is_active)
if (hsotg->lx_state == DWC2_L2)
dwc2_exit_hibernation(hsotg, false);
 
-   /* Kill any ep0 requests as controller will be reinitialized */
-   kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
dwc2_hsotg_core_init_disconnected(hsotg, false);
if (hsotg->enabled)
dwc2_hsotg_core_connect(hsotg);
-- 
2.3.3

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

[PATCH v1 22/32] usb: dwc2: gadget: set op_state in vbus_session call

[Mian Yousaf Kaukab]

From: Gregory Herrero 

Some device may have external id pin control enabled, so op_state
will not be set on id pin interrupt change.
Thus, ensure op_state is set to peripheral during vbus detection.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index a50962e..8783af8 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3209,6 +3209,7 @@ static int dwc2_hsotg_vbus_session(struct usb_gadget 
*gadget, int is_active)
spin_lock_irqsave(>lock, flags);
 
if (is_active) {
+   hsotg->op_state = OTG_STATE_B_PERIPHERAL;
/*
 * If controller is hibernated, it must exit from hibernation
 * before being initialized
-- 
2.3.3

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

[PATCH v1 28/32] usb: dwc2: gadget: only reset core after addressed state

[Mian Yousaf Kaukab]

There is a 200ms guard period to avoid unnecessary resets of the dwc2
ip. This delay sometimes prove to be too large when usbcv is run with
an ehci host. dwc2 only needs to be reset after addressed state.
Change the logic to reset ip after addressed state.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core.h   |  2 --
 drivers/usb/dwc2/gadget.c | 11 +++
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index b1e3364..096012a 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -672,7 +672,6 @@ struct dwc2_hregs_backup {
  * @ctrl_req:   Request for EP0 control packets.
  * @ep0_state:  EP0 control transfers state
  * @test_mode:  USB test mode requested by the host
- * @last_rst:   Time of last reset
  * @eps:The endpoints being supplied to the gadget framework
  * @g_using_dma:  Indicate if dma usage is enabled
  * @g_rx_fifo_sz: Contains rx fifo size value
@@ -815,7 +814,6 @@ struct dwc2_hsotg {
struct usb_gadget gadget;
unsigned int enabled:1;
unsigned int connected:1;
-   unsigned long last_rst;
struct dwc2_hsotg_ep *eps_in[MAX_EPS_CHANNELS];
struct dwc2_hsotg_ep *eps_out[MAX_EPS_CHANNELS];
u32 g_using_dma;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index a6a1a6a..60609fb 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2420,7 +2420,6 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
/* must be at-least 3ms to allow bus to see disconnect */
mdelay(3);
 
-   hsotg->last_rst = jiffies;
hsotg->lx_state = DWC2_L0;
 
 core_init_abort:
@@ -2507,6 +2506,7 @@ irq_retry:
if (gintsts & (GINTSTS_USBRST | GINTSTS_RESETDET)) {
 
u32 usb_status = readl(hsotg->regs + GOTGCTL);
+   u32 connected = hsotg->connected;
 
dev_dbg(hsotg->dev, "%s: USBRst\n", __func__);
dev_dbg(hsotg->dev, "GNPTXSTS=%08x\n",
@@ -2517,13 +2517,8 @@ irq_retry:
/* Report disconnection if it is not already done. */
dwc2_hsotg_disconnect(hsotg);
 
-   if (usb_status & GOTGCTL_BSESVLD) {
-   if (time_after(jiffies, hsotg->last_rst +
-  msecs_to_jiffies(200))) {
-
-   dwc2_hsotg_core_init_disconnected(hsotg, true);
-   }
-   }
+   if (usb_status & GOTGCTL_BSESVLD && connected)
+   dwc2_hsotg_core_init_disconnected(hsotg, true);
}
 
/* check both FIFOs */
-- 
2.3.3

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

[PATCH v1 30/32] usb: dwc2: gadget: exit hibernation before power down

[Mian Yousaf Kaukab]

From: Gregory Herrero 

When disconnecting cable, controller will detect a suspend condition
and enter partial power down. If vbus_session is called by the phy
driver during hibernation, make sure controller exit hibernation
before it is accessed.

Signed-off-by: Jianqiang Tang 
Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 1f11b50..2bb85b0 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3288,14 +3288,15 @@ static int dwc2_hsotg_vbus_session(struct usb_gadget 
*gadget, int is_active)
dev_dbg(hsotg->dev, "%s: is_active: %d\n", __func__, is_active);
spin_lock_irqsave(>lock, flags);
 
+   /*
+* If controller is hibernated, it must exit from hibernation
+* before being initialized / de-initialized
+*/
+   if (hsotg->lx_state == DWC2_L2)
+   dwc2_exit_hibernation(hsotg, false);
+
if (is_active) {
hsotg->op_state = OTG_STATE_B_PERIPHERAL;
-   /*
-* If controller is hibernated, it must exit from hibernation
-* before being initialized
-*/
-   if (hsotg->lx_state == DWC2_L2)
-   dwc2_exit_hibernation(hsotg, false);
 
dwc2_hsotg_core_init_disconnected(hsotg, false);
if (hsotg->enabled)
-- 
2.3.3

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

[PATCH v1 29/32] usb: dwc2: gadget: unmask idstschng interrupt only if controller supports it

[Mian Yousaf Kaukab]

From: Gregory Herrero 

idstschng interrupt should not be used when id pin control is
external. This is already handled on dwc2 host part. Fix it on gadget
part as well.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 60609fb..1f11b50 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2285,6 +2285,7 @@ static int dwc2_hsotg_corereset(struct dwc2_hsotg *hsotg)
 void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg *hsotg,
bool is_usb_reset)
 {
+   u32 intmsk;
u32 val;
 
/* Kill any ep0 requests as controller will be reinitialized */
@@ -2316,14 +2317,16 @@ void dwc2_hsotg_core_init_disconnected(struct 
dwc2_hsotg *hsotg,
 
/* Clear any pending interrupts */
writel(0x, hsotg->regs + GINTSTS);
-
-   writel(GINTSTS_ERLYSUSP | GINTSTS_SESSREQINT |
+   intmsk = GINTSTS_ERLYSUSP | GINTSTS_SESSREQINT |
GINTSTS_GOUTNAKEFF | GINTSTS_GINNAKEFF |
-   GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
-   GINTSTS_RESETDET | GINTSTS_ENUMDONE |
-   GINTSTS_OTGINT | GINTSTS_USBSUSP |
-   GINTSTS_WKUPINT,
-   hsotg->regs + GINTMSK);
+   GINTSTS_USBRST | GINTSTS_RESETDET |
+   GINTSTS_ENUMDONE | GINTSTS_OTGINT |
+   GINTSTS_USBSUSP | GINTSTS_WKUPINT;
+
+   if (hsotg->core_params->external_id_pin_ctl <= 0)
+   intmsk |= GINTSTS_CONIDSTSCHNG;
+
+   writel(intmsk, hsotg->regs + GINTMSK);
 
if (using_dma(hsotg))
writel(GAHBCFG_GLBL_INTR_EN | GAHBCFG_DMA_EN |
-- 
2.3.3

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

[PATCH v1 24/32] usb: dwc2: gadget: ignore stall check for ep0

[Mian Yousaf Kaukab]

dwc2_hsotg_start_req starts a request only if endpoint is not stalled.
Ignore this check for ep0 as core will clear DOEPCTL0.Stall after
sending stall handshake. Prepare instead for receiving next setup
packet.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index e35b052..b8eb6d8 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -556,7 +556,7 @@ static void dwc2_hsotg_start_req(struct dwc2_hsotg *hsotg,
/* If endpoint is stalled, we will restart request later */
ctrl = readl(hsotg->regs + epctrl_reg);
 
-   if (ctrl & DXEPCTL_STALL) {
+   if (index && ctrl & DXEPCTL_STALL) {
dev_warn(hsotg->dev, "%s: ep%d is stalled\n", __func__, index);
return;
}
-- 
2.3.3

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

[PATCH v1 31/32] usb: dwc2: gadget: handle reset interrupt before endpoint interrupts

[Mian Yousaf Kaukab]

If system is loaded, reset, enum-done and setup interrupts can occur
at the same time. Current interrupt handling sequence will handle
setup packet's interrupt before handling reset interrupt. Which will
break the enumeration process. Correct sequence is to handle reset,
enum-done and then any other endpoint interrupts.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 60 +++
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 2bb85b0..b2d41ac 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2463,6 +2463,36 @@ irq_retry:
 
gintsts &= gintmsk;
 
+   if (gintsts & GINTSTS_RESETDET) {
+   dev_dbg(hsotg->dev, "%s: USBRstDet\n", __func__);
+
+   writel(GINTSTS_RESETDET, hsotg->regs + GINTSTS);
+
+   /* This event must be used only if controller is suspended */
+   if (hsotg->lx_state == DWC2_L2) {
+   dwc2_exit_hibernation(hsotg, true);
+   hsotg->lx_state = DWC2_L0;
+   }
+   }
+
+   if (gintsts & (GINTSTS_USBRST | GINTSTS_RESETDET)) {
+
+   u32 usb_status = readl(hsotg->regs + GOTGCTL);
+   u32 connected = hsotg->connected;
+
+   dev_dbg(hsotg->dev, "%s: USBRst\n", __func__);
+   dev_dbg(hsotg->dev, "GNPTXSTS=%08x\n",
+   readl(hsotg->regs + GNPTXSTS));
+
+   writel(GINTSTS_USBRST, hsotg->regs + GINTSTS);
+
+   /* Report disconnection if it is not already done. */
+   dwc2_hsotg_disconnect(hsotg);
+
+   if (usb_status & GOTGCTL_BSESVLD && connected)
+   dwc2_hsotg_core_init_disconnected(hsotg, true);
+   }
+
if (gintsts & GINTSTS_ENUMDONE) {
writel(GINTSTS_ENUMDONE, hsotg->regs + GINTSTS);
 
@@ -2494,36 +2524,6 @@ irq_retry:
}
}
 
-   if (gintsts & GINTSTS_RESETDET) {
-   dev_dbg(hsotg->dev, "%s: USBRstDet\n", __func__);
-
-   writel(GINTSTS_RESETDET, hsotg->regs + GINTSTS);
-
-   /* This event must be used only if controller is suspended */
-   if (hsotg->lx_state == DWC2_L2) {
-   dwc2_exit_hibernation(hsotg, true);
-   hsotg->lx_state = DWC2_L0;
-   }
-   }
-
-   if (gintsts & (GINTSTS_USBRST | GINTSTS_RESETDET)) {
-
-   u32 usb_status = readl(hsotg->regs + GOTGCTL);
-   u32 connected = hsotg->connected;
-
-   dev_dbg(hsotg->dev, "%s: USBRst\n", __func__);
-   dev_dbg(hsotg->dev, "GNPTXSTS=%08x\n",
-   readl(hsotg->regs + GNPTXSTS));
-
-   writel(GINTSTS_USBRST, hsotg->regs + GINTSTS);
-
-   /* Report disconnection if it is not already done. */
-   dwc2_hsotg_disconnect(hsotg);
-
-   if (usb_status & GOTGCTL_BSESVLD && connected)
-   dwc2_hsotg_core_init_disconnected(hsotg, true);
-   }
-
/* check both FIFOs */
 
if (gintsts & GINTSTS_NPTXFEMP) {
-- 
2.3.3

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

[PATCH v1 23/32] usb: dwc2: gadget: abort core init if core_reset fails

[Mian Yousaf Kaukab]

From: Gregory Herrero 

No point of continue with initialization if core is not in a sane
state.

Signed-off-by: Gregory Herrero 
Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/gadget.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 8783af8..e35b052 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2287,7 +2287,8 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
u32 val;
 
if (!is_usb_reset)
-   dwc2_hsotg_corereset(hsotg);
+   if (dwc2_hsotg_corereset(hsotg))
+   goto core_init_abort;
 
/*
 * we must now enable ep0 ready for host detection and then
@@ -2417,6 +2418,9 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
 
hsotg->last_rst = jiffies;
hsotg->lx_state = DWC2_L0;
+
+core_init_abort:
+   return;
 }
 
 static void dwc2_hsotg_core_disconnect(struct dwc2_hsotg *hsotg)
-- 
2.3.3

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

[PATCH v1 32/32] usb: dwc2: exit hibernation on session request

[Mian Yousaf Kaukab]

Controller enters hibernation through suspend interrupt on
disconnection. On connection, session request interrupt is generated.
dwc2 must exit hibernation and restore state from this interrupt
before continuing.

In host mode, exit from hibernation is handled by bus_resume function.

Signed-off-by: Mian Yousaf Kaukab 
Signed-off-by: Gregory Herrero 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/core_intr.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 8f126f2..9c72476 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -313,16 +313,28 @@ static void dwc2_handle_conn_id_status_change_intr(struct 
dwc2_hsotg *hsotg)
  */
 static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
 {
-   dev_dbg(hsotg->dev, "++Session Request Interrupt++\n");
+   int ret;
+
+   dev_dbg(hsotg->dev, "Session request interrupt - lx_state=%d\n",
+   hsotg->lx_state);
 
/* Clear interrupt */
writel(GINTSTS_SESSREQINT, hsotg->regs + GINTSTS);
 
-   /*
-* Report disconnect if there is any previous session established
-*/
-   if (dwc2_is_device_mode(hsotg))
+   if (dwc2_is_device_mode(hsotg)) {
+   if (hsotg->lx_state == DWC2_L2) {
+   ret = dwc2_exit_hibernation(hsotg, true);
+   if (ret && (ret != -ENOTSUPP))
+   dev_err(hsotg->dev,
+   "exit hibernation failed\n");
+   }
+
+   /*
+* Report disconnect if there is any previous session
+* established
+*/
dwc2_hsotg_disconnect(hsotg);
+   }
 }
 
 /*
-- 
2.3.3

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

[PATCH v1 20/32] usb: dwc2: force dr_mode in case of configuration mismatch

[Mian Yousaf Kaukab]

If dual role configuration is not selected, check and force dr_mode
based on the selected configuration.

Signed-off-by: Mian Yousaf Kaukab 
Tested-by: Robert Baldyga 
---
 drivers/usb/dwc2/platform.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 3d1f82d..50a0e70 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -221,6 +221,17 @@ static int dwc2_driver_probe(struct platform_device *dev)
(unsigned long)res->start, hsotg->regs);
 
hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
+   if (IS_ENABLED(CONFIG_USB_DWC2_HOST) &&
+   hsotg->dr_mode != USB_DR_MODE_HOST) {
+   hsotg->dr_mode = USB_DR_MODE_HOST;
+   dev_warn(hsotg->dev,
+   "Configuration mismatch. Forcing host mode\n");
+   } else if (IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL) &&
+   hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
+   hsotg->dr_mode = USB_DR_MODE_PERIPHERAL;
+   dev_warn(hsotg->dev,
+   "Configuration mismatch. Forcing peripheral mode\n");
+   }
 
/*
 * Attempt to find a generic PHY, then look for an old style
-- 
2.3.3

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

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 11:13, Peter Chen wrote:
> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
>> On 09/09/15 05:21, Peter Chen wrote:
>>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:


 On 08/09/15 11:31, Peter Chen wrote:
> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>> On 07/09/15 04:23, Peter Chen wrote:
>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
 + * This is used by the USB Host stack to register the Host controller
 + * to the OTG core. Host controller must not be started by the
 + * caller as it is left upto the OTG state machine to do so.
 + *
 + * Returns: 0 on success, error value otherwise.
 + */
 +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
 +   unsigned long irqflags, struct otg_hcd_ops 
 *ops)
 +{
 +  struct usb_otg *otgd;
 +  struct device *hcd_dev = hcd->self.controller;
 +  struct device *otg_dev = usb_otg_get_device(hcd_dev);
 +
>>>
>>> One big problem here is: there are two designs for current (IP) driver
>>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
>>> Another one doesn't do this, roothub's parent is core device (or otg 
>>> device
>>> in your patch), like chipidea and dwc2.
>>>
>>> Then, otg_dev will be glue layer device for chipidea after that.
>>
>> OK. Let's add a way for the otg controller driver to provide the host 
>> and gadget
>> information to the otg core for such devices like chipidea and dwc2.
>>
>
> Roger, not only chipidea and dwc2, I think the musb uses the same
> hierarchy. If the host, device, and otg share the same register
> region, host part can't be a platform driver since we don't want
> to remap the same register region again.
>
> So, in the design, we may need to consider both situations, one
> is otg/host/device has its own register region, and host is a
> separate platform device (A), the other is three parts share the
> same register region, there is only one platform driver (B).
>
> A:
>
>   IP core device 
>   |
>   |
> |-|-|
> gadget   host platform device 
>   |
>   roothub
>
> B:
>
>   IP core device
>   |
>   |
> |-|-|
> gadget roothub
>   
>
>> This API must be called before the hcd/gadget-driver is added so that 
>> the otg
>> core knows it's linked to an OTG controller.
>>
>> Any better idea?
>>
>
> A flag stands for this hcd controller is the same with otg controller
> can be used, this flag can be stored at struct usb_otg_config.

 What if there is another architecture like so?

 C:
[Parent]
   |
   |
|--|--|
[OTG core]  [gadget][host]

 We need a more flexible mechanism to link the gadget and
 host device to the otg core for non DT case.

 How about adding struct usb_otg parameter to usb_otg_register_hcd()?

 e.g.
 int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)

 If otg is NULL it will try DT otg-controller property or parent to
 get the otg controller.
>>>
>>> How usb_otg_register_hcd get struct usb_otg, from where?
>>
>> This only works when the parent driver creating the hcd has registered the
>> otg controller too.
>>
> 
> Sorry? So we need to find another way to solve this issue, right?

For existing cases this is sufficient.
The otg device is either the one supplied during usb_otg_register_hcd
(cases B and C) or it is the parent device (case A).

It does not work when the 3 devices are totally independent and get registered
at different times.
I don't think there is such a case for non-DT yet, but let's not have this
limitation. So yes, we need to look for better solution :).

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

Re: Maintainer of drivers/usb/serial/mos7840.c

[Johan Hovold]

On Wed, Sep 09, 2015 at 09:55:52AM +0200, mar...@franksalomon.de wrote:
> Hello All,
> 
> Please, I need to know how is the maintainer of 
> drivers/usb/serial/mos7840.c for kernel version 2.6.32.

I'm the maintainer for that driver, but the 2.6.32 stable kernel is
maintained by Willy Tarreau. Note that that kernel is very old and
nearing end of life. You should really consider upgrading.

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 v4 10/13] usb: hcd: Adapt to OTG core

[Roger Quadros]

On 09/09/15 05:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:21PM +0300, Roger Quadros wrote:
>> The existing usb_add/remove_hcd() functionality
>> remains unchanged for non-OTG devices. For OTG
>> devices they only register the HCD with the OTG core.
>>
>> Introduce usb_otg_add/remove_hcd() for use by OTG core.
>> These functions actually add/remove the HCD.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/core/hcd.c | 55 
>> +-
>>  1 file changed, 50 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index c0fd1f6..4851682 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -46,6 +46,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "usb.h"
>>  
>> @@ -2625,8 +2626,8 @@ static void usb_put_invalidate_rhdev(struct usb_hcd 
>> *hcd)
>>   * buffers of consistent memory, register the bus, request the IRQ line,
>>   * and call the driver's reset() and start() routines.
>>   */
>> -int usb_add_hcd(struct usb_hcd *hcd,
>> -unsigned int irqnum, unsigned long irqflags)
>> +static int usb_otg_add_hcd(struct usb_hcd *hcd,
>> +   unsigned int irqnum, unsigned long irqflags)
> 
> You may change the kernel doc to this name too.

Yes.

> 
>>  {
>>  int retval;
>>  struct usb_device *rhdev;
>> @@ -2839,17 +2840,16 @@ err_phy:
>>  }
>>  return retval;
>>  }
>> -EXPORT_SYMBOL_GPL(usb_add_hcd);
>>  
>>  /**
>> - * usb_remove_hcd - shutdown processing for generic HCDs
>> + * usb_otg_remove_hcd - shutdown processing for generic HCDs
>>   * @hcd: the usb_hcd structure to remove
>>   * Context: !in_interrupt()
>>   *
>>   * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>>   * invoking the HCD's stop() method.
>>   */
>> -void usb_remove_hcd(struct usb_hcd *hcd)
>> +static void usb_otg_remove_hcd(struct usb_hcd *hcd)
>>  {
>>  struct usb_device *rhdev = hcd->self.root_hub;
>>  
>> @@ -2923,6 +2923,51 @@ void usb_remove_hcd(struct usb_hcd *hcd)
>>  
>>  usb_put_invalidate_rhdev(hcd);
>>  }
>> +
>> +static struct otg_hcd_ops otg_hcd_intf = {
>> +.add = usb_otg_add_hcd,
>> +.remove = usb_otg_remove_hcd,
>> +};
>> +
>> +/**
>> + * usb_add_hcd - finish generic HCD structure initialization and register
>> + * @hcd: the usb_hcd structure to initialize
>> + * @irqnum: Interrupt line to allocate
>> + * @irqflags: Interrupt type flags
>> + *
>> + * Finish the remaining parts of generic HCD initialization: allocate the
>> + * buffers of consistent memory, register the bus, request the IRQ line,
>> + * and call the driver's reset() and start() routines.
>> + * If it is an OTG device then it only registers the HCD with OTG core.
>> + *
>> + */
>> +int usb_add_hcd(struct usb_hcd *hcd,
>> +unsigned int irqnum, unsigned long irqflags)
>> +{
>> +/* If OTG device, OTG core takes care of adding HCD */
>> +if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
>> +return usb_otg_add_hcd(hcd, irqnum, irqflags);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_add_hcd);
>> +
>> +/**
>> + * usb_remove_hcd - shutdown processing for generic HCDs
>> + * @hcd: the usb_hcd structure to remove
>> + * Context: !in_interrupt()
>> + *
>> + * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>> + * invoking the HCD's stop() method.
>> + * If it is an OTG device then it unregisters the HCD from OTG core
>> + * as well.
>> + */
>> +void usb_remove_hcd(struct usb_hcd *hcd)
>> +{
>> +/* If OTG device, OTG core takes care of stopping HCD */
>> +if (usb_otg_unregister_hcd(hcd))
>> +usb_otg_remove_hcd(hcd);
>> +}
>>  EXPORT_SYMBOL_GPL(usb_remove_hcd);
>>  
>>  void
>> -- 
>> 2.1.4
>>
> 
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Peter Chen]

On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
> On 09/09/15 05:21, Peter Chen wrote:
> > On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
> >>
> >>
> >> On 08/09/15 11:31, Peter Chen wrote:
> >>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>  On 07/09/15 04:23, Peter Chen wrote:
> > On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> >> + * This is used by the USB Host stack to register the Host controller
> >> + * to the OTG core. Host controller must not be started by the
> >> + * caller as it is left upto the OTG state machine to do so.
> >> + *
> >> + * Returns: 0 on success, error value otherwise.
> >> + */
> >> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
> >> +   unsigned long irqflags, struct otg_hcd_ops 
> >> *ops)
> >> +{
> >> +  struct usb_otg *otgd;
> >> +  struct device *hcd_dev = hcd->self.controller;
> >> +  struct device *otg_dev = usb_otg_get_device(hcd_dev);
> >> +
> >
> > One big problem here is: there are two designs for current (IP) driver
> > code, one creates dedicated hcd device as roothub's parent, like dwc3.
> > Another one doesn't do this, roothub's parent is core device (or otg 
> > device
> > in your patch), like chipidea and dwc2.
> >
> > Then, otg_dev will be glue layer device for chipidea after that.
> 
>  OK. Let's add a way for the otg controller driver to provide the host 
>  and gadget
>  information to the otg core for such devices like chipidea and dwc2.
> 
> >>>
> >>> Roger, not only chipidea and dwc2, I think the musb uses the same
> >>> hierarchy. If the host, device, and otg share the same register
> >>> region, host part can't be a platform driver since we don't want
> >>> to remap the same register region again.
> >>>
> >>> So, in the design, we may need to consider both situations, one
> >>> is otg/host/device has its own register region, and host is a
> >>> separate platform device (A), the other is three parts share the
> >>> same register region, there is only one platform driver (B).
> >>>
> >>> A:
> >>>
> >>>   IP core device 
> >>>   |
> >>>   |
> >>> |-|-|
> >>> gadget   host platform device 
> >>>   |
> >>>   roothub
> >>>
> >>> B:
> >>>
> >>>   IP core device
> >>>   |
> >>>   |
> >>> |-|-|
> >>> gadget roothub
> >>>   
> >>>
>  This API must be called before the hcd/gadget-driver is added so that 
>  the otg
>  core knows it's linked to an OTG controller.
> 
>  Any better idea?
> 
> >>>
> >>> A flag stands for this hcd controller is the same with otg controller
> >>> can be used, this flag can be stored at struct usb_otg_config.
> >>
> >> What if there is another architecture like so?
> >>
> >> C:
> >>[Parent]
> >>   |
> >>   |
> >>|--|--|
> >>[OTG core]  [gadget][host]
> >>
> >> We need a more flexible mechanism to link the gadget and
> >> host device to the otg core for non DT case.
> >>
> >> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> >>
> >> e.g.
> >> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> >>
> >> If otg is NULL it will try DT otg-controller property or parent to
> >> get the otg controller.
> > 
> > How usb_otg_register_hcd get struct usb_otg, from where?
> 
> This only works when the parent driver creating the hcd has registered the
> otg controller too.
> 

Sorry? So we need to find another way to solve this issue, right?

> > 
> >>
> >>>
> >>> Peter
> >>>
> >>> P.S: I still read your code, I find not all APIs in this file are used
> >>> in your dwc3 example. 
> >>
> >> Which ones? The ones for registering/unregistered host/gadget are used
> >> by hcd/udc core as part of usb_add/remove_hcd() and
> >> udc_bind_to_driver()/usb_gadget_remove_driver()
> >>
> > 
> > Ok, now I understand your design, usb_create_hcd must be called before
> > the fsm kicks off. The call flow like below:
> > 
> > usb_otg_register->usb_create_hcd->usb_add_hcd->usb_otg_register_hcd->
> > usb_otg_start_host->usb_otg_add_hcd
> 
> Actually these are the discrete steps
> - usb_otg_register
> - usb_create_hcd
> - usb_add_hcd->usb_otg_register_hcd  (HCD is not really added till FSM in 
> host role)
> 
> Above 3 are prerequisite for FSM to start in addition to gadget controller and
> driver being ready.
> 
> When FSM enters in host role
> - usb_otg_start_host(true)->usb_otg_add_hcd (Now HCD is added)
> 
> When FSM exits host role
> - 

Re: [PATCH 3/5] USB: io_ti: Move download and boot mode code out of download_fw

[Johan Hovold]

On Tue, Sep 01, 2015 at 05:54:16PM -0500, Peter E. Berger wrote:
> From: "Peter E. Berger" 
> 
> Separate the download and boot mode code from download_fw() into two new
> helper functions: do_download_mode() and do_boot_mode(), and fix formatting
> in some of the comments.

Please do the comment style clean ups in its own patch (you could cover
the whole file if there are more of those).

I understand why you kept the indentation, but please just fix that in
the same patch when you break download_fw up.

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 2/5] USB: io_ti: use serial->interface for messages in download_fw

[Johan Hovold]

On Wed, Sep 02, 2015 at 10:02:53AM +0200, Oliver Neukum wrote:
> On Tue, 2015-09-01 at 17:54 -0500, Peter E. Berger wrote:
> > From: "Peter E. Berger" 
> > 
> > Use serial->interface instead of serial->dev for messages in download_fw().
> 
> Why? The firmware is per device isn't it?
> So what sense is there in messaging about it
> at interface level?

Yeah, but the driver binds to the interface (and where there more than
one interface this code would get called twice).

I think it makes more sense to have the driver use the device it binds
to for any error or debugging messages.

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 v7 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

[Rob Herring]

On 09/08/2015 01:17 AM, Chunfeng Yun wrote:
> add a DT binding documentation of usb3.0 phy for MT65xx
> SoCs from Mediatek.
> 
> Signed-off-by: Chunfeng Yun 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 
> ++
>  1 file changed, 69 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> new file mode 100644
> index 000..5812d20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -0,0 +1,69 @@
> +mt65xx USB3.0 PHY binding
> +--
> +
> +This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> +
> +Required properties (controller (parent) node):
> + - compatible: should be "mediatek,mt8173-u3phy"
> + - reg   : offset and length of register for phy, exclude port's
> +   register.
> + - clocks: a list of phandle + clock-specifier pairs, one for each
> +   entry in clock-names
> + - clock-names   : must contain
> +   "u3phya_ref": for reference clock of usb3.0 analog phy.
> +
> +Required nodes   : a sub-node is required for each port the controller
> +   provides. Address range information including the usual
> +   'reg' property is used inside these nodes to describe
> +   the controller's topology. These nodes are translated
> +   by the driver's .xlate() function.
> +
> +Required properties (port (child) node):
> +- reg: address and length of the register set for the port.
> +- #phy-cells : should be 1 (See second example)
> +   cell after port phandle is phy type from:
> + - PHY_TYPE_USB2
> + - PHY_TYPE_USB3
> +
> +Example:
> +
> +u3phy: usb-phy@1129 {
> + compatible = "mediatek,mt8173-u3phy";
> + reg = <0 0x1129 0 0x800>;
> + clocks = < CLK_APMIXED_REF2USB_TX>;
> + clock-names = "u3phya_ref";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "okay";
> +
> + phy_port0: port@11290800 {
> + reg = <0 0x11290800 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + phy_port1: port@11291000 {
> + reg = <0 0x11291000 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +};
> +
> +Specifying phy control of devices
> +-
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy port node and a device type;
> +phy-names for each port are optional.
> +
> +Example:
> +
> +#include 
> +
> +usb30: usb@1127 {
> + ...
> + phys = <_port0 PHY_TYPE_USB3>;
> + phy-names = "usb3-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 v2 1/2] usb: musb: set the controller speed based on the config setting

[Bin Liu]

Set the Power register HSENAB bit based on musb->config->maximum_speed,
so that the glue layer can control MUSB to work in high- or full-speed.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 10 +-
 include/linux/usb/musb.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 6dca3d7..5d8014e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
 {
void __iomem*regs = musb->mregs;
u8  devctl = musb_readb(regs, MUSB_DEVCTL);
+   u8  power;
 
dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
 
@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
musb_writeb(regs, MUSB_TESTMODE, 0);
 
/* put into basic highspeed mode and start session */
-   musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
-   | MUSB_POWER_HSENAB
-   /* ENSUSPEND wedges tusb */
-   /* | MUSB_POWER_ENSUSPEND */
-  );
+   power = MUSB_POWER_ISOUPDATE;
+   if (musb->config->maximum_speed == USB_SPEED_HIGH)
+   power |= MUSB_POWER_HSENAB;
+   musb_writeb(regs, MUSB_POWER, power);
 
musb->is_active = 0;
devctl = musb_readb(regs, MUSB_DEVCTL);
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index a4ee1b5..fa6dc13 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -95,7 +95,7 @@ struct musb_hdrc_config {
/* musb CLKIN in Blackfin in MHZ */
unsigned char   clkin;
 #endif
-
+   u32 maximum_speed;
 };
 
 struct musb_hdrc_platform_data {
-- 
1.8.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 v2 2/2] usb: musb: dsps: control musb speed based on dts setting

[Bin Liu]

Hi,

On 09/09/2015 08:56 AM, Sergei Shtylyov wrote:

Hello.

On 9/9/2015 4:37 PM, Bin Liu wrote:


Set musb config->maximum_speed based on the dts setting to control musb
speed.

By default musb works in high-speed mode. Adding

maximum-speed = "full-speed";

to dts usb node will force musb to full-speed mode.

Signed-off-by: Bin Liu 
---
  drivers/usb/musb/musb_dsps.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 65d931a..8c4b064 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -744,6 +744,20 @@ static int dsps_create_musb_pdev(struct dsps_glue
*glue,
  if (!ret && val)
  config->multipoint = true;

+config->maximum_speed = of_usb_get_maximum_speed(dn);
+switch (config->maximum_speed) {
+case USB_SPEED_LOW:
+/* fall */


No need for this line.


Sure, I will remove it.




+case USB_SPEED_FULL:
+break;
+case USB_SPEED_SUPER:
+dev_warn(dev, "ignore incorrect maximum_speed "
+"(super-speed) setting in dts");
+/* fall */


Fall thru.


Will do.

Do I have to re-send patch 1/2 in v3, since it is not revised? I am not 
sure about the general rules in patch submission.


Thanks,
-Bin.




+default:
+config->maximum_speed = USB_SPEED_HIGH;
+}
+
  ret = platform_device_add_data(musb, , sizeof(pdata));
  if (ret) {
  dev_err(dev, "failed to add platform_data\n");


MBR, Sergei


--
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/2] usb: musb: dsps: control musb speed based on dts setting

[Bin Liu]

Set musb config->maximum_speed based on the dts setting to control musb
speed.

By default musb works in high-speed mode. Adding

maximum-speed = "full-speed";

to dts usb node will force musb to full-speed mode.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 65d931a..8c4b064 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -744,6 +744,20 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
if (!ret && val)
config->multipoint = true;
 
+   config->maximum_speed = of_usb_get_maximum_speed(dn);
+   switch (config->maximum_speed) {
+   case USB_SPEED_LOW:
+   /* fall */
+   case USB_SPEED_FULL:
+   break;
+   case USB_SPEED_SUPER:
+   dev_warn(dev, "ignore incorrect maximum_speed "
+   "(super-speed) setting in dts");
+   /* fall */
+   default:
+   config->maximum_speed = USB_SPEED_HIGH;
+   }
+
ret = platform_device_add_data(musb, , sizeof(pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");
-- 
1.8.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 v2 2/2] usb: musb: dsps: control musb speed based on dts setting

[Sergei Shtylyov]

Hello.

On 9/9/2015 4:37 PM, Bin Liu wrote:


Set musb config->maximum_speed based on the dts setting to control musb
speed.

By default musb works in high-speed mode. Adding

maximum-speed = "full-speed";

to dts usb node will force musb to full-speed mode.

Signed-off-by: Bin Liu 
---
  drivers/usb/musb/musb_dsps.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 65d931a..8c4b064 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -744,6 +744,20 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
if (!ret && val)
config->multipoint = true;

+   config->maximum_speed = of_usb_get_maximum_speed(dn);
+   switch (config->maximum_speed) {
+   case USB_SPEED_LOW:
+   /* fall */


   No need for this line.


+   case USB_SPEED_FULL:
+   break;
+   case USB_SPEED_SUPER:
+   dev_warn(dev, "ignore incorrect maximum_speed "
+   "(super-speed) setting in dts");
+   /* fall */


   Fall thru.


+   default:
+   config->maximum_speed = USB_SPEED_HIGH;
+   }
+
ret = platform_device_add_data(musb, , sizeof(pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");


MBR, Sergei

--
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] USB: io_ti: Move request_firmware from edge_startup to download_fw

[Johan Hovold]

On Tue, Sep 01, 2015 at 05:54:18PM -0500, Peter E. Berger wrote:
> From: "Peter E. Berger" 
> 
> Move request_firmware from edge_startup to download_fw
> 
> Signed-off-by: Peter E. Berger 
> ---
>  drivers/usb/serial/io_ti.c | 56 
> --
>  1 file changed, 29 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
> index a226424..9fe12cc 100644
> --- a/drivers/usb/serial/io_ti.c
> +++ b/drivers/usb/serial/io_ti.c
> @@ -991,18 +991,29 @@ static int check_fw_sanity(struct edgeport_serial 
> *serial,
>   * This routine downloads the main operating code into the TI5052, using the
>   * boot code already burned into E2PROM or ROM.
>   */
> -static int download_fw(struct edgeport_serial *serial,
> - const struct firmware *fw)
> +static int download_fw(struct edgeport_serial *serial)
>  {
>   struct device *dev = >serial->interface->dev;
>   int status = 0;
>   struct usb_interface_descriptor *interface;
> - struct edgeport_fw_hdr *fw_hdr = (struct edgeport_fw_hdr *)fw->data;
> + const struct firmware *fw;
> + const char *fw_name = "edgeport/down3.bin";
> + struct edgeport_fw_hdr *fw_hdr;
>  
> - if (check_fw_sanity(serial, fw))
> - return -EINVAL;
> + status = request_firmware(, fw_name, dev);
> + if (status) {
> + dev_err(dev, "Failed to load image \"%s\" err %d\n",
> + fw_name, status);
> + return status;
> + }
> + fw_hdr = (struct edgeport_fw_hdr *)fw->data;

Move this after check_fw_sanity below.

> +
> + if (check_fw_sanity(serial, fw)) {
> + status = -EINVAL;
> + goto out;
> + }
>  
> - /* If on-board version is newer, "fw_version" will be updated below. */
> + /* If on-board version is newer, "fw_version" will be updated later. */
>   serial->fw_version = (fw_hdr->major_version << 8) +
>   fw_hdr->minor_version;

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 v1] media: uvcvideo: handle urb completion in a work queue

[Alan Stern]

On Wed, 9 Sep 2015, Laurent Pinchart wrote:

> On Wednesday 09 September 2015 10:30:12 Hans de Goede wrote:
> > On 08-09-15 16:36, Alan Stern wrote:
> > > On Tue, 8 Sep 2015, Hans de Goede wrote:
> > >> On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> > >>> urb completion callback is executed in host controllers interrupt
> > >>> context. To keep preempt disable time short, add urbs to a list on
> > >>> completion and schedule work to process the list.
> > >>> 
> > >>> Moreover, save timestamp and sof number in the urb completion callback
> > >>> to avoid any delays.
> > >> 
> > >> Erm, I thought that we had already moved to using threaded interrupt
> > >> handling for the urb completion a while (1-2 years ?) back. Is this then
> > >> still needed ?
> > > 
> > > We moved to handling URB completions in a tasklet, not a threaded
> > > handler.
> > 
> > Right.
> > 
> > > (Similar idea, though.)  And the change was made in only one
> > > or two HCDs, not in all of them.
> > 
> > Ah, I was under the impression this was a core change, not a per
> > hcd change.
> 
> Instead of fixing the issue in the uvcvideo driver, would it then make more 
> sense to fix it in the remaining hcd drivers ?

Unfortunately that's not so easy.  It involves some subtle changes 
related to the way isochronous endpoints are handled.  I wouldn't know 
what to change in any of the HCDs, except the ones that I maintain.

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 v2 2/2] usb: musb: dsps: control musb speed based on dts setting

[Felipe Balbi]

On Wed, Sep 09, 2015 at 09:04:55AM -0500, Bin Liu wrote:
> Hi,
> 
> On 09/09/2015 08:56 AM, Sergei Shtylyov wrote:
> >Hello.
> >
> >On 9/9/2015 4:37 PM, Bin Liu wrote:
> >
> >>Set musb config->maximum_speed based on the dts setting to control musb
> >>speed.
> >>
> >>By default musb works in high-speed mode. Adding
> >>
> >>maximum-speed = "full-speed";
> >>
> >>to dts usb node will force musb to full-speed mode.
> >>
> >>Signed-off-by: Bin Liu 
> >>---
> >>  drivers/usb/musb/musb_dsps.c | 14 ++
> >>  1 file changed, 14 insertions(+)
> >>
> >>diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> >>index 65d931a..8c4b064 100644
> >>--- a/drivers/usb/musb/musb_dsps.c
> >>+++ b/drivers/usb/musb/musb_dsps.c
> >>@@ -744,6 +744,20 @@ static int dsps_create_musb_pdev(struct dsps_glue
> >>*glue,
> >>  if (!ret && val)
> >>  config->multipoint = true;
> >>
> >>+config->maximum_speed = of_usb_get_maximum_speed(dn);
> >>+switch (config->maximum_speed) {
> >>+case USB_SPEED_LOW:
> >>+/* fall */
> >
> >No need for this line.
> 
> Sure, I will remove it.
> 
> >
> >>+case USB_SPEED_FULL:
> >>+break;
> >>+case USB_SPEED_SUPER:
> >>+dev_warn(dev, "ignore incorrect maximum_speed "
> >>+"(super-speed) setting in dts");
> >>+/* fall */
> >
> >Fall thru.
> 
> Will do.
> 
> Do I have to re-send patch 1/2 in v3, since it is not revised? I am not sure
> about the general rules in patch submission.

just reply to this email with new version of $subject.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v1] media: uvcvideo: handle urb completion in a work queue

[Alan Stern]

On Wed, 9 Sep 2015, Laurent Pinchart wrote:

> > > Instead of fixing the issue in the uvcvideo driver, would it then make
> > > more sense to fix it in the remaining hcd drivers ?
> > 
> > Unfortunately that's not so easy.  It involves some subtle changes
> > related to the way isochronous endpoints are handled.  I wouldn't know
> > what to change in any of the HCDs, except the ones that I maintain.
> 
> I'm not saying it would be easy, but I'm wondering whether it makes change to 
> move individual USB device drivers to work queues when the long term goal is 
> to use tasklets for URB completion anyway.

I'm not sure that this is a long-term goal for every HCD.  For
instance, there probably isn't much incentive to convert a driver if
its host controllers can only run at low speed or full speed.

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: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

[Roland Weber]

Hi Alan,

I've switched to kernel 4.2 for the latest debug sessions.
In drivers/usb/host/ehci-hcd.c, ehci_stop calls
ehci_silence_controller which calls ehci_halt:

static int ehci_halt (struct ehci_hcd *ehci)
{
  u32 temp;

  printk(KERN_INFO "ehci_halt: entry\n");
  spin_lock_irq(>lock);
  printk(KERN_INFO "ehci_halt: after spin_lock_irq\n");

  /* disable any irqs left enabled by previous code */
  ehci_writel(ehci, 0, >regs->intr_enable);
  printk(KERN_INFO "ehci_halt: after first ehci_writel\n");

  if (ehci_is_TDI(ehci) && !tdi_in_host_mode(ehci)) {
// this branch is not entered
  printk(KERN_INFO "ehci_halt: before early spin_unlock_irq\n");
spin_unlock_irq(>lock);
  printk(KERN_INFO "ehci_halt: early exit\n");
return 0;
  }

  /*
   * This routine gets called during probe before ehci->command
   * has been initialized, so we can't rely on its value.
   */
  ehci->command &= ~CMD_RUN;
  printk(KERN_INFO "ehci_halt: before ehci_readl\n");
  temp = ehci_readl(ehci, >regs->command);
// this point is never reached
  printk(KERN_INFO "ehci_halt: after ehci_readl, before ehci_writel\n");


There's one call to ehci_writel in the first part, which succeeds.
Then the call of ehci_readl freezes. The name sounds like a generic
communication primitive which is used from various places, so I
didn't drill further down. If you think it might help, I will.

Here's a transcript of the output I see:

ehci-pci :00:1d.0: remove, state 4
ehci-pci :00:1d.0: roothub graceful disconnect
usb usb3: USB disconnect, device number 1
usb3-1: USB disconnect, device number 2
usb3-1: ep 81: release intr @ 8+64 (1.0+256) [1/0 us] mask 0001
usb_remove_hcd: calling stop
ehci-pci :00:1d.0: stop
ehci_silence_controller: entry
ehci_halt: entry
ehci_halt: after spin_lock_irq
ehci_halt: after first ehci_writel
ehci_halt: before ehci_readl


thanks and cheers,
  Roland
--
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] media: uvcvideo: handle urb completion in a work queue

[Alan Stern]

On Wed, 9 Sep 2015, Hans de Goede wrote:

> Hi,
> 
> On 08-09-15 16:36, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> >>> urb completion callback is executed in host controllers interrupt
> >>> context. To keep preempt disable time short, add urbs to a list on
> >>> completion and schedule work to process the list.
> >>>
> >>> Moreover, save timestamp and sof number in the urb completion callback
> >>> to avoid any delays.
> >>
> >> Erm, I thought that we had already moved to using threaded interrupt
> >> handling for the urb completion a while (1-2 years ?) back. Is this then
> >> still needed ?
> >
> > We moved to handling URB completions in a tasklet, not a threaded
> > handler.
> 
> Right.
> 
> > (Similar idea, though.)  And the change was made in only one
> > or two HCDs, not in all of them.
> 
> Ah, I was under the impression this was a core change, not a per
> hcd change.

In fact, both the core and the HCD needed to be changed.  For example,
see commits 94dfd7edfd5c (core) and 9118f9eb4f1e (ehci-hcd).  (There
was more to it than just those two commits, of course.)

In one respect the change still isn't complete: Since the completion
callback occurs in a tasklet, we should allow interrupts to remain
enabled while the callback runs.  But some class drivers still expect
interrupts to be disabled at that time, so the core has to disable
interrupts before invoking the callback and then re-enable them
afterward.

There was a proposal to fix up a number of drivers so that we could 
leave interrupts enabled the whole time.  But I don't think it ever got 
merged.

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: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

[Alan Stern]

On Wed, 9 Sep 2015, Roland Weber wrote:

> Hi Alan,
> 
> I've switched to kernel 4.2 for the latest debug sessions.
> In drivers/usb/host/ehci-hcd.c, ehci_stop calls
> ehci_silence_controller which calls ehci_halt:
> 
> static int ehci_halt (struct ehci_hcd *ehci)
> {
>   u32 temp;
> 
>   printk(KERN_INFO "ehci_halt: entry\n");
>   spin_lock_irq(>lock);
>   printk(KERN_INFO "ehci_halt: after spin_lock_irq\n");
> 
>   /* disable any irqs left enabled by previous code */
>   ehci_writel(ehci, 0, >regs->intr_enable);
>   printk(KERN_INFO "ehci_halt: after first ehci_writel\n");
> 
>   if (ehci_is_TDI(ehci) && !tdi_in_host_mode(ehci)) {
> // this branch is not entered
>   printk(KERN_INFO "ehci_halt: before early spin_unlock_irq\n");
> spin_unlock_irq(>lock);
>   printk(KERN_INFO "ehci_halt: early exit\n");
> return 0;
>   }
> 
>   /*
>* This routine gets called during probe before ehci->command
>* has been initialized, so we can't rely on its value.
>*/
>   ehci->command &= ~CMD_RUN;
>   printk(KERN_INFO "ehci_halt: before ehci_readl\n");
>   temp = ehci_readl(ehci, >regs->command);
> // this point is never reached
>   printk(KERN_INFO "ehci_halt: after ehci_readl, before ehci_writel\n");
> 
> 
> There's one call to ehci_writel in the first part, which succeeds.
> Then the call of ehci_readl freezes. The name sounds like a generic
> communication primitive which is used from various places, so I
> didn't drill further down. If you think it might help, I will.

It is indeed a primitive operation, and there's no need to look into it 
any deeper.

> Here's a transcript of the output I see:
> 
> ehci-pci :00:1d.0: remove, state 4
> ehci-pci :00:1d.0: roothub graceful disconnect
> usb usb3: USB disconnect, device number 1
> usb3-1: USB disconnect, device number 2
> usb3-1: ep 81: release intr @ 8+64 (1.0+256) [1/0 us] mask 0001
> usb_remove_hcd: calling stop
> ehci-pci :00:1d.0: stop
> ehci_silence_controller: entry
> ehci_halt: entry
> ehci_halt: after spin_lock_irq
> ehci_halt: after first ehci_writel
> ehci_halt: before ehci_readl

That is odd indeed.  Note that ehci_halt() is called from ehci_setup(),
which runs during probing.  So that same statement was executed
properly at some point in the past.

The only reason I can think of why it might hang is if some clock got 
turned off.  But I don't know of any clock which would have that 
effect, or which would get turned off before we reach this point.

I also don't understand why the ehci_readl() would freeze when the 
preceding ehci_writel() succeeded.  Can you try putting a copy of the 
ehci_readl() line just before the ehci_writel(), to see if it will work 
there?

It's understandable how this could be related to "lsusb -v".  Since you 
don't have any devices attached to this EHCI controller, it would 
naturally go into runtime suspend shortly after probing.  The lsusb 
command would case it to wake up, after which it would go back into 
runtime suspend.  As it happens, the ehci_bus_suspend() routine calls 
ehci_halt().

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 v4 07/13] usb: otg: add OTG core

[Alan Stern]

On Wed, 9 Sep 2015, Roger Quadros wrote:

> (adding back folks in cc)
> 
> On 08/09/15 20:35, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Roger Quadros wrote:
> > 
>  What if there is another architecture like so?
> 
>  C:
>   [Parent]
>  |
>  |
>   |--|--|
>   [OTG core]  [gadget][host]
> 
>  We need a more flexible mechanism to link the gadget and
>  host device to the otg core for non DT case.
> 
>  How about adding struct usb_otg parameter to usb_otg_register_hcd()?
> 
>  e.g.
>  int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
> 
>  If otg is NULL it will try DT otg-controller property or parent to
>  get the otg controller.
> >>>
> >>> This seems a lot like something Peter and I discussed recently.  See
> >>>
> >>>   http://marc.info/?l=linux-usb=143977568021328=2
> >>>
> >>> and the following messages in that thread.
> >>>
> >>
> >> If I understood right, your proposal was to add a usb_pointers data
> >> struct to the device's drvdata?
> > 
> > Right.
> > 
> >> This is fine only if the otg/gadget/host share the same device.
> >> It does not solve the problem where each have different platform devices.
> > 
> > Why not?  Each of the platform devices can store a pointer to the same 
> > usb_pointers structure.  Wouldn't that be suitable?
> > 
> 
> I didn't understand how all of them get the reference to the
> same usb_pointer structure (or contents) when their respective platform 
> devices
> get created so that they can store it in their respective drvdata.
> 
> Worst case, the 3 devices could be totally independent of each other without a
> common parent, and get registered at different times.
> 
> The common resource here is the physical USB port for which the 3 drivers
> otg/host/gadget are being registered.
> There should be a mechanism for each device to tell that it is part of
> this particular USB port. (or usb_pointers struct)

True, it's not clear how to set up the common relationship among the 
three drivers.  But there must be some way to do it if they all are 
talking to the same port or PHY.

The details are an issue for the platform-specific code to handle.  
I'm not sure what would be involved; maybe you can invent something.

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 v1] media: uvcvideo: handle urb completion in a work queue

[Laurent Pinchart]

Hi Alan,

On Wednesday 09 September 2015 11:14:38 Alan Stern wrote:
> On Wed, 9 Sep 2015, Laurent Pinchart wrote:
> > On Wednesday 09 September 2015 10:30:12 Hans de Goede wrote:
> >> On 08-09-15 16:36, Alan Stern wrote:
> >>> On Tue, 8 Sep 2015, Hans de Goede wrote:
>  On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> > urb completion callback is executed in host controllers interrupt
> > context. To keep preempt disable time short, add urbs to a list on
> > completion and schedule work to process the list.
> > 
> > Moreover, save timestamp and sof number in the urb completion
> > callback to avoid any delays.
>  
>  Erm, I thought that we had already moved to using threaded interrupt
>  handling for the urb completion a while (1-2 years ?) back. Is this
>  then still needed ?
> >>> 
> >>> We moved to handling URB completions in a tasklet, not a threaded
> >>> handler.
> >> 
> >> Right.
> >> 
> >>> (Similar idea, though.)  And the change was made in only one
> >>> or two HCDs, not in all of them.
> >> 
> >> Ah, I was under the impression this was a core change, not a per
> >> hcd change.
> > 
> > Instead of fixing the issue in the uvcvideo driver, would it then make
> > more sense to fix it in the remaining hcd drivers ?
> 
> Unfortunately that's not so easy.  It involves some subtle changes
> related to the way isochronous endpoints are handled.  I wouldn't know
> what to change in any of the HCDs, except the ones that I maintain.

I'm not saying it would be easy, but I'm wondering whether it makes change to 
move individual USB device drivers to work queues when the long term goal is 
to use tasklets for URB completion anyway.

-- 
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: [RESEND PATCH 3/7] usb: phy: isp1301: Export I2C module alias information

[Javier Martinez Canillas]

Hello,

On 09/01/2015 05:29 PM, Javier Martinez Canillas wrote:
> Hello Greg and Felipe,
> 
> On 08/25/2015 08:31 AM, Javier Martinez Canillas wrote:
>> The I2C core always reports the MODALIAS uevent as "i2c:> regardless if the driver was matched using the I2C id_table or the
>> of_match_table. So the driver needs to export the I2C table and this
>> be built into the module or udev won't have the necessary information
>> to auto load the correct module when the device is added.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>>  drivers/usb/phy/phy-isp1301.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
>> index 8a55b37d1a02..db68156568e6 100644
>> --- a/drivers/usb/phy/phy-isp1301.c
>> +++ b/drivers/usb/phy/phy-isp1301.c
>> @@ -31,6 +31,7 @@ static const struct i2c_device_id isp1301_id[] = {
>>  { "isp1301", 0 },
>>  { }
>>  };
>> +MODULE_DEVICE_TABLE(i2c, isp1301_id);
>>  
>>  static struct i2c_client *isp1301_i2c_client;
>>  
>>
> 
> Any comments about this patch? The first version
> was posted about a month ago and is very trivial.
>

Another gentle ping about this patch.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[John Youn]

On 9/9/2015 11:16 AM, Roman Bacik wrote:
>> -Original Message-
>> From: John Youn [mailto:john.y...@synopsys.com]
>> Sent: September-03-15 11:53 PM
>> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
>> u...@vger.kernel.org; Roman Bacik
>> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
>> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
>>
>> On 8/31/2015 9:17 AM, Scott Branden wrote:
>>> From: Roman Bacik 
>>>
>>> USB OTG driver in isochronous mode has to set the parity of the
>>> receiving microframe. The parity is set to even by default. This
>>> causes problems for an audio gadget, if the host starts transmitting on odd
>> microframes.
>>>
>>> This fix uses Incomplete Periodic Transfer interrupt to toggle between
>>> even and odd parity until the Transfer Complete interrupt is received.
>>>
>>> Signed-off-by: Roman Bacik 
>>> Reviewed-by: Abhinav Ratna 
>>> Reviewed-by: Srinath Mannam 
>>> Signed-off-by: Scott Branden 
>>> ---
>>>  drivers/usb/dwc2/core.h   |  1 +
>>>  drivers/usb/dwc2/gadget.c | 51
>> ++-
>>>  drivers/usb/dwc2/hw.h |  1 +
>>>  3 files changed, 52 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h index
>>> 0ed87620..a5634fd 100644
>>> --- a/drivers/usb/dwc2/core.h
>>> +++ b/drivers/usb/dwc2/core.h
>>> @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
>>> unsigned intperiodic:1;
>>> unsigned intisochronous:1;
>>> unsigned intsend_zlp:1;
>>> +   unsigned inthas_correct_parity:1;
>>>
>>> charname[10];
>>>  };
>>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
>>> index 4d47b7c..fac3e2f 100644
>>> --- a/drivers/usb/dwc2/gadget.c
>>> +++ b/drivers/usb/dwc2/gadget.c
>>> @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct dwc2_hsotg
>> *hsotg, unsigned int idx,
>>> ints &= ~DXEPINT_XFERCOMPL;
>>>
>>> if (ints & DXEPINT_XFERCOMPL) {
>>> +   hs_ep->has_correct_parity = 1;
>>> if (hs_ep->isochronous && hs_ep->interval == 1) {
>>> if (ctrl & DXEPCTL_EOFRNUM)
>>> ctrl |= DXEPCTL_SETEVENFR;
>>> @@ -2316,7 +2317,8 @@ void s3c_hsotg_core_init_disconnected(struct
>> dwc2_hsotg *hsotg,
>>> GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
>>> GINTSTS_RESETDET | GINTSTS_ENUMDONE |
>>> GINTSTS_OTGINT | GINTSTS_USBSUSP |
>>> -   GINTSTS_WKUPINT,
>>> +   GINTSTS_WKUPINT |
>>> +   GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
>>> hsotg->regs + GINTMSK);
>>>
>>> if (using_dma(hsotg))
>>> @@ -2581,6 +2583,52 @@ irq_retry:
>>> s3c_hsotg_dump(hsotg);
>>> }
>>>
>>> +   if (gintsts & GINTSTS_INCOMPL_SOIN) {
>>> +   u32 idx, epctl_reg, ctrl;
>>> +   struct s3c_hsotg_ep *hs_ep;
>>> +
>>> +   dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
>> __func__);
>>> +   for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
>>
>> Valid endpoints are only up to hsotg->num_of_eps so this might crash on
>> certain configurations.
>>
>> Also, have you tried to find the endpoint which caused the incomplete
>> interrupt by reading the control registers as described in the databook?
>>
> 
> We are using procedure based on description from this source:
> 
> Synopsys, Inc. SolvNet 527
> DesignWare.com
> 3.00a
> April 2012
> USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in DWC_otg 
> Slave Mode
> 
> Synopsys databook is not in a public domain to quote the exact paragraph 
> here. You can find it in Chapter E, pp 526-527. There is no register in this 
> databook, which would provide information about the source endpoint of the 
> incomplete interrupt, as you have described.
> 
> Please, provide an exact reference and possibly enough information that we 
> can turn it into a working code.
> 

You can check the source of the interrupt by reading the DSTS and
ep control registers as described in the databook page 526, last
bullet, and 527 first bullet.

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 v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[Roman Bacik]

> -Original Message-
> From: John Youn [mailto:john.y...@synopsys.com]
> Sent: September-09-15 7:11 PM
> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> 
> On 9/9/2015 11:16 AM, Roman Bacik wrote:
> >> -Original Message-
> >> From: John Youn [mailto:john.y...@synopsys.com]
> >> Sent: September-03-15 11:53 PM
> >> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> >> u...@vger.kernel.org; Roman Bacik
> >> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> >> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> >> isochronous mode
> >>
> >> On 8/31/2015 9:17 AM, Scott Branden wrote:
> >>> From: Roman Bacik 
> >>>
> >>> USB OTG driver in isochronous mode has to set the parity of the
> >>> receiving microframe. The parity is set to even by default. This
> >>> causes problems for an audio gadget, if the host starts transmitting
> >>> on odd
> >> microframes.
> >>>
> >>> This fix uses Incomplete Periodic Transfer interrupt to toggle
> >>> between even and odd parity until the Transfer Complete interrupt is
> received.
> >>>
> >>> Signed-off-by: Roman Bacik 
> >>> Reviewed-by: Abhinav Ratna 
> >>> Reviewed-by: Srinath Mannam 
> >>> Signed-off-by: Scott Branden 
> >>> ---
> >>>  drivers/usb/dwc2/core.h   |  1 +
> >>>  drivers/usb/dwc2/gadget.c | 51
> >> ++-
> >>>  drivers/usb/dwc2/hw.h |  1 +
> >>>  3 files changed, 52 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h index
> >>> 0ed87620..a5634fd 100644
> >>> --- a/drivers/usb/dwc2/core.h
> >>> +++ b/drivers/usb/dwc2/core.h
> >>> @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> >>>   unsigned intperiodic:1;
> >>>   unsigned intisochronous:1;
> >>>   unsigned intsend_zlp:1;
> >>> + unsigned inthas_correct_parity:1;
> >>>
> >>>   charname[10];
> >>>  };
> >>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> >>> index 4d47b7c..fac3e2f 100644
> >>> --- a/drivers/usb/dwc2/gadget.c
> >>> +++ b/drivers/usb/dwc2/gadget.c
> >>> @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct dwc2_hsotg
> >> *hsotg, unsigned int idx,
> >>>   ints &= ~DXEPINT_XFERCOMPL;
> >>>
> >>>   if (ints & DXEPINT_XFERCOMPL) {
> >>> + hs_ep->has_correct_parity = 1;
> >>>   if (hs_ep->isochronous && hs_ep->interval == 1) {
> >>>   if (ctrl & DXEPCTL_EOFRNUM)
> >>>   ctrl |= DXEPCTL_SETEVENFR;
> >>> @@ -2316,7 +2317,8 @@ void s3c_hsotg_core_init_disconnected(struct
> >> dwc2_hsotg *hsotg,
> >>>   GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> >>>   GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> >>>   GINTSTS_OTGINT | GINTSTS_USBSUSP |
> >>> - GINTSTS_WKUPINT,
> >>> + GINTSTS_WKUPINT |
> >>> + GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
> >>>   hsotg->regs + GINTMSK);
> >>>
> >>>   if (using_dma(hsotg))
> >>> @@ -2581,6 +2583,52 @@ irq_retry:
> >>>   s3c_hsotg_dump(hsotg);
> >>>   }
> >>>
> >>> + if (gintsts & GINTSTS_INCOMPL_SOIN) {
> >>> + u32 idx, epctl_reg, ctrl;
> >>> + struct s3c_hsotg_ep *hs_ep;
> >>> +
> >>> + dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
> >> __func__);
> >>> + for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> >>
> >> Valid endpoints are only up to hsotg->num_of_eps so this might crash
> >> on certain configurations.
> >>
> >> Also, have you tried to find the endpoint which caused the incomplete
> >> interrupt by reading the control registers as described in the databook?
> >>
> >
> > We are using procedure based on description from this source:
> >
> > Synopsys, Inc. SolvNet 527
> > DesignWare.com
> > 3.00a
> > April 2012
> > USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in
> > DWC_otg Slave Mode
> >
> > Synopsys databook is not in a public domain to quote the exact paragraph
> here. You can find it in Chapter E, pp 526-527. There is no register in this
> databook, which would provide information about the source endpoint of
> the incomplete interrupt, as you have described.
> >
> > Please, provide an exact reference and possibly enough information that
> we can turn it into a working code.
> >
> 
> You can check the source of the interrupt by reading the DSTS and ep control
> registers as described in the databook page 526, last bullet, and 527 first
> bullet.
> 
> John
> 

Yes, that is exactly what we are doing what is described in the last bullet of 
526 and the first two bullets of page 527. So what is the problem?
--
To unsubscribe from this list: send the line "unsubscribe 

RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[Roman Bacik]

> -Original Message-
> From: John Youn [mailto:john.y...@synopsys.com]
> Sent: September-09-15 7:25 PM
> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> 
> On 9/9/2015 7:16 PM, Roman Bacik wrote:
> >> -Original Message-
> >> From: John Youn [mailto:john.y...@synopsys.com]
> >> Sent: September-09-15 7:11 PM
> >> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> >> u...@vger.kernel.org
> >> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> >> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> >> isochronous mode
> >>
> >> On 9/9/2015 11:16 AM, Roman Bacik wrote:
>  -Original Message-
>  From: John Youn [mailto:john.y...@synopsys.com]
>  Sent: September-03-15 11:53 PM
>  To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
>  u...@vger.kernel.org; Roman Bacik
>  Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
>  Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
>  isochronous mode
> 
>  On 8/31/2015 9:17 AM, Scott Branden wrote:
> > From: Roman Bacik 
> >
> > USB OTG driver in isochronous mode has to set the parity of the
> > receiving microframe. The parity is set to even by default. This
> > causes problems for an audio gadget, if the host starts
> > transmitting on odd
>  microframes.
> >
> > This fix uses Incomplete Periodic Transfer interrupt to toggle
> > between even and odd parity until the Transfer Complete interrupt
> > is
> >> received.
> >
> > Signed-off-by: Roman Bacik 
> > Reviewed-by: Abhinav Ratna 
> > Reviewed-by: Srinath Mannam 
> > Signed-off-by: Scott Branden 
> > ---
> >  drivers/usb/dwc2/core.h   |  1 +
> >  drivers/usb/dwc2/gadget.c | 51
>  ++-
> >  drivers/usb/dwc2/hw.h |  1 +
> >  3 files changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > index 0ed87620..a5634fd 100644
> > --- a/drivers/usb/dwc2/core.h
> > +++ b/drivers/usb/dwc2/core.h
> > @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> > unsigned intperiodic:1;
> > unsigned intisochronous:1;
> > unsigned intsend_zlp:1;
> > +   unsigned inthas_correct_parity:1;
> >
> > charname[10];
> >  };
> > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > index 4d47b7c..fac3e2f 100644
> > --- a/drivers/usb/dwc2/gadget.c
> > +++ b/drivers/usb/dwc2/gadget.c
> > @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct
> > dwc2_hsotg
>  *hsotg, unsigned int idx,
> > ints &= ~DXEPINT_XFERCOMPL;
> >
> > if (ints & DXEPINT_XFERCOMPL) {
> > +   hs_ep->has_correct_parity = 1;
> > if (hs_ep->isochronous && hs_ep->interval == 1) {
> > if (ctrl & DXEPCTL_EOFRNUM)
> > ctrl |= DXEPCTL_SETEVENFR;
> > @@ -2316,7 +2317,8 @@ void
> s3c_hsotg_core_init_disconnected(struct
>  dwc2_hsotg *hsotg,
> > GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> > GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> > GINTSTS_OTGINT | GINTSTS_USBSUSP |
> > -   GINTSTS_WKUPINT,
> > +   GINTSTS_WKUPINT |
> > +   GINTSTS_INCOMPL_SOIN |
> GINTSTS_INCOMPL_SOOUT,
> > hsotg->regs + GINTMSK);
> >
> > if (using_dma(hsotg))
> > @@ -2581,6 +2583,52 @@ irq_retry:
> > s3c_hsotg_dump(hsotg);
> > }
> >
> > +   if (gintsts & GINTSTS_INCOMPL_SOIN) {
> > +   u32 idx, epctl_reg, ctrl;
> > +   struct s3c_hsotg_ep *hs_ep;
> > +
> > +   dev_dbg(hsotg->dev, "%s:
> GINTSTS_INCOMPL_SOIN\n",
>  __func__);
> > +   for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> 
>  Valid endpoints are only up to hsotg->num_of_eps so this might
>  crash on certain configurations.
> 
>  Also, have you tried to find the endpoint which caused the
>  incomplete interrupt by reading the control registers as described in
> the databook?
> 
> >>>
> >>> We are using procedure based on description from this source:
> >>>
> >>> Synopsys, Inc. SolvNet 527
> >>> DesignWare.com
> >>> 3.00a
> >>> April 2012
> >>> USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in
> >>> DWC_otg Slave Mode
> 

RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[Roman Bacik]

> -Original Message-
> From: Roman Bacik
> Sent: September-09-15 7:36 PM
> To: 'John Youn'; Scott Branden; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> Subject: RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> 
> > -Original Message-
> > From: John Youn [mailto:john.y...@synopsys.com]
> > Sent: September-09-15 7:25 PM
> > To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> > u...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> > Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > isochronous mode
> >
> > On 9/9/2015 7:16 PM, Roman Bacik wrote:
> > >> -Original Message-
> > >> From: John Youn [mailto:john.y...@synopsys.com]
> > >> Sent: September-09-15 7:11 PM
> > >> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman;
> > >> linux- u...@vger.kernel.org
> > >> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> > >> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > >> isochronous mode
> > >>
> > >> On 9/9/2015 11:16 AM, Roman Bacik wrote:
> >  -Original Message-
> >  From: John Youn [mailto:john.y...@synopsys.com]
> >  Sent: September-03-15 11:53 PM
> >  To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> >  u...@vger.kernel.org; Roman Bacik
> >  Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> >  Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> >  isochronous mode
> > 
> >  On 8/31/2015 9:17 AM, Scott Branden wrote:
> > > From: Roman Bacik 
> > >
> > > USB OTG driver in isochronous mode has to set the parity of the
> > > receiving microframe. The parity is set to even by default. This
> > > causes problems for an audio gadget, if the host starts
> > > transmitting on odd
> >  microframes.
> > >
> > > This fix uses Incomplete Periodic Transfer interrupt to toggle
> > > between even and odd parity until the Transfer Complete
> > > interrupt is
> > >> received.
> > >
> > > Signed-off-by: Roman Bacik 
> > > Reviewed-by: Abhinav Ratna 
> > > Reviewed-by: Srinath Mannam 
> > > Signed-off-by: Scott Branden 
> > > ---
> > >  drivers/usb/dwc2/core.h   |  1 +
> > >  drivers/usb/dwc2/gadget.c | 51
> >  ++-
> > >  drivers/usb/dwc2/hw.h |  1 +
> > >  3 files changed, 52 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > > index 0ed87620..a5634fd 100644
> > > --- a/drivers/usb/dwc2/core.h
> > > +++ b/drivers/usb/dwc2/core.h
> > > @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> > >   unsigned intperiodic:1;
> > >   unsigned intisochronous:1;
> > >   unsigned intsend_zlp:1;
> > > + unsigned inthas_correct_parity:1;
> > >
> > >   charname[10];
> > >  };
> > > diff --git a/drivers/usb/dwc2/gadget.c
> > > b/drivers/usb/dwc2/gadget.c index 4d47b7c..fac3e2f 100644
> > > --- a/drivers/usb/dwc2/gadget.c
> > > +++ b/drivers/usb/dwc2/gadget.c
> > > @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct
> > > dwc2_hsotg
> >  *hsotg, unsigned int idx,
> > >   ints &= ~DXEPINT_XFERCOMPL;
> > >
> > >   if (ints & DXEPINT_XFERCOMPL) {
> > > + hs_ep->has_correct_parity = 1;
> > >   if (hs_ep->isochronous && hs_ep->interval == 1) {
> > >   if (ctrl & DXEPCTL_EOFRNUM)
> > >   ctrl |= DXEPCTL_SETEVENFR;
> > > @@ -2316,7 +2317,8 @@ void
> > s3c_hsotg_core_init_disconnected(struct
> >  dwc2_hsotg *hsotg,
> > >   GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> > >   GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> > >   GINTSTS_OTGINT | GINTSTS_USBSUSP |
> > > - GINTSTS_WKUPINT,
> > > + GINTSTS_WKUPINT |
> > > + GINTSTS_INCOMPL_SOIN |
> > GINTSTS_INCOMPL_SOOUT,
> > >   hsotg->regs + GINTMSK);
> > >
> > >   if (using_dma(hsotg))
> > > @@ -2581,6 +2583,52 @@ irq_retry:
> > >   s3c_hsotg_dump(hsotg);
> > >   }
> > >
> > > + if (gintsts & GINTSTS_INCOMPL_SOIN) {
> > > + u32 idx, epctl_reg, ctrl;
> > > + struct s3c_hsotg_ep *hs_ep;
> > > +
> > > + dev_dbg(hsotg->dev, "%s:
> > GINTSTS_INCOMPL_SOIN\n",
> >  __func__);
> > > + for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> > 
> >  Valid endpoints are only up to hsotg->num_of_eps so this might
> > 

RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[Roman Bacik]

> -Original Message-
> From: Roman Bacik
> Sent: September-09-15 7:17 PM
> To: 'John Youn'; Scott Branden; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> Subject: RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> 
> > -Original Message-
> > From: John Youn [mailto:john.y...@synopsys.com]
> > Sent: September-09-15 7:11 PM
> > To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> > u...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> > Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > isochronous mode
> >
> > On 9/9/2015 11:16 AM, Roman Bacik wrote:
> > >> -Original Message-
> > >> From: John Youn [mailto:john.y...@synopsys.com]
> > >> Sent: September-03-15 11:53 PM
> > >> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> > >> u...@vger.kernel.org; Roman Bacik
> > >> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> > >> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> > >> isochronous mode
> > >>
> > >> On 8/31/2015 9:17 AM, Scott Branden wrote:
> > >>> From: Roman Bacik 
> > >>>
> > >>> USB OTG driver in isochronous mode has to set the parity of the
> > >>> receiving microframe. The parity is set to even by default. This
> > >>> causes problems for an audio gadget, if the host starts
> > >>> transmitting on odd
> > >> microframes.
> > >>>
> > >>> This fix uses Incomplete Periodic Transfer interrupt to toggle
> > >>> between even and odd parity until the Transfer Complete interrupt
> > >>> is
> > received.
> > >>>
> > >>> Signed-off-by: Roman Bacik 
> > >>> Reviewed-by: Abhinav Ratna 
> > >>> Reviewed-by: Srinath Mannam 
> > >>> Signed-off-by: Scott Branden 
> > >>> ---
> > >>>  drivers/usb/dwc2/core.h   |  1 +
> > >>>  drivers/usb/dwc2/gadget.c | 51
> > >> ++-
> > >>>  drivers/usb/dwc2/hw.h |  1 +
> > >>>  3 files changed, 52 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > >>> index 0ed87620..a5634fd 100644
> > >>> --- a/drivers/usb/dwc2/core.h
> > >>> +++ b/drivers/usb/dwc2/core.h
> > >>> @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> > >>> unsigned intperiodic:1;
> > >>> unsigned intisochronous:1;
> > >>> unsigned intsend_zlp:1;
> > >>> +   unsigned inthas_correct_parity:1;
> > >>>
> > >>> charname[10];
> > >>>  };
> > >>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > >>> index 4d47b7c..fac3e2f 100644
> > >>> --- a/drivers/usb/dwc2/gadget.c
> > >>> +++ b/drivers/usb/dwc2/gadget.c
> > >>> @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct
> > >>> dwc2_hsotg
> > >> *hsotg, unsigned int idx,
> > >>> ints &= ~DXEPINT_XFERCOMPL;
> > >>>
> > >>> if (ints & DXEPINT_XFERCOMPL) {
> > >>> +   hs_ep->has_correct_parity = 1;
> > >>> if (hs_ep->isochronous && hs_ep->interval == 1) {
> > >>> if (ctrl & DXEPCTL_EOFRNUM)
> > >>> ctrl |= DXEPCTL_SETEVENFR;
> > >>> @@ -2316,7 +2317,8 @@ void
> s3c_hsotg_core_init_disconnected(struct
> > >> dwc2_hsotg *hsotg,
> > >>> GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> > >>> GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> > >>> GINTSTS_OTGINT | GINTSTS_USBSUSP |
> > >>> -   GINTSTS_WKUPINT,
> > >>> +   GINTSTS_WKUPINT |
> > >>> +   GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
> > >>> hsotg->regs + GINTMSK);
> > >>>
> > >>> if (using_dma(hsotg))
> > >>> @@ -2581,6 +2583,52 @@ irq_retry:
> > >>> s3c_hsotg_dump(hsotg);
> > >>> }
> > >>>
> > >>> +   if (gintsts & GINTSTS_INCOMPL_SOIN) {
> > >>> +   u32 idx, epctl_reg, ctrl;
> > >>> +   struct s3c_hsotg_ep *hs_ep;
> > >>> +
> > >>> +   dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
> > >> __func__);
> > >>> +   for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> > >>
> > >> Valid endpoints are only up to hsotg->num_of_eps so this might
> > >> crash on certain configurations.
> > >>
> > >> Also, have you tried to find the endpoint which caused the
> > >> incomplete interrupt by reading the control registers as described in the
> databook?
> > >>
> > >
> > > We are using procedure based on description from this source:
> > >
> > > Synopsys, Inc. SolvNet 527
> > > DesignWare.com
> > > 3.00a
> > > April 2012
> > > USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in
> > > DWC_otg Slave Mode
> > >
> > > Synopsys databook is not in a public domain to quote the exact
> > > paragraph
> > here. 

Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[John Youn]

On 9/9/2015 7:16 PM, Roman Bacik wrote:
>> -Original Message-
>> From: John Youn [mailto:john.y...@synopsys.com]
>> Sent: September-09-15 7:11 PM
>> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
>> u...@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
>> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
>>
>> On 9/9/2015 11:16 AM, Roman Bacik wrote:
 -Original Message-
 From: John Youn [mailto:john.y...@synopsys.com]
 Sent: September-03-15 11:53 PM
 To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
 u...@vger.kernel.org; Roman Bacik
 Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
 Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
 isochronous mode

 On 8/31/2015 9:17 AM, Scott Branden wrote:
> From: Roman Bacik 
>
> USB OTG driver in isochronous mode has to set the parity of the
> receiving microframe. The parity is set to even by default. This
> causes problems for an audio gadget, if the host starts transmitting
> on odd
 microframes.
>
> This fix uses Incomplete Periodic Transfer interrupt to toggle
> between even and odd parity until the Transfer Complete interrupt is
>> received.
>
> Signed-off-by: Roman Bacik 
> Reviewed-by: Abhinav Ratna 
> Reviewed-by: Srinath Mannam 
> Signed-off-by: Scott Branden 
> ---
>  drivers/usb/dwc2/core.h   |  1 +
>  drivers/usb/dwc2/gadget.c | 51
 ++-
>  drivers/usb/dwc2/hw.h |  1 +
>  3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h index
> 0ed87620..a5634fd 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
>   unsigned intperiodic:1;
>   unsigned intisochronous:1;
>   unsigned intsend_zlp:1;
> + unsigned inthas_correct_parity:1;
>
>   charname[10];
>  };
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 4d47b7c..fac3e2f 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct dwc2_hsotg
 *hsotg, unsigned int idx,
>   ints &= ~DXEPINT_XFERCOMPL;
>
>   if (ints & DXEPINT_XFERCOMPL) {
> + hs_ep->has_correct_parity = 1;
>   if (hs_ep->isochronous && hs_ep->interval == 1) {
>   if (ctrl & DXEPCTL_EOFRNUM)
>   ctrl |= DXEPCTL_SETEVENFR;
> @@ -2316,7 +2317,8 @@ void s3c_hsotg_core_init_disconnected(struct
 dwc2_hsotg *hsotg,
>   GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
>   GINTSTS_RESETDET | GINTSTS_ENUMDONE |
>   GINTSTS_OTGINT | GINTSTS_USBSUSP |
> - GINTSTS_WKUPINT,
> + GINTSTS_WKUPINT |
> + GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
>   hsotg->regs + GINTMSK);
>
>   if (using_dma(hsotg))
> @@ -2581,6 +2583,52 @@ irq_retry:
>   s3c_hsotg_dump(hsotg);
>   }
>
> + if (gintsts & GINTSTS_INCOMPL_SOIN) {
> + u32 idx, epctl_reg, ctrl;
> + struct s3c_hsotg_ep *hs_ep;
> +
> + dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
 __func__);
> + for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {

 Valid endpoints are only up to hsotg->num_of_eps so this might crash
 on certain configurations.

 Also, have you tried to find the endpoint which caused the incomplete
 interrupt by reading the control registers as described in the databook?

>>>
>>> We are using procedure based on description from this source:
>>>
>>> Synopsys, Inc. SolvNet 527
>>> DesignWare.com
>>> 3.00a
>>> April 2012
>>> USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in
>>> DWC_otg Slave Mode
>>>
>>> Synopsys databook is not in a public domain to quote the exact paragraph
>> here. You can find it in Chapter E, pp 526-527. There is no register in this
>> databook, which would provide information about the source endpoint of
>> the incomplete interrupt, as you have described.
>>>
>>> Please, provide an exact reference and possibly enough information that
>> we can turn it into a working code.
>>>
>>
>> You can check the source of the interrupt by reading the DSTS and ep control
>> registers as described in the databook page 526, last bullet, and 527 first
>> bullet.
>>
>> John
>>
> 
> Yes, that is exactly what we are doing what is described in the last bullet 
> of 526 and the first two bullets of page 527. So what is the 

Re: [PATCH v2 1/2] usb: musb: set the controller speed based on the config setting

[Felipe Balbi]

On Wed, Sep 09, 2015 at 12:18:27PM -0500, Bin Liu wrote:
> Hi,
> 
> On 09/09/2015 08:37 AM, Bin Liu wrote:
> >Set the Power register HSENAB bit based on musb->config->maximum_speed,
> >so that the glue layer can control MUSB to work in high- or full-speed.
> >
> >Signed-off-by: Bin Liu 
> >---
> >  drivers/usb/musb/musb_core.c | 10 +-
> >  include/linux/usb/musb.h |  2 +-
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >
> >diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> >index 6dca3d7..5d8014e 100644
> >--- a/drivers/usb/musb/musb_core.c
> >+++ b/drivers/usb/musb/musb_core.c
> >@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
> >  {
> > void __iomem*regs = musb->mregs;
> > u8  devctl = musb_readb(regs, MUSB_DEVCTL);
> >+u8  power;
> >
> > dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
> >
> >@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
> > musb_writeb(regs, MUSB_TESTMODE, 0);
> >
> > /* put into basic highspeed mode and start session */
> >-musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
> >-| MUSB_POWER_HSENAB
> >-/* ENSUSPEND wedges tusb */
> >-/* | MUSB_POWER_ENSUSPEND */
> >-   );
> >+power = MUSB_POWER_ISOUPDATE;
> >+if (musb->config->maximum_speed == USB_SPEED_HIGH)
> >+power |= MUSB_POWER_HSENAB;
> 
> Well, I think this breaks other glue drivers, in which case that
> musb->config is not allocated, or config->maximum_speed is 0 by default if
> not set in dts. So, to avoid patching all other glue drivers, is the
> following change acceptable?
> 
> + if (musb->config->maximum_speed != USB_SPEED_FULL &&
> + musb->config->maximum_speed != USB_SPEED_LOW)
> + power |= MUSB_POWER_HSENAB;

/*
 * treating UNKNONW as unspecified maximum speed, in which case
 * we will default to HIGH speed.
 */
if (musb->config->maximum_speed == HIGH ||
musb->config->maximum_speed == UNKNOWN)
power |= HSENAB;

how about that ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/2] usb: musb: set the controller speed based on the config setting

[Felipe Balbi]

On Wed, Sep 09, 2015 at 12:55:24PM -0500, Bin Liu wrote:
> On Wed, Sep 9, 2015 at 12:51 PM, Felipe Balbi  wrote:
> > On Wed, Sep 09, 2015 at 12:46:43PM -0500, Bin Liu wrote:
> >> Hi,
> >>
> >> On Wed, Sep 9, 2015 at 12:26 PM, Felipe Balbi  wrote:
> >> > On Wed, Sep 09, 2015 at 12:18:27PM -0500, Bin Liu wrote:
> >> >> Hi,
> >> >>
> >> >> On 09/09/2015 08:37 AM, Bin Liu wrote:
> >> >> >Set the Power register HSENAB bit based on musb->config->maximum_speed,
> >> >> >so that the glue layer can control MUSB to work in high- or full-speed.
> >> >> >
> >> >> >Signed-off-by: Bin Liu 
> >> >> >---
> >> >> >  drivers/usb/musb/musb_core.c | 10 +-
> >> >> >  include/linux/usb/musb.h |  2 +-
> >> >> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >> >> >
> >> >> >diff --git a/drivers/usb/musb/musb_core.c 
> >> >> >b/drivers/usb/musb/musb_core.c
> >> >> >index 6dca3d7..5d8014e 100644
> >> >> >--- a/drivers/usb/musb/musb_core.c
> >> >> >+++ b/drivers/usb/musb/musb_core.c
> >> >> >@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
> >> >> >  {
> >> >> > void __iomem*regs = musb->mregs;
> >> >> > u8  devctl = musb_readb(regs, MUSB_DEVCTL);
> >> >> >+u8  power;
> >> >> >
> >> >> > dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
> >> >> >
> >> >> >@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
> >> >> > musb_writeb(regs, MUSB_TESTMODE, 0);
> >> >> >
> >> >> > /* put into basic highspeed mode and start session */
> >> >> >-musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
> >> >> >-| MUSB_POWER_HSENAB
> >> >> >-/* ENSUSPEND wedges tusb */
> >> >> >-/* | MUSB_POWER_ENSUSPEND */
> >> >> >-   );
> >> >> >+power = MUSB_POWER_ISOUPDATE;
> >> >> >+if (musb->config->maximum_speed == USB_SPEED_HIGH)
> >> >> >+power |= MUSB_POWER_HSENAB;
> >> >>
> >> >> Well, I think this breaks other glue drivers, in which case that
> >> >> musb->config is not allocated, or config->maximum_speed is 0 by default 
> >> >> if
> >> >> not set in dts. So, to avoid patching all other glue drivers, is the
> >> >> following change acceptable?
> >> >>
> >> >> + if (musb->config->maximum_speed != USB_SPEED_FULL &&
> >> >> + musb->config->maximum_speed != USB_SPEED_LOW)
> >> >> + power |= MUSB_POWER_HSENAB;
> >> >
> >> > /*
> >> >  * treating UNKNONW as unspecified maximum speed, in which case
> >> >  * we will default to HIGH speed.
> >> >  */
> >> > if (musb->config->maximum_speed == HIGH ||
> >> > musb->config->maximum_speed == UNKNOWN)
> >> > power |= HSENAB;
> >> >
> >> > how about that ?
> >>
> >> Yeah, It is easy to read, but is musb->config NULL in am35x.c,
> >> tusb6010.c, davinci.c, and other old style gules? I am unable to
> >> follow their init routine to see how musb->config is initialized.
> >
> > config is never NULL, if it is we have bigger problems ;-) Note that
> > musb->config is also used to hold fifo configuration for endpoint setup.
> 
> I noticed fifo config is in musb->config, but just unable to figure
> out how it is initialized in the old style glues. :( I will read the
> code again whenever I get bored.

see allocate_instance()

-- 
balbi


signature.asc
Description: Digital signature

[PATCH v3] usb: musb: set the controller speed based on the config setting

[Bin Liu]

Set the Power register HSENAB bit based on musb->config->maximum_speed,
so that the glue layer can control MUSB to work in high- or full-speed.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 16 ++--
 include/linux/usb/musb.h |  2 +-
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 6dca3d7..e16451c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1014,18 +1014,22 @@ void musb_start(struct musb *musb)
 {
void __iomem*regs = musb->mregs;
u8  devctl = musb_readb(regs, MUSB_DEVCTL);
+   u8  power;
 
dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
 
musb_enable_interrupts(musb);
musb_writeb(regs, MUSB_TESTMODE, 0);
 
-   /* put into basic highspeed mode and start session */
-   musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
-   | MUSB_POWER_HSENAB
-   /* ENSUSPEND wedges tusb */
-   /* | MUSB_POWER_ENSUSPEND */
-  );
+   power = MUSB_POWER_ISOUPDATE;
+   /*
+* treating UNKNOWN as unspecified maximum speed, in which case
+* we will default to high-speed.
+*/
+   if (musb->config->maximum_speed == USB_SPEED_HIGH ||
+   musb->config->maximum_speed == USB_SPEED_UNKNOWN)
+   power |= MUSB_POWER_HSENAB;
+   musb_writeb(regs, MUSB_POWER, power);
 
musb->is_active = 0;
devctl = musb_readb(regs, MUSB_DEVCTL);
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index a4ee1b5..fa6dc13 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -95,7 +95,7 @@ struct musb_hdrc_config {
/* musb CLKIN in Blackfin in MHZ */
unsigned char   clkin;
 #endif
-
+   u32 maximum_speed;
 };
 
 struct musb_hdrc_platform_data {
-- 
1.8.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 v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[Roman Bacik]

> -Original Message-
> From: John Youn [mailto:john.y...@synopsys.com]
> Sent: September-03-15 11:53 PM
> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org; Roman Bacik
> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> 
> On 8/31/2015 9:17 AM, Scott Branden wrote:
> > From: Roman Bacik 
> >
> > USB OTG driver in isochronous mode has to set the parity of the
> > receiving microframe. The parity is set to even by default. This
> > causes problems for an audio gadget, if the host starts transmitting on odd
> microframes.
> >
> > This fix uses Incomplete Periodic Transfer interrupt to toggle between
> > even and odd parity until the Transfer Complete interrupt is received.
> >
> > Signed-off-by: Roman Bacik 
> > Reviewed-by: Abhinav Ratna 
> > Reviewed-by: Srinath Mannam 
> > Signed-off-by: Scott Branden 
> > ---
> >  drivers/usb/dwc2/core.h   |  1 +
> >  drivers/usb/dwc2/gadget.c | 51
> ++-
> >  drivers/usb/dwc2/hw.h |  1 +
> >  3 files changed, 52 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h index
> > 0ed87620..a5634fd 100644
> > --- a/drivers/usb/dwc2/core.h
> > +++ b/drivers/usb/dwc2/core.h
> > @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> > unsigned intperiodic:1;
> > unsigned intisochronous:1;
> > unsigned intsend_zlp:1;
> > +   unsigned inthas_correct_parity:1;
> >
> > charname[10];
> >  };
> > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > index 4d47b7c..fac3e2f 100644
> > --- a/drivers/usb/dwc2/gadget.c
> > +++ b/drivers/usb/dwc2/gadget.c
> > @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct dwc2_hsotg
> *hsotg, unsigned int idx,
> > ints &= ~DXEPINT_XFERCOMPL;
> >
> > if (ints & DXEPINT_XFERCOMPL) {
> > +   hs_ep->has_correct_parity = 1;
> > if (hs_ep->isochronous && hs_ep->interval == 1) {
> > if (ctrl & DXEPCTL_EOFRNUM)
> > ctrl |= DXEPCTL_SETEVENFR;
> > @@ -2316,7 +2317,8 @@ void s3c_hsotg_core_init_disconnected(struct
> dwc2_hsotg *hsotg,
> > GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> > GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> > GINTSTS_OTGINT | GINTSTS_USBSUSP |
> > -   GINTSTS_WKUPINT,
> > +   GINTSTS_WKUPINT |
> > +   GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
> > hsotg->regs + GINTMSK);
> >
> > if (using_dma(hsotg))
> > @@ -2581,6 +2583,52 @@ irq_retry:
> > s3c_hsotg_dump(hsotg);
> > }
> >
> > +   if (gintsts & GINTSTS_INCOMPL_SOIN) {
> > +   u32 idx, epctl_reg, ctrl;
> > +   struct s3c_hsotg_ep *hs_ep;
> > +
> > +   dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
> __func__);
> > +   for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> 
> Valid endpoints are only up to hsotg->num_of_eps so this might crash on
> certain configurations.
> 
> Also, have you tried to find the endpoint which caused the incomplete
> interrupt by reading the control registers as described in the databook?
> 

We are using procedure based on description from this source:

Synopsys, Inc. SolvNet 527
DesignWare.com
3.00a
April 2012
USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in DWC_otg 
Slave Mode

Synopsys databook is not in a public domain to quote the exact paragraph here. 
You can find it in Chapter E, pp 526-527. There is no register in this 
databook, which would provide information about the source endpoint of the 
incomplete interrupt, as you have described.

Please, provide an exact reference and possibly enough information that we can 
turn it into a working code.

> > +   hs_ep = hsotg->eps_in[idx];
> > +
> > +   if (!hs_ep->isochronous || hs_ep-
> >has_correct_parity)
> > +   continue;
> > +
> > +   epctl_reg = DIEPCTL(idx);
> > +   ctrl = readl(hsotg->regs + epctl_reg);
> > +
> > +   if (ctrl & DXEPCTL_EOFRNUM)
> > +   ctrl |= DXEPCTL_SETEVENFR;
> > +   else
> > +   ctrl |= DXEPCTL_SETODDFR;
> > +   writel(ctrl, hsotg->regs + epctl_reg);
> 
> This toggling code could be moved out to a helper function to reduce
> redundancy as it is in three places now.
> 
> Regards,
> John

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

Re: qcserial: AT unsolicited response codes missing with Dell Wireless 5808e

[David Ward]

On 09/08/2015 05:16 PM, Reinhard Speyerer wrote:
> On Mon, Aug 31, 2015 at 07:18:05PM +, Ward, David - 0665 - MITLL wrote:
>> On 01/06/2015 03:58 AM, Bj=F8rn Mork wrote:
>>> Johan Hovold  writes:
>>>
 Ok, let's move the PID to option and if it turns out that more of these
 devices require the modem-control signals (e.g. with more recent
 firmware) we can consider moving it back after adding such support to
 qcserial.

>> This also affects the Dell Wireless 5808e, a branded version of the
>> Sierra Wireless EM7355. Again, moving it from the qcserial driver to the
>> option driver, which calls send_setup, allows URCs to appear.
>>
>> Is it possible to test if the MC7710 also works with the option driver
>> (does send_setup cause problems with it)? If that still works, are there
>> any reasons not to move all of the devices using the Sierra Wireless
>> layout (DEVICE_SWI) from the qcserial driver to the option driver?
> Hi David,
>
> due to lack of time I could not test your patch
> you sent me yesterday. I checked however using
>
> # rmmod qcserial
> # modprobe option
> # echo 1199 68a2 > /sys/bus/usb-serial/drivers/option1/new_id
>
> that AT URCs with a MC7710 still work when option_send_setup() is used.
>
> Since AT URCs already work with the qcserial driver for the MC7710
> "out of the box"
>
> at+gmr
> SWI9200X_03.05.29.03ap r6485 CNSHZ-ED-XP0031 2014/12/02 17:53:15
> OK
> at+cscs=3D"GSM"
> OK
> at+cusd=3D1,"*101#",15
> OK
>
> +CUSD: 0,"Ihr Guthaben betr{gt: 42,00. Jetzt auch Ihr Guthaben aufladen: 
> einfach *103*Aufladenummer# und die H|rertaste eingeben.",15
>
> my suggestion would be to keep the MC77xx in the qcserial driver to
> avoid having to add additional blacklist entries. The current
> version of your patch incorrectly uses the MC73xx blacklist also for
> the MC77xx which would cause the option driver to bind to the MC77xx
> QMI interfaces on USB IF 19 and 20 which it should not do.
>
> Instead of moving the MC77xx to the option driver it might be more
> worthwhile to check whether other EM7305/EM7355-based devices like the
> recently added Dell Wireless 5809e device are also affected by the
> missing AT URCs and should be moved from the qcserial to the option driver.

Reinhard, thanks for trying this on the MC7710 (and pointing out the
difference in device layout).

Are there enough devices with this behavior now to re-consider adding
the control request to the qcserial driver, rather than moving another
device to the option driver? The request doesn't seem to cause issues
on the MC7710 where it is not needed, and it is already implemented in
the "sierra" driver as well.

An earlier e-mail from Reinhard contained a patch that did this for the
MC7304. That patch could be modified as shown below so that the control
request is enabled or disabled from qcprobe() instead. This way, it is
straightforward to enable it for specific interface(s) on a particular
device layout (here, it is only enabled on the AT port in the Sierra
Wireless layout). I tested this with the Dell Wireless 5808e and it was
able to connect to the mobile network as usual and also send AT URCs.

David


diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ebcec8c..c12836e 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -22,6 +22,10 @@
 #define DRIVER_AUTHOR "Qualcomm Inc"
 #define DRIVER_DESC "Qualcomm USB Serial driver"
 
+struct qcserial_private {
+   u8 bInterfaceNumber;
+};
+
 /* standard device layouts supported by this driver */
 enum qcserial_layouts {
QCSERIAL_G2K = 0,   /* Gobi 2000 */
@@ -175,6 +179,7 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
__u8 nintf;
__u8 ifnum;
int altsetting = -1;
+   bool sendsetup = false;
 
nintf = serial->dev->actconfig->desc.bNumInterfaces;
dev_dbg(dev, "Num Interfaces = %d\n", nintf);
@@ -286,6 +291,7 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
break;
case 3:
dev_dbg(dev, "Modem port found\n");
+   sendsetup = true;
break;
default:
/* don't claim any unsupported interface */
@@ -337,17 +343,65 @@ done:
}
}
 
+   if (!retval)
+   usb_set_serial_data(serial, (void *)(unsigned long)sendsetup);
+
return retval;
 }
 
+/* Send RTS/DTR state to the port (CDC ACM SET_CONTROL_LINE_STATE request) */
+static int qc_send_setup(struct usb_serial_port *port)
+{
+   struct usb_serial *serial = port->serial;
+   struct usb_wwan_intf_private *intfdata = usb_get_serial_data(serial);
+   struct usb_wwan_port_private *portdata = usb_get_serial_port_data(port);
+   struct qcserial_private *priv = intfdata->private;
+   int val = 0;
+   int res;
+
+   

Re: [PATCH v2 1/2] usb: musb: set the controller speed based on the config setting

[Bin Liu]

Hi,

On 09/09/2015 08:37 AM, Bin Liu wrote:

Set the Power register HSENAB bit based on musb->config->maximum_speed,
so that the glue layer can control MUSB to work in high- or full-speed.

Signed-off-by: Bin Liu 
---
  drivers/usb/musb/musb_core.c | 10 +-
  include/linux/usb/musb.h |  2 +-
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 6dca3d7..5d8014e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
  {
void __iomem*regs = musb->mregs;
u8  devctl = musb_readb(regs, MUSB_DEVCTL);
+   u8  power;

dev_dbg(musb->controller, "<== devctl %02x\n", devctl);

@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
musb_writeb(regs, MUSB_TESTMODE, 0);

/* put into basic highspeed mode and start session */
-   musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
-   | MUSB_POWER_HSENAB
-   /* ENSUSPEND wedges tusb */
-   /* | MUSB_POWER_ENSUSPEND */
-  );
+   power = MUSB_POWER_ISOUPDATE;
+   if (musb->config->maximum_speed == USB_SPEED_HIGH)
+   power |= MUSB_POWER_HSENAB;


Well, I think this breaks other glue drivers, in which case that 
musb->config is not allocated, or config->maximum_speed is 0 by default 
if not set in dts. So, to avoid patching all other glue drivers, is the 
following change acceptable?


+   if (musb->config->maximum_speed != USB_SPEED_FULL &&
+   musb->config->maximum_speed != USB_SPEED_LOW)
+   power |= MUSB_POWER_HSENAB;

Thanks,
-Bin.


+   musb_writeb(regs, MUSB_POWER, power);

musb->is_active = 0;
devctl = musb_readb(regs, MUSB_DEVCTL);
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index a4ee1b5..fa6dc13 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -95,7 +95,7 @@ struct musb_hdrc_config {
/* musb CLKIN in Blackfin in MHZ */
unsigned char   clkin;
  #endif
-
+   u32 maximum_speed;
  };

  struct musb_hdrc_platform_data {


--
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 1/2] usb: musb: set the controller speed based on the config setting

[Bin Liu]

Hi,

On Wed, Sep 9, 2015 at 12:26 PM, Felipe Balbi  wrote:
> On Wed, Sep 09, 2015 at 12:18:27PM -0500, Bin Liu wrote:
>> Hi,
>>
>> On 09/09/2015 08:37 AM, Bin Liu wrote:
>> >Set the Power register HSENAB bit based on musb->config->maximum_speed,
>> >so that the glue layer can control MUSB to work in high- or full-speed.
>> >
>> >Signed-off-by: Bin Liu 
>> >---
>> >  drivers/usb/musb/musb_core.c | 10 +-
>> >  include/linux/usb/musb.h |  2 +-
>> >  2 files changed, 6 insertions(+), 6 deletions(-)
>> >
>> >diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> >index 6dca3d7..5d8014e 100644
>> >--- a/drivers/usb/musb/musb_core.c
>> >+++ b/drivers/usb/musb/musb_core.c
>> >@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
>> >  {
>> > void __iomem*regs = musb->mregs;
>> > u8  devctl = musb_readb(regs, MUSB_DEVCTL);
>> >+u8  power;
>> >
>> > dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
>> >
>> >@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
>> > musb_writeb(regs, MUSB_TESTMODE, 0);
>> >
>> > /* put into basic highspeed mode and start session */
>> >-musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
>> >-| MUSB_POWER_HSENAB
>> >-/* ENSUSPEND wedges tusb */
>> >-/* | MUSB_POWER_ENSUSPEND */
>> >-   );
>> >+power = MUSB_POWER_ISOUPDATE;
>> >+if (musb->config->maximum_speed == USB_SPEED_HIGH)
>> >+power |= MUSB_POWER_HSENAB;
>>
>> Well, I think this breaks other glue drivers, in which case that
>> musb->config is not allocated, or config->maximum_speed is 0 by default if
>> not set in dts. So, to avoid patching all other glue drivers, is the
>> following change acceptable?
>>
>> + if (musb->config->maximum_speed != USB_SPEED_FULL &&
>> + musb->config->maximum_speed != USB_SPEED_LOW)
>> + power |= MUSB_POWER_HSENAB;
>
> /*
>  * treating UNKNONW as unspecified maximum speed, in which case
>  * we will default to HIGH speed.
>  */
> if (musb->config->maximum_speed == HIGH ||
> musb->config->maximum_speed == UNKNOWN)
> power |= HSENAB;
>
> how about that ?

Yeah, It is easy to read, but is musb->config NULL in am35x.c,
tusb6010.c, davinci.c, and other old style gules? I am unable to
follow their init routine to see how musb->config is initialized.

Regards,
-Bin.

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

Re: [PATCH v2 1/2] usb: musb: set the controller speed based on the config setting

[Felipe Balbi]

On Wed, Sep 09, 2015 at 12:46:43PM -0500, Bin Liu wrote:
> Hi,
> 
> On Wed, Sep 9, 2015 at 12:26 PM, Felipe Balbi  wrote:
> > On Wed, Sep 09, 2015 at 12:18:27PM -0500, Bin Liu wrote:
> >> Hi,
> >>
> >> On 09/09/2015 08:37 AM, Bin Liu wrote:
> >> >Set the Power register HSENAB bit based on musb->config->maximum_speed,
> >> >so that the glue layer can control MUSB to work in high- or full-speed.
> >> >
> >> >Signed-off-by: Bin Liu 
> >> >---
> >> >  drivers/usb/musb/musb_core.c | 10 +-
> >> >  include/linux/usb/musb.h |  2 +-
> >> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >> >
> >> >diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> >> >index 6dca3d7..5d8014e 100644
> >> >--- a/drivers/usb/musb/musb_core.c
> >> >+++ b/drivers/usb/musb/musb_core.c
> >> >@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
> >> >  {
> >> > void __iomem*regs = musb->mregs;
> >> > u8  devctl = musb_readb(regs, MUSB_DEVCTL);
> >> >+u8  power;
> >> >
> >> > dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
> >> >
> >> >@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
> >> > musb_writeb(regs, MUSB_TESTMODE, 0);
> >> >
> >> > /* put into basic highspeed mode and start session */
> >> >-musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
> >> >-| MUSB_POWER_HSENAB
> >> >-/* ENSUSPEND wedges tusb */
> >> >-/* | MUSB_POWER_ENSUSPEND */
> >> >-   );
> >> >+power = MUSB_POWER_ISOUPDATE;
> >> >+if (musb->config->maximum_speed == USB_SPEED_HIGH)
> >> >+power |= MUSB_POWER_HSENAB;
> >>
> >> Well, I think this breaks other glue drivers, in which case that
> >> musb->config is not allocated, or config->maximum_speed is 0 by default if
> >> not set in dts. So, to avoid patching all other glue drivers, is the
> >> following change acceptable?
> >>
> >> + if (musb->config->maximum_speed != USB_SPEED_FULL &&
> >> + musb->config->maximum_speed != USB_SPEED_LOW)
> >> + power |= MUSB_POWER_HSENAB;
> >
> > /*
> >  * treating UNKNONW as unspecified maximum speed, in which case
> >  * we will default to HIGH speed.
> >  */
> > if (musb->config->maximum_speed == HIGH ||
> > musb->config->maximum_speed == UNKNOWN)
> > power |= HSENAB;
> >
> > how about that ?
> 
> Yeah, It is easy to read, but is musb->config NULL in am35x.c,
> tusb6010.c, davinci.c, and other old style gules? I am unable to
> follow their init routine to see how musb->config is initialized.

config is never NULL, if it is we have bigger problems ;-) Note that
musb->config is also used to hold fifo configuration for endpoint setup.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/2] usb: musb: set the controller speed based on the config setting

[Bin Liu]

On Wed, Sep 9, 2015 at 12:56 PM, Felipe Balbi  wrote:
> On Wed, Sep 09, 2015 at 12:55:24PM -0500, Bin Liu wrote:
>> On Wed, Sep 9, 2015 at 12:51 PM, Felipe Balbi  wrote:
>> > On Wed, Sep 09, 2015 at 12:46:43PM -0500, Bin Liu wrote:
>> >> Hi,
>> >>
>> >> On Wed, Sep 9, 2015 at 12:26 PM, Felipe Balbi  wrote:
>> >> > On Wed, Sep 09, 2015 at 12:18:27PM -0500, Bin Liu wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On 09/09/2015 08:37 AM, Bin Liu wrote:
>> >> >> >Set the Power register HSENAB bit based on 
>> >> >> >musb->config->maximum_speed,
>> >> >> >so that the glue layer can control MUSB to work in high- or 
>> >> >> >full-speed.
>> >> >> >
>> >> >> >Signed-off-by: Bin Liu 
>> >> >> >---
>> >> >> >  drivers/usb/musb/musb_core.c | 10 +-
>> >> >> >  include/linux/usb/musb.h |  2 +-
>> >> >> >  2 files changed, 6 insertions(+), 6 deletions(-)
>> >> >> >
>> >> >> >diff --git a/drivers/usb/musb/musb_core.c 
>> >> >> >b/drivers/usb/musb/musb_core.c
>> >> >> >index 6dca3d7..5d8014e 100644
>> >> >> >--- a/drivers/usb/musb/musb_core.c
>> >> >> >+++ b/drivers/usb/musb/musb_core.c
>> >> >> >@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
>> >> >> >  {
>> >> >> > void __iomem*regs = musb->mregs;
>> >> >> > u8  devctl = musb_readb(regs, MUSB_DEVCTL);
>> >> >> >+u8  power;
>> >> >> >
>> >> >> > dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
>> >> >> >
>> >> >> >@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
>> >> >> > musb_writeb(regs, MUSB_TESTMODE, 0);
>> >> >> >
>> >> >> > /* put into basic highspeed mode and start session */
>> >> >> >-musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
>> >> >> >-| MUSB_POWER_HSENAB
>> >> >> >-/* ENSUSPEND wedges tusb */
>> >> >> >-/* | MUSB_POWER_ENSUSPEND */
>> >> >> >-   );
>> >> >> >+power = MUSB_POWER_ISOUPDATE;
>> >> >> >+if (musb->config->maximum_speed == USB_SPEED_HIGH)
>> >> >> >+power |= MUSB_POWER_HSENAB;
>> >> >>
>> >> >> Well, I think this breaks other glue drivers, in which case that
>> >> >> musb->config is not allocated, or config->maximum_speed is 0 by 
>> >> >> default if
>> >> >> not set in dts. So, to avoid patching all other glue drivers, is the
>> >> >> following change acceptable?
>> >> >>
>> >> >> + if (musb->config->maximum_speed != USB_SPEED_FULL &&
>> >> >> + musb->config->maximum_speed != USB_SPEED_LOW)
>> >> >> + power |= MUSB_POWER_HSENAB;
>> >> >
>> >> > /*
>> >> >  * treating UNKNONW as unspecified maximum speed, in which case
>> >> >  * we will default to HIGH speed.
>> >> >  */
>> >> > if (musb->config->maximum_speed == HIGH ||
>> >> > musb->config->maximum_speed == UNKNOWN)
>> >> > power |= HSENAB;
>> >> >
>> >> > how about that ?
>> >>
>> >> Yeah, It is easy to read, but is musb->config NULL in am35x.c,
>> >> tusb6010.c, davinci.c, and other old style gules? I am unable to
>> >> follow their init routine to see how musb->config is initialized.
>> >
>> > config is never NULL, if it is we have bigger problems ;-) Note that
>> > musb->config is also used to hold fifo configuration for endpoint setup.
>>
>> I noticed fifo config is in musb->config, but just unable to figure
>> out how it is initialized in the old style glues. :( I will read the
>> code again whenever I get bored.
>
> see allocate_instance()

Aha, thank you very much for the hint. Obviously I quickly forgot all
the board config files under each platform...

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

Re: Maintainer of drivers/usb/serial/mos7840.c

[Greg KH]

On Wed, Sep 09, 2015 at 09:55:52AM +0200, mar...@franksalomon.de wrote:
> Hello All,
> 
> Please, I need to know how is the maintainer of drivers/usb/serial/mos7840.c
> for kernel version 2.6.32.

No one "maintains" that old, obsolete, kernel version for new fixes.
Please ask the company that is forcing you to say on this version for
support, as you are paying them for this already.

If you have problems with this driver when using the 4.2 kernel release,
this mailing list will be glad to help you out, what is the issues you
are having?

thanks,

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

[PATCH v3] usb: musb: dsps: control musb speed based on dts setting

[Bin Liu]

Set musb config->maximum_speed based on the dts setting to control musb
speed.

By default musb works in high-speed mode. Adding

maximum-speed = "full-speed";

to dts usb node will force musb to full-speed mode.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 65d931a..da656d4 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -744,6 +744,19 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
if (!ret && val)
config->multipoint = true;
 
+   config->maximum_speed = of_usb_get_maximum_speed(dn);
+   switch (config->maximum_speed) {
+   case USB_SPEED_LOW:
+   case USB_SPEED_FULL:
+   break;
+   case USB_SPEED_SUPER:
+   dev_warn(dev, "ignore incorrect maximum_speed "
+   "(super-speed) setting in dts");
+   /* fall through */
+   default:
+   config->maximum_speed = USB_SPEED_HIGH;
+   }
+
ret = platform_device_add_data(musb, , sizeof(pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");
-- 
1.8.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 v2 1/2] usb: musb: set the controller speed based on the config setting

[Bin Liu]

On Wed, Sep 9, 2015 at 12:51 PM, Felipe Balbi  wrote:
> On Wed, Sep 09, 2015 at 12:46:43PM -0500, Bin Liu wrote:
>> Hi,
>>
>> On Wed, Sep 9, 2015 at 12:26 PM, Felipe Balbi  wrote:
>> > On Wed, Sep 09, 2015 at 12:18:27PM -0500, Bin Liu wrote:
>> >> Hi,
>> >>
>> >> On 09/09/2015 08:37 AM, Bin Liu wrote:
>> >> >Set the Power register HSENAB bit based on musb->config->maximum_speed,
>> >> >so that the glue layer can control MUSB to work in high- or full-speed.
>> >> >
>> >> >Signed-off-by: Bin Liu 
>> >> >---
>> >> >  drivers/usb/musb/musb_core.c | 10 +-
>> >> >  include/linux/usb/musb.h |  2 +-
>> >> >  2 files changed, 6 insertions(+), 6 deletions(-)
>> >> >
>> >> >diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> >> >index 6dca3d7..5d8014e 100644
>> >> >--- a/drivers/usb/musb/musb_core.c
>> >> >+++ b/drivers/usb/musb/musb_core.c
>> >> >@@ -1014,6 +1014,7 @@ void musb_start(struct musb *musb)
>> >> >  {
>> >> > void __iomem*regs = musb->mregs;
>> >> > u8  devctl = musb_readb(regs, MUSB_DEVCTL);
>> >> >+u8  power;
>> >> >
>> >> > dev_dbg(musb->controller, "<== devctl %02x\n", devctl);
>> >> >
>> >> >@@ -1021,11 +1022,10 @@ void musb_start(struct musb *musb)
>> >> > musb_writeb(regs, MUSB_TESTMODE, 0);
>> >> >
>> >> > /* put into basic highspeed mode and start session */
>> >> >-musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
>> >> >-| MUSB_POWER_HSENAB
>> >> >-/* ENSUSPEND wedges tusb */
>> >> >-/* | MUSB_POWER_ENSUSPEND */
>> >> >-   );
>> >> >+power = MUSB_POWER_ISOUPDATE;
>> >> >+if (musb->config->maximum_speed == USB_SPEED_HIGH)
>> >> >+power |= MUSB_POWER_HSENAB;
>> >>
>> >> Well, I think this breaks other glue drivers, in which case that
>> >> musb->config is not allocated, or config->maximum_speed is 0 by default if
>> >> not set in dts. So, to avoid patching all other glue drivers, is the
>> >> following change acceptable?
>> >>
>> >> + if (musb->config->maximum_speed != USB_SPEED_FULL &&
>> >> + musb->config->maximum_speed != USB_SPEED_LOW)
>> >> + power |= MUSB_POWER_HSENAB;
>> >
>> > /*
>> >  * treating UNKNONW as unspecified maximum speed, in which case
>> >  * we will default to HIGH speed.
>> >  */
>> > if (musb->config->maximum_speed == HIGH ||
>> > musb->config->maximum_speed == UNKNOWN)
>> > power |= HSENAB;
>> >
>> > how about that ?
>>
>> Yeah, It is easy to read, but is musb->config NULL in am35x.c,
>> tusb6010.c, davinci.c, and other old style gules? I am unable to
>> follow their init routine to see how musb->config is initialized.
>
> config is never NULL, if it is we have bigger problems ;-) Note that
> musb->config is also used to hold fifo configuration for endpoint setup.

I noticed fifo config is in musb->config, but just unable to figure
out how it is initialized in the old style glues. :( I will read the
code again whenever I get bored.

Will send v3 soon.

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