Re: [PATCH v3 1/3] usb: chipidea: imx: support configuring for active low oc signal

[Stefan Wahren]

Am 04.12.18 um 09:52 schrieb Uwe Kleine-König:
> Hello Stefan,
>
> On Tue, Dec 04, 2018 at 09:40:26AM +0100, Stefan Wahren wrote:
>> Am 04.12.18 um 09:31 schrieb Uwe Kleine-König:
>>> The status quo on i.MX6 is that if "over-current-active-high" is
>>> specified in the device tree this is configured as expected. If
>>> the property is missing polarity isn't changed and so the
>>> polarity is kept as setup by the bootloader. Reset default is
>>> active high, so active low can only be used with help by the
>>> bootloader. On i.MX7 it is similar, but there disabling of
>>> over current detection has a similar inconsistency.
>>>
>>> This patch introduces a new property that allows to explicitly
>>> configure for active low over current detection and consistently
>>> sets this up. In the absence of an explicit configuration the
>>> bit is kept as is. On i.MX7 over current detection is used unless
>>> disabled in the device tree.
>>>
>>> Signed-off-by: Uwe Kleine-König 
>>> ---
>>>  .../devicetree/bindings/usb/ci-hdrc-usb2.txt  |  5 ++--
>>>  drivers/usb/chipidea/ci_hdrc_imx.c| 16 ---
>>>  drivers/usb/chipidea/ci_hdrc_imx.h|  8 +-
>>>  drivers/usb/chipidea/usbmisc_imx.c| 28 ++-
>>>  4 files changed, 43 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
>>> b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>>> index 529e51879fb2..c32f6e983cf6 100644
>>> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>>> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>>> @@ -87,8 +87,9 @@ i.mx specific properties
>>>  - fsl,usbmisc: phandler of non-core register device, with one
>>>argument that indicate usb controller index
>>>  - disable-over-current: disable over current detect
>>> -- over-current-active-high: over current signal polarity is high active,
>>> -  typically over current signal polarity is low active.
>>> +- over-current-active-low: over current signal polarity is active low.
>>> +- over-current-active-high: over current signal polarity is active high.
>>> +  It's recommended to specify the over current polarity.
>>>  - external-vbus-divider: enables off-chip resistor divider for Vbus
>>>  
>>>  Example:
>> thanks for making this configurable. But shouldn't this be a separate
>> patch and reviewed by the devicetree guys?
> I'm not sure about the separate patch part. My impression is it depends
> on the maintainer if a change to the binding (opposed to the
> introduction of a binding) should be separate or not.
>
> But for the review you are right, I added the dt people to Cc for them
> to comment. In v2 Matthew also noted that he would prefer to handle the
> situation when both over-current-active-low and over-current-active-high
> were given differently. I think we don't need that as this is a case of
> "broken dt" and it doesn't matter much what is done then. (With my patch
> we're configuring for active high in that case.) A feedback here would
> be great, too.

AFAIR such invalid settings should be catched with a proper error
message and abort of the probing.

Regards
Stefan

>
> Best regards
> Uwe
>

Re: [PATCH v3 1/3] usb: chipidea: imx: support configuring for active low oc signal

[Stefan Wahren]

Hi Uwe,

Am 04.12.18 um 09:31 schrieb Uwe Kleine-König:
> The status quo on i.MX6 is that if "over-current-active-high" is
> specified in the device tree this is configured as expected. If
> the property is missing polarity isn't changed and so the
> polarity is kept as setup by the bootloader. Reset default is
> active high, so active low can only be used with help by the
> bootloader. On i.MX7 it is similar, but there disabling of
> over current detection has a similar inconsistency.
>
> This patch introduces a new property that allows to explicitly
> configure for active low over current detection and consistently
> sets this up. In the absence of an explicit configuration the
> bit is kept as is. On i.MX7 over current detection is used unless
> disabled in the device tree.
>
> Signed-off-by: Uwe Kleine-König 
> ---
>  .../devicetree/bindings/usb/ci-hdrc-usb2.txt  |  5 ++--
>  drivers/usb/chipidea/ci_hdrc_imx.c| 16 ---
>  drivers/usb/chipidea/ci_hdrc_imx.h|  8 +-
>  drivers/usb/chipidea/usbmisc_imx.c| 28 ++-
>  4 files changed, 43 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
> b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> index 529e51879fb2..c32f6e983cf6 100644
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> @@ -87,8 +87,9 @@ i.mx specific properties
>  - fsl,usbmisc: phandler of non-core register device, with one
>argument that indicate usb controller index
>  - disable-over-current: disable over current detect
> -- over-current-active-high: over current signal polarity is high active,
> -  typically over current signal polarity is low active.
> +- over-current-active-low: over current signal polarity is active low.
> +- over-current-active-high: over current signal polarity is active high.
> +  It's recommended to specify the over current polarity.
>  - external-vbus-divider: enables off-chip resistor divider for Vbus
>  
>  Example:

thanks for making this configurable. But shouldn't this be a separate
patch and reviewed by the devicetree guys?

dwc2: scatter-gather support?

[Stefan Wahren]

Hi,

if i connect a UAS capable storage device to the Raspberry Pi, i'm getting the 
following output on 4.18rc:

The driver for the USB controller dwc2_hsotg does not support 
scatter-gather which is
required by the UAS driver. Please try an other USB controller if you wish 
to use UAS.

Are there any plans to implement scatter-gather for dwc2?

Best regards
Stefan
--
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: dwc2: enumeration issue with audio dongle connected to USB hub

[Stefan Wahren]

Hi,

> Stefan Wahren  hat am 2. Mai 2018 um 18:49 
> geschrieben:
> 
> 
> Hi Minas,
> 
> > Minas Harutyunyan  hat am 2. Mai 2018 um 
> > 10:54 geschrieben:
> > 
> > 
> > Hi,
> > 
> > On 4/27/2018 10:03 AM, Stefan Wahren wrote:
> > > Hi,
> > > during my tests with a Raspberry Pi 2 B with an C-Media audio dongle 
> > > connected to a powered USB hub, i noticed the enumeration errors below 
> > > (the device gets finally ernumerated). I tested yesterdays linux-next, 
> > > 4.17-rc2 and 4.14 but all of them show this behavior, if i plugin the 
> > > audio dongle into the USB hub.
> > > 

i retested this setup with next-20180615 and now i get the following output 
(device still enumerate):
after connect and disconnect several times of the audio dongle:

[  121.400211] usb 1-1.4.1.3: new full-speed USB device number 7 using dwc2
[  121.546883] input: C-Media Electronics Inc.   USB PnP Sound Device as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1.3/1-1.4.1.3:1.3/0003:0D8C:013C.0003/input/input4
[  121.611416] hid-generic 0003:0D8C:013C.0003: input: USB HID v1.00 Device 
[C-Media Electronics Inc.   USB PnP Sound Device] on 
usb-3f98.usb-1.4.1.3/input3
[  121.761105] usbcore: registered new interface driver snd-usb-audio
[  133.052028] usb 1-1.4.1.3: USB disconnect, device number 7
[  133.154057] usb 1-1.4.1.3: 1:1: cannot set freq 48000 to ep 0x1
[  133.155655] usb 1-1.4.1.3: 2:1: cannot set freq 48000 to ep 0x82
[  133.158127] usb 1-1.4.1.3: 13:0: cannot get min/max values for control 2 (id 
13)
[  133.159278] usb 1-1.4.1.3: 9:0: cannot get min/max values for control 2 (id 
9)
[  133.160653] usb 1-1.4.1.3: 10:0: cannot get min/max values for control 2 (id 
10)
[  135.990208] usb 1-1.4.1.3: new full-speed USB device number 8 using dwc2
[  136.174266] input: C-Media Electronics Inc.   USB PnP Sound Device as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1.3/1-1.4.1.3:1.3/0003:0D8C:013C.0004/input/input5
[  136.241447] hid-generic 0003:0D8C:013C.0004: input: USB HID v1.00 Device 
[C-Media Electronics Inc.   USB PnP Sound Device] on 
usb-3f98.usb-1.4.1.3/input3
[  141.942016] usb 1-1.4.1.3: USB disconnect, device number 8
[  142.084181] usb 1-1.4.1.3: 1:1: cannot set freq 48000 to ep 0x1
[  142.085715] usb 1-1.4.1.3: 2:1: cannot set freq 48000 to ep 0x82
[  142.088134] usb 1-1.4.1.3: 13:0: cannot get min/max values for control 2 (id 
13)
[  142.089298] usb 1-1.4.1.3: 9:0: cannot get min/max values for control 2 (id 
9)
[  142.090664] usb 1-1.4.1.3: 10:0: cannot get min/max values for control 2 (id 
10)
[  143.930212] usb 1-1.4.1.3: new full-speed USB device number 9 using dwc2
[  144.112908] input: C-Media Electronics Inc.   USB PnP Sound Device as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1.3/1-1.4.1.3:1.3/0003:0D8C:013C.0005/input/input6
[  144.181406] hid-generic 0003:0D8C:013C.0005: input: USB HID v1.00 Device 
[C-Media Electronics Inc.   USB PnP Sound Device] on 
usb-3f98.usb-1.4.1.3/input3
[  148.132026] usb 1-1.4.1.3: USB disconnect, device number 9
[  148.244021] usb 1-1.4.1.3: 1:1: cannot set freq 48000 to ep 0x1
[  148.245506] usb 1-1.4.1.3: 2:1: cannot set freq 48000 to ep 0x82
[  148.247126] usb 1-1.4.1.3: 13:0: cannot get min/max values for control 2 (id 
13)
[  148.248603] usb 1-1.4.1.3: 9:0: cannot get min/max values for control 2 (id 
9)
[  148.250081] usb 1-1.4.1.3: 10:0: cannot get min/max values for control 2 (id 
10)
[  149.560221] usb 1-1.4.1.3: new full-speed USB device number 10 using dwc2
[  149.743422] input: C-Media Electronics Inc.   USB PnP Sound Device as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1.3/1-1.4.1.3:1.3/0003:0D8C:013C.0006/input/input7
[  149.811406] hid-generic 0003:0D8C:013C.0006: input: USB HID v1.00 Device 
[C-Media Electronics Inc.   USB PnP Sound Device] on 
usb-3f98.usb-1.4.1.3/input3
[  151.902017] usb 1-1.4.1.3: USB disconnect, device number 10
[  152.033988] usb 1-1.4.1.3: 1:1: cannot set freq 48000 to ep 0x1
[  152.035524] usb 1-1.4.1.3: 2:1: cannot set freq 48000 to ep 0x82
[  152.037919] usb 1-1.4.1.3: 13:0: cannot get min/max values for control 2 (id 
13)
[  152.039059] usb 1-1.4.1.3: 9:0: cannot get min/max values for control 2 (id 
9)
[  152.040368] usb 1-1.4.1.3: 10:0: cannot get min/max values for control 2 (id 
10)
[  153.150217] usb 1-1.4.1.3: new full-speed USB device number 11 using dwc2
[  153.332898] input: C-Media Electronics Inc.   USB PnP Sound Device as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1.3/1-1.4.1.3:1.3/0003:0D8C:013C.0007/input/input8
[  153.401534] hid-generic 0003:0D8C:013C.0007: input: USB HID v1.00 Device 
[C-Media Electronics Inc.   USB PnP Sound Device] on 
usb-3f98.usb-1.4.1.3/input3
[  156.802020] usb 1-1.4.1.3: USB disconnect, device number 11

Re: [PATCH] usb: gadget: dwc2: fix memory leak in gadget_init()

[Stefan Wahren]

Hi Grigor,

> Grigor Tovmasyan <grigor.tovmas...@synopsys.com> hat am 24. Mai 2018 um 16:22 
> geschrieben:
> 
> 
> Freed allocated request for ep0 to prevent memory leak in case when
> dwc2_driver_probe() failed.
> 
> Signed-off-by: Grigor Tovmasyan <tovma...@synopsys.com>
> Cc: Stefan Wahren <stefan.wah...@i2se.com>
> Cc: Marek Szyprowski <m.szyprow...@samsung.com>

currently i don't much time, but at least my tests with Raspberry Pi Zero W 
were successful.

Tested-by: Stefan Wahren <stefan.wah...@i2se.com>

It would be nice if you can setup some real testing devices at Synopsys in 
order to identify such regressions faster. kernelci.org only tests the host 
role of the Raspberry Pi.

Thanks
Stefan

> ---
>  drivers/usb/dwc2/gadget.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index f0d9ccf1d665..7ccf56da1e50 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -4739,9 +4739,11 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
>   }
>  
>   ret = usb_add_gadget_udc(dev, >gadget);
> - if (ret)
> + if (ret) {
> + dwc2_hsotg_ep_free_request(>eps_out[0]->ep,
> +hsotg->ctrl_req);
>   return ret;
> -
> + }
>   dwc2_hsotg_dump(hsotg);
>  
>   return 0;
> @@ -4755,6 +4757,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
>  int dwc2_hsotg_remove(struct dwc2_hsotg *hsotg)
>  {
>   usb_del_gadget_udc(>gadget);
> + dwc2_hsotg_ep_free_request(>eps_out[0]->ep, hsotg->ctrl_req);
>  
>   return 0;
>  }
> -- 
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 0/2] usb: dwc2: gadget: Fixes for LPM

[Stefan Wahren]

Hi Simon,


Am 07.05.2018 um 14:48 schrieb Simon Shields:

Hi Grigor,

On Wed, May 02, 2018 at 10:12:27AM +, Grigor Tovmasyan wrote:

Hi Simon,

On 4/21/2018 4:52 PM, Simon Shields wrote:

Hi Grigor,

On Fri, Apr 20, 2018 at 01:00:16PM +, Grigor Tovmasyan wrote:

Hi Simon,

On 4/19/2018 8:31 PM, Simon Shields wrote:

Hi all,

On 10/04/2018 10:21 PM, Grigor Tovmasyan wrote:

Here are two little fixes for LPM feature.

First one is coverity warning fix.

The Second one was asserted by Stefan Wahren.

Changes from version 0:

1/2:
   - Instead of converting parameter in the CHECK_RANGE macro
 to int, changed hird_threshold type from u8 to int.


Grigor Tovmasyan (2):
  usb: dwc2: gadget: Fix coverity issue
  usb: dwc2: gadget: Change LPM default values

 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/params.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

The second patch in this series fixes a regression in 4.17-rc1 using dwc2 in 
gadget
mode on Exynos4412, introduced by commit 7455f8b7f0b3 ("usb: dwc2: Enable
LPM"). The regression is that using the cdc_acm serial gadget (and
presumably other gadgets) serial console output will only sporadically
show up on the host (it seems to only show up as input is sent).


The second patch is not fix for described by you issue. We will try to
reproduce your issue and provide fix. Could you provide some logs or usb
traces for issue?

Here's a log[0]. The log is pretty big: I generated it with both regular and 
verbose
debugging enabled for DWC2. However, I suspect the relevant line is
probably:

[   95.222330] dwc2 1248.hsotg: dwc2_hsotg_ep_queue: submit request only in 
active state

Which occurs whenever the controller is in LPM mode. I guess that input
makes it "work" because it reawakens the controller -- but I'm just
spitballing :-). Let me know if you need any more information from my
side.

[0]: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__forkwhiletrue.me_-7Esimon_midas-5Fdwc2-5Flpm-5Fverbose.log=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ=fkdnWR9_dgHLGH5-mN9lDclJ58GWR__m7hS3zz3am28=aind-wCFaB40EyTcHvphrqt6SngQTnf3CYXJxOfBjWc=


However, I'm unsure if completely disabling LPM is the correct fix, as the dwc2
revision in Exynos4412 (0x4f54281a) should support LPM according to the
source

Yes, we can enable LPM based on hardware configuration.


I'm not really sure how to debug this any further (vendor kernel
releases contain no mention of LPM in the gadget drivers), so any pointers
in that direction would be much appreciated.

Cheers,
Simon


Cheers,
Simon


Could you please revert "usb: dwc2: Add core state checking" patch and
try again.

This doesn't really fix the issue, but it does change the results. Now, input 
works
as expected, but output is still only shown after input is given (e.g.
the output of "dmesg" only shows if I press a key after executing dmesg).
However, after a few seconds the USB serial device disappears from the
host entirely. Once this has happened, reading the "regdump" of dwc2's debugfs
appears to hang the system (i.e. it no longer responds to UART). I've attached
another log[0].


the regdump is broken. Please try my patch [1]

Stefan

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

[PATCH] usb: dwc2: debugfs: Don't touch RX FIFO during register dump

[Stefan Wahren]

Dumping the registers via debugfs makes USB on Raspberry Pi completely
unusable. The read of register GRXSTSP ("Receive Status Read and Pop
Register") is responsible for this behaviour, because it pops the RX FIFO.
So avoid this by omitting the relevant register.

CC: Mian Yousaf Kaukab <yousaf.kau...@intel.com>
Fixes: 563cf017c443 ("usb: dwc2: debugfs: add support for complete register 
dump")
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c
index 58c691f..d4c0589 100644
--- a/drivers/usb/dwc2/debugfs.c
+++ b/drivers/usb/dwc2/debugfs.c
@@ -368,7 +368,7 @@ static const struct debugfs_reg32 dwc2_regs[] = {
dump_register(GINTSTS),
dump_register(GINTMSK),
dump_register(GRXSTSR),
-   dump_register(GRXSTSP),
+   /* Omit GRXSTSP */
dump_register(GRXFSIZ),
dump_register(GNPTXFSIZ),
dump_register(GNPTXSTS),
-- 
2.7.4

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

Re: dwc2: enumeration issue with audio dongle connected to USB hub

[Stefan Wahren]

Hi Minas,

> Minas Harutyunyan <minas.harutyun...@synopsys.com> hat am 2. Mai 2018 um 
> 10:54 geschrieben:
> 
> 
> Hi,
> 
> On 4/27/2018 10:03 AM, Stefan Wahren wrote:
> > Hi,
> > during my tests with a Raspberry Pi 2 B with an C-Media audio dongle 
> > connected to a powered USB hub, i noticed the enumeration errors below (the 
> > device gets finally ernumerated). I tested yesterdays linux-next, 4.17-rc2 
> > and 4.14 but all of them show this behavior, if i plugin the audio dongle 
> > into the USB hub.
> > 
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> >  |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
> >  |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
> > Driver=smsc95xx, 480M
> >  |__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
> >  |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
> >  |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
> >  |__ Port 3: Dev 8, If 3, Class=Human Interface Device, 
> > Driver=usbhid, 12M
> >  |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
> >  |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
> >  |__ Port 4: Dev 7, If 1, Class=Human Interface Device, 
> > Driver=usbhid, 1.5M
> >  |__ Port 4: Dev 7, If 0, Class=Human Interface Device, 
> > Driver=usbhid, 1.5M
> > 
> > The verbose version can be found here:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_lategoodbye_baa0f8890325f8698664aeb60ecedfd5=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8=oor4Ij_LNZepp0TZuefnbqFJacQjGXIOEk_BRVa4Vf8=qbdE3PnqX9pigSEbMTqXPeSItGUGJTIOVUapC-fZXdg=
> > 
> > Here is an example dmesg after plugin the audio dongle:
> > [ 1176.382877] usb 1-1.2.1.3: new full-speed USB device number 14 using dwc2
> > [ 1176.516254] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - 
> > ChHltd set, but reason is unknown
> > [ 1176.516284] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1176.516355] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - 
> > ChHltd set, but reason is unknown
> > [ 1176.516372] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1176.516427] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - 
> > ChHltd set, but reason is unknown
> > [ 1176.516442] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.518435] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - 
> > ChHltd set, but reason is unknown
> > [ 1176.518464] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.518532] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - 
> > ChHltd set, but reason is unknown
> > [ 1176.518549] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.518605] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - 
> > ChHltd set, but reason is unknown
> > [ 1176.518623] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1176.520704] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - 
> > ChHltd set, but reason is unknown
> > [ 1176.520734] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.520802] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - 
> > ChHltd set, but reason is unknown
> > [ 1176.520820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.520887] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - 
> > ChHltd set, but reason is unknown
> > [ 1176.520905] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.521127] usb 1-1.2.1.3: unable to read config index 0 descriptor/all
> > [ 1176.521197] usb 1-1.2.1.3: can't read configurations, error -71
> > [ 1176.632956] usb 1-1.2.1.3: new full-speed USB device number 15 using dwc2
> > [ 1176.763789] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - 
> > ChHltd set, but reason is unknown
> > [ 1176.763820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.763890] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - 
> > ChHltd set, but reason is unknown
> > [ 1176.763909] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.763998] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - 
> > ChHltd set, but reason is unknown
> > [ 1176.764016] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1177.012371] input: C-Media Electronics Inc.   USB PnP Sound Device 
> > as 
> > /devices/platform/soc/2098.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1.3/1-1.2.1.3

net: smsc95xx: aligment issues

[Stefan Wahren]

Hi,
after connecting a Raspberry Pi 1 B to my local network i'm seeing aligment 
issues under /proc/cpu/alignment:

User:   0
System: 142 (_decode_session4+0x12c/0x3c8)
Skipped:0
Half:   0
Word:   0
DWord:  127
Multi:  15
User faults:2 (fixup)

I've also seen outputs with _csum_ipv6_magic.

Kernel config: bcm2835_defconfig
Reproducible kernel trees: current linux-next, 4.17-rc2 and 4.14.37 (i didn't 
test older versions)

Please tell if you need more information to narrow down this issue.

Best regards
Stefan
--
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

dwc2: enumeration issue with audio dongle connected to USB hub

[Stefan Wahren]

Hi,
during my tests with a Raspberry Pi 2 B with an C-Media audio dongle connected 
to a powered USB hub, i noticed the enumeration errors below (the device gets 
finally ernumerated). I tested yesterdays linux-next, 4.17-rc2 and 4.14 but all 
of them show this behavior, if i plugin the audio dongle into the USB hub.

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 
480M
|__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 3, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 7, If 1, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 4: Dev 7, If 0, Class=Human Interface Device, 
Driver=usbhid, 1.5M

The verbose version can be found here:
https://gist.github.com/lategoodbye/baa0f8890325f8698664aeb60ecedfd5

Here is an example dmesg after plugin the audio dongle:
[ 1176.382877] usb 1-1.2.1.3: new full-speed USB device number 14 using dwc2
[ 1176.516254] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd 
set, but reason is unknown
[ 1176.516284] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
[ 1176.516355] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd 
set, but reason is unknown
[ 1176.516372] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
[ 1176.516427] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd 
set, but reason is unknown
[ 1176.516442] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.518435] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd 
set, but reason is unknown
[ 1176.518464] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.518532] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd 
set, but reason is unknown
[ 1176.518549] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.518605] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd 
set, but reason is unknown
[ 1176.518623] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
[ 1176.520704] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd 
set, but reason is unknown
[ 1176.520734] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.520802] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd 
set, but reason is unknown
[ 1176.520820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.520887] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd 
set, but reason is unknown
[ 1176.520905] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.521127] usb 1-1.2.1.3: unable to read config index 0 descriptor/all
[ 1176.521197] usb 1-1.2.1.3: can't read configurations, error -71
[ 1176.632956] usb 1-1.2.1.3: new full-speed USB device number 15 using dwc2
[ 1176.763789] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd 
set, but reason is unknown
[ 1176.763820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.763890] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd 
set, but reason is unknown
[ 1176.763909] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
[ 1176.763998] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd 
set, but reason is unknown
[ 1176.764016] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
[ 1177.012371] input: C-Media Electronics Inc.   USB PnP Sound Device as 
/devices/platform/soc/2098.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1.3/1-1.2.1.3:1.3/0003:0D8C:013C.0008/input/input7
[ 1177.088948] hid-generic 0003:0D8C:013C.0008: input: USB HID v1.00 Device 
[C-Media Electronics Inc.   USB PnP Sound Device] on 
usb-2098.usb-1.2.1.3/input3

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

Re: [PATCH] usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

[Stefan Wahren]

Am 23.04.2018 um 09:05 schrieb Grigor Tovmasyan:

Hi Stefan,

On 4/18/2018 1:11 AM, Stefan Wahren wrote:

Hi Grigor,


Grigor Tovmasyan <grigor.tovmas...@synopsys.com> hat am 16. April 2018 um 12:16 
geschrieben:


In dwc2_gadget_init() we allocate EP0 request via
dwc2_hsotg_ep_alloc_request(). After that there are
usb_add_gadget_udc() call and if it failed, then
ctrl_req will not be freed and will cause memory leak.

Reordered function calls in gadget_init: moved up usb_add_gadget_udc()
before dwc2_hsotg_ep_alloc_request().

i'm not sure, but doesn't this change introduce a race condition before EP0 
request has been allocated?

As far as I know the firt request to EP0 coming when the function driver
first bind() to the device, which happens after dwc2 probe.
So, in my opinion this patch is safe.

okay fine


Grigor

Stefan


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

Re: [PATCH] usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

[Stefan Wahren]

Hi Grigor,

> Grigor Tovmasyan  hat am 16. April 2018 um 
> 12:16 geschrieben:
> 
> 
> In dwc2_gadget_init() we allocate EP0 request via
> dwc2_hsotg_ep_alloc_request(). After that there are
> usb_add_gadget_udc() call and if it failed, then
> ctrl_req will not be freed and will cause memory leak.
> 
> Reordered function calls in gadget_init: moved up usb_add_gadget_udc()
> before dwc2_hsotg_ep_alloc_request().

i'm not sure, but doesn't this change introduce a race condition before EP0 
request has been allocated?

Stefan
--
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: dwc2: Memory leak in dwc2_gadget_init

[Stefan Wahren]

Hi Grigor,

> Grigor Tovmasyan <grigor.tovmas...@synopsys.com> hat am 9. April 2018 um 
> 18:42 geschrieben:
> 
> 
> Hi Stefan,
> 
> On 4/2/2018 12:59 PM, Stefan Wahren wrote:
> > Hi Minas,
> > 
> > i noticed that in opposite to all allocations in dwc2_gadget_init() the 
> > function dwc2_hsotg_ep_alloc_request() uses kzalloc. So in case 
> > usb_add_gadget_udc() would fail, the memory of the USB request would be 
> > leaked:
> > 
> > Linux raspberrypi 4.16.0-rc7-next-20180327+ #2 SMP PREEMPT Sat Mar 31 
> > 13:24:47 CEST 2018 armv6l GNU/Linux
> 
> Sorry for late reply.
> Could you please tell me which tool you use for checking memory leak?

there is no additional tool required. Just enable the following settings in the 
kernel config:

Kernel hacking  --->
  Memory Debugging  --->
[*] Kernel memory leak detector (CONFIG_DEBUG_KMEMLEAK=y)
(1400) Maximum kmemleak early log entries 
(CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=1400)

The log entries depends on your system, these are the settings for an Raspberry 
Pi. The detector noticed only leaks that has been triggered AFTER 10 minutes.

> I prepared the patch and wanted to check it.

So in order to reproduce this issue you will need to make probing fail at the 
same point.

Please follow this patch [1] and this bootlog [2] for more context.

Thanks
Stefan

[1] - https://www.spinics.net/lists/linux-usb/msg167472.html
[2] - 
https://storage.kernelci.org/next/master/next-20180409/arm/bcm2835_defconfig/lab-baylibre/boot-bcm2837-rpi-3-b.txt

> 
> Thanks,
> Grigor.
> 
> > 
> > unreferenced object 0xd8703cc0 (size 64):
> >comm "kworker/0:1", pid 18, jiffies 4294937977 (age 2780.490s)
> >hex dump (first 32 bytes):
> >  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> >  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> >backtrace:
> >  [<09023b43>] kmemleak_alloc+0x78/0xc0
> >  [<60182b94>] kmem_cache_alloc_trace+0x150/0x398
> >  [] dwc2_hsotg_ep_alloc_request+0x34/0x58
> >  [<401a2371>] dwc2_gadget_init+0x32c/0x3ec
> >  [<2b1d6850>] dwc2_driver_probe+0x320/0x418
> >  [<765bc59d>] platform_drv_probe+0x60/0xac
> >  [<65e4f320>] driver_probe_device+0x2d4/0x46c
> >  [<57a8c266>] __device_attach_driver+0xb0/0x104
> >  [<14964192>] bus_for_each_drv+0x98/0xa0
> >  [<34c644b4>] __device_attach+0xb0/0x13c
> >  [] device_initial_probe+0x1c/0x20
> >  [] bus_probe_device+0x38/0x94
> >  [<550305ed>] deferred_probe_work_func+0x12c/0x14c
> >  [<681db7c3>] process_one_work+0x3c8/0x76c
> >  [<818bc895>] process_scheduled_works+0x38/0x3c
> >  [<0dd47435>] worker_thread+0x2c4/0x43c
> > 
> > Best regards
> > Stefan
> > --
> > 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  
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ=i65dP-5DLfIelHtOk6TiLygqXtfp5tcq2CKdocriNto=EijYUhFJlFmz34zKw20t_Hq5TQHZoWJIbNmjpj2H7N8=
> > 
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] usb: dwc2: gadget: Fixes for LPM

[Stefan Wahren]

Hi Grigor,

Am 03.04.2018 um 13:21 schrieb Grigor Tovmasyan:

Here are two little fixes for LPM feature.

First one is coverity warning fix.

The Second one was asserted by Stefan Wahren.


AFAIK Minas Harutyunyan is the new maintainer of dwc2. So this series 
should go to him.


Regards
Stefan




Grigor Tovmasyan (2):
   usb: dwc2: gadget: Fix coverity issue
   usb: dwc2: gadget: Change default values

  drivers/usb/dwc2/params.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)



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

Re: [PATCH] usb: core: phy: Fix usb_phy_roothub_add_phy if GENERIC_PHY=n

[Stefan Wahren]

Hi Martin,

> Martin Blumenstingl <martin.blumensti...@googlemail.com> hat am 31. März 2018 
> um 22:12 geschrieben:
> 
> 
> Hello Stefan,
> 
> On Sat, Mar 31, 2018 at 9:28 PM, Stefan Wahren <stefan.wah...@i2se.com> wrote:
> > If the generic PHY support is disabled the stub of devm_of_phy_get_by_index
> > returns ENOSYS. This corner case isn't handled properly by
> > usb_phy_roothub_add_phy and at least breaks USB support on Raspberry Pi
> > (bcm2835_defconfig):
> >
> > dwc2 2098.usb: dwc2_hcd_init() FAILED, returning -38
> > dwc2: probe of 2098.usb failed with error -38
> thank you for reporting and proposing a fix!
> 
> > Fixes: 07dbff0ddbd8 ("usb: core: add a wrapper for the USB PHYs on the HCD")
> > Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
> > ---
> >  drivers/usb/core/phy.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
> > index 09b7c43..c89e9be 100644
> > --- a/drivers/usb/core/phy.c
> > +++ b/drivers/usb/core/phy.c
> > @@ -39,7 +39,7 @@ static int usb_phy_roothub_add_phy(struct device *dev, 
> > int index,
> > struct phy *phy = devm_of_phy_get_by_index(dev, dev->of_node, 
> > index);
> >
> > if (IS_ERR_OR_NULL(phy)) {
> > -   if (!phy || PTR_ERR(phy) == -ENODEV)
> > +   if (!phy || PTR_ERR(phy) == -ENODEV || PTR_ERR(phy) == 
> > -ENOSYS)
> > return 0;
> > else
> > return PTR_ERR(phy);
> > --
> > 2.7.4
> I have three patches pending, one of them (the patch from [1]) touches
> the same function:
> - "usb: core: phy: fix return value of usb_phy_roothub_exit()" [0]
> - "usb: core: split usb_phy_roothub_{init, alloc}" [1]
> - "usb: core: use phy_exit during suspend if wake up is not supported" [2]
> 
> maybe we should make it more explicit that the whole code is only
> useful if CONFIG_GENERIC_PHY is enabled
> what do you think about adding the following two lines at the
> beginning of usb_phy_roothub_alloc (after patch [1] is applied, before
> this function was basically called usb_phy_roothub_init)
> if (!IS_ENABLED(CONFIG_GENERIC_PHY))
> return NULL;
> 
> this should even allow the compiler to optimize away some unused code

sounds reasonable to me.

Regards
Stefan

> 
> 
> Regards
> Martin
> 
> 
> [0] https://patchwork.kernel.org/patch/10306053/
> [1] https://patchwork.kernel.org/patch/10311701/
> [2] https://patchwork.kernel.org/patch/10311703/
--
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: dwc2: Confusing warnings in next-20180327 on Raspberry Pi

[Stefan Wahren]

Hi Grigor,

> Grigor Tovmasyan <grigor.tovmas...@synopsys.com> hat am 2. April 2018 um 
> 18:00 geschrieben:
> 
> 
> Hi Stefan,
> 
> On 4/2/2018 7:47 PM, Stefan Wahren wrote:
> > Hi Minas,
> > 
> > in linux-next-20180327 i will get the following confusing warnings on the 
> > Raspberry Pi:
> > 
> > Linux raspberrypi 4.16.0-rc7-next-20180327+ #2 SMP PREEMPT Sat Mar 31 
> > 13:24:47 CEST 2018 armv6l GNU/Linux
> > 
> > [6.809185] dwc2 2098.usb: dwc2_check_params: Invalid parameter lpm=1
> > [6.816741] dwc2 2098.usb: dwc2_check_params: Invalid parameter 
> > lpm_clock_gating=1
> > [6.825852] dwc2 2098.usb: dwc2_check_params: Invalid parameter 
> > besl=1
> > [6.833836] dwc2 2098.usb: dwc2_check_params: Invalid parameter 
> > hird_threshold_en=1
> > 
> > I think the reason is that these features aren't supported.
> 
> Yes. By default LPM feature enabled in dwc2  driver, and if  hardware 
> does not support LPM feature this warning are asserting.

thanks for your fast reply. These warnings aren't acceptable, because users 
think there is something wrong with the driver.

As the driver is able to detect the support of this feature, we can avoid this.

Stefan

> 
> > 
> > DWC2 core: 2.80a
> > 
> > Extract of the BCM2835 datasheet:
> > LPM Mode of Operation: 0 (Non-LPM-capable core)
> > Enable Power Optimization: No
> > 
> > I hope we can suppress these confusing warnings. >
> > Best regards
> > Stefan
> > --
> > 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  
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ=p8QSzOQ6Jl5b4edTsdasqPqOC-ZomQDDvkluCvJItpU=u8I6yUuioJrmqhLWhxbAkQbxnCvYXqyPqqpZSzxp0UU=
> > 
> 
> Thanks,
> Grigor.
--
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

dwc2: Confusing warnings in next-20180327 on Raspberry Pi

[Stefan Wahren]

Hi Minas,

in linux-next-20180327 i will get the following confusing warnings on the 
Raspberry Pi:

Linux raspberrypi 4.16.0-rc7-next-20180327+ #2 SMP PREEMPT Sat Mar 31 13:24:47 
CEST 2018 armv6l GNU/Linux

[6.809185] dwc2 2098.usb: dwc2_check_params: Invalid parameter lpm=1
[6.816741] dwc2 2098.usb: dwc2_check_params: Invalid parameter 
lpm_clock_gating=1
[6.825852] dwc2 2098.usb: dwc2_check_params: Invalid parameter besl=1
[6.833836] dwc2 2098.usb: dwc2_check_params: Invalid parameter 
hird_threshold_en=1

I think the reason is that these features aren't supported.

DWC2 core: 2.80a

Extract of the BCM2835 datasheet:
LPM Mode of Operation: 0 (Non-LPM-capable core)
Enable Power Optimization: No

I hope we can suppress these confusing warnings.

Best regards
Stefan
--
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

dwc2: Memory leak in dwc2_gadget_init

[Stefan Wahren]

Hi Minas,

i noticed that in opposite to all allocations in dwc2_gadget_init() the 
function dwc2_hsotg_ep_alloc_request() uses kzalloc. So in case 
usb_add_gadget_udc() would fail, the memory of the USB request would be leaked:

Linux raspberrypi 4.16.0-rc7-next-20180327+ #2 SMP PREEMPT Sat Mar 31 13:24:47 
CEST 2018 armv6l GNU/Linux

unreferenced object 0xd8703cc0 (size 64):
  comm "kworker/0:1", pid 18, jiffies 4294937977 (age 2780.490s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[<09023b43>] kmemleak_alloc+0x78/0xc0
[<60182b94>] kmem_cache_alloc_trace+0x150/0x398
[] dwc2_hsotg_ep_alloc_request+0x34/0x58
[<401a2371>] dwc2_gadget_init+0x32c/0x3ec
[<2b1d6850>] dwc2_driver_probe+0x320/0x418
[<765bc59d>] platform_drv_probe+0x60/0xac
[<65e4f320>] driver_probe_device+0x2d4/0x46c
[<57a8c266>] __device_attach_driver+0xb0/0x104
[<14964192>] bus_for_each_drv+0x98/0xa0
[<34c644b4>] __device_attach+0xb0/0x13c
[] device_initial_probe+0x1c/0x20
[] bus_probe_device+0x38/0x94
[<550305ed>] deferred_probe_work_func+0x12c/0x14c
[<681db7c3>] process_one_work+0x3c8/0x76c
[<818bc895>] process_scheduled_works+0x38/0x3c
[<0dd47435>] worker_thread+0x2c4/0x43c

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

[PATCH] usb: core: phy: Fix usb_phy_roothub_add_phy if GENERIC_PHY=n

[Stefan Wahren]

If the generic PHY support is disabled the stub of devm_of_phy_get_by_index
returns ENOSYS. This corner case isn't handled properly by
usb_phy_roothub_add_phy and at least breaks USB support on Raspberry Pi
(bcm2835_defconfig):

dwc2 2098.usb: dwc2_hcd_init() FAILED, returning -38
dwc2: probe of 2098.usb failed with error -38

Fixes: 07dbff0ddbd8 ("usb: core: add a wrapper for the USB PHYs on the HCD")
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/core/phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index 09b7c43..c89e9be 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -39,7 +39,7 @@ static int usb_phy_roothub_add_phy(struct device *dev, int 
index,
struct phy *phy = devm_of_phy_get_by_index(dev, dev->of_node, index);
 
if (IS_ERR_OR_NULL(phy)) {
-   if (!phy || PTR_ERR(phy) == -ENODEV)
+   if (!phy || PTR_ERR(phy) == -ENODEV || PTR_ERR(phy) == -ENOSYS)
return 0;
else
return PTR_ERR(phy);
-- 
2.7.4

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

Re: [PATCH] usb: dwc2: Print error if unable to set DMA coherent mask

[Stefan Wahren]

> Stefan Wahren <stefan.wah...@i2se.com> hat am 12. Februar 2018 um 21:20 
> geschrieben:
> 
> 
> We better print an error in case probing of dwc2 fails on
> setting the DMA coherent mask.
> 
> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
> ---
>  drivers/usb/dwc2/platform.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 4703478..4ddbdbd 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -382,8 +382,10 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   if (!dev->dev.dma_mask)
>   dev->dev.dma_mask = >dev.coherent_dma_mask;
>   retval = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> - if (retval)
> + if (retval) {
> + dev_err(>dev, "can't set coherent DMA mask: %d\n", retval);
>   return retval;
> + }
>  
>   res = platform_get_resource(dev, IORESOURCE_MEM, 0);
>   hsotg->regs = devm_ioremap_resource(>dev, res);
> -- 
> 2.7.4
>

ping ...
--
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: Continuous USB resets on NXP i.MX 6ULL device

[Stefan Wahren]

Am 02.03.2018 um 04:03 schrieb Peter Chen:
  

For non-core registers, i.mx6ull can use i.mx6q as its base setting,
the bits you mentioned may also be reserved at imx6qdl RM.


just for my understanding: MX6_BM_NON_BURST_SETTING is a no-op on
i.MX6ULL or not properly documented in reference manual?

Not properly documented in reference manual.

Peter


Thanks, okay back to topic

@Stefan: Did you try to disable over-current detection via DT?
--
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: Continuous USB resets on NXP i.MX 6ULL device

[Stefan Wahren]

Hi Peter,

Am 01.03.2018 um 03:00 schrieb Peter Chen:
> On Wed, Feb 28, 2018 at 06:08:20PM +0100, Stefan Wahren wrote:
>> Hi,
>>
>> i'm not sure this is related, but i noticed something ugly in
>> driver/usb/chipidea/usbmisc_imx.c.
>>
>> The compatible "fsl,imx6ul-usbmisc" uses imx6sx_usbmisc_ops, which uses
>> usbmisc_imx6sx_init (which also calls usbmisc_imx6q_init).
>> Within usbmisc_imx6q_init the flag MX6_BM_NON_BURST_SETTING is enabled.
>>
>> But according to the i.MX6 ULL reference manual this bit is marked as
>> reserved and set to zero at reset.
>>
> For non-core registers, i.mx6ull can use i.mx6q as its base setting, the
> bits you mentioned may also be reserved at imx6qdl RM.
>
just for my understanding: MX6_BM_NON_BURST_SETTING is a no-op on
i.MX6ULL or not properly documented in reference manual?

--
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: Continuous USB resets on NXP i.MX 6ULL device

[Stefan Wahren]

Hi,

i'm not sure this is related, but i noticed something ugly in
driver/usb/chipidea/usbmisc_imx.c.

The compatible "fsl,imx6ul-usbmisc" uses imx6sx_usbmisc_ops, which uses
usbmisc_imx6sx_init (which also calls usbmisc_imx6q_init).
Within usbmisc_imx6q_init the flag MX6_BM_NON_BURST_SETTING is enabled.

But according to the i.MX6 ULL reference manual this bit is marked as
reserved and set to zero at reset.

So i think it would be better to have separate imx6ul_usbmisc_ops.

Regards
Stefan

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

[PATCH] usb: dwc2: Print error if unable to set DMA coherent mask

[Stefan Wahren]

We better print an error in case probing of dwc2 fails on
setting the DMA coherent mask.

Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/platform.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4703478..4ddbdbd 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -382,8 +382,10 @@ static int dwc2_driver_probe(struct platform_device *dev)
if (!dev->dev.dma_mask)
dev->dev.dma_mask = >dev.coherent_dma_mask;
retval = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
-   if (retval)
+   if (retval) {
+   dev_err(>dev, "can't set coherent DMA mask: %d\n", retval);
return retval;
+   }
 
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
hsotg->regs = devm_ioremap_resource(>dev, res);
-- 
2.7.4

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

Re: [PATCH] usb: dwc2: Fix endless deferral probe

[Stefan Wahren]

Am 12.01.2018 um 00:32 schrieb Arnd Bergmann:

On Wed, Jan 10, 2018 at 1:15 PM, Stefan Wahren <stefan.wah...@i2se.com> wrote:

Hi Arnd,


Am 09.01.2018 um 22:33 schrieb Arnd Bergmann:

On Tue, Jan 9, 2018 at 8:28 PM, Stefan Wahren <stefan.wah...@i2se.com>
wrote:

The dwc2 USB driver tries to find a generic PHY first and then look
for an old style USB PHY. In case of a valid generic PHY node without
a PHY driver, the PHY layer will return -EPROBE_DEFER forever. So dwc2
will never tries for an USB PHY.

Fix this issue by finding a generic PHY and an old style USB PHY
at once.

This would fix only one of the USB controllers (dwc2), but not the others
that are affected. As I wrote in my suggested patch, dwc3 appears to be
affected the same way, and all other host drivers that call usb_add_hcd()
without first setting hcd->phy would suffer from this as well.

If we go down the route of addressing it here in the hcd drivers, we
should
at least change all three of those, and hope this doesn't regress in
another way.

 Arnd


i fully unterstand. But we leaving the path of "fixing a critical issue on
BCM2835" and go to "fixing multiple USB host controller". I do this all in
my spare time and don't have any of the other USB controller available. So
before i proceed with any other patch i like so see some feedback from John,
Greg or Felipe.

After finalizing this patch i think the chance is little that this would be
applied to 4.15. So i seems to me that we still revert my DT clean up patch.

Could you confirm that this simpler patch fixes the problem for  you?
My feeling right now is that this would be the least invasive variant.
This is obviously a critical regression for BCM2835, but I'm fairly sure
it's just as critical for a lot of other SoCs that haven't done as much
testing on linux-next.


Even worse arm64 and mips could be affected, too.



Hans has already verified the earlier (more complex) version, but my
analysis today has made it very likely that this one is fully sufficient
to fix all affected platforms.

Reverting all nine patches that add #phy-cells would still be an option,
but seems way more invasive at this point.

Arnd

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..93b55fb71d54 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node
*np, int index)
 if (ret)
 return ERR_PTR(-ENODEV);

+   /* This phy type handled by the usb-phy subsystem for now */
+   if (of_device_is_compatible(np, "usb-nop-xceiv"))
+   return ERR_PTR(-ENODEV);
+
 mutex_lock(_provider_mutex);
 phy_provider = of_phy_provider_lookup(args.np);
 if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {


I tried this, but it doesn't work. "np" is the node of the USB 
controller, not of the phy?

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

Re: [PATCH] usb: dwc2: Fix endless deferral probe

[Stefan Wahren]

Hi Arnd,

Am 09.01.2018 um 22:33 schrieb Arnd Bergmann:

On Tue, Jan 9, 2018 at 8:28 PM, Stefan Wahren <stefan.wah...@i2se.com> wrote:

The dwc2 USB driver tries to find a generic PHY first and then look
for an old style USB PHY. In case of a valid generic PHY node without
a PHY driver, the PHY layer will return -EPROBE_DEFER forever. So dwc2
will never tries for an USB PHY.

Fix this issue by finding a generic PHY and an old style USB PHY
at once.

This would fix only one of the USB controllers (dwc2), but not the others
that are affected. As I wrote in my suggested patch, dwc3 appears to be
affected the same way, and all other host drivers that call usb_add_hcd()
without first setting hcd->phy would suffer from this as well.

If we go down the route of addressing it here in the hcd drivers, we should
at least change all three of those, and hope this doesn't regress in
another way.

Arnd


i fully unterstand. But we leaving the path of "fixing a critical issue 
on BCM2835" and go to "fixing multiple USB host controller". I do this 
all in my spare time and don't have any of the other USB controller 
available. So before i proceed with any other patch i like so see some 
feedback from John, Greg or Felipe.


After finalizing this patch i think the chance is little that this would 
be applied to 4.15. So i seems to me that we still revert my DT clean up 
patch.


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

Re: [PATCH v3 00/49] usb: dwc2: fixes, enhancements and new features

[Stefan Wahren]

Hi Razmik,

> Razmik Karapetyan <razmik.karapet...@synopsys.com> hat am 8. Januar 2018 um 
> 13:40 geschrieben:
> 
> 
> On 12/31/2017 9:19 PM, Stefan Wahren wrote:
> 
> Hi Stefan,
> 
> >>
> >> Razmik Karapetyan (10):
> >>usb: dwc2: Set AHB burst size to INCR
> > 
> > The usage hsotg->params.ahbcfg instead of the defines is a unintended fix 
> > for BCM2835. According to the BCM2835 datasheet this register have a 
> > different definition. So i like to see this split up.
> > 
> 
> This patch sets AHB burst size by default to INCR, but it can be 
> customized later for each platform by device match table. For BSM you 
> have dwc2_set_bcm_params() function.
> 
> Patch also uses already calculated value for burst size 
> "hsotg->params.ahbcfg" in dwc2_hsotg_core_init_disconnected()
> instead of calculating the same value again.
> 
> What kind of problems you see here?

the problem is there is no AHB burst size on BCM2835.

Quote from BCM2835 datasheet (p. 204):

  The USB_GAHBCFG register has been adapted. Bits [4:1] which are marked in the 
Synopsys
  documentation as "Burst Length/Type (HBstLen)" have been used differently.

Your patch is doing two different things, which should better be split up. So 
in case of a revert only one part is affected.

Stefan

> 
> >>usb: dwc2: Define PCGCCTL1 register in hw.h
> >>usb: dwc2: Define Active Clock Gating support bit in GHWCFG4
> > 
> > I think this one should be merged into the first patch which uses this 
> > define.
> > 
> 
> I am ok with this observation, i will change it.
> 
> Best regards,
> Razmik
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: dwc2: Fix endless deferral probe

[Stefan Wahren]

The dwc2 USB driver tries to find a generic PHY first and then look
for an old style USB PHY. In case of a valid generic PHY node without
a PHY driver, the PHY layer will return -EPROBE_DEFER forever. So dwc2
will never tries for an USB PHY.

Fix this issue by finding a generic PHY and an old style USB PHY
at once.

Fixes: 6c2dad69163f ("usb: dwc2: Return errors from PHY")
Link: https://marc.info/?l=linux-usb=151518314314753=2
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/platform.c | 42 --
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 3e26550..5279567 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -225,10 +225,11 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
hsotg->phyif = GUSBCFG_PHYIF16;
 
/*
-* Attempt to find a generic PHY, then look for an old style
-* USB PHY and then fall back to pdata
+* Attempt to find a generic PHY or an old style USB PHY at once
+* otherwise fall back to pdata
 */
hsotg->phy = devm_phy_get(hsotg->dev, "usb2-phy");
+   hsotg->uphy = devm_usb_get_phy(hsotg->dev, USB_PHY_TYPE_USB2);
if (IS_ERR(hsotg->phy)) {
ret = PTR_ERR(hsotg->phy);
switch (ret) {
@@ -237,29 +238,34 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
hsotg->phy = NULL;
break;
case -EPROBE_DEFER:
-   return ret;
+   if (IS_ERR(hsotg->uphy))
+   return ret;
+
+   hsotg->phy = NULL;
+   break;
default:
dev_err(hsotg->dev, "error getting phy %d\n", ret);
return ret;
}
}
 
-   if (!hsotg->phy) {
-   hsotg->uphy = devm_usb_get_phy(hsotg->dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(hsotg->uphy)) {
-   ret = PTR_ERR(hsotg->uphy);
-   switch (ret) {
-   case -ENODEV:
-   case -ENXIO:
-   hsotg->uphy = NULL;
-   break;
-   case -EPROBE_DEFER:
-   return ret;
-   default:
-   dev_err(hsotg->dev, "error getting usb phy 
%d\n",
-   ret);
+   if (IS_ERR(hsotg->uphy)) {
+   ret = PTR_ERR(hsotg->uphy);
+   switch (ret) {
+   case -ENODEV:
+   case -ENXIO:
+   hsotg->uphy = NULL;
+   break;
+   case -EPROBE_DEFER:
+   if (!hsotg->phy)
return ret;
-   }
+
+   hsotg->uphy = NULL;
+   break;
+   default:
+   dev_err(hsotg->dev, "error getting usb phy %d\n",
+   ret);
+   return ret;
}
}
 
-- 
2.7.4

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

[Bug] Endless deferred probe of dwc2 on RPi 3

[Stefan Wahren]

Hi,
i noticed on my Raspberry Pi 3 (Linux 4.15rc6, ARM64, defconfig) that probing 
of dwc2 driver is deferred endlessly. This issue is triggered by a recent DT 
clean up 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing 
phy-cells") which is correct according to 
Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt

Here is the call stack which always returns -EPROBE_DEFER on this platform:
dwc2_lowlevel_hw_init()
devm_phy_get()
phy_get()
_of_phy_get()

Btw Raspberry Pi 2 (ARM, multi_v7_defconfig) is also affected, but not 
Raspberry Pi Zero W (ARM, bcm2835_config) while all 3 platforms share the same 
USB DT nodes.

Any ideas to fix this issue are welcome.

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

Re: [PATCH v3 00/49] usb: dwc2: fixes, enhancements and new features

[Stefan Wahren]

Hi Grigor,

sorry for misusing the cover letter for my comments, but i didn't received all 
patches.

> Grigor Tovmasyan  hat am 26. Dezember 2017 um 
> 12:21 geschrieben:
> 
> 
> ...
> 
> Gevorg Sahakyan (1):
>   usb: dwc2: Remove version check in GSNPSID
> 
> Grigor Tovmasyan (4):
>   usb: dwc2: Delete unused functionality
>   usb: dwc2: Make function static

Better subject: Make dwc2_force_mode static

>   usb: dwc2: Add call_gadget() function call
>   usb: dwc2: Add core state checking
> 
> John Youn (2):
>   usb: dwc2: Enable LPM
>   usb: dwc2: Enable power down
> 
> Minas Harutyunyan (5):
>   usb: dwc2: Change TxFIFO and RxFIFO flushing flow

I don't how critical this patch is, because it doesn't mention any consequences.

In case it's critical this patch should be in a separate patch series as Greg 
mentioned. If not, i would prefer to apply "[PATCH v3 44/49] usb: dwc2: Update 
bit polling functionality" before this patch so we do not need to review code 
which is removed later in the series.

>   usb: dwc2: hcd: Fix host channel halt flow
>   usb: dwc2: Add safety check for STSPHSERCVD intr
>   usb: dwc2: host: Fix transaction errors in host mode
>   usb: dwc2: Add safety check in setting of descriptor chain pointers
> 
> Razmik Karapetyan (10):
>   usb: dwc2: Set AHB burst size to INCR

The usage hsotg->params.ahbcfg instead of the defines is a unintended fix for 
BCM2835. According to the BCM2835 datasheet this register have a different 
definition. So i like to see this split up.

>   usb: dwc2: Remove unnecessary debug prints
>   usb: dwc2: Define PCGCCTL1 register in hw.h
>   usb: dwc2: Define Active Clock Gating support bit in GHWCFG4

I think this one should be merged into the first patch which uses this define.

>   usb: dwc2: Add dwc2_enable_acg function
>   usb: dwc2: Backup and restore PCGCCTL1 register
>   usb: dwc2: Update dwc2_handle_incomplete_isoc_in() function
>   usb: dwc2: Update dwc2_handle_incomplete_isoc_out() function
>   usb: dwc2: Update GINTSTS_GOUTNAKEFF interrupt handling
>   usb: dwc2: Rename function names

Better subject: Improve bit function names 

> 
> Sevak Arakelyan (7):
>   usb: dwc2: Fix GLPMCFG... definitions

Better subject: Rename GLPMCFG... definitions

and please fix the typo "definitoins" in the commit log

>   usb: dwc2: Add core parameters for LPM support
>   usb: dwc2: gadget: Add functionality to exit from LPM L1 state
>   usb: dwc2: gadget: LPM interrupt handler
>   usb: dwc2: Enable LPM Transaction Received interrupt

Would be nice to extend the commit log, why this is necessary.

>   usb: dwc2: gadget: Configure the core to enable LPM
>   usb: dwc2: Update bit polling functionality
> 
> Vardan Mikayelyan (20):
>   usb: dwc2: eliminate irq parameter from dwc2_gadget_init
>   usb: dwc2: Force mode optimizations
>   usb: dwc2: Rename hibernation to partial_power_down
>   usb: dwc2: Add hibernation field into dwc2_hw_params
>   usb: dwc2: gadget: Moved dtxfsiz backup array place
>   usb: dwc2: gadget: Fix dwc2_restore_device_registers
>   usb: dwc2: core: Add hibernated flag

This commit log isn't very descriptive. Why is this flag necessary?

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

Re: [PATCH v3 00/49] usb: dwc2: fixes, enhancements and new features

[Stefan Wahren]

Hi Grigor,

> Grigor Tovmasyan  hat am 26. Dezember 2017 um 
> 12:21 geschrieben:
> 
> 
> This patch series includes new features such us Active Clock Gating(ACG), 
> LPM and Hibernation, enhancements and fixes for already existing features.
> All this patches were already sent to lkml separately. ACG, LPM and 
> Hibernation
> were sent as patch series.

thanks for collecting and rebasing all those patches. But AFAIK patch bombs 
(nearly 50 patches) have a little chance to get merged. So smaller series (< 20 
patches) are easier to handle. Apart from that a public git repo (e.g. 
https://github.com/synopsys-usb/) with applied series would be very helpful for 
testers. Also hints for testing are always welcome.

Sorry, i'm not a USB expert but from my point of view some of the commit 
messages doesn't answer the question "Why is this changed?".

Btw it's very helpful to separate fixes from improvements and move the fixes 
before the improvements.

Stefan
--
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] usb: dwc2: host: Don't retry NAKed transactions right away

[Stefan Wahren]

Hi Doug,

> Doug Anderson  hat am 19. Dezember 2017 um 16:57 
> geschrieben:
> 
> 
> Felipe,
> 
> On Tue, Dec 12, 2017 at 10:30 AM, Douglas Anderson
>  wrote:
> ...
> 
> I don't mean to be a pest, but I'm hoping that we can land this
> somewhere (if nothing else in your /next tree) just so it doesn't miss
> another release cycle.  If you're not so keen on collecting dwc2 host
> patches these days, I can also see if Greg KH is willing to take this
> directly into his tree.  Please let me know.  Thanks for your time!
> :)
> 
> -Doug

it's applied to next:

https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/commit/?h=next=38d2b5fb75c15923fb89c32134516a623515bce4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc2: Change TxFIFO and RxFIFO flushing flow

[Stefan Wahren]

Hi Minas,

Am 11.12.2017 um 11:45 schrieb Minas Harutyunyan:
> Hi Stefan,
> On 12/8/2017 8:25 PM, Stefan Wahren wrote:
>> Hi Minas,
>>
>> Am 07.12.2017 um 17:51 schrieb Stefan Wahren:
>>> Hi Minas,
>>>
>>> Am 07.12.2017 um 09:40 schrieb Stefan Wahren:
>>>> Before flushing fifos required to check AHB master state and
>>>> flush when AHB master is in IDLE state.
>>>>
>>>> Signed-off-by: Minas Harutyunyan <hmi...@synopsys.com>
>>>> ---
>>>>drivers/usb/dwc2/core.c | 27 +++
>>>>1 file changed, 27 insertions(+)
>>>>
>>>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>>>> index dbca3b8890da..cbc7c562477f 100644
>>>> --- a/drivers/usb/dwc2/core.c
>>>> +++ b/drivers/usb/dwc2/core.c
>>>> @@ -670,10 +670,23 @@ void dwc2_flush_tx_fifo(struct dwc2_hsotg *hsotg, 
>>>> const int num)
>>>>
>>>>dev_vdbg(hsotg->dev, "Flush Tx FIFO %d\n", num);
>>>>
>>>> +  /* Wait for AHB master IDLE state */
>>>> +  do {
>>>> +  udelay(1);
>>> is this delay always necessary before reading GRSTCTL?
>>>
>>> If yes please add a comment why.
>>> If no please rework the loop in order to avoid this delay in case the
>>> AHB master is already idle.
>>>
>> i've seen your Patch V2, but it isn't what i thought of. How about:
>>
>>
>> while (1) {
>>       greset = dwc2_readl(hsotg->regs + GRSTCTL);
>>       if (greset & GRSTCTL_AHBIDLE)
>>           break;
>>
>>       if (++count > 1) {
>>           dev_warn(hsotg->dev,
>>                "%s() HANG! AHB Idle GRSTCTL=%0x\n",
>>                __func__, greset);
>>           return;
>>       }
>   udelay(1);
>> }
>>
> I'm Ok with above loop, just think to add udelay(1) in bottom of loop. 
> udelay() required to allow AHB go to idle, if not yet.

sorry my fault, i forgot the udelay in my suggestion. I'm fine with your
addition.

>
> Actually in core.c lot of similar code: to wait for set or clear some 
> bits which should be fully updated. BTW, my first patch just copied from 
> dwc_core_reset() function.
>
>
>> Btw: Please provide a change history, so the maintainers can keep track
>> of your changes.
>>
>> Regards
>> Stefan
>>
> Thanks,
> Minas


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

Re: [PATCH] usb: dwc2: Change TxFIFO and RxFIFO flushing flow

[Stefan Wahren]

Hi Minas,

Am 07.12.2017 um 17:51 schrieb Stefan Wahren:

Hi Minas,

Am 07.12.2017 um 09:40 schrieb Stefan Wahren:

Before flushing fifos required to check AHB master state and
flush when AHB master is in IDLE state.

Signed-off-by: Minas Harutyunyan <hmi...@synopsys.com>
---
  drivers/usb/dwc2/core.c | 27 +++
  1 file changed, 27 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index dbca3b8890da..cbc7c562477f 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -670,10 +670,23 @@ void dwc2_flush_tx_fifo(struct dwc2_hsotg *hsotg, const 
int num)
  
  	dev_vdbg(hsotg->dev, "Flush Tx FIFO %d\n", num);
  
+	/* Wait for AHB master IDLE state */

+   do {
+   udelay(1);

is this delay always necessary before reading GRSTCTL?

If yes please add a comment why.
If no please rework the loop in order to avoid this delay in case the
AHB master is already idle.



i've seen your Patch V2, but it isn't what i thought of. How about:


while (1) {
    greset = dwc2_readl(hsotg->regs + GRSTCTL);
    if (greset & GRSTCTL_AHBIDLE)
        break;

    if (++count > 1) {
        dev_warn(hsotg->dev,
             "%s() HANG! AHB Idle GRSTCTL=%0x\n",
             __func__, greset);
        return;
    }
}

Btw: Please provide a change history, so the maintainers can keep track 
of your changes.


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

Re: [PATCH] usb: dwc2: hcd: Fix host channel halt flow

[Stefan Wahren]

Hi Minas,

Am 07.12.2017 um 18:08 schrieb Stefan Wahren:
> According databook in Buffer and External DMA mode
> non-split periodic channels can't be halted.

do you know of any consequences not having this patch applied?

>
> Signed-off-by: Minas Harutyunyan <hmi...@synopsys.com>

Please add a fixes tag.

Thanks
Stefan

> ---
>  drivers/usb/dwc2/hcd.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 614bb9603def..987122497408 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -985,6 +985,25 @@ void dwc2_hc_halt(struct dwc2_hsotg *hsotg, struct 
> dwc2_host_chan *chan,
>  
>   if (dbg_hc(chan))
>   dev_vdbg(hsotg->dev, "%s()\n", __func__);
> +
> + /*
> +  * In buffer DMA or external DMA mode channel can't be halted
> +  * for non-split periodic channels. At the end of the next
> +  * uframe/frame (in the worst case), the core generates a channel
> +  * halted and disables the channel automatically.
> +  */
> + if ((hsotg->core_params->dma_enable > 0 &&
> +  hsotg->core_params->dma_desc_enable <= 0) ||
> +  hsotg->hw_params.arch == GHWCFG2_EXT_DMA_ARCH) {
> + if (!chan->do_split &&
> + (chan->ep_type == USB_ENDPOINT_XFER_ISOC ||
> +  chan->ep_type == USB_ENDPOINT_XFER_INT)) {
> + dev_err(hsotg->dev, "%s() Channel can't be halted\n",
> + __func__);
> + return;
> + }
> + }
> +
>   if (halt_status == DWC2_HC_XFER_NO_HALT_STATUS)
>   dev_err(hsotg->dev, "!!! halt_status = %d !!!\n", halt_status);
>  


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

Re: [PATCH] usb: dwc2: host: Setting TOUTCAL and USBTRDTIM fields in host mode

[Stefan Wahren]

Hi Minas,

Am 07.12.2017 um 17:56 schrieb Stefan Wahren:
> Added missing GUSBCFG programming in host mode.
>
> These fields even if was programmed in device mode (in function
> dwc2_hsotg_core_init_disconnected()) will be resetting to POR values
> after core soft reset applied.
> So, each time when switching to host mode required to set these fields
> to correct values. It's allow fix issues with lot of transaction errors
> due to timeouts and turnarrounds on USB bus.
>
> Signed-off-by: Minas Harutyunyan <hmi...@synopsys.com>

please add a fixes tag.

> ---
>  drivers/usb/dwc2/hcd.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 614bb9603def..05e4e8c07bf1 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -2317,10 +2317,17 @@ static int dwc2_core_init(struct dwc2_hsotg *hsotg, 
> bool initial_setup)
>   */
>  static void dwc2_core_host_init(struct dwc2_hsotg *hsotg)
>  {
> - u32 hcfg, hfir, otgctl;
> + u32 hcfg, hfir, otgctl, usbcfg, val;
>  
>   dev_dbg(hsotg->dev, "%s(%p)\n", __func__, hsotg);
>  
> + /* Set HS/FS Timeout Calibration and USBTrdTim */
> + usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
> + usbcfg &= ~(GUSBCFG_TOUTCAL_MASK | GUSBCFG_USBTRDTIM_MASK);
> + val = (hsotg->phyif == GUSBCFG_PHYIF8) ? 9 : 5;
> + usbcfg |= (GUSBCFG_TOUTCAL(7) | (val << GUSBCFG_USBTRDTIM_SHIFT));

These are too much magic numbers (9,5,7). Could you please add a comment
or even better defines for them?

Thanks

> + dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
> +
>   /* Restart the Phy Clock */
>   dwc2_writel(0, hsotg->regs + PCGCTL);
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc2: Change TxFIFO and RxFIFO flushing flow

[Stefan Wahren]

Hi Minas,

Am 07.12.2017 um 09:40 schrieb Stefan Wahren:
> Before flushing fifos required to check AHB master state and
> flush when AHB master is in IDLE state.
>
> Signed-off-by: Minas Harutyunyan <hmi...@synopsys.com>
> ---
>  drivers/usb/dwc2/core.c | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index dbca3b8890da..cbc7c562477f 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -670,10 +670,23 @@ void dwc2_flush_tx_fifo(struct dwc2_hsotg *hsotg, const 
> int num)
>  
>   dev_vdbg(hsotg->dev, "Flush Tx FIFO %d\n", num);
>  
> + /* Wait for AHB master IDLE state */
> + do {
> + udelay(1);

is this delay always necessary before reading GRSTCTL?

If yes please add a comment why.
If no please rework the loop in order to avoid this delay in case the
AHB master is already idle.

> + greset = dwc2_readl(hsotg->regs + GRSTCTL);
> + if (++count > 1) {
> + dev_warn(hsotg->dev,
> +  "%s() HANG! AHB Idle GRSTCTL=%0x\n",
> +  __func__, greset);
> + return;
> + }
> + } while (!(greset & GRSTCTL_AHBIDLE));
> +
>   greset = GRSTCTL_TXFFLSH;
>   greset |= num << GRSTCTL_TXFNUM_SHIFT & GRSTCTL_TXFNUM_MASK;
>   dwc2_writel(greset, hsotg->regs + GRSTCTL);
>  
> + count = 0;
>   do {
>   greset = dwc2_readl(hsotg->regs + GRSTCTL);
>   if (++count > 1) {
> @@ -702,9 +715,23 @@ void dwc2_flush_rx_fifo(struct dwc2_hsotg *hsotg)
>  
>   dev_vdbg(hsotg->dev, "%s()\n", __func__);
>  
> + /* Wait for AHB master IDLE state */
> + do {
> + udelay(1);
> + greset = dwc2_readl(hsotg->regs + GRSTCTL);
> + if (++count > 1) {
> + dev_warn(hsotg->dev,
> +  "%s() HANG! AHB Idle GRSTCTL=%0x\n",
> +  __func__, greset);
> + return;
> + }
> + } while (!(greset & GRSTCTL_AHBIDLE));
> +
>   greset = GRSTCTL_RXFFLSH;
>   dwc2_writel(greset, hsotg->regs + GRSTCTL);
>  
> + /* Wait for RxFIFO flush done */
> + count = 0;
>   do {
>   greset = dwc2_readl(hsotg->regs + GRSTCTL);
>   if (++count > 1) {


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

Re: [PATCH v3 1/2] usb: dwc2: host: Don't retry NAKed transactions right away

[Stefan Wahren]

Hi Felipe,
Hi John,


Am 30.10.2017 um 18:08 schrieb Douglas Anderson:

On rk3288-veyron devices on Chrome OS it was found that plugging in an
Arduino-based USB device could cause the system to lockup, especially
if the CPU Frequency was at one of the slower operating points (like
100 MHz / 200 MHz).

Upon tracing, I found that the following was happening:
* The USB device (full speed) was connected to a high speed hub and
   then to the rk3288.  Thus, we were dealing with split transactions,
   which is all handled in software on dwc2.
* Userspace was initiating a BULK IN transfer
* When we sent the SSPLIT (to start the split transaction), we got an
   ACK.  Good.  Then we issued the CSPLIT.
* When we sent the CSPLIT, we got back a NAK.  We immediately (from
   the interrupt handler) started to retry and sent another SSPLIT.
* The device kept NAKing our CSPLIT, so we kept ping-ponging between
   sending a SSPLIT and a CSPLIT, each time sending from the interrupt
   handler.
* The handling of the interrupts was (because of the low CPU speed and
   the inefficiency of the dwc2 interrupt handler) was actually taking
   _longer_ than it took the other side to send the ACK/NAK.  Thus we
   were _always_ in the USB interrupt routine.
* The fact that USB interrupts were always going off was preventing
   other things from happening in the system.  This included preventing
   the system from being able to transition to a higher CPU frequency.

As I understand it, there is no requirement to retry super quickly
after a NAK, we just have to retry sometime in the future.  Thus one
solution to the above is to just add a delay between getting a NAK and
retrying the transmission.  If this delay is sufficiently long to get
out of the interrupt routine then the rest of the system will be able
to make forward progress.  Even a 25 us delay would probably be
enough, but we'll be extra conservative and try to delay 1 ms (the
exact amount depends on HZ and the accuracy of the jiffy and how close
the current jiffy is to ticking, but could be as much as 20 ms or as
little as 1 ms).

Presumably adding a delay like this could impact the USB throughput,
so we only add the delay with repeated NAKs.

NOTE: Upon further testing of a pl2303 serial adapter, I found that
this fix may help with problems there.  Specifically I found that the
pl2303 serial adapters tend to respond with a NAK when they have
nothing to say and thus we end with this same sequence.

Signed-off-by: Douglas Anderson <diand...@chromium.org>
Cc: sta...@vger.kernel.org
Reviewed-by: Julius Werner <jwer...@chromium.org>
Tested-by: Stefan Wahren <stefan.wah...@i2se.com>
---

Changes in v3:
- Add tested-by for Stefan Wahren
- Sent to Felipe Balbi as candiate to land this.
- Add Cc for stable (it's always been broken so go as far is as easy)

Changes in v2:
- Address http://crosreview.com/737520 feedback



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

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

[Stefan Wahren]

Hi Minas,

> Minas Harutyunyan  hat am 23. November 2017 
> um 11:00 geschrieben:
> 
> 
> Hi Stefan,
> 
> ...
> 
> In addition to above patches please apply this one:
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 42ac47f85bb4..7db50c27c061 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -433,6 +433,14 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool 
> host)
>  dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
> 
>  dwc2_wait_for_mode(hsotg, host);
> +
> +   /* Reset after mode changed. Required to restore
> +* 'power on reset' values for chosen mode
> +*/
> +   if (dwc2_core_reset(hsotg, true))
> +   dev_err(hsotg->dev,
> +   "%s: Reset failed, aborting", __func__);
> +
>  return;
>   }
> 

now i get this output in the unconnected case:

[2.203265] dwc2 2098.usb: dwc2_check_params: Invalid parameter 
host_perio_tx_fifo_size=0
[2.223595] dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[2.237313] dwc2 2098.usb: DCFG=0x0020, DCTL=0x, 
DIEPMSK=
[2.251241] dwc2 2098.usb: GAHBCFG=0x, GHWCFG1=0x
[2.264092] dwc2 2098.usb: GRXFSIZ=0x1000, GNPTXFSIZ=0x00201000
[2.276997] dwc2 2098.usb: DPTx[1] FSize=512, StAddr=0x1020
[2.289533] dwc2 2098.usb: DPTx[2] FSize=512, StAddr=0x1220
[2.301811] dwc2 2098.usb: DPTx[3] FSize=512, StAddr=0x1420
[2.313895] dwc2 2098.usb: DPTx[4] FSize=512, StAddr=0x1620
[2.325905] dwc2 2098.usb: DPTx[5] FSize=512, StAddr=0x1820
[2.337737] dwc2 2098.usb: DPTx[6] FSize=768, StAddr=0x1a20
[2.349314] dwc2 2098.usb: DPTx[7] FSize=768, StAddr=0x1d20
[2.360658] dwc2 2098.usb: ep0-in: EPCTL=0x8800, SIZ=0x, 
DMA=0xc7cc399d
[2.373898] dwc2 2098.usb: ep0-out: EPCTL=0x8000, SIZ=0x, 
DMA=0x4369542a
[2.391729] dwc2 2098.usb: ep1-in: EPCTL=0x1000, SIZ=0x, 
DMA=0x3cf1e8ff
[2.405310] dwc2 2098.usb: ep1-out: EPCTL=0x, SIZ=0x, 
DMA=0xfee68e5b
[2.424087] dwc2 2098.usb: ep2-in: EPCTL=0x1800, SIZ=0x, 
DMA=0x250c46a5
[2.438198] dwc2 2098.usb: ep2-out: EPCTL=0x, SIZ=0x, 
DMA=0x09126d05
[2.458271] dwc2 2098.usb: ep3-in: EPCTL=0x2000, SIZ=0x, 
DMA=0xad3adfdb
[2.472553] dwc2 2098.usb: ep3-out: EPCTL=0x, SIZ=0x, 
DMA=0x975be477
[2.492567] dwc2 2098.usb: ep4-in: EPCTL=0x2800, SIZ=0x, 
DMA=0x4b1c0566
[2.506976] dwc2 2098.usb: ep4-out: EPCTL=0x, SIZ=0x, 
DMA=0x1790a498
[2.527472] dwc2 2098.usb: ep5-in: EPCTL=0x3000, SIZ=0x, 
DMA=0xd73f7ded
[2.541993] dwc2 2098.usb: ep5-out: EPCTL=0x, SIZ=0x, 
DMA=0x37bc32ff
[2.562397] dwc2 2098.usb: ep6-in: EPCTL=0x3800, SIZ=0x, 
DMA=0xc6ac6b1e
[2.576850] dwc2 2098.usb: ep6-out: EPCTL=0x, SIZ=0x, 
DMA=0xdd2f97d1
[2.597308] dwc2 2098.usb: ep7-in: EPCTL=0x4000, SIZ=0x, 
DMA=0xeb84b4fb
[2.612023] dwc2 2098.usb: ep7-out: EPCTL=0x, SIZ=0x, 
DMA=0xfadeb4e6
[2.633447] dwc2 2098.usb: DVBUSDIS=0x17d7, DVBUSPULSE=05b8
[2.647954] dwc2 2098.usb: DWC OTG Controller
[2.660187] dwc2 2098.usb: new USB bus registered, assigned bus number 1
[2.674855] dwc2 2098.usb: irq 33, io mem 0x2098
[2.689352] hub 1-0:1.0: USB hub found
[2.700837] hub 1-0:1.0: 1 port detected
[2.716013] dwc2 2098.usb: Mode Mismatch Interrupt: currently in Device 
mode

and this in connected case:

[2.203259] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[6]=768
[2.224317] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[7]=768
[2.245984] dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[2.260139] dwc2 2098.usb: DCFG=0x, DCTL=0x, 
DIEPMSK=
[2.274290] dwc2 2098.usb: GAHBCFG=0x, GHWCFG1=0x
[2.287245] dwc2 2098.usb: GRXFSIZ=0x1000, GNPTXFSIZ=0x01001000
[2.300289] dwc2 2098.usb: DPTx[1] FSize=512, StAddr=0x2000
[2.313124] dwc2 2098.usb: DPTx[2] FSize=512, StAddr=0x2000
[2.325661] dwc2 2098.usb: DPTx[3] FSize=512, StAddr=0x2000
[2.338103] dwc2 2098.usb: DPTx[4] FSize=512, StAddr=0x2000
[2.350176] dwc2 2098.usb: DPTx[5] FSize=512, StAddr=0x2000
[2.361982] dwc2 2098.usb: DPTx[6] FSize=512, StAddr=0x2000
[2.373877] dwc2 2098.usb: DPTx[7] FSize=512, StAddr=0x2000
[2.385304] dwc2 2098.usb: ep0-in: EPCTL=0x0800, SIZ=0x, 
DMA=0xc7cc3f81
[2.398589] dwc2 2098.usb: ep0-out: EPCTL=0x0800, SIZ=0x, 
DMA=0xc7cc3f81
[

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

[Stefan Wahren]

Hi Minas,

> Stefan Wahren <stefan.wah...@i2se.com> hat am 22. November 2017 um 12:21 
> geschrieben:
> 
> 
> Hi Minas,
> 
> > Minas Harutyunyan <minas.harutyun...@synopsys.com> hat am 21. November 2017 
> > um 13:02 geschrieben:
> >
> > Hi Stefan,
> > 
> > We have prepared patch for this issue in July-August'17.
> > Find attached 2 patch files. Please apply patches and test. If issue 
> > gone, we will send these patches to LKML by regular flow.
> 
> thanks, but the first patch doesn't apply. My version see below, i hope i 
> didn't break anything.
> 
> Unfortunately after applying both patches the issue still persists (EP 1-7 
> fifo size to 512) and the EP 1-7 TX total size increases from 3776 to 3792. I 
> will follow my u-boot theory  ...

okay there is no influence of u-boot. If i boot directly from the RPi 
Bootloader it shows the same behavior.

I did the following test cases with enabled debug:
1. boot RPI Zero (OTG configured per DT) without anything connected to the OTG 
port
2. boot RPI Zero (OTG configured per DT) only a OTG cable connected to the OTG 
port

test case 1 (nothing connected, no issue):
dwc2 2098.usb: mapped PA 2098 to VA dc85
dwc2 2098.usb: registering common handler for irq33
dwc2 2098.usb: Core Release: 2.80a (snpsid=4f54280a)
dwc2 2098.usb: Forcing mode to host
dwc2 2098.usb: NonPeriodic TXFIFO size: 32
dwc2 2098.usb: RXFIFO size: 256
dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
dwc2 2098.usb: DCFG=0x0020, DCTL=0x, DIEPMSK=
dwc2 2098.usb: GAHBCFG=0x, GHWCFG1=0x
dwc2 2098.usb: GRXFSIZ=0x1000, GNPTXFSIZ=0x00201000
dwc2 2098.usb: DPTx[1] FSize=512, StAddr=0x1020
dwc2 2098.usb: DPTx[2] FSize=512, StAddr=0x1220
dwc2 2098.usb: DPTx[3] FSize=512, StAddr=0x1420
dwc2 2098.usb: DPTx[4] FSize=512, StAddr=0x1620
dwc2 2098.usb: DPTx[5] FSize=512, StAddr=0x1820
dwc2 2098.usb: DPTx[6] FSize=768, StAddr=0x1a20
dwc2 2098.usb: DPTx[7] FSize=768, StAddr=0x1d20
...
dwc2 2098.usb: Core Global Registers
dwc2 2098.usb: GOTGCTL@0xDC85 : 0x000D
dwc2 2098.usb: GOTGINT@0xDC850004 : 0x
dwc2 2098.usb: GAHBCFG@0xDC850008 : 0x0030
dwc2 2098.usb: GUSBCFG@0xDC85000C : 0x1700
dwc2 2098.usb: GRSTCTL@0xDC850010 : 0x8000
dwc2 2098.usb: GINTSTS@0xDC850014 : 0x04008C22
dwc2 2098.usb: GINTMSK@0xDC850018 : 0xD806
dwc2 2098.usb: GRXSTSR@0xDC85001C : 0xFADEA4E0
dwc2 2098.usb: GRXFSIZ@0xDC850024 : 0x1000
dwc2 2098.usb: GNPTXFSIZ  @0xDC850028 : 0x00201000
dwc2 2098.usb: GNPTXSTS   @0xDC85002C : 0x00080020
dwc2 2098.usb: GI2CCTL@0xDC850030 : 0x
dwc2 2098.usb: GPVNDCTL   @0xDC850034 : 0x
dwc2 2098.usb: GGPIO  @0xDC850038 : 0x
dwc2 2098.usb: GUID   @0xDC85003C : 0x2708A000
dwc2 2098.usb: GSNPSID@0xDC850040 : 0x4F54280A
dwc2 2098.usb: GHWCFG1@0xDC850044 : 0x
dwc2 2098.usb: GHWCFG2@0xDC850048 : 0x228DDD50
dwc2 2098.usb: GHWCFG3@0xDC85004C : 0x0FF000E8
dwc2 2098.usb: GHWCFG4@0xDC850050 : 0x1FF00020
dwc2 2098.usb: GLPMCFG@0xDC850054 : 0x75736230
dwc2 2098.usb: GPWRDN @0xDC850058 : 0x
dwc2 2098.usb: GDFIFOCFG  @0xDC85005C : 0x
dwc2 2098.usb: HPTXFSIZ   @0xDC850100 : 0x
dwc2 2098.usb: PCGCTL @0xDC850E00 : 0x
...
dwc2 2098.usb: gintsts=04008c22  gintmsk=d806
dwc2 2098.usb: Mode Mismatch Interrupt: currently in Device mode
dwc2 2098.usb: USB SUSPEND
dwc2 2098.usb: DSTS=0x3
dwc2 2098.usb: DSTS.Suspend Status=1 HWCFG4.Power Optimize=0
dwc2 2098.usb: dwc2_hsotg_irq: 04008420  (d806) retry 8

test case 2 (OTG cable connected, issue):
dwc2 2098.usb: mapped PA 2098 to VA dc85
dwc2 2098.usb: registering common handler for irq33
dwc2 2098.usb: Core Release: 2.80a (snpsid=4f54280a)
dwc2 2098.usb: Forcing mode to device
dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter 
g_tx_fifo_size[6]=768
dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter 
g_tx_fifo_size[7]=768
dwc2 2098.usb: NonPeriodic TXFIFO size: 32
dwc2 2098.usb: RXFIFO size: 256
dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
dwc2 2098.usb: DCFG=0x, DCTL=0x, DIEPMSK=
dwc2 2098.usb: GAHBCFG=0x, GHWCFG1=0x
dwc2 2098.usb: GRXFSIZ=0x1000, GNPTXFSIZ=0x01001000
dwc2 2098.usb: DPTx[1] FSize=512, StAddr=0x2000
dwc2 2098.usb: DPTx[2] FSize=512, StAddr=0x2000
dwc2 2098.usb: DPTx[3] FSize=512, StAddr=0x2000
dwc2 2098.usb: DPTx[4] FSize=512, StAddr=0x2000
d

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

[Stefan Wahren]

Hi Minas,

> Minas Harutyunyan <minas.harutyun...@synopsys.com> hat am 21. November 2017 
> um 13:02 geschrieben:
>
> Hi Stefan,
> 
> We have prepared patch for this issue in July-August'17.
> Find attached 2 patch files. Please apply patches and test. If issue 
> gone, we will send these patches to LKML by regular flow.

thanks, but the first patch doesn't apply. My version see below, i hope i 
didn't break anything.

Unfortunately after applying both patches the issue still persists (EP 1-7 fifo 
size to 512) and the EP 1-7 TX total size increases from 3776 to 3792. I will 
follow my u-boot theory  ...

>From 12fcc090bc7588275c1d942009676cb3fa5129f2 Mon Sep 17 00:00:00 2001
From: Gevorg Sahakyan <sahak...@synopsys.com>
Date: Wed, 22 Nov 2017 11:15:16 +0100
Subject: [PATCH] usb: dwc2: Fix TxFIFO setup issue

In host mode reading from DPTXSIZn returning invalid value(0) in
dwc2_check_param_tx_fifo_sizes function.

Added g_tx_fifo_size array in dwc2_hw_params structure in which stored
power on reset valus of DPTXSIZn registers in device mode (forced to
device).

Updated dwc2_get_hwparams function to write DPTXFSIZn to array.

Modyfied dwc2_check_param_tx_fifo_sizes function accordingly.

Change-Id: I61d3db753b1bc06f0f2caf40df350a09655f18fd
Signed-off-by: Gevorg Sahakyan <sahak...@synopsys.com>
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/core.h   |  1 +
 drivers/usb/dwc2/params.c | 11 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 8367d4f..47e9092 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -587,6 +587,7 @@ struct dwc2_hw_params {
unsigned utmi_phy_data_width:2;
u32 snpsid;
u32 dev_ep_dirs;
+   u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
 };
 
 /* Size of control and EP0 buffers */
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index a3ffe97..04f1868 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -469,8 +469,7 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
dwc2_hsotg *hsotg)
}
 
for (fifo = 1; fifo <= fifo_count; fifo++) {
-   dptxfszn = (dwc2_readl(hsotg->regs + DPTXFSIZN(fifo)) &
-   FIFOSIZE_DEPTH_MASK) >> FIFOSIZE_DEPTH_SHIFT;
+   dptxfszn = hsotg->hw_params.g_tx_fifo_size[fifo];
 
if (hsotg->params.g_tx_fifo_size[fifo] < min ||
hsotg->params.g_tx_fifo_size[fifo] >  dptxfszn) {
@@ -617,6 +616,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
 {
struct dwc2_hw_params *hw = >hw_params;
unsigned int width;
+   int fifo, fifo_count;
u32 hwcfg1, hwcfg2, hwcfg3, hwcfg4;
u32 grxfsiz;
 
@@ -705,6 +705,13 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
hw->rx_fifo_size = (grxfsiz & GRXFSIZ_DEPTH_MASK) >>
GRXFSIZ_DEPTH_SHIFT;
 
+   fifo_count = dwc2_hsotg_tx_fifo_count(hsotg);
+
+   for (fifo = 1; fifo <= fifo_count; fifo++) {
+   u32 val = dwc2_readl(hsotg->regs + DPTXFSIZN(fifo));
+   hw->g_tx_fifo_size[fifo] = (val & FIFOSIZE_DEPTH_MASK) >>
+  FIFOSIZE_DEPTH_SHIFT;
+   }
return 0;
 }
 
-- 
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

[Stefan Wahren]

Hi Minas,

Am 20.11.2017 um 12:59 schrieb Minas Harutyunyan:
> Hi Stefan,
> Looks like I know cause of issue... but I'm overloaded today and will able to 
> check it tomorrow. Sorry for delay.

thanks for your reply. There is no need to hurry, because the merge
window isn't open yet, but i like to get this fixed for the next kernel
release.

I have the suspicion this is related to the fact that u-boot already
initialize the USB IP, before dwc2 driver is loaded.

Regards
Stefan

>
> Thanks,
> Minas
>

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

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

[Stefan Wahren]

Hi Minas,

> Minas Harutyunyan <minas.harutyun...@synopsys.com> hat am 17. November 2017 
> um 08:48 geschrieben:
> 
> 
> On 11/17/2017 2:35 AM, Stefan Wahren wrote:
> > Hi Eric,
> > 
> >> Stefan Wahren <stefan.wah...@i2se.com> hat am 31. Oktober 2017 um 09:43 
> >> geschrieben:
> >>
> >>
> >> Hi Eric,
> >>
> >>> Eric Anholt <e...@anholt.net> hat am 31. Oktober 2017 um 01:40 
> >>> geschrieben:
> >>>
> >>>
> >>> Stefan Wahren <stefan.wah...@i2se.com> writes:
> >>>
> >>>>> Stefan Wahren <stefan.wah...@i2se.com> hat am 7. Oktober 2017 um 12:16 
> >>>>> geschrieben:
> >>>>>
> >>>>>
> >>>>> In case the RPi Zero has at least a device connected to the OTG port
> >>>>> at boot time, the upper limit of tx fifo size for endpoint 6 and 7 is
> >>>>> also reduced to 512 bytes. So fix this accordingly.
> >>>>>
> >>>>> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
> >>>>> Fixes: 1aa1d858f582 ("ARM: dts: bcm283x: Add dtsi for OTG mode")
> >>>>
> >>>> gentle ping ...
> >>>
> >>> I've tried to make sense of this a couple of times, but I don't get it:
> >>> why does EP 6/7 get reduced to 512 bytes in this case?
> >>
> >> i cannot give you an answer for this specific case.
> >>
> >> Since the dwc2 databook isn't public, i started a thread on linux-usb [1] 
> >> about proper fifo size configuration. But i didn't get any reply.
> >>
> >> The problem here is there different contraints:
> >> * the sum of all fifo values must not exceed 3776 bytes
> >> * each slot have its individual upper limit (available in the BCM2835 
> >> datasheet)
> >>
> >> During my tests for OTG mode i missed the specific case above. Now my 
> >> determined limits of 512 for EP 6 and 7 are contrary to the BCM2835 
> >> datasheet. Maybe the Synopsys guys have an answer?
> >>
> >> Btw the values in the downstream tree also violate the contraints.
> >>
> >> [1] - 
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Dusb_msg157200.html=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI=O2ngUGajgx3MfHk4IQKp5iRlwOOpG62gkji4R2gE64k=8ClOBwWN5B69mL1TDjnN3l78JBrvd1YHunRdzei-xrA=
> > 
> > still concerns about this patch, because it's not included in dt-fixes?
> > 
> 
> Hi Stefan,
> 
> According BCM2835 datasheet Total Data FIFO RAM Depth is 4096. I assume 
> that in datasheet assumed 4096 dwords, not a bytes. DFIFO depth in 
> dwords stored GHWCFG3[31:16].
> 
> So, for buffer DMA mode max space in dwords which available to allocate 
> to FIFO's is 4096-8*2=4080, where 8 EP count including EP0 and 2 for 
> both directions of EP's. Based on bcm283x-rpi-usb-otg.dtsi:
> g-rx-fifo-size + g-np-tx-fifo-size + g-tx-fifo-size[1..7] = 
> 256+32+256+256+512+512+512+768+768 = 3872 < 4080.
> So, I don't see any reason to change EP 6,7 TxFIFO sizes.

that's a nice calculation, but not relevant in my case.

Let's step back to the original problem. If i try to boot the Raspberry Pi Zero 
(Linux 4.14, U-Boot 2017-07) in OTG mode with at least 1 USB device connected, 
i will get the following warnings:

[2.997476] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[6]=768
[3.015754] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[7]=768

These warnings doesn't appear if there are no devices connected during boot.

In order to understand how i came to the "real" constraints 3776 bytes and to 
the new values for EP 6,7 i add some debug:

--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -462,6 +462,8 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
dwc2_hsotg *hsotg)
for (fifo = 1; fifo <= fifo_count; fifo++)
total += hsotg->params.g_tx_fifo_size[fifo];
 
+   dev_warn(hsotg->dev, "%s: g-tx-fifo-size: %d\n", __func__, 
dwc2_hsotg_tx_fifo_total_depth(hsotg));
+
if (total > dwc2_hsotg_tx_fifo_total_depth(hsotg) || !total) {
dev_warn(hsotg->dev, "%s: Invalid parameter g-tx-fifo-size, 
setting to default average\n",
 __func__);
@@ -472,6 +474,8 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
dwc2_hsotg *hsotg)
dptxfszn = (dwc2_readl(hsotg->regs + DPTXFSIZN(fifo)) &
FIFOSIZE_DEPTH_MASK) >

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

[Stefan Wahren]

Hi Eric,

> Stefan Wahren <stefan.wah...@i2se.com> hat am 31. Oktober 2017 um 09:43 
> geschrieben:
> 
> 
> Hi Eric,
> 
> > Eric Anholt <e...@anholt.net> hat am 31. Oktober 2017 um 01:40 geschrieben:
> > 
> > 
> > Stefan Wahren <stefan.wah...@i2se.com> writes:
> > 
> > >> Stefan Wahren <stefan.wah...@i2se.com> hat am 7. Oktober 2017 um 12:16 
> > >> geschrieben:
> > >> 
> > >> 
> > >> In case the RPi Zero has at least a device connected to the OTG port
> > >> at boot time, the upper limit of tx fifo size for endpoint 6 and 7 is
> > >> also reduced to 512 bytes. So fix this accordingly.
> > >> 
> > >> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
> > >> Fixes: 1aa1d858f582 ("ARM: dts: bcm283x: Add dtsi for OTG mode")
> > >
> > > gentle ping ...
> > 
> > I've tried to make sense of this a couple of times, but I don't get it:
> > why does EP 6/7 get reduced to 512 bytes in this case?
> 
> i cannot give you an answer for this specific case.
> 
> Since the dwc2 databook isn't public, i started a thread on linux-usb [1] 
> about proper fifo size configuration. But i didn't get any reply.
> 
> The problem here is there different contraints:
> * the sum of all fifo values must not exceed 3776 bytes
> * each slot have its individual upper limit (available in the BCM2835 
> datasheet)
> 
> During my tests for OTG mode i missed the specific case above. Now my 
> determined limits of 512 for EP 6 and 7 are contrary to the BCM2835 
> datasheet. Maybe the Synopsys guys have an answer?
> 
> Btw the values in the downstream tree also violate the contraints. 
> 
> [1] - https://www.spinics.net/lists/linux-usb/msg157200.html

still concerns about this patch, because it's not included in dt-fixes?
--
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: [1/2] mm: drop migrate type checks from has_unmovable_pages

[Stefan Wahren]

Am 06.11.2017 um 09:14 schrieb Michal Hocko:
> On Sun 05-11-17 22:56:32, Stefan Wahren wrote:
>> Hi Michal,
>>
>> the dwc2 USB driver on BCM2835 in linux-next is affected by the CMA
>> allocation issue. A quick web search guide me to your patch, which
>> avoid the issue.
> Thanks for your testing. Can I assume your Tested-by?

Yes

>
>> Since the patch wasn't accepted, i want to know is there another solution?
> The patch should be in next-20171106
>
--
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: [1/2] mm: drop migrate type checks from has_unmovable_pages

[Stefan Wahren]

Hi Michal,

the dwc2 USB driver on BCM2835 in linux-next is affected by the CMA allocation 
issue. A quick web search guide me to your patch, which avoid the issue.

Since the patch wasn't accepted, i want to know is there another solution?
Is this an issue in dwc2?

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

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

[Stefan Wahren]

Hi Eric,

> Eric Anholt <e...@anholt.net> hat am 31. Oktober 2017 um 01:40 geschrieben:
> 
> 
> Stefan Wahren <stefan.wah...@i2se.com> writes:
> 
> >> Stefan Wahren <stefan.wah...@i2se.com> hat am 7. Oktober 2017 um 12:16 
> >> geschrieben:
> >> 
> >> 
> >> In case the RPi Zero has at least a device connected to the OTG port
> >> at boot time, the upper limit of tx fifo size for endpoint 6 and 7 is
> >> also reduced to 512 bytes. So fix this accordingly.
> >> 
> >> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
> >> Fixes: 1aa1d858f582 ("ARM: dts: bcm283x: Add dtsi for OTG mode")
> >
> > gentle ping ...
> 
> I've tried to make sense of this a couple of times, but I don't get it:
> why does EP 6/7 get reduced to 512 bytes in this case?

i cannot give you an answer for this specific case.

Since the dwc2 databook isn't public, i started a thread on linux-usb [1] about 
proper fifo size configuration. But i didn't get any reply.

The problem here is there different contraints:
* the sum of all fifo values must not exceed 3776 bytes
* each slot have its individual upper limit (available in the BCM2835 datasheet)

During my tests for OTG mode i missed the specific case above. Now my 
determined limits of 512 for EP 6 and 7 are contrary to the BCM2835 datasheet. 
Maybe the Synopsys guys have an answer?

Btw the values in the downstream tree also violate the contraints. 

[1] - https://www.spinics.net/lists/linux-usb/msg157200.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: dwc2: host: Don't retry NAKed transactions right away

[Stefan Wahren]

Hi Doug,

[add Felipe since this should go through his tree]

i'm back from vacation and happy to see this patch.

> Douglas Anderson <diand...@chromium.org> hat am 26. Oktober 2017 um 22:22 
> geschrieben:
> 
> 
> On rk3288-veyron devices on Chrome OS it was found that plugging in an
> Arduino-based USB device could cause the system to lockup, especially
> if the CPU Frequency was at one of the slower operating points (like
> 100 MHz / 200 MHz).
> 
> Upon tracing, I found that the following was happening:
> * The USB device (full speed) was connected to a high speed hub and
>   then to the rk3288.  Thus, we were dealing with split transactions,
>   which is all handled in software on dwc2.
> * Userspace was initiating a BULK IN transfer
> * When we sent the SSPLIT (to start the split transaction), we got an
>   ACK.  Good.  Then we issued the CSPLIT.
> * When we sent the CSPLIT, we got back a NAK.  We immediately (from
>   the interrupt handler) started to retry and sent another SSPLIT.
> * The device kept NAKing our CSPLIT, so we kept ping-ponging between
>   sending a SSPLIT and a CSPLIT, each time sending from the interrupt
>   handler.
> * The handling of the interrupts was (because of the low CPU speed and
>   the inefficiency of the dwc2 interrupt handler) was actually taking
>   _longer_ than it took the other side to send the ACK/NAK.  Thus we
>   were _always_ in the USB interrupt routine.
> * The fact that USB interrupts were always going off was preventing
>   other things from happening in the system.  This included preventing
>   the system from being able to transition to a higher CPU frequency.
> 
> As I understand it, there is no requirement to retry super quickly
> after a NAK, we just have to retry sometime in the future.  Thus one
> solution to the above is to just add a delay between getting a NAK and
> retrying the transmission.  If this delay is sufficiently long to get
> out of the interrupt routine then the rest of the system will be able
> to make forward progress.  Even a 25 us delay would probably be
> enough, but we'll be extra conservative and try to delay 1 ms (the
> exact amount depends on HZ and the accuracy of the jiffy and how close
> the current jiffy is to ticking, but could be as much as 20 ms or as
> little as 1 ms).
> 
> Presumably adding a delay like this could impact the USB throughput,
> so we only add the delay with repeated NAKs.
> 
> NOTE: Upon further testing of a pl2303 serial adapter, I found that
> this fix may help with problems there.  Specifically I found that the
> pl2303 serial adapters tend to respond with a NAK when they have
> nothing to say and thus we end with this same sequence.

This patch fixes "dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s" 
on bcm2835. After applying your patch on linux-next plus "mm: drop migrate type 
checks from has_unmovable_pages" i'm able to open 3 PL2303 serial adapters 
parallel on a Raspberry Pi 1 B without any issues.

Tested-by: Stefan Wahren <stefan.wah...@i2se.com>

Please see my comment below

> 
> Signed-off-by: Douglas Anderson <diand...@chromium.org>
> Reviewed-by: Julius Werner <jwer...@chromium.org>
> ---
> 
> Changes in v2:
> - Address http://crosreview.com/737520 feedback
> 
>  drivers/usb/dwc2/core.h  |  1 +
>  drivers/usb/dwc2/hcd.c   |  7 
>  drivers/usb/dwc2/hcd.h   |  9 +
>  drivers/usb/dwc2/hcd_intr.c  | 20 +++
>  drivers/usb/dwc2/hcd_queue.c | 81 
> +---
>  5 files changed, 114 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 8367d4f985c1..c0807e558726 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -962,6 +962,7 @@ struct dwc2_hsotg {
>   } flags;
>  
>   struct list_head non_periodic_sched_inactive;
> + struct list_head non_periodic_sched_waiting;
>   struct list_head non_periodic_sched_active;
>   struct list_head *non_periodic_qh_ptr;
>   struct list_head periodic_sched_inactive;
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index c2631145f404..ed92ae78dcf9 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -653,6 +653,10 @@ static void dwc2_dump_channel_info(struct dwc2_hsotg 
> *hsotg,
>   list_for_each_entry(qh, >non_periodic_sched_inactive,
>   qh_list_entry)
>   dev_dbg(hsotg->dev, "%p\n", qh);
> + dev_dbg(hsotg->dev, "  NP waiting sched:\n");
> + list_for_each_entry(qh, >non_periodic_sched_waiting,
> + qh_list_entry)
> +

Re: [PATCH v3] dma-mapping: skip USB devices when configuring DMA during probe

[Stefan Wahren]

Hi Robin,

Am 08.08.2017 um 20:03 schrieb Johan Hovold:
> On Sat, Aug 05, 2017 at 10:38:07AM +0200, Christoph Hellwig wrote:
>> I think the root problem is that the code added by
>> " of/acpi: Configure dma operations at probe time for platform/amba/pci bus
>> devices"
>>
>> is completely bogus and needs to be reverted.  We can't simply iterate
>> over all devices in the system and set up dma for them.  We'll need
>> to ask the firmware / OF what root port this applies to and only
>> apply it to those buses.
> I'm afraid I haven't had time to look any more at this, and now I'll be
> offline for the next two weeks.
>
> It sounded like Robin was working on a fix for the broken DMA-mask on
> RPI3 and that should address Hans's ethernet regression too even if we
> ultimately need to fix dma_configure() as well.

can you confirm that DMA-mask on RPI3 is broken? Why?

>
> 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: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

[Stefan Wahren]

> Johan Hovold <jo...@kernel.org> hat am 2. August 2017 um 13:45 geschrieben:
> 
> 
> On Wed, Aug 02, 2017 at 01:10:33PM +0200, Stefan Wahren wrote:
> > Am 02.08.2017 um 09:03 schrieb Hans Verkuil:
> > > When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel
> > > I discovered that there was no ethernet. After bisecting I got to commit
> > > 2bf69867 ('USB: of: fix root-hub device-tree node handling').
> > >
> > > With that commit lsusb outputs:
> > >
> > > rpi3: ~ # lsusb
> > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > >
> > > After reverting just that commit (I'm on 4.13-rc3 now) ethernet is
> > > restored and lsusb gives me:
> > >
> > > rpi3: ~ $ lsusb
> > > Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
> > > SMSC9512/9514 Fast Ethernet Adapter
> > > Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
> > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > >
> > > I don't speak USB, so I have no idea why this patch causes these issues,
> > > but I am happy to test patches.
> > 
> > Thanks for finding.
> > 
> > Just a note, Andreas Färber also found a regression in 4.13-rc1, which
> > is related to USB & DMA [1].
> > Unfortunately i wasn't able to bisect this issue. I think it's related
> > to the configuration.
> > 
> > [1] -
> > http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-July/006658.html
> 
> Ah, thanks, that makes more sense (at least if Hans is also getting
> those "Cannot do DMA to address" errors during probe).
> 
> It should be commit 2bf698671205 ("USB: of: fix root-hub device-tree
> node handling") interacting with 09515ef5ddad ("of/acpi: Configure dma
> operations at probe time for platform/amba/pci bus devices").

I can confirm that reverting 2bf698671205 ("USB: of: fix root-hub device-tree 
node handling")
also fix the "Cannot do DMA to address" errors.

> 
> Let me take a closer look.
> 
> 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: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

[Stefan Wahren]

Am 02.08.2017 um 09:03 schrieb Hans Verkuil:
> When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel
> I discovered that there was no ethernet. After bisecting I got to commit
> 2bf69867 ('USB: of: fix root-hub device-tree node handling').
>
> With that commit lsusb outputs:
>
> rpi3: ~ # lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> After reverting just that commit (I'm on 4.13-rc3 now) ethernet is
> restored and lsusb gives me:
>
> rpi3: ~ $ lsusb
> Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 
> Fast Ethernet Adapter
> Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> I don't speak USB, so I have no idea why this patch causes these issues,
> but I am happy to test patches.

Thanks for finding.

Just a note, Andreas Färber also found a regression in 4.13-rc1, which
is related to USB & DMA [1].
Unfortunately i wasn't able to bisect this issue. I think it's related
to the configuration.

[1] -
http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-July/006658.html

>
> Regards,
>
>   Hans
>
> ___
> linux-rpi-kernel mailing list
> linux-rpi-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
--
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: No Ethernet on Raspberry Pi 3 in v4.13-rc1

[Stefan Wahren]

> Robin Murphy <robin.mur...@arm.com> hat am 25. Juli 2017 um 15:21 geschrieben:
> 
> 
> Hi Stefan,
> 
> On 25/07/17 06:19, Stefan Wahren wrote:
> >>> With arm64 4.13-rc1 I get no eth0 device on Pi3 (openSUSE Tumbleweed).
> >>> The v4.13-rc1 DT works okay with a 4.12 kernel.
> >>>
> >>> Possibly related:
> >>>
> >>> [   15.916350] OF: /soc/usb@7e98: could not get #phy-cells for /phy
> >>>
> >>> [   16.496662] usb 1-1: new high-speed USB device number 2 using dwc2
> >>> [   16.502988] dwc2 3f98.usb: Cannot do DMA to address
> >>> 0x335da400
> >>
> >> This is from SWIOTLB's map_single(), which means whatever device was
> >> passed into dma_map_single() when mapping the URB had a DMA mask smaller
> >> than 30 bits (or none at all), which sounds wrong and is almost
> >> certainly the root of the problem (i.e. it probably wasn't the actual
> >> HCD device described in DT and set up by of_dma_configure()). 
> > 
> > how can i figure out what's cause this issue (bcm283x or dwc2 specific)?
> > 
> > The dwc2 hcd already check the DMA mask on probe [1] and i never saw a 
> > warning in error case.
> 
> I'll admit I'm a little stumped, since the two commits to dwc2 since
> 4.12 seem entirely inconsequential.
> 
> The only way I can see this happening is if the first dma_capable()
> check in swiotlb_map_page() fails, and since swiotlb_force must be set
> to SWIOTLB_NOFORCE in order to print the error later, and the address
> and size look reasonable, that only leaves dev->dma_mask as the culprit.
> 
> From the subsequent fallout (which on closer inspection looks more to do
> with calling into uninitialised SWIOTLB state than the arm64 DMA code
> actually doing anything wrong), I'd guess dev->dma_pfn_offset is
> probably 0 as well, which further points to the wrong device. Maybe
> something's changed lower down in the USB core? Turning on tracing and
> booting with "tp_printk trace_event=swiotlb_bounced" on the command line
> should shed a bit more light on what's going on.
> 

FWIW, i added some dev_info before and after dma_set_mask in dwc2 (error case):

[5.471761] dwc2 3f98.usb: before mask: 
[5.491016] dwc2 3f98.usb: before coherent mask: 
[5.513379] dwc2 3f98.usb: after mask: 
[5.532572] dwc2 3f98.usb: after coherent mask: 
[5.555039] dwc2 3f98.usb: DWC OTG Controller
[5.575855] dwc2 3f98.usb: new USB bus registered, assigned bus number 1
[5.605944] dwc2 3f98.usb: irq 41, io mem 0x3f98

which doesn't match the tracing outputs.

> Robin.
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: No Ethernet on Raspberry Pi 3 in v4.13-rc1

[Stefan Wahren]

> Robin Murphy  hat am 25. Juli 2017 um 15:21 geschrieben:
> 
> From the subsequent fallout (which on closer inspection looks more to do
> with calling into uninitialised SWIOTLB state than the arm64 DMA code
> actually doing anything wrong), I'd guess dev->dma_pfn_offset is
> probably 0 as well, which further points to the wrong device. Maybe
> something's changed lower down in the USB core? Turning on tracing and
> booting with "tp_printk trace_event=swiotlb_bounced" on the command line
> should shed a bit more light on what's going on.

I took a slightly different config which also works with 4.12 and break with 
4.13-rc1:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.13.0-rc1-ARCH (stefan@Latitude-E4310) (gcc 
version 6.3.1 20170109 (Linaro GCC 6.3-2017.02)) #34 SMP Tue Jul 25 20:31:35 
CEST 2017
[0.00] Boot CPU: AArch64 Processor [410fd034]
[0.00] Machine model: Raspberry Pi 3 Model B Rev 1.2
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Failed to reserve 512 MiB
[0.00] percpu: Embedded 3 pages/cpu @80003ae9 s125336 r8192 
d63080 u196608
[0.00] Detected VIPT I-cache on CPU0
[0.00] Built 1 zonelists in Zone order, mobility grouping off.  Total 
pages: 15089
[0.00] Kernel command line: earlyprintk console=ttyAMA0 
bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 
dma.dmachans=0x7f35 bcm2709.boardrev=0xa02082 bcm2709.serial=0x53a68e44 
bcm2709.uart_clock=4800 smsc95xx.macaddr=B8:27:EB:A6:8E:44 
vc_mem.mem_base=0x3dc0 vc_mem.mem_size=0x3f00  dwc_otg.lpm_enable=0 
console=ttyS0,115200 console=tty1 root=PARTUUID=29cb32be-02 rootfstype=ext4 
elevator=deadline fsck.repair=yes rootwait tp_printk trace_event=swiotlb_bounced
[0.00] PID hash table entries: 4096 (order: -1, 32768 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 3, 524288 bytes)
[0.00] Memory: 939712K/966656K available (11836K kernel code, 2400K 
rwdata, 5376K rodata, 1600K init, 1269K bss, 26944K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] modules : 0x - 0x0800   (   128 
MB)
[0.00] vmalloc : 0x0800 - 0x7bdf   (126847 
GB)
[0.00]   .text : 0x0808 - 0x08c1   ( 11840 
KB)
[0.00] .rodata : 0x08c1 - 0x0916   (  5440 
KB)
[0.00]   .init : 0x0916 - 0x092f   (  1600 
KB)
[0.00]   .data : 0x092f - 0x09548200   (  2401 
KB)
[0.00].bss : 0x09548200 - 0x09685988   (  1270 
KB)
[0.00] fixed   : 0x7fdffe7d - 0x7fdffec0   (  4288 
KB)
[0.00] PCI I/O : 0x7fdffee0 - 0x7fdfffe0   (16 
MB)
[0.00] vmemmap : 0x7fe0 - 0x8000   (   128 
GB maximum)
[0.00]   0x7fe0 - 0x7feec000   ( 0 
MB actual)
[0.00] memory  : 0x8000 - 0x80003b00   (   944 
MB)
[0.00] random: get_random_u64 called from 
cache_random_seq_create+0x60/0x118 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 43369 entries in 11 pages
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[0.00]  Tasks RCU enabled.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[0.00] arch_timer: WARNING: Invalid trigger for IRQ2, assuming level low
[0.00] arch_timer: WARNING: Please fix your firmware
[0.00] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[0.06] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 
4398046511078ns
[0.000180] Console: colour dummy device 80x25
[0.001202] console [tty1] enabled
[0.001246] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 38.40 BogoMIPS (lpj=192000)
[0.001296] pid_max: default: 32768 minimum: 301
[0.002076] Security Framework initialized
[0.002106] Yama: becoming mindful.
[0.002325] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes)
[0.002417] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes)
[0.004540] ASID allocator initialised with 65536 entries
[0.004664] Hierarchical SRCU implementation.
[0.010622] EFI services will not be available.
[0.010923] smp: Bringing up secondary CPUs ...
[0.011453] Detected 

Re: No Ethernet on Raspberry Pi 3 in v4.13-rc1

[Stefan Wahren]

Hi Robin,

> Robin Murphy  hat am 24. Juli 2017 um 13:22 geschrieben:
> 
> 
> Hi Andreas,
> 
> On 22/07/17 13:29, Andreas Färber wrote:
> > Hello,
> > 
> > With arm64 4.13-rc1 I get no eth0 device on Pi3 (openSUSE Tumbleweed).
> > The v4.13-rc1 DT works okay with a 4.12 kernel.
> > 
> > Possibly related:
> > 
> > [   15.916350] OF: /soc/usb@7e98: could not get #phy-cells for /phy
> > 
> > [   16.496662] usb 1-1: new high-speed USB device number 2 using dwc2
> > [   16.502988] dwc2 3f98.usb: Cannot do DMA to address
> > 0x335da400
> 
> This is from SWIOTLB's map_single(), which means whatever device was
> passed into dma_map_single() when mapping the URB had a DMA mask smaller
> than 30 bits (or none at all), which sounds wrong and is almost
> certainly the root of the problem (i.e. it probably wasn't the actual
> HCD device described in DT and set up by of_dma_configure()). 

how can i figure out what's cause this issue (bcm283x or dwc2 specific)?

The dwc2 hcd already check the DMA mask on probe [1] and i never saw a warning 
in error case.

Regards
Stefan

[1] - 
http://elixir.free-electrons.com/linux/latest/source/drivers/usb/dwc2/hcd.c#L5096

> However,
> arm64's __swiotlb_map_page() still shouldn't be trying to perform cache
> maintenance on the error value returned, which looks to be where the
> actual splat below hails from - leave that one with me ;)
> 
> Robin.
>
--
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

dwc2: g-tx-fifo-size configuration on bcm2835

[Stefan Wahren]

Hi,

since the dwc2 should be able to properly setup its fifos, i want to enable otg 
mode for Raspberry Pi Zero (BCM2835). According to the BCM2835 datasheet [1] it 
has 7 device EPs with a max FIFO depth for EP1..5 = 512 and EP6,7 = 768. This 
makes in sum 4096, which also seems to be okay regarding to datasheet.

So i defined the following DTS part:

 {
dr_mode = "otg";
g-rx-fifo-size = <256>;
g-np-tx-fifo-size = <32>;
g-tx-fifo-size = <512 512 512 512 512 768 768>;
};

Unfortunately i get the following errors from dwc2:

[2.535879] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g-tx-fifo-size, setting to default average
[2.561611] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[1]=539
[2.586045] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[2]=539
[2.611045] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[3]=539
[2.636209] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[4]=539
[2.661952] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
parameter g_tx_fifo_size[5]=539
[2.688044] dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[2.704753] g_serial gadget: Gadget Serial v2.4
[2.717962] g_serial gadget: g_serial ready
[2.730830] dwc2 2098.usb: bound driver g_serial
[2.745485] dwc2 2098.usb: DWC OTG Controller
[2.759763] dwc2 2098.usb: new USB bus registered, assigned bus number 1
[2.776556] dwc2 2098.usb: irq 33, io mem 0x2098

Since these messages aren't really helpful, i added a info messages about 
fifo_count, sum of all fifo sizes and allowed total from hardware:

[2.512808] dwc2 2098.usb: dwc2_check_param_tx_fifo_sizes: fifo_count = 
7, sum = 4096, total = 3776

So i decided to use the following setting, which works without any issues:

g-tx-fifo-size = <512 512 512 512 512 512 512>;

Here are my questions:

Is the dwc2 still broken regarding to this error or is the datasheet wrong?

Is it save to use the working g-tx-fifo-size for peripheral and otg mode? Or do 
i need to reserve some space in fifo (for host mode)?

Is this the proper way to evaluate the right g-tx-fifo-size setting?

Regards
Stefan

[1] - 
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

> Doug Anderson <diand...@chromium.org> hat am 11. Mai 2017 um 01:50 
> geschrieben:
> 
> 
> Hi,
> 
> On Wed, May 10, 2017 at 9:31 AM, Johan Hovold <jo...@kernel.org> wrote:
> > On Mon, May 08, 2017 at 10:22:08PM +0200, Stefan Wahren wrote:
> >> @Doug, @John Y., @Johan: Any further ideas to narrow down the reason
> >> for this interrupt storm?
> >
> > No, sorry.
> >
> > I suggested earlier that you could try commenting out the interrupt-URB
> > submission in a naive attempt to narrow it down since that is an obvious
> > difference from the ftdi driver, but then again so are the frequent ftdi
> > status bulk messages (and any other timing differences).
> >
> > Seems like you need to dig into dwc2.
> 
> I haven't had a chance to dig and not sure when I'll have that time.
> I'll keep this around in my inbox for now on the off chance that I
> clean it out enough to get back to this.  Sorry!
> 

But thanks for all your feedback guys.

Btw i think i took a step forward. During the whole time i a took a Raspberry 
Pi B to reproduce this issue, which has a builtin USB hub and a SMSC USB to 
ethernet chip.

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 
480M
|__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

I decide to switch to the Raspberry Pi Zero which neither have a builtin USB 
hub or a USB ethernet chip. If i connect the PL2303 directly to the RPi Zero 
the issue is not reproducible and usb_test behave as expected by opening the 
port and terminate after a few seconds (good case).

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

After that i placed a USB 4 port hub between RPi Zero and PL2303. Now the issue 
(interrupt storm) occurs on the RPi Zero (bad case). After nearly 20 seconds i 
disconnected the PL2303 in order to make the system usable and stop the trace.

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

Additional i made usbmon traces of both cases. Maybe that's useful for somebody 
with more USB knowledge than me.

Stefan

good case:

d9adfd00 1324940464 S Co:1:005:0 s 40 01 0008   0
d9adfd00 1324941739 C Co:1:005:0 0 0
d9adfd00 1324941792 S Co:1:005:0 s 40 01 0009   0
d9adfd00 1324941879 C Co:1:005:0 0 0
d9adfd00 1324941920 S Ci:1:005:0 s a1 21   0007 7 <
d9adfd00 1324942046 C Ci:1:005:0 0 7 = 8025 00
d9adfd00 1324942093 S Co:1:005:0 s 21 20   0007 7 = 8025 08
d9adfd00 1324942211 C Co:1:005:0 0 7 >
d9adfd00 1324942248 S Co:1:005:0 s 40 01    0
d9adfd00 1324942335 C Co:1:005:0 0 0
da6ef600 1324942367 S Ii:1:005:1 -115:1 10 <
da6efd00 1324942412 S Bi:1:005:3 -115 256 <
da6ef800 1324942431 S Bi:1:005:3 -115 256 <
d9adfd00 1324942447 S Co:1:005:0 s 21 22 0003   0
d9adfd00 1324943310 C Co:1:005:0 0 0
da6ef600 1324944174 C Ii:1:005:1 0:1 10 = a120 0200 8b06
da6ef600 1324944192 S Ii:1:005:1 -115:1 10 <
da6ef600 1324946152 C Ii:1:005:1 0:1 10 = a120 0200 8b00
da6ef600 1324946161 S Ii:1:005:1 -115:1 10 <
da6ef600 1325451149 C Ii:1:005:1 -5:1 0
da6ef600 1325451177 S Ii:1:005:1 -115:1 10 <
d9adf400 1330210089 S Co:1:005:0 s 21 22    0
d9adf400 1330211717 C Co:1:005:0 0 0
da6efd00 1330211855 C Bi:1:005:3 -2 0
da6ef800 1330211921 C Bi:1:005:3 -2 0
da6ef600 1330211969 C Ii:1:005:1 -2:1 0
d9adf400 1330211997 S Co:1:005:0 s 21 23    0
d9adf400 1330212158 C Co:1:005:0 0 0

bad case:

da6efb00 316377734 S Co:1:004:0 s 40 01 0008   0
da6efb00 316378587 C Co:1:004:0 0 0
da6efb00 316378837 S Co:1:004:0 s 40 01 0009   0
da6efb00 316379201 C Co:1:004:0 0 0
da6efb00 316379397 S Ci:1:004:0 s a1 21   0007 7 <
da6efb00 316379697 C Ci:1:004:0 0 7 = 8025 00
da6efb00 316379890 S Co:1:004:0 s 21 20   0007 7 = 8025 08
da6efb00 316380350 C Co:1:004:0 0 7 >
da6efb00 316380580 S Co:1:004:0 s 40 01    0
da6efb00 316380932 C Co:1:004:0 0 0
d9a14b00 316381132 S Ii:1:004:1 -115:1 10 <
da780600 316381325 S Bi:1:004:3 -115 256 <
da780100 316381488 S Bi:1:004:3 -115 256 <
d9a14b00 316389933 C Ii:1:004:1 0:1 10 = a120 0200 8b06
d9a14b00 316390820 S Ii:1:004:1 -115:1 10 <
d9a14b00 316398308 C Ii:1:004:1 0:1 10 = a120 0200 8b00
d9a14b00 316399936 S Ii:1:004:1 -115:1 10 <
da6efb00 316419808 S Co:1:004:0 s 21 22 0003   0
da6efb00 316438433 C Co:1:004:0 0 0
da780600 339316684 C Bi:1:004:3 -32 0
da780100 339316772 C Bi:1:004:3 -32 0
d9a14b00 339317035 C Ii:1:

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

> Stefan Wahren <stefan.wah...@i2se.com> hat am 25. April 2017 um 20:11 
> geschrieben:
> 
> 
> > Stefan Wahren <stefan.wah...@i2se.com> hat am 22. April 2017 um 22:50 
> > geschrieben:
> > 
> > 
> > Hi,
> > 
> > > Eric Anholt <e...@anholt.net> hat am 20. April 2017 um 20:54 geschrieben:
> > > 
> > > 
> > > Stefan Wahren <stefan.wah...@i2se.com> writes:
> > > 
> > > > Hi,
> > > >
> > > >> Doug Anderson <diand...@chromium.org> hat am 18. April 2017 um 22:41 
> > > >> geschrieben:
> > > >> 
> > > >> 
> > > >> It's hard to know for sure that all of this time is really in
> > > >> urb_enqueue().  Possible we could have task switched out and been
> > > >> blocked elsewhere.  Using ftrace to get more fine-grained timings
> > > >> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
> > > >> friends here if you want to use trace_printk.
> > > >
> > > > i'm a newbie to ftrace, so i hope this would be helpful.
> > > >
> > > > # connect PL2303 to the onboard hub
> > > > # echo 0 > options/sleep-time
> > > > # echo 0 > function_profile_enabled
> > > > # echo 1 > function_profile_enabled
> > > > # ./usb_test
> > > > # Waiting for at least 20 seconds and then disconnect PL2303
> > > > # echo 0 > function_profile_enabled
> > > > # cat trace_stat/function0
> > > >
> > > >   Function   HitTimeAvg 
> > > > s^2
> > > >      ------ 
> > > > ---
> > > >   bcm2835_handle_irq  361347219567633 us 
> > > > 607.636 us  1485199 us  
> > > >   __handle_domain_irq1082482212639551 us 
> > > > 196.437 us  3642030 us  
> > > >   generic_handle_irq 1082482100592051 us 92.927 
> > > > us   50511334 us 
> > > >   irq_exit   108248298197771 us 90.715 
> > > > us   29649040 us 
> > > >   handle_level_irq   108248295812379 us 88.511 
> > > > us   51910093 us 
> > > 
> > > If I'm reading this output right, we're spending half of our interrupt
> > > processing time in irq_exit(), so even if dwc2's interrupt was free (the
> > > generic_handle_irq() chain), we'd be eating about half the CPU getting
> > > back out of the interrupt handler, right?
> > > 
> > > I don't really know anything about DWC2 or USB, but is there any way we
> > > could mitigate the interrupt frequency with this hardware?  If nothing
> > > else, could we loop reading gintsts until it reads back 0?
> > 
> > first of all i updated my kernel to 4.11rc7 and the issue still occures. 
> > Today i had some time to investigate this issue further and i made some 
> > interesting observations:
> > 
> > 1. The lockup doesn't occure always after starting usb_test. In rare cases 
> > i was able to run the program without lockup.
> > 2. In case the lockup occured we are always able to "rescue" the BCM2835 
> > from this state by sending some serial data to the PL2303.
> 
> Based on this scenario i patched the interrupt routine to detect the 
> interrupt storm and normal condition. So i can dump the global and host 
> registers in both situations (bad and goodcase).
> 
> Here is the diff between both register dumps, maybe someone see something 
> interesting:
> 
> --- badcase.txt   2017-04-25 18:02:59.0 +
> +++ goodcase.txt  2017-04-25 18:02:59.0 +
> @@ -4,12 +4,12 @@
>   dwc2_dump_global_registers: GAHBCFG  @0xCC850008 : 0x0031
>   dwc2_dump_global_registers: GUSBCFG  @0xCC85000C : 0x20001700
>   dwc2_dump_global_registers: GRSTCTL  @0xCC850010 : 0x8000
> - dwc2_dump_global_registers: GINTSTS  @0xCC850014 : 0x0621
> + dwc2_dump_global_registers: GINTSTS  @0xCC850014 : 0x0629
>   dwc2_dump_global_registers: GINTMSK  @0xCC850018 : 0xF300080E
> - dwc2_dump_global_registers: GRXSTSR  @0xCC85001C : 0x00070044
> + dwc2_dump_global_registers: GRXSTSR  @0xCC85001C : 0x000F0001
>   dwc2_dump_global_registers: GRXFSIZ  @0xCC850024 : 0x0306
>   dwc2_dump_global_registers: GNPTXFSIZ@0xCC850028 : 0x01000306
> - dwc2_dump_global_registers: GNPTXSTS @0xCC85002C : 0x1D080100
> + dwc2_dump_global_registers: GNPTXSTS @0xCC85002C : 0x18080100
> ...

@Doug, @John Y., @Johan: Any further ideas to narrow down the reason for this 
interrupt storm?

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

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

> Stefan Wahren <stefan.wah...@i2se.com> hat am 22. April 2017 um 22:50 
> geschrieben:
> 
> 
> Hi,
> 
> > Eric Anholt <e...@anholt.net> hat am 20. April 2017 um 20:54 geschrieben:
> > 
> > 
> > Stefan Wahren <stefan.wah...@i2se.com> writes:
> > 
> > > Hi,
> > >
> > >> Doug Anderson <diand...@chromium.org> hat am 18. April 2017 um 22:41 
> > >> geschrieben:
> > >> 
> > >> 
> > >> It's hard to know for sure that all of this time is really in
> > >> urb_enqueue().  Possible we could have task switched out and been
> > >> blocked elsewhere.  Using ftrace to get more fine-grained timings
> > >> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
> > >> friends here if you want to use trace_printk.
> > >
> > > i'm a newbie to ftrace, so i hope this would be helpful.
> > >
> > > # connect PL2303 to the onboard hub
> > > # echo 0 > options/sleep-time
> > > # echo 0 > function_profile_enabled
> > > # echo 1 > function_profile_enabled
> > > # ./usb_test
> > > # Waiting for at least 20 seconds and then disconnect PL2303
> > > # echo 0 > function_profile_enabled
> > > # cat trace_stat/function0
> > >
> > >   Function   HitTimeAvg   
> > >   s^2
> > >      ------   
> > >   ---
> > >   bcm2835_handle_irq  361347219567633 us 607.636 
> > > us  1485199 us  
> > >   __handle_domain_irq1082482212639551 us 196.437 
> > > us  3642030 us  
> > >   generic_handle_irq 1082482100592051 us 92.927 
> > > us   50511334 us 
> > >   irq_exit   108248298197771 us 90.715 us 
> > >   29649040 us 
> > >   handle_level_irq   108248295812379 us 88.511 us 
> > >   51910093 us 
> > 
> > If I'm reading this output right, we're spending half of our interrupt
> > processing time in irq_exit(), so even if dwc2's interrupt was free (the
> > generic_handle_irq() chain), we'd be eating about half the CPU getting
> > back out of the interrupt handler, right?
> > 
> > I don't really know anything about DWC2 or USB, but is there any way we
> > could mitigate the interrupt frequency with this hardware?  If nothing
> > else, could we loop reading gintsts until it reads back 0?
> 
> first of all i updated my kernel to 4.11rc7 and the issue still occures. 
> Today i had some time to investigate this issue further and i made some 
> interesting observations:
> 
> 1. The lockup doesn't occure always after starting usb_test. In rare cases i 
> was able to run the program without lockup.
> 2. In case the lockup occured we are always able to "rescue" the BCM2835 from 
> this state by sending some serial data to the PL2303.

Based on this scenario i patched the interrupt routine to detect the interrupt 
storm and normal condition. So i can dump the global and host registers in both 
situations (bad and goodcase).

Here is the diff between both register dumps, maybe someone see something 
interesting:

--- badcase.txt 2017-04-25 18:02:59.0 +
+++ goodcase.txt2017-04-25 18:02:59.0 +
@@ -4,12 +4,12 @@
  dwc2_dump_global_registers: GAHBCFG@0xCC850008 : 0x0031
  dwc2_dump_global_registers: GUSBCFG@0xCC85000C : 0x20001700
  dwc2_dump_global_registers: GRSTCTL@0xCC850010 : 0x8000
- dwc2_dump_global_registers: GINTSTS@0xCC850014 : 0x0621
+ dwc2_dump_global_registers: GINTSTS@0xCC850014 : 0x0629
  dwc2_dump_global_registers: GINTMSK@0xCC850018 : 0xF300080E
- dwc2_dump_global_registers: GRXSTSR@0xCC85001C : 0x00070044
+ dwc2_dump_global_registers: GRXSTSR@0xCC85001C : 0x000F0001
  dwc2_dump_global_registers: GRXFSIZ@0xCC850024 : 0x0306
  dwc2_dump_global_registers: GNPTXFSIZ  @0xCC850028 : 0x01000306
- dwc2_dump_global_registers: GNPTXSTS   @0xCC85002C : 0x1D080100
+ dwc2_dump_global_registers: GNPTXSTS   @0xCC85002C : 0x18080100
  dwc2_dump_global_registers: GI2CCTL@0xCC850030 : 0x
  dwc2_dump_global_registers: GPVNDCTL   @0xCC850034 : 0x
  dwc2_dump_global_registers: GGPIO  @0xCC850038 : 0x
@@ -27,64 +27,64 @@
  dwc2_dump_host_registers: Host Global Registers
  dwc2_dump_host_registers: HCFG @0xCC850400 : 0x
  dwc2_dump_host_registers: HFIR @0xCC850404 : 0x1D4B
- dwc2_dump_host_registers: HFNUM@0xCC850408 : 0x0

Re: [PATCH] usb: chipidea: udc: fix NULL pointer dereference if udc_start failed

[Stefan Wahren]

Am 25.04.2017 um 11:20 schrieb Peter Chen:
>  
 diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
 index f88e9157fad0..60a786c87c06 100644
 --- a/drivers/usb/chipidea/udc.c
 +++ b/drivers/usb/chipidea/udc.c
 @@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct
 ci_hdrc *ci)  int ci_hdrc_gadget_init(struct ci_hdrc *ci)  {
struct ci_role_driver *rdrv;
 +  int ret;

if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
return -ENXIO;
 @@ -1996,7 +1997,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
rdrv->stop  = udc_id_switch_for_host;
rdrv->irq   = udc_irq;
rdrv->name  = "gadget";
 -  ci->roles[CI_ROLE_GADGET] = rdrv;

 -  return udc_start(ci);
 +  ret = udc_start(ci);
 +  if (!ret)
 +  ci->roles[CI_ROLE_GADGET] = rdrv;
 +
 +  return ret;
  }
 --
>>> Thanks for fixing it. In fact, we'd better return failure if ret &&
>>> ret != -ENXIO at probe, it stands for initialization for host or
>>> gadget has failed.
>>>
>> I got your meaning. I'll cook v2. I don't have preference, since either one 
>> can fix the
>> issue.
>>
> Both are needed, you don't need to send this one again. Only a new one, 
> thanks.

I'm not sure how easy it is to reproduce the issue.

Shouldn't make a Fixes tag sense at least?

>
> Peter
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

Hi,

> Eric Anholt <e...@anholt.net> hat am 20. April 2017 um 20:54 geschrieben:
> 
> 
> Stefan Wahren <stefan.wah...@i2se.com> writes:
> 
> > Hi,
> >
> >> Doug Anderson <diand...@chromium.org> hat am 18. April 2017 um 22:41 
> >> geschrieben:
> >> 
> >> 
> >> It's hard to know for sure that all of this time is really in
> >> urb_enqueue().  Possible we could have task switched out and been
> >> blocked elsewhere.  Using ftrace to get more fine-grained timings
> >> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
> >> friends here if you want to use trace_printk.
> >
> > i'm a newbie to ftrace, so i hope this would be helpful.
> >
> > # connect PL2303 to the onboard hub
> > # echo 0 > options/sleep-time
> > # echo 0 > function_profile_enabled
> > # echo 1 > function_profile_enabled
> > # ./usb_test
> > # Waiting for at least 20 seconds and then disconnect PL2303
> > # echo 0 > function_profile_enabled
> > # cat trace_stat/function0
> >
> >   Function   HitTimeAvg 
> > s^2
> >      ------ 
> > ---
> >   bcm2835_handle_irq  361347219567633 us 607.636 us 
> >  1485199 us  
> >   __handle_domain_irq1082482212639551 us 196.437 us 
> >  3642030 us  
> >   generic_handle_irq 1082482100592051 us 92.927 us  
> >  50511334 us 
> >   irq_exit   108248298197771 us 90.715 us   
> > 29649040 us 
> >   handle_level_irq   108248295812379 us 88.511 us   
> > 51910093 us 
> 
> If I'm reading this output right, we're spending half of our interrupt
> processing time in irq_exit(), so even if dwc2's interrupt was free (the
> generic_handle_irq() chain), we'd be eating about half the CPU getting
> back out of the interrupt handler, right?
> 
> I don't really know anything about DWC2 or USB, but is there any way we
> could mitigate the interrupt frequency with this hardware?  If nothing
> else, could we loop reading gintsts until it reads back 0?

first of all i updated my kernel to 4.11rc7 and the issue still occures. Today 
i had some time to investigate this issue further and i made some interesting 
observations:

1. The lockup doesn't occure always after starting usb_test. In rare cases i 
was able to run the program without lockup.
2. In case the lockup occured we are always able to "rescue" the BCM2835 from 
this state by sending some serial data to the PL2303.
3. I looked again at the logic analyzer traces of the PL2303 and FTDI. After 
usb_test has been started the time between 2 _dwc2_hcd_irq calls is mostly 
smaller than 6 us (this can't be correct for a single device doesn't send any 
data). With other words it seems to me one or more interrupt(s) are never acked.
4. I placed a trace_printk into dwc2_handle_hcd_intr() in order to dump 
GINTSTS. In normal state we usually reach the value 0x0429, but not in 
lockup state.

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

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

Am 19.04.2017 um 23:47 schrieb Doug Anderson:
> Hi,
>
> On Wed, Apr 19, 2017 at 1:25 PM, Stefan Wahren <stefan.wah...@i2se.com> wrote:
>> Hi,
>>
>>> Doug Anderson <diand...@chromium.org> hat am 18. April 2017 um 22:41 
>>> geschrieben:
>>>
>>>
>>> It's hard to know for sure that all of this time is really in
>>> urb_enqueue().  Possible we could have task switched out and been
>>> blocked elsewhere.  Using ftrace to get more fine-grained timings
>>> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
>>> friends here if you want to use trace_printk.
>> i'm a newbie to ftrace, so i hope this would be helpful.
>>
>> # connect PL2303 to the onboard hub
>> # echo 0 > options/sleep-time
>> # echo 0 > function_profile_enabled
>> # echo 1 > function_profile_enabled
>> # ./usb_test
>> # Waiting for at least 20 seconds and then disconnect PL2303
>> # echo 0 > function_profile_enabled
>> # cat trace_stat/function0
>>
>>   Function   HitTimeAvg  
>>s^2
>>      ------  
>>---
>>   bcm2835_handle_irq  361347219567633 us 607.636 us  
>> 1485199 us
>>   __handle_domain_irq1082482212639551 us 196.437 us  
>> 3642030 us
>>   generic_handle_irq 1082482100592051 us 92.927 us   
>> 50511334 us
>>   irq_exit   108248298197771 us 90.715 us
>>29649040 us
>>   handle_level_irq   108248295812379 us 88.511 us
>>51910093 us
>>   do_sys_open   180687612983 us 48512.17 us  
>>2198507 us
>>   SyS_open  160187372331 us 54573.59 us  
>>1898996 us
>>   do_filp_open  186287368058 us 46921.62 us  
>>1634982 us
>>   path_openat   186287314553 us 46892.88 us  
>>3357817 us
>>   __do_softirq  303586266050 us 28423.73 us  
>>6449768 us
>>   vfs_open  151585877012 us 56684.49 us  
>>101673.5 us
>>   do_dentry_open151585861429 us 56674.21 us  
>>812420.7 us
>>   usb_submit_urb 13685760172 us 630589.5 us  
>>59532024 us
>>   usb_hcd_submit_urb 13485756518 us 639974.0 us  
>>726298102 us
>>   _dwc2_hcd_urb_enqueue  13485738333 us 639838.3 us  
>>874104371 us
> The 134 calls to this are taking a ton of time.  It would be nice to
> know where all the time actually was in here.  Are you on a
> single-core device, or multi-core?

Raspberry Pi B is a single core device which runs with 700 MHz cpu freq.

> Oh, probably this so slow because we're just getting interrupted
> constantly.  You can see that during your trace 80686112 us was in
> handle_irq_event().  Presumably all of that time could have been
> counted towards whatever code you were in when the interrupt went off.
> Of that 80 seconds, 60 seconds or so was usb_hcd_irq, and of that 57
> seconds was in _dwc2_hcd_irq().

Since the FTDI (full speed device) and the PL2303 (also full speed
device) behaves differently, i will try to compare those ftraces.

>
> Presumably the big part of your problem is that dwc2_handle_hcd_intr()
> is just too slow.  From glancing at the numbers below, it seems likely
> that nothing in particular is slow, it's just running a lot of code
> and (in total) all of that is slow.  ...but someone with more time on
> their hands would need to really debug.
>
> One thing that would be interesting would be to see if you can
> increase the bug clock for talking to the dwc2 controller.  

Unfortunately the bcm2835 datasheet [1] doesn't provide many information
about the USB IP core and the Synopsys documents aren't public
available. The Raspberry Pi Foundation decided to use a different driver
which uses FIQ in the downstream tree [2], but this won't be an option here.

Maybe i could start with comparing the register settings between dwc2
and dwc_otg.

[1] -
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
[2] -
https://github.com/raspberrypi/linux/commit/65165df02f2ba9feccebf45d8c732dffb34b6109

> Possibly
> some of those memory mapped IOs talking to dwc2 could be making
> everything slow?
>
> Other than that, maybe you can find some way to optimize the code in
> dwc2 so it runs faster, at least in the cases you care about...
>

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

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

Hi,

> Doug Anderson  hat am 18. April 2017 um 22:41 
> geschrieben:
> 
> 
> It's hard to know for sure that all of this time is really in
> urb_enqueue().  Possible we could have task switched out and been
> blocked elsewhere.  Using ftrace to get more fine-grained timings
> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
> friends here if you want to use trace_printk.

i'm a newbie to ftrace, so i hope this would be helpful.

# connect PL2303 to the onboard hub
# echo 0 > options/sleep-time
# echo 0 > function_profile_enabled
# echo 1 > function_profile_enabled
# ./usb_test
# Waiting for at least 20 seconds and then disconnect PL2303
# echo 0 > function_profile_enabled
# cat trace_stat/function0

  Function   HitTimeAvg 
s^2
     ------ 
---
  bcm2835_handle_irq  361347219567633 us 607.636 us 
 1485199 us  
  __handle_domain_irq1082482212639551 us 196.437 us 
 3642030 us  
  generic_handle_irq 1082482100592051 us 92.927 us  
 50511334 us 
  irq_exit   108248298197771 us 90.715 us   
29649040 us 
  handle_level_irq   108248295812379 us 88.511 us   
51910093 us 
  do_sys_open   180687612983 us 48512.17 us 
2198507 us  
  SyS_open  160187372331 us 54573.59 us 
1898996 us  
  do_filp_open  186287368058 us 46921.62 us 
1634982 us  
  path_openat   186287314553 us 46892.88 us 
3357817 us  
  __do_softirq  303586266050 us 28423.73 us 
6449768 us  
  vfs_open  151585877012 us 56684.49 us 
101673.5 us 
  do_dentry_open151585861429 us 56674.21 us 
812420.7 us 
  usb_submit_urb 13685760172 us 630589.5 us 
59532024 us 
  usb_hcd_submit_urb 13485756518 us 639974.0 us 
726298102 us 
  _dwc2_hcd_urb_enqueue  13485738333 us 639838.3 us 
874104371 us 
  chrdev_open 8785716519 us 985247.3 us 
1951112835 us 
  tty_open 385714494 us 28571498 us 
3743206849 us 
  tty_port_open385712603 us 28570867 us 
1968003468 us 
  serial_open  185712472 us 85712472 us 
0.000 us
  serial_port_activate 185709890 us 85709890 us 
0.000 us
  pl2303_open  185709875 us 85709875 us 
0.000 us
  usb_serial_generic_open  185701170 us 85701170 us 
0.000 us
  usb_serial_generic_submit_read   185701166 us 85701166 us 
0.000 us
  usb_serial_generic_submit_read   285701160 us 42850580 us 
2252410463 us 
  handle_irq_event   108248280686112 us 74.538 us   
36417905 us 
  handle_irq_event_percpu108248278398378 us 72.424 us   
34060119 us 
  __handle_irq_event_percpu  108248268466046 us 63.249 us   
53609076 us 
  usb_hcd_irq107894559761116 us 55.388 us   
25139388 us 
  _dwc2_hcd_irq  107894557481606 us 53.275 us   
30847036 us 
  dwc2_handle_hcd_intr   107894555380910 us 51.328 us   
35986237 us 
  do_idle39443577379 us 110602.4 us 
84278209 us 
  dwc2_hc_n_intr  65106542408491 us 65.137 us   
7281229 us  
  default_idle_call   22996938021287 us 165.332 us  
11386904 us 
  arch_cpu_idle   22996937379305 us 162.540 us  
2168909 us  
  dwc2_halt_channel   65081134208348 us 52.562 us   
7792012 us  
  dwc2_release_channel65106533042638 us 50.751 us   
8112754 us  
  dwc2_hc_nak_intr33468918892951 us 56.449 us   
1823592 us  
  dwc2_hc_ack_intr31598618323433 us 57.988 us   
151346.6 us 
  dwc2_hcd_select_transactions   173001011694955 us 6.760 us
1188442 us  
  dwc2_hcd_queue_transactions 65106510931854 us 16.790 us   
952074.2 us 
  dwc2_assign_and_init_hc 6510659540885 us  14.654 us   
258067.1 us 
  dwc2_queue_transaction  6510659192559 us  14.119 us   
736431.6 us 
  tick_nohz_irq_exit  3250559052192 us  27.848 us   
916293.3 us 
  

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

Am 19.04.2017 um 10:56 schrieb Johan Hovold:
> On Tue, Apr 18, 2017 at 10:25:06PM +0200, Stefan Wahren wrote:
>> Hi,
>>
>> [add Johan]
>>
>>> Stefan Wahren <stefan.wah...@i2se.com> hat am 18. April 2017 um 10:07 
>>> geschrieben:
>>>
>>>
>>> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
>>>> Hi,
>>>>
>>>> On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wah...@i2se.com> 
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> Stefan Wahren <stefan.wah...@i2se.com> hat am 31. Oktober 2016 um 21:34 
>>>>>> geschrieben:
>>>>>>
>>>>>>
>>>>>> I inspired by this issue [1] i build up a slightly modified
>>>>>> setup with a Raspberry Pi B (mainline kernel 4.9rc3), a powered
>>>>>> 7 port USB hub and 5 Prolific PL2303 USB to serial convertors. I
>>>>>> modified the usb_test for dwc2 [2], which only tries to open all
>>>>>> ttyUSB devices one after the other.
>>>>>>
>>>>>> Unfortunately the complete system stuck after opening the first
>>>>>> ttyUSB device ( heartbeat LED stop blinking, no reaction to
>>>>>> debug UART). The only way to reanimate the system is to
>>>>>> powerdown the USB hub with the USB to serial convertors.
>>>>>>
>>>>>> [1] - https://github.com/raspberrypi/linux/issues/1692
>> i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure
>> _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
>>
>> So i made my observations for 3 test cases:
>>
>> 1) no serial converter connected (idle)
>> 2) 1 FTDI serial converter connected
>> 3) 1 PL2303 serial converter connected
>>
>> case   | ksoftirq cpu | mean duration | max duration  | max duration | 
>> urb_enqueue  |
>>|  | hcd_irq   | hcd_irq   | urb_enqueue  | 
>> within 10 sec|
>> ---+--+---+---+--+--+
>> idle   | 0.0% | 2 us  | 16.5 us   | 12 us| 5 
>>|
>> FTDI   | 25.0%| 8.5 us| 18.0 us   |  31000 us| ~ 
>> 400|
>> PL2303 | top doesn't work | 8.5 us| 22.5 us   | 90 us| 4 
>>|
>>
>> So it seems the serial USB driver has also an impact. In the analyzer
>> trace the FTDI triggers many smaller urb_enqueue calls in the opposite
>> to the PL2303 which only has few but huge calls.
> What do you mean by "huge calls" above?

The time it takes until _dwc2_hcd_urb_enqueue is finished.

>
> Are you just keeping the ports open (i.e. with no data being received or
> sent)?

Yes, only open and no data is received or sent (LEDs doesn't show any
activity).

>
> FTDI devices are notorious for their status messages being sent
> continuously while the port is open. You'll get a two-byte bulk-in
> message every 16ms by default (these were sent every millisecond up
> until recently due to a long-standing regression).
>
> PL2303 devices have an interrupt-in endpoint which is used for status
> notifications so you would not see any completion callbacks on an
> otherwise idle port.
>
>> Additional notes:
>> After closing the serial connection to the FTDI the system is usable
>> as before. In case of PL2303 i need to disconnect the converter in
>> order to get a usable system.
> Does your system lock up when you open the first pl2303 device?

Yes (directly to the onboard hub or an external hub make no difference).

>
>> Why do they behave so differently?
> So the ftdi bulk-in status messages and the pl2303 interrupt-in endpoint
> could be two reasons, but I guess so could any change in timing etc.
>
> Is your ftdi-device a Full Speed device like the pl2303?

Sorry, i will need to verify.

Thanks
Stefan

>
> 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: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

> Doug Anderson <diand...@chromium.org> hat am 18. April 2017 um 22:41 
> geschrieben:
> 
> 
> Stefan,
> 
> On Tue, Apr 18, 2017 at 1:25 PM, Stefan Wahren <stefan.wah...@i2se.com> wrote:
> > Hi,
> >
> > [add Johan]
> >
> >> Stefan Wahren <stefan.wah...@i2se.com> hat am 18. April 2017 um 10:07 
> >> geschrieben:
> >>
> >>
> >> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> >> > Hi,
> >> >
> >> > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wah...@i2se.com> 
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >>> Stefan Wahren <stefan.wah...@i2se.com> hat am 31. Oktober 2016 um 
> >> >>> 21:34 geschrieben:
> >> >>>
> >> >>>
> >> >>> I inspired by this issue [1] i build up a slightly modified setup with 
> >> >>> a
> >> >>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 
> >> >>> 5 Prolific
> >> >>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], 
> >> >>> which
> >> >>> only tries to open all ttyUSB devices one after the other.
> >> >>>
> >> >>> Unfortunately the complete system stuck after opening the first ttyUSB 
> >> >>> device (
> >> >>> heartbeat LED stop blinking, no reaction to debug UART). The only way 
> >> >>> to
> >> >>> reanimate the system is to powerdown the USB hub with the USB to serial
> >> >>> convertors.
> >> >>>
> >> >>> [1] - https://github.com/raspberrypi/linux/issues/1692
> >> >>> [2] - 
> >> >>> https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
> >> >> since this issue still exists with 4.11 (even without or with 
> >> >> microframe scheduler enabled), i want to ask some additional questions:
> >> >>
> >> >> Is this issue reproducible with other dwc2 platforms than bcm2835?
> >> > +Edmund Szeto, who I seem to remember emailing me about similar
> >> > questions in the past.
> >> >
> >> >
> >> >> Does the soft lockup also occurs after opening the second serial 
> >> >> convertor or later?
> >> > I don't have serial converters easily available to me, but back in the
> >> > day when I was stressing things out on rk3288 I never saw anything
> >> > this bad.  ...of course, on rk3288 we've got 4 A17 cores running
> >> > really fast, so possibly just being slower is what causes your
> >> > problems here?
> >>
> >> The downstream kernel of the Raspberry Pi foundation with it's
> >> out-of-tree dwc_otg driver is able to handle 8 serial converter on a RPI
> >> B. I would be happy to get at least 2 or 3 working on mainline.
> >>
> >> >
> >> > I will make the following observations:
> >> >
> >> > 1. With dwc2 you often end up in the situation where you need to
> >> > service an interrupt every 125 uS.  If servicing that interrupt takes
> >> > anywhere near 125 uS in the common case then you'll be in trouble.
> >>
> >> I will try to measure this with a logic analyzer.
> >>
> >
> > i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure 
> > _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
> >
> > So i made my observations for 3 test cases:
> >
> > 1) no serial converter connected (idle)
> > 2) 1 FTDI serial converter connected
> > 3) 1 PL2303 serial converter connected
> >
> > case   | ksoftirq cpu | mean duration | max duration  | max duration | 
> > urb_enqueue  |
> >|  | hcd_irq   | hcd_irq   | urb_enqueue  | 
> > within 10 sec|
> > ---+--+---+---+--+--+
> > idle   | 0.0% | 2 us  | 16.5 us   | 12 us| 
> > 5|
> > FTDI   | 25.0%| 8.5 us| 18.0 us   |  31000 us| 
> > ~ 400|
> > PL2303 | top doesn't work | 8.5 us| 22.5 us   | 90 us| 
> > 4|
> 
> It's hard to know for sure that all of this time is really in
> urb_enqueue().  Possible we could have task switched out and been
> blocked elsewhere.  Using ftrace to get more fine-grained timings
> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
> friends here if you want to use trace_printk.
> 

I saw your last reply after sending my last mail. I will go further with ftrace.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

Hi,

[add Johan]

> Stefan Wahren <stefan.wah...@i2se.com> hat am 18. April 2017 um 10:07 
> geschrieben:
> 
> 
> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> > Hi,
> >
> > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wah...@i2se.com> 
> > wrote:
> >> Hi,
> >>
> >>> Stefan Wahren <stefan.wah...@i2se.com> hat am 31. Oktober 2016 um 21:34 
> >>> geschrieben:
> >>>
> >>>
> >>> I inspired by this issue [1] i build up a slightly modified setup with a
> >>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 
> >>> Prolific
> >>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], 
> >>> which
> >>> only tries to open all ttyUSB devices one after the other.
> >>>
> >>> Unfortunately the complete system stuck after opening the first ttyUSB 
> >>> device (
> >>> heartbeat LED stop blinking, no reaction to debug UART). The only way to
> >>> reanimate the system is to powerdown the USB hub with the USB to serial
> >>> convertors.
> >>>
> >>> [1] - https://github.com/raspberrypi/linux/issues/1692
> >>> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
> >> since this issue still exists with 4.11 (even without or with microframe 
> >> scheduler enabled), i want to ask some additional questions:
> >>
> >> Is this issue reproducible with other dwc2 platforms than bcm2835?
> > +Edmund Szeto, who I seem to remember emailing me about similar
> > questions in the past.
> >
> >
> >> Does the soft lockup also occurs after opening the second serial convertor 
> >> or later?
> > I don't have serial converters easily available to me, but back in the
> > day when I was stressing things out on rk3288 I never saw anything
> > this bad.  ...of course, on rk3288 we've got 4 A17 cores running
> > really fast, so possibly just being slower is what causes your
> > problems here?
> 
> The downstream kernel of the Raspberry Pi foundation with it's
> out-of-tree dwc_otg driver is able to handle 8 serial converter on a RPI
> B. I would be happy to get at least 2 or 3 working on mainline.
> 
> >
> > I will make the following observations:
> >
> > 1. With dwc2 you often end up in the situation where you need to
> > service an interrupt every 125 uS.  If servicing that interrupt takes
> > anywhere near 125 uS in the common case then you'll be in trouble.
> 
> I will try to measure this with a logic analyzer.
> 

i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure 
_dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).

So i made my observations for 3 test cases:

1) no serial converter connected (idle)
2) 1 FTDI serial converter connected
3) 1 PL2303 serial converter connected

case   | ksoftirq cpu | mean duration | max duration  | max duration | 
urb_enqueue  |
   |  | hcd_irq   | hcd_irq   | urb_enqueue  | 
within 10 sec|
---+--+---+---+--+--+
idle   | 0.0% | 2 us  | 16.5 us   | 12 us| 5
|
FTDI   | 25.0%| 8.5 us| 18.0 us   |  31000 us| ~ 
400|
PL2303 | top doesn't work | 8.5 us| 22.5 us   | 90 us| 4
|

So it seems the serial USB driver has also an impact. In the analyzer trace the 
FTDI triggers many smaller urb_enqueue calls in the opposite to the PL2303 
which only has few but huge calls.

Additional notes:
After closing the serial connection to the FTDI the system is usable as before. 
In case of PL2303 i need to disconnect the converter in order to get a usable 
system.

Why do they behave so differently?
Are these results of a overload?
Doug, can you point me to your timing patch?

Thanks
Stefan

PS: My hacky patches for measuring

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1a7e830..aa490c3 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -930,6 +930,9 @@ struct dwc2_hsotg {
struct dentry *debug_root;
struct debugfs_regset32 *regset;
 
+   int gpio_17;
+   int gpio_18;
+
/* DWC OTG HW Release versions */
 #define DWC2_CORE_REV_2_71a0x4f54271a
 #define DWC2_CORE_REV_2_90a0x4f54290a
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a73722e..97271c8 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4595,13 +4596,17 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hc

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> Hi,
>
> On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wah...@i2se.com> wrote:
>> Hi,
>>
>>> Stefan Wahren <stefan.wah...@i2se.com> hat am 31. Oktober 2016 um 21:34 
>>> geschrieben:
>>>
>>>
>>> I inspired by this issue [1] i build up a slightly modified setup with a
>>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 
>>> Prolific
>>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
>>> only tries to open all ttyUSB devices one after the other.
>>>
>>> Unfortunately the complete system stuck after opening the first ttyUSB 
>>> device (
>>> heartbeat LED stop blinking, no reaction to debug UART). The only way to
>>> reanimate the system is to powerdown the USB hub with the USB to serial
>>> convertors.
>>>
>>> [1] - https://github.com/raspberrypi/linux/issues/1692
>>> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
>> since this issue still exists with 4.11 (even without or with microframe 
>> scheduler enabled), i want to ask some additional questions:
>>
>> Is this issue reproducible with other dwc2 platforms than bcm2835?
> +Edmund Szeto, who I seem to remember emailing me about similar
> questions in the past.
>
>
>> Does the soft lockup also occurs after opening the second serial convertor 
>> or later?
> I don't have serial converters easily available to me, but back in the
> day when I was stressing things out on rk3288 I never saw anything
> this bad.  ...of course, on rk3288 we've got 4 A17 cores running
> really fast, so possibly just being slower is what causes your
> problems here?

The downstream kernel of the Raspberry Pi foundation with it's
out-of-tree dwc_otg driver is able to handle 8 serial converter on a RPI
B. I would be happy to get at least 2 or 3 working on mainline.

>
> I will make the following observations:
>
> 1. With dwc2 you often end up in the situation where you need to
> service an interrupt every 125 uS.  If servicing that interrupt takes
> anywhere near 125 uS in the common case then you'll be in trouble.

I will try to measure this with a logic analyzer.

>
> ===
>
> 2. When I was testing on rk3288 (on kernel 3.14) I did see occasions
> where uvc_video_complete() could sometimes take > 125 uS.  It's been a
> long time now, but if I remember correctly this had to do with the
> fact that the URB buffers were allocated in a way where you had to
> access them non-cached and this was super duper slow.  In my
> particular case I could "fix" it by adjusting UVC_MAX_PACKETS
> (crosreview.com/321932).  ...and I had some timing code in
> crosreview.com/321980.
>
> Again, it was a long time ago, but elsewhere I have written down:
>
> -
>
> Specifically:
> * The USB "complete" functions are called with local interrupts
> disabled.  Specifically see __usb_hcd_giveback_urb().
> * I see calls to uvc_video_complete() that easily take > 125us.
>
> Unfortunately the interrupts disabled while uvc_video_complete() is
> called are always the interrupts for the same CPU that's dealing with
> the normal dwc2 USB interrupts.
>
> --
>
> Ugh.  This may be the memcpy() as others have found:
>
> http://www.spinics.net/lists/linux-usb/msg83581.html
>
> ...looks like the issue is that the driver is allocating memory that's
> supposed to be DMA coherent and copying from this memory is slow.
>
> -
>
> You could probably pick my timing patch and then see if you're
> actually hitting cases like this, I guess?
>
> ===
>
> 3. Are you running CPUFreq by chance?
>
> ...back in the day we had a bug on rk3288 where we were temporarily
> running the CPU as slow as 8 MHz for a short while during a CPUFreq
> transition.  If you happened to get a dwc2 interrupt while at this
> speed then you were in trouble.

There is no CPUFreq driver for bcm2835 in mainline and i hope the GPU
firmware doesn't play with the core frequency during runtime.

I also use the bcm2835_defconfig, which does have anything disabled
under kernel hacking.

Thanks
Stefan

>
>
> -Doug

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

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

Hi,

> Stefan Wahren <stefan.wah...@i2se.com> hat am 31. Oktober 2016 um 21:34 
> geschrieben:
> 
> 
> I inspired by this issue [1] i build up a slightly modified setup with a
> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 
> Prolific
> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
> only tries to open all ttyUSB devices one after the other. 
> 
> Unfortunately the complete system stuck after opening the first ttyUSB device 
> (
> heartbeat LED stop blinking, no reaction to debug UART). The only way to
> reanimate the system is to powerdown the USB hub with the USB to serial
> convertors.
> 
> [1] - https://github.com/raspberrypi/linux/issues/1692
> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa

since this issue still exists with 4.11 (even without or with microframe 
scheduler enabled), i want to ask some additional questions:

Is this issue reproducible with other dwc2 platforms than bcm2835?
Does the soft lockup also occurs after opening the second serial convertor or 
later?

Regards
Stefan

> 
> pi@raspberrypi:~$ lsusb -t
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx,
> 480M
> |__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 2: Dev 14, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 3: Dev 16, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> 
> pi@raspberrypi:~$ ./usb_test
> idle
> opening [/dev/ttyUSB0] ok
> [  232.658768] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s!
> [usb_test:522]
> [  232.678443] Modules linked in: pwm_bcm2835 vchiq(C)
> [  232.678481] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
>  4.9.0-rc3+ #33
> [  232.678486] Hardware name: BCM2835
> [  232.678498] task: cab54e40 task.stack: c688c000
> [  232.678520] PC is at __do_softirq+0x68/0x2a8
> [  232.678538] LR is at irq_exit+0xb8/0x120
> [  232.678552] pc : []lr : []psr: 6113
> sp : c688da60  ip : c688daa8  fp : c688daa4
> [  232.678560] r10: c0b7f800  r9 : c688c000  r8 : 0040
> [  232.678567] r7 : 000a  r6 : cb802400  r5 :   r4 : 0001
> [  232.678575] r3 :   r2 : 0100  r1 : 0040  r0 : 
> [  232.678585] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [  232.678593] Control: 00c5387d  Table: 068a4008  DAC: 0051
> [  232.678604] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
>  4.9.0-rc3+ #33
> [  232.678609] Hardware name: BCM2835
> [  232.678667] [] (unwind_backtrace) from []
> (show_stack+0x20/0x24)
> [  232.678695] [] (show_stack) from []
> (dump_stack+0x20/0x28)
> [  232.678718] [] (dump_stack) from [] 
> (show_regs+0x1c/0x20)
> [  232.678752] [] (show_regs) from []
> (watchdog_timer_fn+0x140/0x19c)
> [  232.678779] [] (watchdog_timer_fn) from []
> (__hrtimer_run_queues.constprop.3+0xec/0x210)
> [  232.678798] [] (__hrtimer_run_queues.constprop.3) from 
> []
> (hrtimer_interrupt+0xa4/0x1cc)
> [  232.678827] [] (hrtimer_interrupt) from []
> (bcm2835_time_interrupt+0x40/0x48)
> [  232.678865] [] (bcm2835_time_interrupt) from []
> (__handle_irq_event_percpu+0x68/0x1b8)
> [  232.678891] [] (__handle_irq_event_percpu) from []
> (handle_irq_event_percpu+0x2c/0x68)
> [  232.678915] [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x38/0x4c)
> [  232.678939] [] (handle_irq_event) from []
> (handle_level_irq+0xc4/0xf8)
> [  232.678960] [] (handle_level_irq) from []
> (generic_handle_irq+0x28/0x38)
> [  232.678983] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x90/0xb8)
> [  232.679004] [] (__handle_domain_irq) from []
> (bcm2835_handle_irq+0x30/0x48)
> [  232.679022] [] (bcm2835_handle_irq) from []
> (__irq_svc+0x6c/0x90)
> [  232.679031] Exception stack(0xc688da10 to 0xc688da58)
> [  232.679044] da00:  0040
> 0100 
> [  232.679062] da20: 0001  cb802400 000a 0040 c688c000
> c0b7f800 c688daa4
> [  232.679078] da40: c688daa8 c688da60 c0121270 c01014d0 6113 f00
> c687a300 c9374900 ca918b00 caff1200 c688db84
> [  232.679235] db20: c688db28 c688db40 c04a1cf8 c049

dwc2: g_serial doesn't enumerate when builtin

[Stefan Wahren]

Hi,

this seems like a newbie question, but shouldn't g_serial also work in case 
it's builtin?

I tested g_serial with a Raspberry Pi Zero (OTG mode, Linux 4.11-rc1) as gadget 
and a Linux Laptop as host (Linux 4.10.9). In case g_serial is build as a 
kernel module the RPi gets enumerated on the Linux host and in case of g_serial 
builtin not. In both cases i didn't provide any gadget configuration via 
configfs or kernel commandline.

Regards
Stefan

Gadget builtin (bad case)
=

dmesg (Host)

[19755.687770] usb 2-1.1.3: new high-speed USB device number 20 using ehci-pci
[19756.055743] usb 2-1.1.3: new high-speed USB device number 21 using ehci-pci
[19761.271755] usb 2-1.1.3: device descriptor read/64, error -110
[19776.887724] usb 2-1.1.3: device descriptor read/64, error -110
[19777.075724] usb 2-1.1.3: new high-speed USB device number 22 using ehci-pci
[19782.263715] usb 2-1.1.3: device descriptor read/64, error -110
[19797.879679] usb 2-1.1.3: device descriptor read/64, error -110
[19798.067654] usb 2-1.1.3: new high-speed USB device number 23 using ehci-pci
[19808.759654] usb 2-1.1.3: device not accepting address 23, error -110
[19808.843564] usb 2-1.1.3: new high-speed USB device number 24 using ehci-pci
[19819.511555] usb 2-1.1.3: device not accepting address 24, error -110
[19819.511699] usb 2-1.1-port3: unable to enumerate USB device

.config (RPi Zero)

CONFIG_USB_DWC2=y
CONFIG_USB_DWC2_DUAL_ROLE=y
CONFIG_USB_PHY=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_GADGET=y
CONFIG_USB_LIBCOMPOSITE=y
CONFIG_USB_F_ACM=y
CONFIG_USB_U_SERIAL=y
CONFIG_USB_F_SERIAL=y
CONFIG_USB_F_OBEX=y
CONFIG_USB_G_SERIAL=y

dmesg (RPi Zero)

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.11.0-rc1+ (user@Raspberry) (gcc version 4.7.1 
20120402 (prerelease) (crosstool-NG 1.15.2) ) #4 Sat Apr 15 12:31:27 UTC 2017
...
[0.691449] udc-core: couldn't find an available UDC - added [g_serial] to 
list of pending drivers
...
[2.265701] dwc2 2098.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[2.280590] g_serial gadget: Gadget Serial v2.4
[2.291998] g_serial gadget: g_serial ready
[2.302774] dwc2 2098.usb: bound driver g_serial
[2.314624] dwc2 2098.usb: DWC OTG Controller
[2.325990] dwc2 2098.usb: new USB bus registered, assigned bus number 1
[2.339981] dwc2 2098.usb: irq 33, io mem 0x2098
[2.353571] hub 1-0:1.0: USB hub found
[2.364030] hub 1-0:1.0: 1 port detected

Gadget Module (good case)
=

dmesg (Host)

[   83.789606] usb 2-1.1.4: new high-speed USB device number 6 using ehci-pci
[   84.045604] usb 2-1.1.4: new high-speed USB device number 7 using ehci-pci
[   89.241203] usb 2-1.1.4: device descriptor read/64, error -110
[  104.856069] usb 2-1.1.4: device descriptor read/64, error -110
[  105.044058] usb 2-1.1.4: new high-speed USB device number 8 using ehci-pci
[  110.231823] usb 2-1.1.4: device descriptor read/64, error -110
[  125.743732] usb 2-1.1.4: new high-speed USB device number 9 using ehci-pci
[  125.857294] usb 2-1.1.4: New USB device found, idVendor=0525, idProduct=a4a7
[  125.857298] usb 2-1.1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[  125.857300] usb 2-1.1.4: Product: Gadget Serial v2.4
[  125.857303] usb 2-1.1.4: Manufacturer: Linux 4.11.0-rc1+ with 2098.usb
[  125.926208] cdc_acm 2-1.1.4:2.0: ttyACM0: USB ACM device
[  125.926559] usbcore: registered new interface driver cdc_acm
[  125.926560] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters

lsusb (Host)

Bus 002 Device 009: ID 0525:a4a7 Netchip Technology, Inc. Linux-USB Serial 
Gadget (CDC ACM mode)
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0525 Netchip Technology, Inc.
  idProduct  0xa4a7 Linux-USB Serial Gadget (CDC ACM mode)
  bcdDevice4.11
  iManufacturer   1 
  iProduct2 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   75
bNumInterfaces  2
bConfigurationValue 2
iConfiguration  4 
bmAttributes 0xc0
  Self Powered
MaxPower2mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass  2 Communications
  bFunctionSubClass   2 Abstract (modem)
  bFunctionProtocol   1 AT-commands (v.25ter)
  iFunction   7 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber 

Re: usb/net/hso: WARNING: ungligned urb->setup_dma

[Stefan Wahren]

Hi Baruch,

Am 01.03.2017 um 11:54 schrieb Baruch Siach:
> Hi Stefan,
>
> On Tue, Feb 28, 2017 at 07:32:09PM +0100, Stefan Wahren wrote: 
>>> Baruch Siach <bar...@tkos.co.il> hat am 28. Februar 2017 um 19:07 
>>> geschrieben:
>>> On Tue, Feb 28, 2017 at 05:21:18PM +0100, Stefan Wahren wrote:
>>>> Am 28.02.2017 um 13:01 schrieb Baruch Siach:
>>>>> On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
>>>>>> I'm hitting this warning consistently on my Raspberry Pi 3 running 
>>>>>> kernel
>>>>>> v4.10.1 with some unrelated device tree changes, and a debug print 
>>>>>> (below).
>>>>>> The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: 
>>>>>> 6971.
>>>>>> The warning triggers consistently on first write access to /dev/ttyHS0 
>>>>>> that
>>>>>> ModemManager attempts. The first line in the log is my debug print.
>>>>> I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) using 
>>>>> the
>>>>> same kernel version (4.10.1), and on an x86_64 PC (4.9). So this seems to 
>>>>> be
>>>>> platform specific. I don't have any other ARM64 machine at the moment, 
>>>>> though.
>>>> those platforms usually doesn't use the dwc2 USB host controller. So it
>>>> should be tested with another dwc2 platform.
>>> The code that initializes setup_dma is not under drivers/usb/dwc2/. Though 
>>> the 
>>> problem looks like memory corruption, so its cause might be anywhere.
>> only a suspicion, but could you please try this patch [1]?
>>
>> [1] - https://patchwork.kernel.org/patch/9166771/
> It doesn't change anything.
>
> My guess is that source of the issue is memory corruption that just happens 
> to 
> corrupt also the setup_dma field of struct urb. In other words, it has 
> nothing 
> to do with DMA, IMO.

may you could use

CONFIG_DMA_API_DEBUG

or

CONFIG_SLUB_DEBUG

in order to find the source?

>
> Thanks,
> baruch
>


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

Re: usb/net/hso: WARNING: ungligned urb->setup_dma

[Stefan Wahren]

Hi Baruch,

> Baruch Siach <bar...@tkos.co.il> hat am 28. Februar 2017 um 19:07 geschrieben:
> 
> 
> Hi Stefan,
> 
> On Tue, Feb 28, 2017 at 05:21:18PM +0100, Stefan Wahren wrote:
> > Am 28.02.2017 um 13:01 schrieb Baruch Siach:
> > > On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
> > > > I'm hitting this warning consistently on my Raspberry Pi 3 running 
> > > > kernel
> > > > v4.10.1 with some unrelated device tree changes, and a debug print 
> > > > (below).
> > > > The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: 
> > > > 6971.
> > > > The warning triggers consistently on first write access to /dev/ttyHS0 
> > > > that
> > > > ModemManager attempts. The first line in the log is my debug print.
> > > I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) using 
> > > the
> > > same kernel version (4.10.1), and on an x86_64 PC (4.9). So this seems to 
> > > be
> > > platform specific. I don't have any other ARM64 machine at the moment, 
> > > though.
> > 
> > those platforms usually doesn't use the dwc2 USB host controller. So it
> > should be tested with another dwc2 platform.
> 
> The code that initializes setup_dma is not under drivers/usb/dwc2/. Though 
> the 
> problem looks like memory corruption, so its cause might be anywhere.

only a suspicion, but could you please try this patch [1]?

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

Re: usb/net/hso: WARNING: ungligned urb->setup_dma

[Stefan Wahren]

Hi Baruch,

Am 28.02.2017 um 13:01 schrieb Baruch Siach:

Hi linux-usb list,

(Dropped Jan's bouncing address, added Rpi3 platform lists)

On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:

Hi linux-usb list,

I'm hitting this warning consistently on my Raspberry Pi 3 running kernel
v4.10.1 with some unrelated device tree changes, and a debug print (below).
The device identifies as "GlobeTrotter HSDPA Modem", VID: 0af0, PID: 6971.
The warning triggers consistently on first write access to /dev/ttyHS0 that
ModemManager attempts. The first line in the log is my debug print.

I tested the same hardware successfully on an i.MX6 CuBox-i (ARM32) using the
same kernel version (4.10.1), and on an x86_64 PC (4.9). So this seems to be
platform specific. I don't have any other ARM64 machine at the moment, though.


those platforms usually doesn't use the dwc2 USB host controller. So it 
should be tested with another dwc2 platform.


Is the issue reproducible with other USB devices like keyboards?
Are you using arm64 defconfig?
Are you able to bisect this issue?

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

Re: USB/swiotlb failure on arm64/RPi3

[Stefan Wahren]

[Add John and linux-usb]

Am 24.01.2017 um 23:52 schrieb Aaro Koskinen:
> Hi,
>
> Booting Debian rootfs from USB hard disk (ext4) using 64-bit 4.9 kernel
> on Raspberry Pi 3 fails early in the boot as follows:
>
> [   15.162466] systemd[1]: Detected architecture arm64.
>
> Welcome to Debian GNU/Linux 9 (stretch)!
>
> [   15.200822] systemd[1]: Set hostname to .
> [   46.135227] usb 1-1.5: reset high-speed USB device number 4 using dwc2
> [   76.844211] usb 1-1.5: reset high-speed USB device number 4 using dwc2
> [  105.257888] systemd[1]: system-generators terminated by signal ALRM.
> [  108.087234] usb 1-1.5: reset high-speed USB device number 4 using dwc2
> [  138.796224] usb 1-1.5: reset high-speed USB device number 4 using dwc2
> [  170.039222] usb 1-1.5: reset high-speed USB device number 4 using dwc2
> [  201.261222] usb 1-1.5: reset high-speed USB device number 4 using dwc2
> [  201.405906] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x05 
> driverbyte=0x00
> [  201.414234] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 02 c7 c5 90 00 
> 00 68 00
> [  201.421951] blk_update_request: I/O error, dev sda, sector 46646672
>
> Boot hangs and I/O does not recover.
>
> I first suspected the dwc2 driver, but the cause turns out to be DMA
> mapping error in usb_hcd_map_urb_for_dma(). This will cause usb_sg_wait()
> to loop forever trying to re-try. On RPi3 dma_mapping_error() is:
>
> int
> swiotlb_dma_mapping_error(struct device *hwdev, dma_addr_t dma_addr)
> {
>   return (dma_addr == phys_to_dma(hwdev, io_tlb_overflow_buffer));
> }
>
> On arm64, swiotlb is not initialized by default, so io_tlb_overflow_buffer
> is 0. But phys_to_dma(hwdev, 0) should be a valid DMA address and not
> be rejected. I tested this by initializing io_tlb_overflow_buffer with
> INVALID_PHYS_ADDR, and then the boot passes and system runs fine.
>
> Any ideas how this should be fixed properly?
>
> A.
>
> ___
> linux-rpi-kernel mailing list
> linux-rpi-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel


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

Re: [PATCH v3 24/24] usb: dwc2: gadget: Add checking for g-tx-fifo-size parameter

[Stefan Wahren]

Hi John,

could you please push this series to the github synopsys-usb repo?

I didn't have the chance to test combination of your last series.

Stefan
--
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 25/28] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

[Stefan Wahren]

Hi John,

is there a public git repo where this series is already applied?

Stefan
--
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 RFT] usb: dwc2: gadget: Fix fifo size configuration

[Stefan Wahren]

Hi Sevak,

> Sevak Arakelyan <sevak.arakel...@synopsys.com> hat am 20. Dezember 2016 um 
> 13:57 geschrieben:
> 
> 
> On 12/19/2016 8:39 PM, Stefan Wahren wrote:
> > Currently the upper limit for the endpoint index during fifo size
> > config was always 16 instead of the available endpoints. So fix this
> > by using the determined amount of endpoints and avoid a warning about
> > "insufficient fifo memory" on bcm2835 which has only 8 endpoints.
> >
> > Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
> > Fixes: 0a176279db68 ("usb: dwc2: gadget: configure fifos from device tree")
> > ---
> >  drivers/usb/dwc2/gadget.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Since revert of ("usb: dwc2: gadget: fix TX FIFO size and address") which
> > caused regressions on some platforms this is the second attempt to fix
> > gadget support for bcm2835.
> >
> > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > index b95930f..b00184c 100644
> > --- a/drivers/usb/dwc2/gadget.c
> > +++ b/drivers/usb/dwc2/gadget.c
> > @@ -228,7 +228,7 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg 
> > *hsotg)
> >  * them to endpoints dynamically according to maxpacket size value of
> >  * given endpoint.
> >  */
> > -   for (ep = 1; ep < MAX_EPS_CHANNELS; ep++) {
> > +   for (ep = 1; ep < hsotg->num_of_eps; ep++) {
> > if (!txfsz[ep])
> > continue;
> > val = addr;
> 
> Hi Stefan,
> 
> This patch is only temporary, not full solution for bcm2835 and in
> the loop you need to use hsotg->num_of_eps in shared FIFO mode and the
> number of device IN EPs which is in GHWCFG4 with mask
> GHWCFG4_NUM_IN_EPS_MASK in dedicated FIFO mode.

i don't have any documentation for this. So i tried to fix this obviously error.

> 
> The upper limit is up to 15 but the actual number of FIFOa are being
> configured according to the given legacy array
> DWC2_G_P_LEGACY_TX_FIFO_SIZE {256, 256, 256, 256, 768, 768, 768, 768, 0,
> 0, 0, 0, 0, 0, 0}, in that case it is 8 FIFOs. The legacy values are the
> main issue. We must do correct calculation according to FIFO operation
> mode, device operation mode, take into consideration the EP Info Block
> which must be at the end of total FIFO and after that configure correct
> number of FIFOs with correct size of depth on every setup. We prepared a
> patch series to fix that issue and it is under internal review and
> testing process and will be submitted soon.

I wanted to avoid this by providing the TX FIFO sizes via DT [1].

Sorry for my impatience.

[1] - 
https://github.com/lategoodbye/rpi-zero/commit/a6ec75dd8ea6a7ce0609ae082d3fa748beaba22c

>   
> Thanks,
> Sevak
>
--
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 RFT] usb: dwc2: gadget: Fix fifo size configuration

[Stefan Wahren]

Currently the upper limit for the endpoint index during fifo size
config was always 16 instead of the available endpoints. So fix this
by using the determined amount of endpoints and avoid a warning about
"insufficient fifo memory" on bcm2835 which has only 8 endpoints.

Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
Fixes: 0a176279db68 ("usb: dwc2: gadget: configure fifos from device tree")
---
 drivers/usb/dwc2/gadget.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Since revert of ("usb: dwc2: gadget: fix TX FIFO size and address") which
caused regressions on some platforms this is the second attempt to fix
gadget support for bcm2835.

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index b95930f..b00184c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -228,7 +228,7 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 * them to endpoints dynamically according to maxpacket size value of
 * given endpoint.
 */
-   for (ep = 1; ep < MAX_EPS_CHANNELS; ep++) {
+   for (ep = 1; ep < hsotg->num_of_eps; ep++) {
if (!txfsz[ep])
continue;
val = addr;
-- 
1.7.9.5

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

[PATCH] usb: dwc2: gadget: Fix fifo size configuration

[Stefan Wahren]

Currently the upper limit for the endpoint index during fifo size
config was always 16 instead of the available endpoints. So fix this
by using the determined amount of endpoints and avoid a warning about
"insufficient fifo memory" on bcm2835 which has only 8 endpoints.

Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
Fixes: 0a176279db68 ("usb: dwc2: gadget: configure fifos from device tree")
---
 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 b95930f..b00184c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -228,7 +228,7 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 * them to endpoints dynamically according to maxpacket size value of
 * given endpoint.
 */
-   for (ep = 1; ep < MAX_EPS_CHANNELS; ep++) {
+   for (ep = 1; ep < hsotg->num_of_eps; ep++) {
if (!txfsz[ep])
continue;
val = addr;
-- 
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 v2 2/3] Revert "usb: dwc2: gadget: fix TX FIFO size and address initialization"

[Stefan Wahren]

Hi John,

> John Youn  hat am 18. Oktober 2016 um 02:36
> geschrieben:
> 
> 
> This reverts commit aa381a7259c3 ("usb: dwc2: gadget: fix TX FIFO size
> and address initialization").
> 
> The original commit removed the FIFO size programming per endpoint. The
> DPTXFSIZn register is also used for DIEPTXFn and the SIZE field is r/w
> in dedicated fifo mode. So it isn't appropriate to simply remove this
> initialization as it might break existing behavior.
> 
> Also, some cores might not have enough fifo space to handle the
> programming method used in the reverted patch, resulting in fifo
> initialization failure.

since the original patch is still necessary for bcm2835 gadget support i want to
know if there is an alternative solution?

Stefan
--
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: dwc2: fix kernel-doc for dwc2_set_param

[Stefan Wahren]

Hi Felipe,

Am 22.11.2016 um 13:23 schrieb Felipe Balbi:
> Hi,
>
> Stefan Wahren <stefan.wah...@i2se.com> writes:
>> Since there is no parameter @value replace it with @legacy.
>>
>> Fixes: 05ee799f202 ("usb: dwc2: Move gadget settings into core_params")
>> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
>> ---
>>  drivers/usb/dwc2/params.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>> index 11fe68a..10407cb 100644
>> --- a/drivers/usb/dwc2/params.c
>> +++ b/drivers/usb/dwc2/params.c
>> @@ -320,7 +320,7 @@ static void dwc2_set_core_param(void *param, u8 size, 
>> u64 value)
>>   * @size: The size of the core parameter in bytes, or 0 for bool.
>>   *
>>   * This function looks up @property and sets the @param to that value.
>> - * If the property doesn't exist it uses the passed-in @value. It will
>> + * If the property doesn't exist it uses the passed-in @legacy value. It 
>> will
> This doesn't fix any bugs. 

you are right. I found this documentation bug while fixing the issues
before.

Since this is the last patch of the series, you could ignore it. And i
resend it without fixes tag after the merge window.

> Also, is @legacy a parameter?
>

|/** * dwc2_set_param() - Set a core parameter * * @hsotg: Programming
view of the DWC_otg controller * @param: Pointer to the parameter to set
* @lookup: True if the property should be looked up * @property: The
device property to read * @legacy: The param value to set if @property
is not available. This * will typically be the legacy value set in the
static * params structure. * @def: The default value * @min: The minimum
value * @max: The maximum value * @size: The size of the core parameter
in bytes, or 0 for bool. * * This function looks up @property and sets
the @param to that value. * If the property doesn't exist it uses the
passed-in @value. It will * verify that the value falls between @min and
@max. If it doesn't, * it will output an error and set the parameter to
either @def or, * failing that, to @min. * * The @size is used to write
to @param and to query the device * properties so that this same
function can be used with different * types of parameters. */ static
void dwc2_set_param(struct dwc2_hsotg *hsotg, void *param, bool lookup,
char *property, u64 legacy, u64 def, u64 min, u64 max, u8 size)|



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

[PATCH 5/5] usb: dwc2: fix kernel-doc for dwc2_set_param

[Stefan Wahren]

Since there is no parameter @value replace it with @legacy.

Fixes: 05ee799f202 ("usb: dwc2: Move gadget settings into core_params")
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/params.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 11fe68a..10407cb 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -320,7 +320,7 @@ static void dwc2_set_core_param(void *param, u8 size, u64 
value)
  * @size: The size of the core parameter in bytes, or 0 for bool.
  *
  * This function looks up @property and sets the @param to that value.
- * If the property doesn't exist it uses the passed-in @value. It will
+ * If the property doesn't exist it uses the passed-in @legacy value. It will
  * verify that the value falls between @min and @max. If it doesn't,
  * it will output an error and set the parameter to either @def or,
  * failing that, to @min.
-- 
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 2/5] usb: dwc2: fix dwc2_get_device_property for u8 and u16

[Stefan Wahren]

According to the Devicetree ePAPR [1] the datatypes u8 and u16 are
not defined. So using device_property_read_u16() would result in
a partial read of a 32-bit big-endian integer which is not intended.
So we better read the complete 32-bit value. This fixes a regression
on bcm2835 where the values for g-rx-fifo-size and g-np-tx-fifo-size
always read as zero:

  Invalid value 0 for param g-rx-fifo-size
  Invalid value 0 for param g-np-tx-fifo-size

[1] - http://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf

Fixes: 05ee799f202 ("usb: dwc2: Move gadget settings into core_params")
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/params.c |   12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index fd5f7f8..2c7b624 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -247,8 +247,6 @@
 static void dwc2_get_device_property(struct dwc2_hsotg *hsotg,
 char *property, u8 size, u64 *value)
 {
-   u8 val8;
-   u16 val16;
u32 val32;
 
switch (size) {
@@ -256,17 +254,7 @@ static void dwc2_get_device_property(struct dwc2_hsotg 
*hsotg,
*value = device_property_read_bool(hsotg->dev, property);
break;
case 1:
-   if (device_property_read_u8(hsotg->dev, property, ))
-   return;
-
-   *value = val8;
-   break;
case 2:
-   if (device_property_read_u16(hsotg->dev, property, ))
-   return;
-
-   *value = val16;
-   break;
case 4:
if (device_property_read_u32(hsotg->dev, property, ))
return;
-- 
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 0/5] usb: dwc2: fix parameter handling

[Stefan Wahren]

This patch series fixes several parameter handling issues
found on bcm2835 in gadget mode. It's based on Felipe's USB next.

Stefan Wahren (5):
  usb: dwc2: Do not set host parameter in peripheral mode
  usb: dwc2: fix dwc2_get_device_property for u8 and u16
  usb: dwc2: fix default value for DMA support
  usb: dwc2: gadget: fix default value for gadget-dma-desc
  usb: dwc2: fix kernel-doc for dwc2_set_param

 drivers/usb/dwc2/params.c |   32 ++--
 1 file changed, 10 insertions(+), 22 deletions(-)

-- 
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 3/5] usb: dwc2: fix default value for DMA support

[Stefan Wahren]

The current defaults for DMA results on a non-DMA platform in a unnecessary
error message:

  Invalid value 0 for param gadget-dma

So fix this by using dma_capable as default value.

Fixes: 9962b62f1be ("usb: dwc2: Deprecate g-use-dma binding")
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/params.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 2c7b624..30b954e 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1088,7 +1088,7 @@ static void dwc2_set_gadget_dma(struct dwc2_hsotg *hsotg)
/* Buffer DMA */
dwc2_set_param_bool(hsotg, >g_dma,
false, "gadget-dma",
-   true, false,
+   dma_capable, false,
dma_capable);
 
/* DMA Descriptor */
@@ -1118,7 +1118,7 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
 
dwc2_set_param_bool(hsotg, >host_dma,
false, "host-dma",
-   true, false,
+   dma_capable, false,
dma_capable);
dwc2_set_param_host_rx_fifo_size(hsotg,
params->host_rx_fifo_size);
-- 
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 1/5] usb: dwc2: Do not set host parameter in peripheral mode

[Stefan Wahren]

Since commit "usb: dwc2: Improve handling of host and device hwparams" the
host mode specific hardware parameter aren't initialized in peripheral mode
from the register settings anymore. So we better do not set them in this
case which avoids the following warnings on bcm2835:

  256 invalid for host_nperio_tx_fifo_size. Check HW configuration.
  512 invalid for host_perio_tx_fifo_size. Check HW configuration.

Fixes: 55e1040e424b ("usb: dwc2: Improve handling of host and device hwparams")
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/params.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index a786256..fd5f7f8 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1132,6 +1132,12 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
false, "host-dma",
true, false,
dma_capable);
+   dwc2_set_param_host_rx_fifo_size(hsotg,
+   params->host_rx_fifo_size);
+   dwc2_set_param_host_nperio_tx_fifo_size(hsotg,
+   params->host_nperio_tx_fifo_size);
+   dwc2_set_param_host_perio_tx_fifo_size(hsotg,
+   params->host_perio_tx_fifo_size);
}
dwc2_set_param_dma_desc_enable(hsotg, params->dma_desc_enable);
dwc2_set_param_dma_desc_fs_enable(hsotg, params->dma_desc_fs_enable);
@@ -1140,12 +1146,6 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
params->host_support_fs_ls_low_power);
dwc2_set_param_enable_dynamic_fifo(hsotg,
params->enable_dynamic_fifo);
-   dwc2_set_param_host_rx_fifo_size(hsotg,
-   params->host_rx_fifo_size);
-   dwc2_set_param_host_nperio_tx_fifo_size(hsotg,
-   params->host_nperio_tx_fifo_size);
-   dwc2_set_param_host_perio_tx_fifo_size(hsotg,
-   params->host_perio_tx_fifo_size);
dwc2_set_param_max_transfer_size(hsotg,
params->max_transfer_size);
dwc2_set_param_max_packet_count(hsotg,
-- 
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 4/5] usb: dwc2: gadget: fix default value for gadget-dma-desc

[Stefan Wahren]

The current default for gadget DMA descriptor results on bcm2835 in a
unnecessary error message:

  Invalid value 1 for param gadget-dma-desc

So fix this by using hw->dma_desc_enable as default value.

Fixes: dec4b55677e ("usb: dwc2: gadget: Add descriptor DMA parameter")
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
 drivers/usb/dwc2/params.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 30b954e..11fe68a 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1094,7 +1094,7 @@ static void dwc2_set_gadget_dma(struct dwc2_hsotg *hsotg)
/* DMA Descriptor */
dwc2_set_param_bool(hsotg, >g_dma_desc, false,
"gadget-dma-desc",
-   p->g_dma, false,
+   !!hw->dma_desc_enable, false,
!!hw->dma_desc_enable);
 }
 
-- 
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 v2 2/4] usb: dwc2: Add binding for AHB burst

[Stefan Wahren]

Hi John,

Am 17.11.2016 um 00:47 schrieb John Youn:
> Add the "snps,ahb-burst" binding and read it in.
>
> This property controls which burst type to perform on the AHB bus as a
> master in internal DMA mode. This overrides the legacy param value,
> which we need to keep around for now since several platforms use it.
>
> Some platforms may see better or worse performance based on this
> value. The HAPS platform is one example where all INCRx have worse
> performance than INCR.
>
> Other platforms (such as the Canyonlands board) report that the default
> value causes system hangs.
>
> Signed-off-by: John Youn 
> Cc: Christian Lamparter 
> ---
>  Documentation/devicetree/bindings/usb/dwc2.txt |  2 +
>  drivers/usb/dwc2/core.h|  9 +
>  drivers/usb/dwc2/params.c  | 56 
> ++
>  3 files changed, 67 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
> b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 6c7c2bce..9e7b4b4 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt

according to Documentation/devicetree/bindings/submitting-patches.txt
this change should be a separate patch.

> @@ -26,6 +26,8 @@ Optional properties:
>  Refer to phy/phy-bindings.txt for generic phy consumer properties
>  - dr_mode: shall be one of "host", "peripheral" and "otg"
>Refer to usb/generic.txt
> +- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
> +  "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".

This doesn't apply in case of the bcm2835. I would prefer this option is
ignored in that case with a dev_warn("snps,ahb-burst is not supported on
this platform").

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

Re: [PATCH 1/4] usb: dwc2: Fix AHB burst type for bcm2835

[Stefan Wahren]

Hi John,

> John Youn  hat am 16. November 2016 um 01:36
> geschrieben:
> 
> 
> The ahbcfg param for bcm2835 is specifying a HBSTLEN of 0x8 (0x10 >> 1)
> which is not a valid value for that field. Remove the param and default
> to using INCR4.

i don't have any Synopsys documentation about this IP core. But according to p.
204 of the BCM2835 datasheet [1] the register USB_GAHBCFG is different than the
other implementations:

  Address 0x 7E98 0008 
  The USB_GAHBCFG register has been adapted. Bits [4:1] which are marked in the 
  Synopsys documentation as "Burst Length/Type (HBstLen)" have been used
differently. 

  [4]1 = Wait for all outstanding AXI writes to complete before signalling
(internally) that 
 DMA is done.  
 0 = don't wait.  
  [3]Not used 
  [2:1]  Sets the maximum AXI burst length, but the bits are inverted,  
 00 = maximum AXI burst length of 4,  
 01 = maximum AXI burst length of 3, 
 10 = maximum AXI burst length of 2 
 11 = maximum AXI burst length of 1

Did you already take care of that?

[1] -
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Stefan Wahren]

I inspired by this issue [1] i build up a slightly modified setup with a
Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 Prolific
PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
only tries to open all ttyUSB devices one after the other. 

Unfortunately the complete system stuck after opening the first ttyUSB device (
heartbeat LED stop blinking, no reaction to debug UART). The only way to
reanimate the system is to powerdown the USB hub with the USB to serial
convertors.

[1] - https://github.com/raspberrypi/linux/issues/1692
[2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa

pi@raspberrypi:~$ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx,
480M
|__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 14, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 3: Dev 16, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M

pi@raspberrypi:~$ ./usb_test
idle
opening [/dev/ttyUSB0] ok
[  232.658768] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s!
[usb_test:522]
[  232.678443] Modules linked in: pwm_bcm2835 vchiq(C)
[  232.678481] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
 4.9.0-rc3+ #33
[  232.678486] Hardware name: BCM2835
[  232.678498] task: cab54e40 task.stack: c688c000
[  232.678520] PC is at __do_softirq+0x68/0x2a8
[  232.678538] LR is at irq_exit+0xb8/0x120
[  232.678552] pc : []lr : []psr: 6113
sp : c688da60  ip : c688daa8  fp : c688daa4
[  232.678560] r10: c0b7f800  r9 : c688c000  r8 : 0040
[  232.678567] r7 : 000a  r6 : cb802400  r5 :   r4 : 0001
[  232.678575] r3 :   r2 : 0100  r1 : 0040  r0 : 
[  232.678585] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  232.678593] Control: 00c5387d  Table: 068a4008  DAC: 0051
[  232.678604] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
 4.9.0-rc3+ #33
[  232.678609] Hardware name: BCM2835
[  232.678667] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[  232.678695] [] (show_stack) from []
(dump_stack+0x20/0x28)
[  232.678718] [] (dump_stack) from [] (show_regs+0x1c/0x20)
[  232.678752] [] (show_regs) from []
(watchdog_timer_fn+0x140/0x19c)
[  232.678779] [] (watchdog_timer_fn) from []
(__hrtimer_run_queues.constprop.3+0xec/0x210)
[  232.678798] [] (__hrtimer_run_queues.constprop.3) from []
(hrtimer_interrupt+0xa4/0x1cc)
[  232.678827] [] (hrtimer_interrupt) from []
(bcm2835_time_interrupt+0x40/0x48)
[  232.678865] [] (bcm2835_time_interrupt) from []
(__handle_irq_event_percpu+0x68/0x1b8)
[  232.678891] [] (__handle_irq_event_percpu) from []
(handle_irq_event_percpu+0x2c/0x68)
[  232.678915] [] (handle_irq_event_percpu) from []
(handle_irq_event+0x38/0x4c)
[  232.678939] [] (handle_irq_event) from []
(handle_level_irq+0xc4/0xf8)
[  232.678960] [] (handle_level_irq) from []
(generic_handle_irq+0x28/0x38)
[  232.678983] [] (generic_handle_irq) from []
(__handle_domain_irq+0x90/0xb8)
[  232.679004] [] (__handle_domain_irq) from []
(bcm2835_handle_irq+0x30/0x48)
[  232.679022] [] (bcm2835_handle_irq) from []
(__irq_svc+0x6c/0x90)
[  232.679031] Exception stack(0xc688da10 to 0xc688da58)
[  232.679044] da00:  0040
0100 
[  232.679062] da20: 0001  cb802400 000a 0040 c688c000
c0b7f800 c688daa4
[  232.679078] da40: c688daa8 c688da60 c0121270 c01014d0 6113 f00
c687a300 c9374900 ca918b00 caff1200 c688db84
[  232.679235] db20: c688db28 c688db40 c04a1cf8 c049cb64 6013 
[  232.679272] [] (__irq_svc) from []
(_dwc2_hcd_urb_enqueue+0x414/0x560)
[  232.679302] [] (_dwc2_hcd_urb_enqueue) from []
(usb_hcd_submit_urb+0x704/0x8c4)
[  232.679327] [] (usb_hcd_submit_urb) from []
(usb_submit_urb+0x438/0x4e0)
[  232.679358] [] (usb_submit_urb) from []
(usb_serial_generic_submit_read_urb+0x50/0xc8)
[  232.679382] [] (usb_serial_generic_submit_read_urb) from
[] (usb_serial_generic_submit_read_urbs+0x28/0x70)
[  232.679407] [] (usb_serial_generic_submit_read_urbs) from
[] (usb_serial_generic_open+0x44/0x4c)
[  232.679435] [] (usb_serial_generic_open) from []
(pl2303_open+0xc0/0xe0)
[  232.679458] [] (pl2303_open) from []
(serial_port_activate+0x54/0x8c)
[  232.679486] [] (serial_port_activate) from []
(tty_port_open+0x84/0xd4)
[  232.679509] [] (tty_port_open) from []
(serial_open+0x34/0x5c)
[  232.679546] [] (serial_open) from []

[PATCH] usb: chipidea: host: fix NULL ptr dereference during shutdown

[Stefan Wahren]

After commit b09b5224fe86 ("usb: chipidea: implement platform shutdown
callback") and commit 43a404577a93 ("usb: chipidea: host: set host to 
be null after hcd is freed") a NULL pointer dereference is caused 
on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and
we finish interrupt handling before the hcd is deallocated. This avoids
the NULL pointer dereference.

Suggested-by: Alan Stern <st...@rowland.harvard.edu>
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
Fixes: b09b5224fe86 ("usb: chipidea: implement platform shutdown callback")
---
 drivers/usb/chipidea/host.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 053bac9..887be34 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
 
if (hcd) {
usb_remove_hcd(hcd);
+   ci->role = CI_ROLE_END;
+   synchronize_irq(ci->irq);
usb_put_hcd(hcd);
if (ci->platdata->reg_vbus && !ci_otg_is_fsm_mode(ci) &&
(ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON))
-- 
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: usb: chipidea: hdc: kernel panic during shutdown

[Stefan Wahren]

Am 05.09.2016 um 04:51 schrieb Peter Chen:
> On Fri, Sep 02, 2016 at 08:20:35PM +0200, Stefan Wahren wrote:
>> Hi Peter,
>>
>>> Stefan Wahren <stefan.wah...@i2se.com> hat am 25. August 2016 um 19:17
>>> geschrieben:
>>>
>>>
>>> Hi,
>>>
>>>> Peter Chen <hzpeterc...@gmail.com> hat am 25. August 2016 um 11:16
>>>> geschrieben:
>>>>
>>>>
>>>> On Thu, Aug 25, 2016 at 08:27:03AM +0200, Stefan Wahren wrote:
>>>>> Am 25.08.2016 um 08:44 schrieb Peter Chen:
>>>>>> On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> i tried the following patch:
>>>>>>> --- a/drivers/usb/chipidea/host.c
>>>>>>> +++ b/drivers/usb/chipidea/host.c
>>>>>>> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
>>>>>>>  
>>>>>>> if (hcd) {
>>>>>>> usb_remove_hcd(hcd);
>>>>>>> +   ci_role_stop(ci);
>>>>>>> +   synchronize_irq(ci->irq);
>>>>>> Would you please just add below line to see if this problem can be
>>>>>> fixed?
>>>>>> +ci->role = CI_ROLE_END;
>>>>>>
>>>>>> When ci->role is CI_ROLE_END, neither host nor device interrupt handler
>>>>>> will run.
>>>>> I would add this before synchronize_irq() as Alan suggested.
>>> i replaced my ci_role_stop(ci) with ci->role = CI_ROLE_END and the panic
>>> disappear:
>>>
>>> [  114.98] ci_hdrc ci_hdrc.0: remove, state 1
>>> [  114.99] usb usb1: USB disconnect, device number 1
>>> [  115.00] usb 1-1: USB disconnect, device number 2
>>> [  115.00] usb 1-1.1: USB disconnect, device number 3
>>> [  115.03] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx'
>>> usb-ci_hdrc.0-1.1,
>>> smsc95xx USB 2.0 Ethernet
>>> [  115.22] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
>>> [  115.23] otgsc:0x4e20, usbsts:0x0
>>> [  115.24] reboot: System halted
>> do you need more information?
>>
> I would like to know which interrupt is triggered at that time?

So the added debug messages didn't help to find the interrupt source (
otgsc:0x4e20, usbsts:0x0 ) ?

Any other suggestions ?

At least i would like to create a patch with Alan's suggestion before
4.8 is final.

--
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: [RFT PATCH v4 0/3] usb: dwc2: Fix core reset and force mode delays

[Stefan Wahren]

Hi John,

> John Youn <johny...@synopsys.com> hat am 1. September 2016 um 23:07
> geschrieben:
> 
> 
> This series accounts for the delay from the IDDIG debounce filter when
> switching modes. This delay is a function of the PHY clock speed and
> can range from 5-50 ms. This delay must be taken into account on core
> reset and force modes. A full explanation is provided in the patch
> commit log and code comments.
> 
> This revision of the series increases the IDDIG delay to 100 ms. Some
> rockchip platforms seem to timeout even with 50 ms so I have doubled
> this.
> 
> Appreciate any testing on RK3188 and RPi platforms.

i tested the whole series successful with a Raspberry Pi B in dr_mode "host" and
"otg"

Tested-by: Stefan Wahren <stefan.wah...@i2se.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: chipidea: hdc: kernel panic during shutdown

[Stefan Wahren]

Hi Peter,

> Stefan Wahren <stefan.wah...@i2se.com> hat am 25. August 2016 um 19:17
> geschrieben:
> 
> 
> Hi,
> 
> > Peter Chen <hzpeterc...@gmail.com> hat am 25. August 2016 um 11:16
> > geschrieben:
> > 
> > 
> > On Thu, Aug 25, 2016 at 08:27:03AM +0200, Stefan Wahren wrote:
> > > Am 25.08.2016 um 08:44 schrieb Peter Chen:
> > > > On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
> > > >> Hi Alan,
> > > >>
> > > >> i tried the following patch:
> > > >> --- a/drivers/usb/chipidea/host.c
> > > >> +++ b/drivers/usb/chipidea/host.c
> > > >> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
> > > >>  
> > > >> if (hcd) {
> > > >> usb_remove_hcd(hcd);
> > > >> +   ci_role_stop(ci);
> > > >> +   synchronize_irq(ci->irq);
> > > > Would you please just add below line to see if this problem can be
> > > > fixed?
> > > > +   ci->role = CI_ROLE_END;
> > > >
> > > > When ci->role is CI_ROLE_END, neither host nor device interrupt handler
> > > > will run.
> > > 
> > > I would add this before synchronize_irq() as Alan suggested.
> 
> i replaced my ci_role_stop(ci) with ci->role = CI_ROLE_END and the panic
> disappear:
> 
> [  114.98] ci_hdrc ci_hdrc.0: remove, state 1
> [  114.99] usb usb1: USB disconnect, device number 1
> [  115.00] usb 1-1: USB disconnect, device number 2
> [  115.00] usb 1-1.1: USB disconnect, device number 3
> [  115.03] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx'
> usb-ci_hdrc.0-1.1,
> smsc95xx USB 2.0 Ethernet
> [  115.22] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> [  115.23] otgsc:0x4e20, usbsts:0x0
> [  115.24] reboot: System halted

do you need more information?

What would be the next step?

Stefan

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

Re: usb: chipidea: hdc: kernel panic during shutdown

[Stefan Wahren]

Hi,

> Peter Chen <hzpeterc...@gmail.com> hat am 25. August 2016 um 11:16
> geschrieben:
> 
> 
> On Thu, Aug 25, 2016 at 08:27:03AM +0200, Stefan Wahren wrote:
> > Am 25.08.2016 um 08:44 schrieb Peter Chen:
> > > On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
> > >> Hi Alan,
> > >>
> > >> i tried the following patch:
> > >> --- a/drivers/usb/chipidea/host.c
> > >> +++ b/drivers/usb/chipidea/host.c
> > >> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
> > >>  
> > >> if (hcd) {
> > >> usb_remove_hcd(hcd);
> > >> +   ci_role_stop(ci);
> > >> +   synchronize_irq(ci->irq);
> > > Would you please just add below line to see if this problem can be
> > > fixed?
> > > + ci->role = CI_ROLE_END;
> > >
> > > When ci->role is CI_ROLE_END, neither host nor device interrupt handler
> > > will run.
> > 
> > I would add this before synchronize_irq() as Alan suggested.

i replaced my ci_role_stop(ci) with ci->role = CI_ROLE_END and the panic
disappear:

[  114.98] ci_hdrc ci_hdrc.0: remove, state 1
[  114.99] usb usb1: USB disconnect, device number 1
[  115.00] usb 1-1: USB disconnect, device number 2
[  115.00] usb 1-1.1: USB disconnect, device number 3
[  115.03] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-ci_hdrc.0-1.1,
smsc95xx USB 2.0 Ethernet
[  115.22] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[  115.23] otgsc:0x4e20, usbsts:0x0
[  115.24] reboot: System halted

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

Re: usb: chipidea: hdc: kernel panic during shutdown

[Stefan Wahren]

Am 25.08.2016 um 08:44 schrieb Peter Chen:
> On Thu, Aug 25, 2016 at 07:06:12AM +0200, Stefan Wahren wrote:
>> Hi Alan,
>>
>> i tried the following patch:
>> --- a/drivers/usb/chipidea/host.c
>> +++ b/drivers/usb/chipidea/host.c
>> @@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
>>  
>> if (hcd) {
>> usb_remove_hcd(hcd);
>> +   ci_role_stop(ci);
>> +   synchronize_irq(ci->irq);
> Would you please just add below line to see if this problem can be
> fixed?
> + ci->role = CI_ROLE_END;
>
> When ci->role is CI_ROLE_END, neither host nor device interrupt handler
> will run.

I would add this before synchronize_irq() as Alan suggested.

>
> What is your controller role? (dr_mode = host, peripheral or otg)?

I'm using the unmodified arch/arm/boot/dts/imx23-olinuxino.dts so:

dr_mode = host

> Besides, you would please add below line at core.c to show what
> interrupt occurs at that time:
>
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index b5c155b..e6b8a7e 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -596,6 +596,12 @@ static irqreturn_t ci_irq(int irq, void *data)
>   /* Handle device/host interrupt */
>   if (ci->role != CI_ROLE_END)
>   ret = ci_role(ci)->irq(ci);
> + else
> + dev_info(ci->dev, "otgsc:0x%x, usbsts:0x%x\n",
> + hw_read_otgsc(ci, ~0),
> + hw_read_intr_status(ci) & 
> hw_read_intr_enable(ci)
> + );
> +
>  
>   return ret;
>  }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: chipidea: hdc: kernel panic during shutdown

[Stefan Wahren]

Hi Alan,

> Alan Stern <st...@rowland.harvard.edu> hat am 24. August 2016 um 20:55
> geschrieben:
> 
> 
> On Wed, 24 Aug 2016, Stefan Wahren wrote:
> 
> > Hi,
> > 
> > [add Li Jun to CC]
> > 
> > > Alan Stern <st...@rowland.harvard.edu> hat am 24. August 2016 um 15:45
> > > geschrieben:
> > > 
> > > 
> > > On Wed, 24 Aug 2016, Peter Chen wrote:
> > > 
> > > > On Tue, Aug 23, 2016 at 09:17:02PM +0200, Stefan Wahren wrote:
> > > > > Hi,
> > > > > 
> > > > > i'm using a iMX233-OLinuXino board and the kernel panics during
> > > > > shutdown
> > > > > with
> > > > > 4.8.0-rc2-next-20160819:
> > > > > 
> > > > > [  420.04] ci_hdrc ci_hdrc.0: remove, state 1
> > > > > [  420.05] usb usb1: USB disconnect, device number 1
> > > > > [  420.06] usb 1-1: USB disconnect, device number 2
> > > > > [  420.06] usb 1-1.1: USB disconnect, device number 3
> > > > > [  420.09] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx'
> > > > > usb-ci_hdrc.0-1.1,
> > > > > smsc95xx USB 2.0 Ethernet
> > > > > [  420.29] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> > > > > [  420.30] Unable to handle kernel NULL pointer dereference at
> > > > > virtual
> > > > > address 0118
> > > > > [  420.30] pgd = c2ea4000
> > > > > [  420.30] [0118] *pgd=
> > > > > [  420.30] Internal error: Oops: 5 [#1] ARM
> > > > > [  420.30] Modules linked in:
> > > > > [  420.30] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted
> > > > > 4.8.0-rc2-next-20160819 #1
> > > > > [  420.30] Hardware name: Freescale MXS (Device Tree)
> > > > > [  420.30] task: c349 task.stack: c348e000
> > > > > [  420.30] PC is at usb_hcd_irq+0x0/0x34
> > > > > [  420.30] LR is at ci_irq+0x58/0x12c
> > > 
> > > > I am afraid the hcd is freed before the interrupt triggered. Would you
> > > > please try below changes:
> > > > 
> > > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> > > > index 96ae695..61237a9 100644
> > > > --- a/drivers/usb/chipidea/host.c
> > > > +++ b/drivers/usb/chipidea/host.c
> > > > @@ -103,7 +103,7 @@ static const struct ehci_driver_overrides
> > > > ehci_ci_overrides = {
> > > > static irqreturn_t host_irq(struct ci_hdrc *ci)
> > > > {
> > > > -   return usb_hcd_irq(ci->irq, ci->hcd);
> > > > +   return ci->hcd ? usb_hcd_irq(ci->irq, ci->hcd) : IRQ_NONE;
> > > > }
> > > 
> > > This should not be needed.  Instead, the driver should make sure that 
> > > the interrupt handler has been fully unregistered before the hcd is 
> > > deallocated.
> > 
> > according to ci_hdrc_probe() from the chipidea core the IRQ seems to be
> > requested via devm_request_irq() with the flag IRQF_SHARED. 
> > 
> > I have the suspicion the following commit triggers the kernel panic:
> > 
> > 43a404577a93 ("usb: chipidea: host: set host to be null after hcd is freed")
> 
> No, that's not the cause.  Without that commit, you would try to access 
> deallocated memory instead of trying to dereference a NULL pointer, but 
> the kernel would still oops.
> 
> Instead, how about setting ci->role to CI_ROLE_END and then calling
> synchronize_irq(ci->irq) in host_stop(), before the usb_put_hcd()?

i tried the following patch:

--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci)
 
if (hcd) {
usb_remove_hcd(hcd);
+   ci_role_stop(ci);
+   synchronize_irq(ci->irq);
usb_put_hcd(hcd);
if (ci->platdata->reg_vbus && !ci_otg_is_fsm_mode(ci) &&
(ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON))

the i get the following during shutdown:

[  102.17] ci_hdrc ci_hdrc.0: remove, state 1
[  102.18] usb usb1: USB disconnect, device number 1
[  102.18] usb 1-1: USB disconnect, device number 2
[  102.19] usb 1-1.1: USB disconnect, device number 3
[  102.22] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-ci_hdrc.0-1.1,
smsc95xx USB 2.0 Ethernet
[  102.41] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[  102.42] ci_hdrc ci

Re: usb: chipidea: hdc: kernel panic during shutdown

[Stefan Wahren]

Hi,

[add Li Jun to CC]

> Alan Stern <st...@rowland.harvard.edu> hat am 24. August 2016 um 15:45
> geschrieben:
> 
> 
> On Wed, 24 Aug 2016, Peter Chen wrote:
> 
> > On Tue, Aug 23, 2016 at 09:17:02PM +0200, Stefan Wahren wrote:
> > > Hi,
> > > 
> > > i'm using a iMX233-OLinuXino board and the kernel panics during shutdown
> > > with
> > > 4.8.0-rc2-next-20160819:
> > > 
> > > [  420.04] ci_hdrc ci_hdrc.0: remove, state 1
> > > [  420.05] usb usb1: USB disconnect, device number 1
> > > [  420.06] usb 1-1: USB disconnect, device number 2
> > > [  420.06] usb 1-1.1: USB disconnect, device number 3
> > > [  420.09] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx'
> > > usb-ci_hdrc.0-1.1,
> > > smsc95xx USB 2.0 Ethernet
> > > [  420.29] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> > > [  420.30] Unable to handle kernel NULL pointer dereference at virtual
> > > address 0118
> > > [  420.30] pgd = c2ea4000
> > > [  420.30] [0118] *pgd=
> > > [  420.30] Internal error: Oops: 5 [#1] ARM
> > > [  420.30] Modules linked in:
> > > [  420.30] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted
> > > 4.8.0-rc2-next-20160819 #1
> > > [  420.30] Hardware name: Freescale MXS (Device Tree)
> > > [  420.30] task: c349 task.stack: c348e000
> > > [  420.30] PC is at usb_hcd_irq+0x0/0x34
> > > [  420.30] LR is at ci_irq+0x58/0x12c
> 
> > I am afraid the hcd is freed before the interrupt triggered. Would you
> > please try below changes:
> > 
> > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> > index 96ae695..61237a9 100644
> > --- a/drivers/usb/chipidea/host.c
> > +++ b/drivers/usb/chipidea/host.c
> > @@ -103,7 +103,7 @@ static const struct ehci_driver_overrides
> > ehci_ci_overrides = {
> > static irqreturn_t host_irq(struct ci_hdrc *ci)
> > {
> > -   return usb_hcd_irq(ci->irq, ci->hcd);
> > +   return ci->hcd ? usb_hcd_irq(ci->irq, ci->hcd) : IRQ_NONE;
> > }
> 
> This should not be needed.  Instead, the driver should make sure that 
> the interrupt handler has been fully unregistered before the hcd is 
> deallocated.

according to ci_hdrc_probe() from the chipidea core the IRQ seems to be
requested via devm_request_irq() with the flag IRQF_SHARED. 

I have the suspicion the following commit triggers the kernel panic:

43a404577a93 ("usb: chipidea: host: set host to be null after hcd is freed")

I will validate this.

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

usb: chipidea: hdc: kernel panic during shutdown

[Stefan Wahren]

Hi,

i'm using a iMX233-OLinuXino board and the kernel panics during shutdown with
4.8.0-rc2-next-20160819:

[  420.04] ci_hdrc ci_hdrc.0: remove, state 1
[  420.05] usb usb1: USB disconnect, device number 1
[  420.06] usb 1-1: USB disconnect, device number 2
[  420.06] usb 1-1.1: USB disconnect, device number 3
[  420.09] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-ci_hdrc.0-1.1,
smsc95xx USB 2.0 Ethernet
[  420.29] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[  420.30] Unable to handle kernel NULL pointer dereference at virtual
address 0118
[  420.30] pgd = c2ea4000
[  420.30] [0118] *pgd=
[  420.30] Internal error: Oops: 5 [#1] ARM
[  420.30] Modules linked in:
[  420.30] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted
4.8.0-rc2-next-20160819 #1
[  420.30] Hardware name: Freescale MXS (Device Tree)
[  420.30] task: c349 task.stack: c348e000
[  420.30] PC is at usb_hcd_irq+0x0/0x34
[  420.30] LR is at ci_irq+0x58/0x12c
[  420.30] pc : []lr : []psr: a093
[  420.30] sp : c348fd20  ip : c348fcd8  fp : c3704624
[  420.30] r10: c3708300  r9 : c3602010  r8 : 6013
[  420.30] r7 : 0094  r6 : 2013  r5 : c3549600  r4 : c3602010
[  420.30] r3 : 12a0  r2 : 0808  r1 :   r0 : 0094
[  420.30] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment
none
[  420.30] Control: 0005317f  Table: 42ea4000  DAC: 0051
[  420.30] Process systemd-shutdow (pid: 1, stack limit = 0xc348e190)
[  420.30] Stack: (0xc348fd20 to 0xc349)
[  420.30] fd20: c3549610 c3549600 2013 c006bfac c3549600 
0094 c3602010
[  420.30] fd40: c370e2e0 c36f4e80 c36f4e80 0005 c370e2e0 c006c098
c348fd70 c3704410
[  420.30] fd60: c370e2e0 c039cd68 0005 a013 c36f4e00 c370e2e0
a013 c039ce0c
[  420.30] fd80: c354b844 c348fe5c  c08d604c c3704624 c370e2e0
0001 c3704410
[  420.30] fda0: c08bc194 c08ad460 c354b844 c348fe5c  c08d604c
be829c58 c03997e8
[  420.30] fdc0: c370 c3704410 c08ad460 c0399954 c3402a4c c3704410
c08ad460 c0398d64
[  420.30] fde0: c3704410 c354b810 c112ebf4 c0396e2c c349 0007
0006 c348fe5c
[  420.30] fe00: c3704400 c3704410 c354b810 c354b844 c348fe5c c039bb90
c3704400 c3708090
[  420.30] fe20: c354b810 c039c118  c044941c c354b800 c044e6f8
c354b810 c03a47fc
[  420.30] fe40: c354b810 c354b410 c112ebf4 c039b578 c354b810 c0397410
0002 c08ad22c
[  420.30] fe60: c342fa20 c354b81c 4321fedc c0866838 cdef0123 f3f82200
c000a484 c348e000
[  420.30] fe80:  c00427f4 4321fedc c0042a10  
c348fec8 0029
[  420.30] fea0: c2e2d488  c34b9c28 0002 c00690fc 
 c0132e0c
[  420.30] fec0:   be8291f8 0004 be829f8a 0010
be829224 0005
[  420.30] fee0: be8292c4 000f 7f5fb9f8 0001 be828d3c c08629b4
c348ffb0 00053177
[  420.30] ff00: 07ff 000f0f24 c2e2d480   
 
[  420.30] ff20:   0001  0029 c348fec8
0005 
[  420.30] ff40:  0004001e 0005 be82924c 0005 be82924c
c348e000 
[  420.30] ff60: 7f60e854 c0132f24 c348ff88  c2e2d480 c2e2d480
 c0132f70
[  420.30] ff80:  c000a484  8102d190 8102c118 
8102d190 8102c118
[  420.30] ffa0: 0058 c000a2e0  8102d190 fee1dead 28121969
cdef0123 f3f82200
[  420.30] ffc0:  8102d190 8102c118 0058 be829bc4 
 be829c58
[  420.30] ffe0: 7f60de4c be829b08 7f5ee114 b6e46088 6010 fee1dead
 
[  420.30] [] (usb_hcd_irq) from [] (0xc3549600)
[  420.30] Code: c077a4d4 c08b802c c08b8040 c08b7fb0 (e5913118)
[  420.30] ---[ end trace 5e83b1955a5bd084 ]---
[  420.62] systemd-shutdow: 2 output lines suppressed due to ratelimiting
[  420.62] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[  420.62]
[  420.62] ---[ end Kernel panic - not syncing: Attempted to kill init!

I will try to bisect this issue.

Regards
Stefan
--
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] usb: dwc2: host function broken in OTG mode on bcm283x

[Stefan Wahren]

Hi John,

> John Youn  hat am 23. August 2016 um 20:37
> geschrieben:
> 
> 
> 
> How about we fall back to smaller defaults if the original values
> fail? And don't configure more than the amount of endpoints.

this sounds good. I would prefer to calculate the estimated gadget fifo size
before configuring the hardware, so we can bail out without breaking the host
function.

Regards
Stefan

> 
> That should take care of most of the cases. If an irregular
> configuration shows up, require it to use the DT properties.
> 
> Regards,
> John
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] usb: dwc2: host function broken in OTG mode on bcm283x

[Stefan Wahren]

Hi John,

> John Youn <john.y...@synopsys.com> hat am 23. August 2016 um 00:08
> geschrieben:
> 
> 
> On 8/22/2016 1:47 PM, Stefan Wahren wrote:
> > Hi John,
> > 
> >> John Youn <john.y...@synopsys.com> hat am 22. August 2016 um 22:06
> >> geschrieben:
> >>
> >>
> >> On 8/20/2016 6:03 AM, Stefan Wahren wrote:
> >>> Hi John,
> >>>
> >>>
> >>
> >> Hi Stefan,
> >>
> >> Why doesn't DT work? I think all the properties are there to set
> >> these.
> > 
> > it only works for the future releases, not for existing DT blobs. The DT is
> > part
> > of the ABI.
> > 
> > Yes, i already send a patch to fix the DT [1], but it would be better to fix
> > the
> > issue in deep.
> 
> I don't know much about DT issues. So I'm not sure what the issue is
> with this.The properties for the gadget fifo sizes already exist so
> there's no change to the ABI, correct?

It's correct the ABI doesn't change, but it also means that newer kernel must
work with older DTB files. So the fix should be better in the driver and not in
the DT sources.

> 
> Also, the patch you linked doesn't seem to have settings for the FIFO
> sizes.

It wouldn't make sense to provide gadget fifo sizes for a host-only setup. The
mentioned patch doesn't really fix this issue, that's why i mentioned that we
should fix this issue first.

> 
> > 
> >>
> >> I hesitate to change the legacy/default settings in case it breaks any
> >> existing drivers that depend on them.
> > 
> > Platforms? I didn't expected that other drivers use these settings.
> 
> Yes, I mean platforms.
> 
> I believe these values were hard-coded since before the unified "dwc2"
> existed. So for sure there are platforms using these settings and to
> lower them will negatively impact those platforms. The DT properties
> were introduced to override these.

Unfortunately the gadget fifo sizes should have been marked as required for OTG
and gadget mode. But now it's too late. We only can improve DT binding here or
at least add a warning during probe.

> 
> I think it is best to override them in the broken platforms. Either
> that or fix it so that the defaults are more intelligently determined
> in a way that maximizes the fifo sizes and cannot fail, as opposed to
> some other arbitrary values.
> 

I don't have the knowledge for the second solution and i wouldn't prefer much
more detection intelligence.

> > 
> > Another option would be to add the gadget fifo sizes to platform data, but
> > it's
> > not a nice solution.
> 
> I agree, that wouldn't be good.
> 
> 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: [Bug] usb: dwc2: host function broken in OTG mode on bcm283x

[Stefan Wahren]

Hi John,

> John Youn <john.y...@synopsys.com> hat am 22. August 2016 um 22:06
> geschrieben:
> 
> 
> On 8/20/2016 6:03 AM, Stefan Wahren wrote:
> > Hi John,
> > 
> > 
> 
> Hi Stefan,
> 
> Why doesn't DT work? I think all the properties are there to set
> these.

it only works for the future releases, not for existing DT blobs. The DT is part
of the ABI.

Yes, i already send a patch to fix the DT [1], but it would be better to fix the
issue in deep.

> 
> I hesitate to change the legacy/default settings in case it breaks any
> existing drivers that depend on them.

Platforms? I didn't expected that other drivers use these settings.

Another option would be to add the gadget fifo sizes to platform data, but it's
not a nice solution.

Regards
Stefan

[1] -
http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-August/004225.html

> 
> Regards,
> John
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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