[GIT PULL] USB-serial fixes for v4.14-rc6
Hi Greg, This should my last set of "fixes" for 4.14. Just a single device id this time. Thanks, Johan The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9: Linux 4.14-rc5 (2017-10-15 21:01:12 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.14-rc6 for you to fetch changes up to 31dc3f819bac28a0990b36510197560258ab7421: USB: serial: metro-usb: add MS7820 device id (2017-10-16 09:34:58 +0200) USB-serial fixes for v4.14-rc6 Here's a new metro-usb device id for another bar-code scanner. Signed-off-by: Johan Hovold Johan Hovold (1): USB: serial: metro-usb: add MS7820 device id drivers/usb/serial/metro-usb.c | 1 + 1 file changed, 1 insertion(+) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB-serial fixes for v4.14-rc6
On Thu, Oct 19, 2017 at 09:08:39AM +0200, Johan Hovold wrote: > Hi Greg, > > This should my last set of "fixes" for 4.14. Just a single device id this > time. > > Thanks, > Johan > > > The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9: > > Linux 4.14-rc5 (2017-10-15 21:01:12 -0400) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-4.14-rc6 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb-gadget tree with the usb tree
Hi,
Kees Cook writes:
> On Wed, Oct 18, 2017 at 7:42 AM, Mark Brown wrote:
>> Hi Felipe,
>>
>> Today's linux-next merge of the usb-gadget tree got a conflict in:
>>
>> drivers/usb/gadget/udc/snps_udc_core.c
>>
>> between commit:
>>
>> 29bce57723351f63d ("usb/gadget/snps_udc_core: Convert timers to use
>> timer_setup()")
>>
>> from the usb tree and commit:
>>
>> 46b614affda8667f9 ("usb: gadget: udc: snps_udc_core: use setup_timer()
>> helper.")
>>
>> from the usb-gadget tree.
>>
>> I fixed it up by taking the USB version and can carry the fix as
>> necessary. This is now fixed as far as linux-next is concerned, but any
>> non trivial conflicts should be mentioned to your upstream maintainer
>> when your tree is submitted for merging. You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise any
>> particularly complex conflicts.
>
> FWIW, timer_setup() should be preferred over setup_timer().
I'll drop the one from my tree.
thanks
--
balbi
signature.asc
Description: PGP signature
Re: [iMX6Q][CI] EHCI Low-speed device problem
Hi Peter,
> On Thu, Oct 19, 2017 at 07:47:01AM +0200, Lukasz Majewski wrote:
> > > > I'm wondering if it is feasible to manually check the XactErr
> > > > bit and then for example order the soft USB reset (from the
> > > > root hub)?
> > > >
> > > > Or is there any other acceptable in upstream solution?
> > > >
> > > > >
> > > > > > The problem has been described in detail (including screen
> > > > > > shots from USB analyzer + some further investigations) here:
> > > > > > https://community.nxp.com/thread/462409
> > > > >
> > >
> > > Lukasz, there is a known issue
> >
> > Could you point me to any "Errata" document describing this issue?
> >
> > Could you elaborate on it a bit more?
> >
>
> No, it assumes PHY's power is prior to controller's initialization.
Is there any particular time necessary?
>
> > > that low speed device may have issue
> > > that i.mx6 PHY's power is not ready before controller goes to
> > > initialize,
> >
> > Please correct my understanding if I'm wrong - the issue here is
> > with USB PHY. When low-speed device is connected, the USB PHY may
> > be not properly powered, but the USB controller is ready for
> > serving the transmission.
>
> Yes.
>
> >
> > > so for i.mx6, we should not use PORT_PP for PHY's power.
> >
> > In our design we do control (with some dedicated USB VBUS switch
> > IC) the VBUS power with USB_H1_PWR# pin PAD_EIM_D31, which indeed
> > is the output controlled by PORTSC1's bit 12 (PP).
>
> Please configure PAD_EIM_D31 as GPIO instead of USB_PWR_EN.
pinctrl_usbh1_vbus: usbh1_vbus_grp {
fsl,pins = <
MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
>;
};
It did not help.
I've also setup the regulator API to enable VBUS and then wait ~300ms
with stable power before we proceed with USB Host further
initialization.
reg_usbh1_vbus: usb-h1-vbus {
compatible = "regulator-fixed";
gpio = <&gpio3 31 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh1_vbus>;
regulator-name = "usb_h1_vbus";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-enable-ramp-delay = <30>;
};
&usbh1 {
vbus-supply = <®_usbh1_vbus>;
}
The ~300ms is from touchscreen datasheet - time needed for
initialization.
However, with EHCI from Samsung/Intel I don't need such time to have
touchscreen properly enumerated.
> >
> > One more strange thing, which I've observed - the bit 4 (OCA) from
> > PORTSC1 goes high during the operation - no matter if we succeed or
> > no with the USB enumeration:
> >
> > IMX6#0>mdahb 0x02184384 1
> > AHB/AXI 00_02184384 : 14001415
> >
> > It indicates that we do have an "over-current" condition, but the
> > touchscreen IC's MAX current consumption is 18 mA, and the port can
> > provide 100 mA. The touchscreen IC is the only device connected to
> > USB Host1.
>
> Please check if pinctrl and polarity of OC pin are correct.
The OC on the PCB is active low (and it is externally pullup'ed with
10k resistor).
>
> >
> > > See flag: CI_HDRC_TURN_VBUS_EARLY_ON for detail.
> >
> > This flag enables very early the VBUS power. I do use standard
> > settings here (the flag is set).
> >
>
> You need to enable VBUS power early really, that means using GPIO to
> control it instead of USB PIN. See imx6qdl-sabresd as an example.
OK. This is already done (I checked that the CI_HDRC_TURN_VBUS_EARLY_ON
is enabled and USB_PWR_EN is configured as GPIO).
>
> > > At i.mx6, the VBUS
> > > 5v is the power for USB PHY.
> >
> > So the VBUS is at iMX6q also the power for USB PHY?
> >
> > In our design we do use VBUS to power the sensor.
> >
> > How can I workaround this issue? Can it be done in SW (to avoid
> > changing the PCB routing)?
> >
>
> One of USBOTG1_VBUS and USBH1_VBUS can be both USB PHY's power.
> Usually, it doesn't matter the VBUS powers USB peripheral unless
> the peripheral really consumes too much current, eg > 500mA, it
> may have problem, I am not sure, I am not hardware guy.
>
Could you look into the picture attached to the earlier e-mail and
comment on Alan's reply (especially about the lack of error indication
fo XactErr)?
Thanks in advance,
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
--
To unsubscribe from this list: send the line "unsubscribe 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: add SPDX identifiers to all files in drivers/usb/
Hi Greg,
On Thu, Oct 19, 2017 at 10:38 AM, Greg Kroah-Hartman
wrote:
> It's good to have SPDX identifiers in all files to make it easier to
> audit the kernel tree for correct licenses. This patch adds these
> identifiers to all files in drivers/usb/ based on a script and data from
> Thomas Gleixner, Philippe Ombredanne, and Kate Stewart.
>
> Cc: Thomas Gleixner
> Cc: Kate Stewart
> Cc: Philippe Ombredanne
> Signed-off-by: Greg Kroah-Hartman
> ---
> Unless someone really complains, I'm going to add this to my tree for
> 4.15-rc1.
It would be good to include a diffstat, esp. when touching +600 files.
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index 9650b351c26c..cb8d902b801d 100644
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe 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: add SPDX identifiers to all files in drivers/usb/
On Thu, Oct 19, 2017 at 10:49:47AM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > On Thu, Oct 19, 2017 at 10:38 AM, Greg Kroah-Hartman > wrote: > > It's good to have SPDX identifiers in all files to make it easier to > > audit the kernel tree for correct licenses. This patch adds these > > identifiers to all files in drivers/usb/ based on a script and data from > > Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. > > > > Cc: Thomas Gleixner > > Cc: Kate Stewart > > Cc: Philippe Ombredanne > > Signed-off-by: Greg Kroah-Hartman > > --- > > Unless someone really complains, I'm going to add this to my tree for > > 4.15-rc1. > > It would be good to include a diffstat, esp. when touching +600 files. I wanted to, but I was worried it would be too long to prevent the patch from hitting the list :) Here it is: drivers/usb/Makefile |1 + drivers/usb/atm/Makefile |1 + drivers/usb/atm/cxacru.c |1 + drivers/usb/atm/speedtch.c |1 + drivers/usb/atm/ueagle-atm.c |2 ++ drivers/usb/atm/usbatm.c |1 + drivers/usb/atm/usbatm.h |1 + drivers/usb/atm/xusbatm.c |1 + drivers/usb/c67x00/c67x00-drv.c|2 ++ drivers/usb/c67x00/c67x00-hcd.c|2 ++ drivers/usb/c67x00/c67x00-hcd.h|2 ++ drivers/usb/c67x00/c67x00-ll-hpi.c |2 ++ drivers/usb/c67x00/c67x00-sched.c |2 ++ drivers/usb/c67x00/c67x00.h|2 ++ drivers/usb/chipidea/Makefile |1 + drivers/usb/chipidea/bits.h|2 ++ drivers/usb/chipidea/ci.h |2 ++ drivers/usb/chipidea/ci_hdrc_imx.c |2 ++ drivers/usb/chipidea/ci_hdrc_imx.h |2 ++ drivers/usb/chipidea/ci_hdrc_msm.c |2 ++ drivers/usb/chipidea/ci_hdrc_pci.c |2 ++ drivers/usb/chipidea/ci_hdrc_usb2.c|2 ++ drivers/usb/chipidea/ci_hdrc_zevio.c |2 ++ drivers/usb/chipidea/core.c|2 ++ drivers/usb/chipidea/debug.c |1 + drivers/usb/chipidea/host.c|2 ++ drivers/usb/chipidea/host.h|1 + drivers/usb/chipidea/otg.c |2 ++ drivers/usb/chipidea/otg.h |2 ++ drivers/usb/chipidea/otg_fsm.c |2 ++ drivers/usb/chipidea/otg_fsm.h |2 ++ drivers/usb/chipidea/udc.c |2 ++ drivers/usb/chipidea/udc.h |2 ++ drivers/usb/chipidea/ulpi.c|2 ++ drivers/usb/chipidea/usbmisc_imx.c |2 ++ drivers/usb/class/cdc-acm.c|2 ++ drivers/usb/class/cdc-acm.h|2 ++ drivers/usb/class/cdc-wdm.c|2 ++ drivers/usb/class/usblp.c |2 ++ drivers/usb/class/usbtmc.c |2 ++ drivers/usb/common/Makefile|1 + drivers/usb/common/common.c|2 ++ drivers/usb/common/led.c |2 ++ drivers/usb/common/ulpi.c |2 ++ drivers/usb/common/usb-otg-fsm.c |2 ++ drivers/usb/core/Makefile |1 + drivers/usb/core/devices.c |2 ++ drivers/usb/core/devio.c |6 +- drivers/usb/core/hcd-pci.c |2 ++ drivers/usb/core/hcd.c |2 ++ drivers/usb/core/hub.h |2 ++ drivers/usb/core/ledtrig-usbport.c |2 ++ drivers/usb/core/of.c |2 ++ drivers/usb/core/otg_whitelist.h |2 ++ drivers/usb/core/port.c|2 ++ drivers/usb/core/quirks.c |2 ++ drivers/usb/core/usb-acpi.c|2 ++ drivers/usb/dwc2/Makefile |1 + drivers/usb/dwc2/core.c|2 ++ drivers/usb/dwc2/core.h|2 ++ drivers/usb/dwc2/core_intr.c |2 ++ drivers/usb/dwc2/debug.h |2 ++ drivers/usb/dwc2/debugfs.c |2 ++ drivers/usb/dwc2/gadget.c |2 ++ drivers/usb/dwc2/hcd.c |2 ++ drivers/usb/dwc2/hcd.h |2 ++ drivers/usb/dwc2/hcd_ddma.c|2 ++ drivers/usb/dwc2/hcd_intr.c|2 ++ drivers/usb/dwc2/hcd_queue.c |2 ++ drivers/usb/dwc2/hw.h |2 ++ drivers/usb/dwc2/params.c |2 ++ drivers/usb/dwc2/pci.c |2 ++
Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/
On Thu, 19 Oct 2017, Greg Kroah-Hartman wrote:
> It's good to have SPDX identifiers in all files to make it easier to
> audit the kernel tree for correct licenses. This patch adds these
> identifiers to all files in drivers/usb/ based on a script and data from
> Thomas Gleixner, Philippe Ombredanne, and Kate Stewart.
>
> Cc: Thomas Gleixner
> Cc: Kate Stewart
> Cc: Philippe Ombredanne
> Signed-off-by: Greg Kroah-Hartman
> ---
> Unless someone really complains, I'm going to add this to my tree for
> 4.15-rc1.
>
>
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index 9650b351c26c..cb8d902b801d 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -1,6 +1,7 @@
> #
> # Makefile for the kernel USB device drivers.
> #
> +# SPDX-License-Identifier: GPL-2.0
The last discussion about this was to add the identifier as the first line
of the file or as the second in case of files with a shebang in the first
one.
I think you missed the last version of the script. Attached.
Thanks,
tglx
#!/usr/bin/env python
#
import sys
import os
def insert_at(srclines, pos, tag, style):
srclines.insert(pos, '%s SPDX-License-Identifier: %s\n' %(style, tag))
return True
def handle_c_h(srclines, tag):
return insert_at(srclines, 0, tag, '//')
def handle_asm(srclines, tag):
# Stupid search for a proper style to comment the SPDX tag
pos = 0
style = None
for line in srclines:
pos += 1
if line.startswith(';;;'):
style = ';;;'
elif line.startswith(';;'):
style = ';;'
elif line.startswith(';'):
style = ';'
elif line.startswith('|'):
style = '|'
elif line.startswith('!'):
style = '!'
elif line.startswith('//'):
style = '//'
elif line.startswith("/*"):
style = '//'
else:
continue
return insert_at(srclines, 0, tag, style)
return False
def handle_sh(srclines, tag):
return insert_at(srclines, 1, tag, '#')
tf = open(sys.argv[1])
for entry in tf.readlines():
if len(entry.strip()) == 0:
continue
nr, fname, tag = entry.strip().split(',')
# FIXME: Use a proper encoder
fname = fname.replace('%2C',',')
if tag == 'NOTAG':
print("Skipping %s" %fname)
continue
if not os.path.isfile(fname):
print("FAIL: File %s does not exist anymore" %fname)
continue
srclines = open(fname).readlines()
done = False
for line in srclines:
if line.find('SPDX-License-Identifier') >= 0:
done = True
break
if done:
print("SPDX id exists already in %s" %fname)
continue
ok = False
if fname.endswith('.c') or fname.endswith('.h') or fname.endswith('.uc'):
ok = handle_c_h(srclines, tag)
elif fname.endswith('.S'):
ok = handle_asm(srclines, tag)
elif fname.endswith('.cocci'):
ok = insert_at(srclines, 0, tag, '//')
elif fname.endswith('.dts') or fname.endswith('.dtsi'):
ok = insert_at(srclines, 0, tag, '//')
elif fname.endswith('.py') or fname.endswith('.tc') or fname.endswith('.sh'):
ok = insert_at(srclines, 1, tag, '#')
elif fname.endswith('Makefile') or fname.find('Kconfig') > 0 or fname.find('Kbuild') > 0:
ok = insert_at(srclines, 0, tag, '#')
else:
print("Unhandled or ignored file %s" %fname)
continue
if ok:
open(fname, 'w').writelines(srclines)
print("Inserted %s into %s" %(tag, fname))
else:
print("FAIL: No place for insertion found %s" %fname)
Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/
On Thu, Oct 19, 2017 at 10:50:44AM +0200, Thomas Gleixner wrote: > On Thu, 19 Oct 2017, Greg Kroah-Hartman wrote: > > > It's good to have SPDX identifiers in all files to make it easier to > > audit the kernel tree for correct licenses. This patch adds these > > identifiers to all files in drivers/usb/ based on a script and data from > > Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. > > > > Cc: Thomas Gleixner > > Cc: Kate Stewart > > Cc: Philippe Ombredanne > > Signed-off-by: Greg Kroah-Hartman > > --- > > Unless someone really complains, I'm going to add this to my tree for > > 4.15-rc1. > > > > > > diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile > > index 9650b351c26c..cb8d902b801d 100644 > > --- a/drivers/usb/Makefile > > +++ b/drivers/usb/Makefile > > @@ -1,6 +1,7 @@ > > # > > # Makefile for the kernel USB device drivers. > > # > > +# SPDX-License-Identifier: GPL-2.0 > > The last discussion about this was to add the identifier as the first line > of the file or as the second in case of files with a shebang in the first > one. > > I think you missed the last version of the script. Attached. Oh, I did, thanks, let me run this again... -- To unsubscribe from this list: send the line "unsubscribe 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: add SPDX identifiers to all files in drivers/usb/
On Thu, Oct 19, 2017 at 10:50:44AM +0200, Thomas Gleixner wrote: > On Thu, 19 Oct 2017, Greg Kroah-Hartman wrote: > > > It's good to have SPDX identifiers in all files to make it easier to > > audit the kernel tree for correct licenses. This patch adds these > > identifiers to all files in drivers/usb/ based on a script and data from > > Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. > > > > Cc: Thomas Gleixner > > Cc: Kate Stewart > > Cc: Philippe Ombredanne > > Signed-off-by: Greg Kroah-Hartman > > --- > > Unless someone really complains, I'm going to add this to my tree for > > 4.15-rc1. > > > > > > diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile > > index 9650b351c26c..cb8d902b801d 100644 > > --- a/drivers/usb/Makefile > > +++ b/drivers/usb/Makefile > > @@ -1,6 +1,7 @@ > > # > > # Makefile for the kernel USB device drivers. > > # > > +# SPDX-License-Identifier: GPL-2.0 > > The last discussion about this was to add the identifier as the first line > of the file or as the second in case of files with a shebang in the first > one. > > I think you missed the last version of the script. Attached. Ugh, that's ugly, creating stuff like this: --- a/drivers/usb/atm/speedtch.c +++ b/drivers/usb/atm/speedtch.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /** * speedtch.c - Alcatel SpeedTouch USB xDSL modem driver * diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c Are we really ok with the '//' comments? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/
On Thu, 19 Oct 2017, Greg Kroah-Hartman wrote: > On Thu, Oct 19, 2017 at 10:50:44AM +0200, Thomas Gleixner wrote: > > The last discussion about this was to add the identifier as the first line > > of the file or as the second in case of files with a shebang in the first > > one. > > > > I think you missed the last version of the script. Attached. > > Ugh, that's ugly, creating stuff like this: > > --- a/drivers/usb/atm/speedtch.c > +++ b/drivers/usb/atm/speedtch.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0+ > > /** > * speedtch.c - Alcatel SpeedTouch USB xDSL modem driver > * > diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c > > > Are we really ok with the '//' comments? That's what Linus suggested so it stands out. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe 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: add SPDX identifiers to all files in drivers/usb/
Hi Greg,
On Thu, Oct 19, 2017 at 10:52 AM, Greg Kroah-Hartman
wrote:
> On Thu, Oct 19, 2017 at 10:49:47AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Oct 19, 2017 at 10:38 AM, Greg Kroah-Hartman
>> wrote:
>> > It's good to have SPDX identifiers in all files to make it easier to
>> > audit the kernel tree for correct licenses. This patch adds these
>> > identifiers to all files in drivers/usb/ based on a script and data from
>> > Thomas Gleixner, Philippe Ombredanne, and Kate Stewart.
>> >
>> > Cc: Thomas Gleixner
>> > Cc: Kate Stewart
>> > Cc: Philippe Ombredanne
>> > Signed-off-by: Greg Kroah-Hartman
>> > ---
>> > Unless someone really complains, I'm going to add this to my tree for
>> > 4.15-rc1.
>>
>> It would be good to include a diffstat, esp. when touching +600 files.
>
> I wanted to, but I was worried it would be too long to prevent the patch
> from hitting the list :)
>
> Here it is:
[...]
Thanks!
BTW, some files seem to be "SPDX-License-Identifier: GPL-1.0+".
Was this intentional, given COPYING says the default is v2?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe 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: add SPDX identifiers to all files in drivers/usb/
On Thu, Oct 19, 2017 at 11:01:56AM +0200, Thomas Gleixner wrote: > On Thu, 19 Oct 2017, Greg Kroah-Hartman wrote: > > On Thu, Oct 19, 2017 at 10:50:44AM +0200, Thomas Gleixner wrote: > > > The last discussion about this was to add the identifier as the first line > > > of the file or as the second in case of files with a shebang in the first > > > one. > > > > > > I think you missed the last version of the script. Attached. > > > > Ugh, that's ugly, creating stuff like this: > > > > --- a/drivers/usb/atm/speedtch.c > > +++ b/drivers/usb/atm/speedtch.c > > @@ -1,3 +1,4 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > > > /** > > * speedtch.c - Alcatel SpeedTouch USB xDSL modem driver > > * > > diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c > > > > > > Are we really ok with the '//' comments? > > That's what Linus suggested so it stands out. Oh, it stands out alright :( But all that matters is the tag is there for tools to be able to extract it properly. And if we have that, it doesn't matter what the comment "style" would be, so might as well make it look "nicer". And, to take it to the next conclusion, if we have the SPDX identifier, we can get rid of the "boilerplate" GPL license crap as well, right? How about this example patch of just 2 files, we could drop so many lines that we are all tired of reading over and over... thanks, greg k-h --- drivers/usb/core/hcd-pci.c | 15 ++- drivers/usb/core/hub.h | 12 ++-- 2 files changed, 4 insertions(+), 23 deletions(-) diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c index ea829ad798c0..a50caac7bffb 100644 --- a/drivers/usb/core/hcd-pci.c +++ b/drivers/usb/core/hcd-pci.c @@ -1,19 +1,8 @@ /* - * (C) Copyright David Brownell 2000-2002 - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * SPDX-License-Identifier: GPL-2.0+ * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY - * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * for more details. + * (C) Copyright David Brownell 2000-2002 * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software Foundation, - * Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ #include diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h index 34c1a7e22aae..2291ca86f5cb 100644 --- a/drivers/usb/core/hub.h +++ b/drivers/usb/core/hub.h @@ -1,4 +1,6 @@ /* + * SPDX-License-Identifier: GPL-2.0 + * * usb hub driver head file * * Copyright (C) 1999 Linus Torvalds @@ -7,16 +9,6 @@ * Copyright (C) 2001 Brad Hards (bha...@bigpond.net.au) * Copyright (C) 2012 Intel Corp (tianyu@intel.com) * - * move struct usb_hub to this file. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY - * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * for more details. */ #include -- To unsubscribe from this list: send the line "unsubscribe 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: add SPDX identifiers to all files in drivers/usb/
On Thu, 19 Oct 2017, Geert Uytterhoeven wrote: > On Thu, Oct 19, 2017 at 10:52 AM, Greg Kroah-Hartman > wrote: > > On Thu, Oct 19, 2017 at 10:49:47AM +0200, Geert Uytterhoeven wrote: > >> On Thu, Oct 19, 2017 at 10:38 AM, Greg Kroah-Hartman > >> wrote: > >> > It's good to have SPDX identifiers in all files to make it easier to > >> > audit the kernel tree for correct licenses. This patch adds these > >> > identifiers to all files in drivers/usb/ based on a script and data from > >> > Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. > >> > > >> > Cc: Thomas Gleixner > >> > Cc: Kate Stewart > >> > Cc: Philippe Ombredanne > >> > Signed-off-by: Greg Kroah-Hartman > >> > --- > >> > Unless someone really complains, I'm going to add this to my tree for > >> > 4.15-rc1. > >> > >> It would be good to include a diffstat, esp. when touching +600 files. > > > > I wanted to, but I was worried it would be too long to prevent the patch > > from hitting the list :) > > > > Here it is: > > [...] > > Thanks! > > BTW, some files seem to be "SPDX-License-Identifier: GPL-1.0+". > Was this intentional, given COPYING says the default is v2? Yes. The license mentioned in the file says something like: This is licensed under GPL. which is equivalent to GPL-1.0+. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe 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: add SPDX identifiers to all files in drivers/usb/
Hi, Greg Kroah-Hartman writes: > On Thu, Oct 19, 2017 at 10:49:47AM +0200, Geert Uytterhoeven wrote: >> Hi Greg, >> >> On Thu, Oct 19, 2017 at 10:38 AM, Greg Kroah-Hartman >> wrote: >> > It's good to have SPDX identifiers in all files to make it easier to >> > audit the kernel tree for correct licenses. This patch adds these >> > identifiers to all files in drivers/usb/ based on a script and data from >> > Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. >> > >> > Cc: Thomas Gleixner >> > Cc: Kate Stewart >> > Cc: Philippe Ombredanne >> > Signed-off-by: Greg Kroah-Hartman >> > --- >> > Unless someone really complains, I'm going to add this to my tree for >> > 4.15-rc1. >> >> It would be good to include a diffstat, esp. when touching +600 files. > > I wanted to, but I was worried it would be too long to prevent the patch > from hitting the list :) > > Here it is: > > drivers/usb/Makefile |1 + > drivers/usb/atm/Makefile |1 + > drivers/usb/atm/cxacru.c |1 + > drivers/usb/atm/speedtch.c |1 + > drivers/usb/atm/ueagle-atm.c |2 ++ > drivers/usb/atm/usbatm.c |1 + > drivers/usb/atm/usbatm.h |1 + > drivers/usb/atm/xusbatm.c |1 + > drivers/usb/c67x00/c67x00-drv.c|2 ++ > drivers/usb/c67x00/c67x00-hcd.c|2 ++ > drivers/usb/c67x00/c67x00-hcd.h|2 ++ > drivers/usb/c67x00/c67x00-ll-hpi.c |2 ++ > drivers/usb/c67x00/c67x00-sched.c |2 ++ > drivers/usb/c67x00/c67x00.h|2 ++ > drivers/usb/chipidea/Makefile |1 + > drivers/usb/chipidea/bits.h|2 ++ > drivers/usb/chipidea/ci.h |2 ++ > drivers/usb/chipidea/ci_hdrc_imx.c |2 ++ > drivers/usb/chipidea/ci_hdrc_imx.h |2 ++ > drivers/usb/chipidea/ci_hdrc_msm.c |2 ++ > drivers/usb/chipidea/ci_hdrc_pci.c |2 ++ > drivers/usb/chipidea/ci_hdrc_usb2.c|2 ++ > drivers/usb/chipidea/ci_hdrc_zevio.c |2 ++ > drivers/usb/chipidea/core.c|2 ++ > drivers/usb/chipidea/debug.c |1 + > drivers/usb/chipidea/host.c|2 ++ > drivers/usb/chipidea/host.h|1 + > drivers/usb/chipidea/otg.c |2 ++ > drivers/usb/chipidea/otg.h |2 ++ > drivers/usb/chipidea/otg_fsm.c |2 ++ > drivers/usb/chipidea/otg_fsm.h |2 ++ > drivers/usb/chipidea/udc.c |2 ++ > drivers/usb/chipidea/udc.h |2 ++ > drivers/usb/chipidea/ulpi.c|2 ++ > drivers/usb/chipidea/usbmisc_imx.c |2 ++ > drivers/usb/class/cdc-acm.c|2 ++ > drivers/usb/class/cdc-acm.h|2 ++ > drivers/usb/class/cdc-wdm.c|2 ++ > drivers/usb/class/usblp.c |2 ++ > drivers/usb/class/usbtmc.c |2 ++ > drivers/usb/common/Makefile|1 + > drivers/usb/common/common.c|2 ++ > drivers/usb/common/led.c |2 ++ > drivers/usb/common/ulpi.c |2 ++ > drivers/usb/common/usb-otg-fsm.c |2 ++ > drivers/usb/core/Makefile |1 + > drivers/usb/core/devices.c |2 ++ > drivers/usb/core/devio.c |6 +- > drivers/usb/core/hcd-pci.c |2 ++ > drivers/usb/core/hcd.c |2 ++ > drivers/usb/core/hub.h |2 ++ > drivers/usb/core/ledtrig-usbport.c |2 ++ > drivers/usb/core/of.c |2 ++ > drivers/usb/core/otg_whitelist.h |2 ++ > drivers/usb/core/port.c|2 ++ > drivers/usb/core/quirks.c |2 ++ > drivers/usb/core/usb-acpi.c|2 ++ > drivers/usb/dwc2/Makefile |1 + > drivers/usb/dwc2/core.c|2 ++ > drivers/usb/dwc2/core.h|2 ++ > drivers/usb/dwc2/core_intr.c |2 ++ > drivers/usb/dwc2/debug.h |2 ++ > drivers/usb/dwc2/debugfs.c |2 ++ > drivers/usb/dwc2/gadget.c |2 ++ > drivers/usb/dwc2/hcd.c |2 ++ > drivers/usb/dwc2/hcd.h |2 ++ > drivers/usb/dwc2/hcd_ddma.c|2 ++ > drivers/usb/dwc2/hcd_intr.c|2 ++ > drivers/usb/dwc2/hcd_queue.c
Re: [PATCH v7 2/4] usb: dwc3: of-simple: Re-order resource handling in remove
Hi, Philipp Zabel writes: > From: Vivek Gautam > > Move clock handling after of_platform_depopulate to achieve > a sequence that is reverse of the probe sequence. > > Cc: Felipe Balbi > Signed-off-by: Vivek Gautam does this depend on the rest of the series? Doesn't seem like it does. -- balbi signature.asc Description: PGP signature
Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device
Philipp Zabel writes: > From: Vivek Gautam > > Add support to get a list of resets available for the device. > These resets must be kept de-asserted until the device is > in use. > > Cc: Felipe Balbi > Signed-off-by: Vivek Gautam > [p.za...@pengutronix.de: switch to hidden reset control array] > Signed-off-by: Philipp Zabel now this seems like it depends on patch 1/4, right? Is the reset API change going on v4.15? -- balbi signature.asc Description: PGP signature
Re: [RFC usb-next v5 1/3] dt-bindings: usb: add the documentation for USB root-hub
On 18/10/2017 11:05, Arnd Bergmann wrote: > On Tue, Oct 17, 2017 at 11:19 PM, Martin Blumenstingl > wrote: >>> Ok, very good! >>> is there anything else you want me to test? >>> >>> What about the same dtb when run on a kernel without your >>> patch series? Does that work as well, or are your patches >>> required to make it work? >> >> this is the only device I have which uses devicetree and a xHCI >> controller. I can test it with a dwc2 based device though if you want > > Does dwc2 also use separate nodes for the roothub? From your > description it sounds like it would not be affected by your patch. > > To rephrase what I'm interested in, can you check that with your > patch series, we correctly associate a device node in DT with the > struct device in the kernel both with and without the optional > roothub node in the dtb? > > Since you used a dtb that already listed an endpoint device below > an xhci, that would answer my earlier question of whether it worked > before your patch series, and you tested that it still works with your > patches applied and the roothub node added in the dtb. Now we > just need to make sure we don't break existing dtb files that don't > have the roothub node but do have endpoint device nodes. > >Arnd > > ___ > linux-amlogic mailing list > linux-amlo...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic > Hi Arnd, I tested in the same conditions : - On Odroid-C2 using DWC2, but not using the roothub functionnality - patch v6 applied - node for on-board hub - printk in usb core And it works : [8.767964] usb 1-1: of_node /soc/usb@c910/hub@1 parent /soc/usb@c910 [8.955901] usb 1-1: new high-speed USB device number 2 using dwc2 [9.165641] hub 1-1:1.0: USB hub found [9.165939] hub 1-1:1.0: 4 ports detected Neil -- To unsubscribe from this list: send the line "unsubscribe 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-next v6 0/3] initialize (multiple) PHYs on the roothub
On 17/10/2017 23:20, Martin Blumenstingl wrote:
> This series is the outcome of a discussion with Felipe Balbi,
> see [0] and [1] as well as Mathias Nyman, see [7] and [8].
> The quick-summary of this is:
> - dwc3 already takes one USB2 and one USB3 PHY and initializes these
> correct
> - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
> ohci-platform.c) do not have a limitation on the number of PHYs - they
> support one PHY per actual host port
> - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
> or three USB2 ports enabled on the internal root-hub. The SoCs also
> provide separate USB2 PHYs, one per port. All USB2 PHYs (which are
> internally "connected" to the dwc3 roothub) need to be powered on,
> otherwise USB devices cannot be enumerated (even if just one PHY is
> disabled and if the device is plugged into another, enabled port)
>
> In my first attempt to get USB supported on the GXL and GXM SoCs I tried
> to work-around the problem that I could not pass multiple PHYs to the
> dwc3 controller.
> This was rejected by Rob Herring (which was definitely the thing to do in
> my opinion), see [2]
>
> This series adds a new "roothub PHY wrapper". This can be configured
> through devicetree by passing a child-node with "reg = <0>" (in other
> words: it describes the roothub) to the USB controller.
> Additionally there has to be a child-node for each port on
> the root-hub. Each of the child-nodes takes a "phys" and "phy-names"
> property. This allows modeling the root-hub in devicetree similar to the
> USB device binding (documented in devicetree/bindings/usb/usb-device.txt)
> This avoids and backwards-compatibility problems (which was a concern
> regardless of the solution, see [3]) since the binding for the root-hub
> was previously not specified (and we're not using the "phys" property of
> the controller, which might have served different purposes before,
> depending on the drivers).
>
> Additionally this integrates the new roothub PHY wrapper into hcd.c
> which automatically enables it for all USB controller drivers (tested
> on an Amlogic Meson GXL SoC which uses a dwc3 controller).
>
> Changes since RfC v5 at [10]:
> - dropped RfC prefix
> - removed noisy dev_err if no roothub node was found (spotted by
> Xiaolong Ye's kbuild test robot - thank you for that!)
> - moved the call to usb_phy_roothub_power_off() within
> hcd_bus_suspend() to make sure that the PHYs are turned off
> if the "race with a root-hub wakeup event" condition is met (in
> this case the PHYs are turned on again, with the old code we did
> break the PHYs internal ref-counting because we never turned the
> PHYs off before turning them on again in case of that special
> "race with a root-hub wakeup event").
> additionally we're not handling the status returned by
> usb_phy_roothub_power_off() anymore (the bus is already turned off
> and we tried to turn off all PHYs as well - only the PHYs which
> failed to power off will stay in the current state).
> thanks to Alan Stern for the suggestion
> - removed return value from usb_phy_roothub_power_off() because none
> of my code uses it anymore. thanks to Alan Stern for the suggestion
>
> Changes since v4 at [9]:
> - renamed the subject of the cover-letter (old name was:
> "initialize (multiple) PHYs in xhci-plat")
> - back into RFC status (see below for the reasons)
> - dropped Tested-by from Chunfeng Yun (same reasons as RFC status)
> - reworded cover-letter and commit messages from "platform-roothub"
> to "roothub PHY wrapper"
> - moved code from drivers/usb/host/platform-roothub.* to
> drivers/usb/core/phy.* and the changes to
> drivers/usb/host/xhci-plat.c to drivers/usb/core/hcd.c as suggested
> by Mathias Nyman (as a benefit this will enable the new logic for
> non-xHCI controllers as well - however this was not tested yet)
> - rename the structs, function names, etc from platform_roothub_* to
> usb_phy_roothub*
>
> Changes since RFCv3 at [6]:
> - moved the DT binding change from patch #3 to patch #1 as suggested
> by Rob Herring (and slightly adjusted the commit message to account
> for that)
> - added Tested-by from Chunfeng Yun (who confirmed that the whole
> concept and implementation works fine on Mediatek SoCs - many thanks
> again!) to patch #2
> - added Rob Herring's ACK to patches 1 and 3
> - dropped RFC status (RFCv3 -> PATCH v4)
>
> Changes since RFCv2 at [5]:
> - split phy_{init,exit} and phy_power_{on,off} handling. up until RFCv2
> I called phy_init plus phy_power_on in platform_roothub_power_on and
> phy_power_off plus phy_exit in platform_roothub_power_off. However,
> Chunfeng Yun (a Mediatek SoC developer - many thanks for testing my
> series and providing great feedback) reported that only using
> phy_power_off (and omitting phy_exit) during system suspend fixes an
> issue where USB devices would be re-enumerated when resuming. His
> ori
Re: dwc2 - ChHltd set, but reason is unknown
On Thu, 19 Oct 2017, Minas Harutyunyan wrote:
Could you please apply this patch.
If you confirm that this patch fix your issue with "Transaction Error"
and " ChHltd set, but reason is unknown" I'll submit to LKML as final patch.
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
f4ef159b538e..7da22152df68 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -331,6 +331,9 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
usbcfg &= ~(GUSBCFG_HNPCAP | GUSBCFG_SRPCAP);
+ /* Set HS/FS Timeout Calibration */
+ usbcfg |= GUSBCFG_TOUTCAL(7);
+
switch (hsotg->hw_params.op_mode) {
case GHWCFG2_OP_MODE_HNP_SRP_CAPABLE:
if (hsotg->params.otg_cap ==
Hi Minas,
The patch clearly reduced the amount of errors logged, but did not fully
fix the problem. This was with kernel 4.9.39, I can also try with a 4.13
kernel.
Regards,
Anders Montonen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device
Hi Felipe,
On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote:
> Philipp Zabel writes:
>
> > From: Vivek Gautam
> >
> > Add support to get a list of resets available for the device.
> > These resets must be kept de-asserted until the device is
> > in use.
> >
> > Cc: Felipe Balbi
> > Signed-off-by: Vivek Gautam
> > [p.za...@pengutronix.de: switch to hidden reset control array]
> > Signed-off-by: Philipp Zabel
>
> now this seems like it depends on patch 1/4, right? Is the reset API
> change going on v4.15?
Thank you for the reminder. Patch 1 has made it into v4.14-rc1, commit
17c82e206d2a ("reset: Add APIs to manage array of resets"). The other
patches could be picked up for v4.15 without any dependency issues.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe 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: "USB Host halt failed, -110" error when rebooting system
On 18.10.2017 17:50, Alan Stern wrote:
On Tue, 17 Oct 2017 wenxi...@linux.vnet.ibm.com wrote:
From: Wen Xiong
We saw "Host halt failed, -110" error when rebooting system/
shutdowning system/kexec constantly.
This patch called usb_disconnect() before calling xhci_halt().
usb_disconnect()disconnect the parent and all of its children,
clean up hardware state and make sure that hardware is ready
to be halted down.
Rebooting.
[18648.996035] sd 0:2:1:0: [sdb] Synchronizing SCSI cache
[18678.831197] mpt3sas_cm1: sending message unit reset !!
[18678.832774] mpt3sas_cm1: message unit reset: SUCCESS
[18683.900798] mpt3sas_cm0: sending message unit reset !!
[18683.902370] mpt3sas_cm0: message unit reset: SUCCESS
[18693.921103] xhci_hcd 0005:01:00.0: Host halt failed, -110
[18693.924483] reboot: Restarting system
[18861.282906007,5] OPAL: Reboot request...
Signed-off-by: Wen Xiong
Thanks,
Wendy
---
drivers/usb/host/xhci.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ee198ea..67fdb0f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -709,10 +709,17 @@ static void xhci_stop(struct usb_hcd *hcd)
static void xhci_shutdown(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct usb_device *rhdev = hcd->self.root_hub;
+
+ dev_info(hcd->self.controller, "remove, state %x\n", hcd->state);
if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
+ mutex_lock(&usb_bus_idr_lock);
+ usb_disconnect(&rhdev);
+ mutex_unlock(&usb_bus_idr_lock);
+
spin_lock_irq(&xhci->lock);
xhci_halt(xhci);
/* Workaround for spurious wakeups at shutdown with HSW */
This does not seem right. For one thing, shutdown routines are
supposed to avoid taking locks (as much as possible), so that system
shutdown can proceed without deadlocking.
For another, this is a layering violation. The xhci-hcd driver does
not register the root hub, so it should not unregister it.
The right way to fix this is to make sure that the shutdown routine
will succeed even if the host controller is busy with other activity.
The other activities should all be aborted, and all future requests
should fail.
Current shutdown routine just forces the host controller to stop, it clears the
run bit and polls the "halted" status for 16ms. Apparently we don't see the
halted
bit within 16ms.
Spec say that the correct way to stop is to first command all transfer rings to
stop,
then stop the command ring, and after that stop the host controller.
If we just bluntly stop the host (as we do) spec say (xhci 5.4.1.1) it should
stop
anyway within 16ms, but undefined behavior may occur.
So the options in xHCI are down to:
1. just clear the run bit and ignore checking any status.
- really fast shutdown routine for xhci
2. clear run bit and increase status polling time, see if we get rid of error
message.
- can get rid of error message but no actual change, well, we would know if
host stopped
3. properly stop all transfer rings and command ring, and then stop host.
- cleanest and slowest way, do we care about this? everything should be
reset after shutdown.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/
On Thu, Oct 19, 2017 at 11:10 AM, Greg Kroah-Hartman wrote: > And, to take it to the next conclusion, if we have the SPDX identifier, > we can get rid of the "boilerplate" GPL license crap as well, right? > > How about this example patch of just 2 files, we could drop so many > lines that we are all tired of reading over and over... Greg: Exactly! And the tool [0] I used to detect the licenses can also collect the exact matched text: so based on this we could craft a script to do the grunt work of deleting the boilerplate and be reasonably smart about it: - focus on GPL first, ignoring BSD/MIT for now - only take out unambiguous boilerplate that is matched exactly - and only take it out if there a proper and corresponding license identifier already there, or add one otherwise [0] https://github.com/nexB/scancode-toolkit -- Cordially Philippe Ombredanne -- To unsubscribe from this list: send the line "unsubscribe 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/serial/visor: slab-out-of-bounds in palm_os_3_probe
On Wed, Oct 4, 2017 at 4:40 PM, Greg Kroah-Hartman wrote: > On Tue, Oct 03, 2017 at 11:29:40AM +0200, Johan Hovold wrote: >> On Fri, Sep 29, 2017 at 10:37:55AM +0200, Greg Kroah-Hartman wrote: >> > On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote: >> > > Hi! >> > > >> > > I've got the following report while fuzzing the kernel with syzkaller. >> > > >> > > On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+). >> > > >> > > There's no check on the connection_info->num_ports value when >> > > iterating over ports. >> > > >> > > usb 1-1: Handspring Visor / Palm OS: port 162, is for unknown use >> > > usb 1-1: Handspring Visor / Palm OS: port 81, is for unknown use >> > > == >> > > BUG: KASAN: slab-out-of-bounds in palm_os_3_probe+0x4e4/0x570 >> > > Read of size 1 at addr 8800686daa26 by task kworker/0:1/24 >> >> Thanks for the report, Andrey. >> >> > Ah, nice catch, this bug is _old_, sorry about that. >> > >> > The patch below should resolve this. It looks bigger than it really is, >> > as I'm just moving the error checking higher up in the function, and >> > loosing an indentation for when there is invalid data. >> > >> > Can you let me know if this solves the issue? >> >> And thanks for fixing this up, Greg. Will you send a proper patch that I >> can apply? > > Yes, let me redo it based on your comments, and will send it out > "correctly" in a few days. Hi Greg, I was going through the bugs I've reported, and it seems that you didn't mail the patch for this one. Reminding in case you've accidentally forgotten about it. Thanks! > > thanks for the review, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device
Hi,
Philipp Zabel writes:
> Hi Felipe,
>
> On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote:
>> Philipp Zabel writes:
>>
>> > From: Vivek Gautam
>> >
>> > Add support to get a list of resets available for the device.
>> > These resets must be kept de-asserted until the device is
>> > in use.
>> >
>> > Cc: Felipe Balbi
>> > Signed-off-by: Vivek Gautam
>> > [p.za...@pengutronix.de: switch to hidden reset control array]
>> > Signed-off-by: Philipp Zabel
>>
>> now this seems like it depends on patch 1/4, right? Is the reset API
>> change going on v4.15?
>
> Thank you for the reminder. Patch 1 has made it into v4.14-rc1, commit
> 17c82e206d2a ("reset: Add APIs to manage array of resets"). The other
> patches could be picked up for v4.15 without any dependency issues.
Thanks, I'll put other dwc3 patches in my tree :-)
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device
Hi,
Philipp Zabel writes:
> Hi Felipe,
>
> On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote:
>> Philipp Zabel writes:
>>
>> > From: Vivek Gautam
>> >
>> > Add support to get a list of resets available for the device.
>> > These resets must be kept de-asserted until the device is
>> > in use.
>> >
>> > Cc: Felipe Balbi
>> > Signed-off-by: Vivek Gautam
>> > [p.za...@pengutronix.de: switch to hidden reset control array]
>> > Signed-off-by: Philipp Zabel
>>
>> now this seems like it depends on patch 1/4, right? Is the reset API
>> change going on v4.15?
>
> Thank you for the reminder. Patch 1 has made it into v4.14-rc1, commit
> 17c82e206d2a ("reset: Add APIs to manage array of resets"). The other
> patches could be picked up for v4.15 without any dependency issues.
patch 2 applied fine. patch 3 fails to apply hunk 2.
checking file drivers/usb/dwc3/dwc3-of-simple.c
Hunk #1 succeeded at 28 (offset -1 lines).
Hunk #2 FAILED at 98.
1 out of 5 hunks FAILED
Care to rebase on my testing/next?
--
balbi
signature.asc
Description: PGP signature
Re: usb/serial/visor: slab-out-of-bounds in palm_os_3_probe
On Thu, Oct 19, 2017 at 01:19:13PM +0200, Andrey Konovalov wrote: > On Wed, Oct 4, 2017 at 4:40 PM, Greg Kroah-Hartman > wrote: > > On Tue, Oct 03, 2017 at 11:29:40AM +0200, Johan Hovold wrote: > >> On Fri, Sep 29, 2017 at 10:37:55AM +0200, Greg Kroah-Hartman wrote: > >> > On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote: > >> > > Hi! > >> > > > >> > > I've got the following report while fuzzing the kernel with syzkaller. > >> > > > >> > > On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+). > >> > > > >> > > There's no check on the connection_info->num_ports value when > >> > > iterating over ports. > >> > > > >> > > usb 1-1: Handspring Visor / Palm OS: port 162, is for unknown use > >> > > usb 1-1: Handspring Visor / Palm OS: port 81, is for unknown use > >> > > == > >> > > BUG: KASAN: slab-out-of-bounds in palm_os_3_probe+0x4e4/0x570 > >> > > Read of size 1 at addr 8800686daa26 by task kworker/0:1/24 > >> > >> Thanks for the report, Andrey. > >> > >> > Ah, nice catch, this bug is _old_, sorry about that. > >> > > >> > The patch below should resolve this. It looks bigger than it really is, > >> > as I'm just moving the error checking higher up in the function, and > >> > loosing an indentation for when there is invalid data. > >> > > >> > Can you let me know if this solves the issue? > >> > >> And thanks for fixing this up, Greg. Will you send a proper patch that I > >> can apply? > > > > Yes, let me redo it based on your comments, and will send it out > > "correctly" in a few days. > > Hi Greg, > > I was going through the bugs I've reported, and it seems that you > didn't mail the patch for this one. Reminding in case you've > accidentally forgotten about it. It's not forgotten, it's on my TODO list, sorry, been swamped with other things these past few weeks. Hope to get to it soon... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/4] usb: dwc3: of-simple: Add support to get resets for the device
On Thu, 2017-10-19 at 14:31 +0300, Felipe Balbi wrote:
> Hi,
>
> Philipp Zabel writes:
> > Hi Felipe,
> >
> > On Thu, 2017-10-19 at 12:38 +0300, Felipe Balbi wrote:
> > > Philipp Zabel writes:
> > >
> > > > From: Vivek Gautam
> > > >
> > > > Add support to get a list of resets available for the device.
> > > > These resets must be kept de-asserted until the device is
> > > > in use.
> > > >
> > > > Cc: Felipe Balbi
> > > > Signed-off-by: Vivek Gautam
> > > > [p.za...@pengutronix.de: switch to hidden reset control array]
> > > > Signed-off-by: Philipp Zabel
> > >
> > > now this seems like it depends on patch 1/4, right? Is the reset API
> > > change going on v4.15?
> >
> > Thank you for the reminder. Patch 1 has made it into v4.14-rc1, commit
> > 17c82e206d2a ("reset: Add APIs to manage array of resets"). The other
> > patches could be picked up for v4.15 without any dependency issues.
>
> patch 2 applied fine. patch 3 fails to apply hunk 2.
>
> checking file drivers/usb/dwc3/dwc3-of-simple.c
> Hunk #1 succeeded at 28 (offset -1 lines).
> Hunk #2 FAILED at 98.
> 1 out of 5 hunks FAILED
>
>
> Care to rebase on my testing/next?
Thanks, I'll resend patch 3 separately.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe 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 v8] usb: dwc3: of-simple: Add support to get resets for the device
From: Vivek Gautam
Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.
Signed-off-by: Vivek Gautam
[p.za...@pengutronix.de: switch to hidden reset control array]
Signed-off-by: Philipp Zabel
---
v7: Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
---
drivers/usb/dwc3/dwc3-of-simple.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index e129c32780818..ceea1619f8aa3 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -28,11 +28,13 @@
#include
#include
#include
+#include
struct dwc3_of_simple {
struct device *dev;
struct clk **clks;
int num_clocks;
+ struct reset_control*resets;
};
static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
@@ -95,10 +97,21 @@ static int dwc3_of_simple_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, simple);
simple->dev = dev;
+ simple->resets = of_reset_control_array_get_optional_exclusive(np);
+ if (IS_ERR(simple->resets)) {
+ ret = PTR_ERR(simple->resets);
+ dev_err(dev, "failed to get device resets, err=%d\n", ret);
+ return ret;
+ }
+
+ ret = reset_control_deassert(simple->resets);
+ if (ret)
+ goto err_resetc_put;
+
ret = dwc3_of_simple_clk_init(simple, of_count_phandle_with_args(np,
"clocks", "#clock-cells"));
if (ret)
- return ret;
+ goto err_resetc_assert;
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
@@ -107,7 +120,7 @@ static int dwc3_of_simple_probe(struct platform_device
*pdev)
clk_put(simple->clks[i]);
}
- return ret;
+ goto err_resetc_assert;
}
pm_runtime_set_active(dev);
@@ -115,6 +128,13 @@ static int dwc3_of_simple_probe(struct platform_device
*pdev)
pm_runtime_get_sync(dev);
return 0;
+
+err_resetc_assert:
+ reset_control_assert(simple->resets);
+
+err_resetc_put:
+ reset_control_put(simple->resets);
+ return ret;
}
static int dwc3_of_simple_remove(struct platform_device *pdev)
@@ -130,6 +150,9 @@ static int dwc3_of_simple_remove(struct platform_device
*pdev)
clk_put(simple->clks[i]);
}
+ reset_control_assert(simple->resets);
+ reset_control_put(simple->resets);
+
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
--
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: dwc2: usb: Unable to clear channel error
On 10/18/2017 6:07 PM, Marek Vasut wrote: > On 10/18/2017 04:05 PM, Dinh Nguyen wrote: >> Hi, >> >> I'm trying to bringup the DWC2 USB IP version 330A on a new Stratix10 >> SoC and have encountered this error in both Linux and U-Boot: >> >> U-Boot(version v2017.09) >> >> # usb start >> starting USB... >> USB0: Core Release: 3.30a >> dwc_otg_core_host_init: Timeout! >> dwc_otg_core_host_init: Timeout! >> >> Linux(kernel v4.13) >> >> [1.299891] dwc2 ffb0.usb: DWC OTG Controller >> [1.304628] dwc2 ffb0.usb: new USB bus registered, assigned bus >> number 1 >> [1.311698] dwc2 ffb0.usb: irq 13, io mem 0xffb0 >> [1.318309] dwc2 ffb0.usb: Unable to clear enable on channel 0 >> [1.325749] dwc2 ffb0.usb: Unable to clear enable on channel 1 >> [1.333187] dwc2 ffb0.usb: Unable to clear enable on channel 2 >> [1.340626] dwc2 ffb0.usb: Unable to clear enable on channel 3 >> [1.348064] dwc2 ffb0.usb: Unable to clear enable on channel 4 >> [1.355503] dwc2 ffb0.usb: Unable to clear enable on channel 5 >> [1.362941] dwc2 ffb0.usb: Unable to clear enable on channel 6 >> [1.370379] dwc2 ffb0.usb: Unable to clear enable on channel 7 >> [1.377818] dwc2 ffb0.usb: Unable to clear enable on channel 8 >> [1.385256] dwc2 ffb0.usb: Unable to clear enable on channel 9 >> [1.392694] dwc2 ffb0.usb: Unable to clear enable on channel 10 >> [1.400218] dwc2 ffb0.usb: Unable to clear enable on channel 11 >> [1.407743] dwc2 ffb0.usb: Unable to clear enable on channel 12 >> [1.415269] dwc2 ffb0.usb: Unable to clear enable on channel 13 >> [1.422794] dwc2 ffb0.usb: Unable to clear enable on channel 14 >> >> Just wondering if anyone might have an idea on what could be causing >> this error? > > Maybe some clock are not enabled ? > Hi , Are you following board/hisilicon/hikey/README file instructions when using U-Boot? Specially paragraph FLASHING point 4, where discussed "dwc_otg_core_host_init: Timeout!" message. Regards, Grigor Tovmasyan -- To unsubscribe from this list: send the line "unsubscribe 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: usb: Unable to clear channel error
On 10/19/2017 06:55 AM, Grigor Tovmasyan wrote: > On 10/18/2017 6:07 PM, Marek Vasut wrote: >> On 10/18/2017 04:05 PM, Dinh Nguyen wrote: >>> Hi, >>> >>> I'm trying to bringup the DWC2 USB IP version 330A on a new Stratix10 >>> SoC and have encountered this error in both Linux and U-Boot: >>> >>> U-Boot(version v2017.09) >>> >>> # usb start >>> starting USB... >>> USB0: Core Release: 3.30a >>> dwc_otg_core_host_init: Timeout! >>> dwc_otg_core_host_init: Timeout! >>> >>> Linux(kernel v4.13) >>> >>> [1.299891] dwc2 ffb0.usb: DWC OTG Controller >>> [1.304628] dwc2 ffb0.usb: new USB bus registered, assigned bus >>> number 1 >>> [1.311698] dwc2 ffb0.usb: irq 13, io mem 0xffb0 >>> [1.318309] dwc2 ffb0.usb: Unable to clear enable on channel 0 >>> [1.325749] dwc2 ffb0.usb: Unable to clear enable on channel 1 >>> [1.333187] dwc2 ffb0.usb: Unable to clear enable on channel 2 >>> [1.340626] dwc2 ffb0.usb: Unable to clear enable on channel 3 >>> [1.348064] dwc2 ffb0.usb: Unable to clear enable on channel 4 >>> [1.355503] dwc2 ffb0.usb: Unable to clear enable on channel 5 >>> [1.362941] dwc2 ffb0.usb: Unable to clear enable on channel 6 >>> [1.370379] dwc2 ffb0.usb: Unable to clear enable on channel 7 >>> [1.377818] dwc2 ffb0.usb: Unable to clear enable on channel 8 >>> [1.385256] dwc2 ffb0.usb: Unable to clear enable on channel 9 >>> [1.392694] dwc2 ffb0.usb: Unable to clear enable on channel 10 >>> [1.400218] dwc2 ffb0.usb: Unable to clear enable on channel 11 >>> [1.407743] dwc2 ffb0.usb: Unable to clear enable on channel 12 >>> [1.415269] dwc2 ffb0.usb: Unable to clear enable on channel 13 >>> [1.422794] dwc2 ffb0.usb: Unable to clear enable on channel 14 >>> >>> Just wondering if anyone might have an idea on what could be causing >>> this error? >> >> Maybe some clock are not enabled ? >> > > Hi , > > Are you following board/hisilicon/hikey/README file instructions when > using U-Boot? Specially paragraph FLASHING point 4, where discussed > "dwc_otg_core_host_init: Timeout!" message. > I saw that, but I don't know how that applies to a Stratix10 platform? Dinh -- To unsubscribe from this list: send the line "unsubscribe 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 02/15] usb: gadget: make config_item_type structures const
> > Now we have 9 const instances of the config_item_type structure that are > identical, with only the .ct_owner field set. Should they be all merged into > a > single structure ? I think that's a good idea. But I'm about to slurp up this whole series into my tree, how about making that an incremental patch? -- To unsubscribe from this list: send the line "unsubscribe 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 02/15] usb: gadget: make config_item_type structures const
Hi Christoph, On Thursday, 19 October 2017 17:06:57 EEST Christoph Hellwig wrote: > > Now we have 9 const instances of the config_item_type structure that are > > identical, with only the .ct_owner field set. Should they be all merged > > into a single structure ? > > I think that's a good idea. > > But I'm about to slurp up this whole series into my tree, how about making > that an incremental patch? I'm fine with that. Bhumika, would you like to submit an incremental patch, or should I do it ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers
Hi Jon, Thierry,
On Wed, 2017-07-19 at 17:59 +0200, Philipp Zabel wrote:
> From: Vivek Gautam
>
> Make use of of_reset_control_array_get_exclusive() to manage
> an array of reset controllers available with the device.
>
> Cc: Jon Hunter
> Cc: Thierry Reding
> Signed-off-by: Vivek Gautam
> [p.za...@pengutronix.de: switch to hidden reset control array]
> Signed-off-by: Philipp Zabel
will you pick this up now that the prerequisite patch 1 is contained in
master?
Please let me know if there are any issues with this patch.
regards
Philipp
> ---
> No changes since v6.
> ---
> drivers/soc/tegra/pmc.c | 82
> -
> 1 file changed, 20 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
> index e233dd5dcab3d..749b218147a19 100644
> --- a/drivers/soc/tegra/pmc.c
> +++ b/drivers/soc/tegra/pmc.c
> @@ -124,8 +124,7 @@ struct tegra_powergate {
> unsigned int id;
> struct clk **clks;
> unsigned int num_clks;
> - struct reset_control **resets;
> - unsigned int num_resets;
> + struct reset_control *reset;
> };
>
> struct tegra_io_pad_soc {
> @@ -348,32 +347,14 @@ static int tegra_powergate_enable_clocks(struct
> tegra_powergate *pg)
> return err;
> }
>
> -static int tegra_powergate_reset_assert(struct tegra_powergate *pg)
> +static inline int tegra_powergate_reset_assert(struct tegra_powergate *pg)
> {
> - unsigned int i;
> - int err;
> -
> - for (i = 0; i < pg->num_resets; i++) {
> - err = reset_control_assert(pg->resets[i]);
> - if (err)
> - return err;
> - }
> -
> - return 0;
> + return reset_control_assert(pg->reset);
> }
>
> -static int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
> +static inline int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
> {
> - unsigned int i;
> - int err;
> -
> - for (i = 0; i < pg->num_resets; i++) {
> - err = reset_control_deassert(pg->resets[i]);
> - if (err)
> - return err;
> - }
> -
> - return 0;
> + return reset_control_deassert(pg->reset);
> }
>
> static int tegra_powergate_power_up(struct tegra_powergate *pg,
> @@ -566,8 +547,7 @@ int tegra_powergate_sequence_power_up(unsigned int id,
> struct clk *clk,
> pg.id = id;
> pg.clks = &clk;
> pg.num_clks = 1;
> - pg.resets = &rst;
> - pg.num_resets = 1;
> + pg.reset = IS_ERR(rst) ? NULL : rst;
>
> err = tegra_powergate_power_up(&pg, false);
> if (err)
> @@ -755,45 +735,26 @@ static int tegra_powergate_of_get_clks(struct
> tegra_powergate *pg,
> static int tegra_powergate_of_get_resets(struct tegra_powergate *pg,
>struct device_node *np, bool off)
> {
> - struct reset_control *rst;
> - unsigned int i, count;
> int err;
>
> - count = of_count_phandle_with_args(np, "resets", "#reset-cells");
> - if (count == 0)
> - return -ENODEV;
> -
> - pg->resets = kcalloc(count, sizeof(rst), GFP_KERNEL);
> - if (!pg->resets)
> - return -ENOMEM;
> -
> - for (i = 0; i < count; i++) {
> - pg->resets[i] = of_reset_control_get_by_index(np, i);
> - if (IS_ERR(pg->resets[i])) {
> - err = PTR_ERR(pg->resets[i]);
> - goto error;
> - }
> -
> - if (off)
> - err = reset_control_assert(pg->resets[i]);
> - else
> - err = reset_control_deassert(pg->resets[i]);
> -
> - if (err) {
> - reset_control_put(pg->resets[i]);
> - goto error;
> - }
> + pg->reset = of_reset_control_array_get_exclusive(np);
> + if (IS_ERR(pg->reset)) {
> + pr_err("failed to get device resets\n");
> + return PTR_ERR(pg->reset);
> }
>
> - pg->num_resets = count;
> + if (off)
> + err = reset_control_assert(pg->reset);
> + else
> + err = reset_control_deassert(pg->reset);
>
> - return 0;
> + if (err)
> + goto put_reset;
>
> -error:
> - while (i--)
> - reset_control_put(pg->resets[i]);
> + return 0;
>
> - kfree(pg->resets);
> +put_reset:
> + reset_control_put(pg->reset);
>
> return err;
> }
> @@ -885,10 +846,7 @@ static void tegra_powergate_add(struct tegra_pmc *pmc,
> struct device_node *np)
> pm_genpd_remove(&pg->genpd);
>
> remove_resets:
> - while (pg->num_resets--)
> - reset_control_put(pg->resets[pg->num_resets]);
> -
> - kfree(pg->resets);
> + reset_control_put(pg->reset);
>
> remove_clks:
> while (pg->num_clks--)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Re: [iMX6Q][CI] EHCI Low-speed device problem
On Thu, 19 Oct 2017, Lukasz Majewski wrote: > > > Problem: > > > > > > I do observe that the USB transfers are truncated - for example > > > "Get Configuration Descriptor", which length is 34B only gets 16B > > > from the device. > > > > > > I do get the "Invalid PID sequence" error and despite the > > > > How do you know the error is "Invalid PID sequence" and not something > > else, like CRC error or timeout? > > I'm using TotalPhase USB 480 Analyzer. It shows only "Invalid PID > sequence" as the error. When I "unroll" the GetConfigurationDescriptor, > then all data is the same as for correct transmission. > > > > > > DATA1 Packet received by host - the EHCI controller is not sending > > > ACK. > > > > The DATA1 packets are the ones containing bytes 9-16, 25-32, and so on > > (low speed always uses maxpacket size = 8). Since you received 16 > > bytes, this means the host controller accepted the DATA1 packet but > > didn't send an ACK -- that certainly would be a hardware bug. > > I do receive 16B, but those are "comprised" of two separate IN > transactions (8 B each). > One such transaction is built with SETUP -> DATA1 -> ACK packets. > > [Please see the attached screen] According to the screen dump, the device sent a DATA1 packet which the host controller did not ACK. That's a bug in the host controller. In the next transaction, the device sent an empty DATA1 packet instead of resending the previous data. That's a bug in the device. > > Anyway, > > this should have caused the device to retransmit the DATA1 packet in > > response to the next IN packet (if there was one). > > There is IN packet sent afterwards, but it is empty. The whole > GetConfigurationDescriptor ends with OUT ZLP That part is normal. > I'm wondering if it is feasible to manually check the XactErr bit and > then for example order the soft USB reset (from the root hub)? > > Or is there any other acceptable in upstream solution? Not in general. For this one particular case (a short transfer for a Get-Configuration-Descriptor request), it would be easy enough to retry the transfer. Just put a short retry loop around the second usb_get_descriptor() call in usb_get_configuration() in drivers/usb/core/config.c. But similar failures at other times would be harder to recover from. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: "USB Host halt failed, -110" error when rebooting system
On Thu, 19 Oct 2017, Mathias Nyman wrote: > Current shutdown routine just forces the host controller to stop, it clears > the > run bit and polls the "halted" status for 16ms. Apparently we don't see the > halted > bit within 16ms. > > Spec say that the correct way to stop is to first command all transfer rings > to stop, > then stop the command ring, and after that stop the host controller. > > If we just bluntly stop the host (as we do) spec say (xhci 5.4.1.1) it should > stop > anyway within 16ms, but undefined behavior may occur. > > So the options in xHCI are down to: > 1. just clear the run bit and ignore checking any status. > - really fast shutdown routine for xhci > 2. clear run bit and increase status polling time, see if we get rid of error > message. > - can get rid of error message but no actual change, well, we would know > if host stopped > 3. properly stop all transfer rings and command ring, and then stop host. > - cleanest and slowest way, do we care about this? everything should be > reset after shutdown. Or you could use a sledgehammer approach, and do a hardware reset of the controller chip. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] reset: Add APIs to manage array of resets
On Wed 19 Jul 08:59 PDT 2017, Philipp Zabel wrote: > From: Vivek Gautam > > Many devices may want to request a bunch of resets and control them. So > it's better to manage them as an array. Add APIs to _get() an array of > reset_control, reusing the _assert(), _deassert(), and _reset() APIs for > single reset controls. Since reset controls already may control multiple > reset lines with a single hardware bit, from the user perspective, reset > control arrays are not at all different from single reset controls. > Note that these APIs don't guarantee that the reset lines managed in the > array are handled in any particular order. > > Cc: Felipe Balbi > Cc: Jon Hunter > Signed-off-by: Vivek Gautam > [p.za...@pengutronix.de: changed API to hide reset control arrays behind > struct reset_control] > Signed-off-by: Philipp Zabel This looks more or less identical to how regulators and clocks already deals with resources in bulk; see regulator_bulk_data and clk_bulk_data and their associated functions. I would really like to see that you follow this model, to make it easier for developers to work with and use the various subsystems. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe 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: [iMX6Q][CI] EHCI Low-speed device problem
Hi Alan, > On Thu, 19 Oct 2017, Lukasz Majewski wrote: > > > > > Problem: > > > > > > > > I do observe that the USB transfers are truncated - for example > > > > "Get Configuration Descriptor", which length is 34B only gets > > > > 16B from the device. > > > > > > > > I do get the "Invalid PID sequence" error and despite the > > > > > > How do you know the error is "Invalid PID sequence" and not > > > something else, like CRC error or timeout? > > > > I'm using TotalPhase USB 480 Analyzer. It shows only "Invalid PID > > sequence" as the error. When I "unroll" the > > GetConfigurationDescriptor, then all data is the same as for > > correct transmission. > > > > > > > > > DATA1 Packet received by host - the EHCI controller is not > > > > sending ACK. > > > > > > The DATA1 packets are the ones containing bytes 9-16, 25-32, and > > > so on (low speed always uses maxpacket size = 8). Since you > > > received 16 bytes, this means the host controller accepted the > > > DATA1 packet but didn't send an ACK -- that certainly would be a > > > hardware bug. > > > > I do receive 16B, but those are "comprised" of two separate IN > > transactions (8 B each). > > One such transaction is built with SETUP -> DATA1 -> ACK packets. > > > > [Please see the attached screen] > > According to the screen dump, the device sent a DATA1 packet which > the host controller did not ACK. That's a bug in the host > controller. In the next transaction, the device sent an empty DATA1 > packet instead of resending the previous data. That's a bug in the > device. > Ok. So then we do have HW issues in both sides :-). Nice... > > > Anyway, > > > this should have caused the device to retransmit the DATA1 packet > > > in response to the next IN packet (if there was one). > > > > There is IN packet sent afterwards, but it is empty. The whole > > GetConfigurationDescriptor ends with OUT ZLP > > That part is normal. Ok. > > > I'm wondering if it is feasible to manually check the XactErr bit > > and then for example order the soft USB reset (from the root hub)? > > > > Or is there any other acceptable in upstream solution? > > Not in general. For this one particular case (a short transfer for a > Get-Configuration-Descriptor request), it would be easy enough to > retry the transfer. Just put a short retry loop around the second > usb_get_descriptor() call in usb_get_configuration() in > drivers/usb/core/config.c. But similar failures at other times would > be harder to recover from. This only one case. Those errors happens also at other parts of the enumeration phase -> very often also the "Get Report Descriptor" (178 bytes in size) is truncated. This is more severe, since those errors are propagated up the USB stack and exceed the "rule of thumb" of 4 retries set by Linus back at 2005 I'm now trying to force the code from ./usb/host/ehci-q.c qh_completions() to re-execute retry_xacterr. Unfortunately, it would be hard since CI Host Controller do not set "Halt" token status (bit 6) and some extra hacks are needed. @ Fabio, Peter, is there anybody from NXP, who can I contact to get some info regarding the way this IP block works (some IP block designer/ RTL implementor)? Maybe, I could get some hints on how to look for "reserved" registers? Or alleviating the HW problem on the CI HCI side? > > 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 Anyway, many thanks for clarification. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
On Tue, Oct 17, 2017 at 1:41 AM, Minas Harutyunyan wrote: > On 10/17/2017 1:34 AM, John Stultz wrote: >> On Mon, Oct 16, 2017 at 1:36 AM, Minas Harutyunyan >> wrote: >>> On b-plug disconnect should asserted GOTGINT.SesEndDet interrupt. >>> According previously sent by you register dump (GHWCFG2 = 0x23affc70) >>> your core OTG_MODE=0. >>> Bellow fragment from programming guide on Device disconnect: >>> >>> "7.3Device Disconnection >>> The device session ends when the USB cable is disconnected or if the >>> VBUS is switched off by the Host. The >>> device disconnect flow varies depending on the value of the OTG_MODE >>> configuration parameter. >>> >>> When OTG_MODE = 0,1, or 3 >>> When OTG_MODE is set to 0,1, or 3, the device disconnect flow is as follows: >>> 1. When the USB cable is unplugged or when the VBUS is switched off by >>> the Host, the Device core >>> trigger GINTSTS.OTGInt [bit 2] interrupt bit. >>> 2. When the device application detects GINTSTS.OTGInt interrupt, it >>> checks that the >>> GOTGINT.SesEndDet (Session End Detected) bit is set to 1’b1." >>> >>> So, you should receive and handle "Session End Detected". In function >>> dwc2_handle_otg_intr() on this interrupt (in device mode) calling >>> dwc2_hsotg_disconnect() function. By adding your patch "[PATCH 3/3] usb: >>> dwc2: Fix UDC state tracking" state changed to not attached as required. >> >> >> So, on the HiKey board (using 4.14-rc5 + Vardan's patch), I'm not >> seeing the GOTGINT_SES_END_DET in dwc2_handle_otg_intr() when I remove >> the USB OTG cable. >> >> In fact, I'm not seeing any calls to dwc2_handle_otg_intr()... which >> seems... odd maybe? Any clues as to what might be going wrong then? >> >> thanks >> -john >> > Hi John Stultz, > So, on Hikey board on unplug B connector GOTGINT.SesEndDet interrupt not > asserted, instead asserted GINTSTS_CONIDSTSCHNG. Please, confirm. Correct. On B unplug, I see: dwc2_handle_conn_id_status_change_intr: ++Connector ID Status Change Interrupt++ (Host) And I never see any calls to dwc2_handle_otg_intr(). > In this case without your patch "[PATCH 1/3] usb: dwc2: Improve gadget > state disconnection handling" but by applying your patch "[PATCH 3/3] > usb: dwc2: Fix UDC state tracking": > 1. On B plug connect UDC state will be set to "configured" > 2. On B plug disconnect - "not attached". > Is it Ok for you? So this is what I expect, but I don't see it. Since without my patch, nothing seems to call disconenct when the B plug is disconnected, I still see: # cat /sys/class/udc/f72c.usb/state configured thanks -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: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey
On Wed, Oct 18, 2017 at 11:46 PM, Minas Harutyunyan
wrote:
> Could you please apply this patch. Please not apply your patch series
> "[PATCH 0/3] dwc2 fixes for edge cases on hikey" to check only below patch.
> If you confirm that this patch fix your issue with "Transaction Error"
> and " ChHltd set, but reason is unknown" I'll submit to LKML as final patch.
> Then can be applied your patch series, without patch 1/3 (changing in
> connector id status change) to correctly set UDC states.
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
> f4ef159b538e..7da22152df68 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -331,6 +331,9 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
> usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
> usbcfg &= ~(GUSBCFG_HNPCAP | GUSBCFG_SRPCAP);
>
> + /* Set HS/FS Timeout Calibration */
> + usbcfg |= GUSBCFG_TOUTCAL(7);
> +
> switch (hsotg->hw_params.op_mode) {
> case GHWCFG2_OP_MODE_HNP_SRP_CAPABLE:
> if (hsotg->params.otg_cap ==
So while using this patch and the earlier one from Vardan, I don't see
the "Transaction Error"
and " ChHltd set, but reason is unknown" messages, but I do see:
[ 272.290459] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290476] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290491] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290507] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290522] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290538] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290554] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290570] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290585] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290687] dwc2 f72c.usb: dwc2_hsotg_ep_stop_xfr: timeout DIEPINT.NAKEFF
[ 272.290702] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
[ 272.290717] dwc2 f72c.usb: Mode Mismatch Interrupt: currently
in Host mode
After which the USB eth device stops functioning.
So its not really much functional change from without the patch from
my perspective.
Additionally, I'm still not seeing any disconnect calls when removing
the B plug.
Re-adding my three patches ontop of this change and Vardan's does fix
both the UDC state handling and avoids usb devices from failing when
the board is in host mode and the /dev/usb-ffs/adb/ep0 file is closed
by adbd.
thanks
-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: [RFC usb-next v5 1/3] dt-bindings: usb: add the documentation for USB root-hub
Hi Arnd, On Wed, Oct 18, 2017 at 11:05 AM, Arnd Bergmann wrote: > On Tue, Oct 17, 2017 at 11:19 PM, Martin Blumenstingl > wrote: >>> Ok, very good! >>> is there anything else you want me to test? >>> >>> What about the same dtb when run on a kernel without your >>> patch series? Does that work as well, or are your patches >>> required to make it work? >> >> this is the only device I have which uses devicetree and a xHCI >> controller. I can test it with a dwc2 based device though if you want > > Does dwc2 also use separate nodes for the roothub? From your > description it sounds like it would not be affected by your patch. currently it doesn't use separate notes for the roothub - however, with this patch it could (although I haven't explicitly tested this) > To rephrase what I'm interested in, can you check that with your > patch series, we correctly associate a device node in DT with the > struct device in the kernel both with and without the optional > roothub node in the dtb? I can do the same tests that Neil did with SoCs that use a dwc2 controller (Amlogic Meson8m2 and Meson8b). the only SoC I have which uses a dwc3 controller is an Amlogic Meson GXL - however this won't see any devices (apart from the root-hub) without this patch > Since you used a dtb that already listed an endpoint device below > an xhci, that would answer my earlier question of whether it worked > before your patch series, and you tested that it still works with your > patches applied and the roothub node added in the dtb. Now we > just need to make sure we don't break existing dtb files that don't > have the roothub node but do have endpoint device nodes. the endpoint you're seeing is the root-hub - you can see the full .dts here: [0] maybe my patch description or documentation is not clear - could you please explain what makes you think that specifying the root-hub didn't work before (so I can update the comments where needed)? to sum up what this series does: find the node with reg = <0>; (= the root-hub) and get all PHY instances from the child-nodes this should not change any existing behavior except if someone had a node with reg = <0>; below any USB controller node (which was undocumented behavior before my patches) Regards, Martin [0] https://github.com/xdarklight/linux/blob/meson-gxl-usb-v6/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi#L55 -- To unsubscribe from this list: send the line "unsubscribe 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-next v6 0/3] initialize (multiple) PHYs on the roothub
Hi Chunfeng Yun, many thanks for your efforts (testing and explaining the Mediatek SoC implementatino) on the earlier versions of this series! On Tue, Oct 17, 2017 at 11:20 PM, Martin Blumenstingl wrote: > This series is the outcome of a discussion with Felipe Balbi, > see [0] and [1] as well as Mathias Nyman, see [7] and [8]. > The quick-summary of this is: > - dwc3 already takes one USB2 and one USB3 PHY and initializes these > correct > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and > ohci-platform.c) do not have a limitation on the number of PHYs - they > support one PHY per actual host port > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two > or three USB2 ports enabled on the internal root-hub. The SoCs also > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are > internally "connected" to the dwc3 roothub) need to be powered on, > otherwise USB devices cannot be enumerated (even if just one PHY is > disabled and if the device is plugged into another, enabled port) > > In my first attempt to get USB supported on the GXL and GXM SoCs I tried > to work-around the problem that I could not pass multiple PHYs to the > dwc3 controller. > This was rejected by Rob Herring (which was definitely the thing to do in > my opinion), see [2] > > This series adds a new "roothub PHY wrapper". This can be configured > through devicetree by passing a child-node with "reg = <0>" (in other > words: it describes the roothub) to the USB controller. > Additionally there has to be a child-node for each port on > the root-hub. Each of the child-nodes takes a "phys" and "phy-names" > property. This allows modeling the root-hub in devicetree similar to the > USB device binding (documented in devicetree/bindings/usb/usb-device.txt) > This avoids and backwards-compatibility problems (which was a concern > regardless of the solution, see [3]) since the binding for the root-hub > was previously not specified (and we're not using the "phys" property of > the controller, which might have served different purposes before, > depending on the drivers). > > Additionally this integrates the new roothub PHY wrapper into hcd.c > which automatically enables it for all USB controller drivers (tested > on an Amlogic Meson GXL SoC which uses a dwc3 controller). > > Changes since RfC v5 at [10]: > - dropped RfC prefix > - removed noisy dev_err if no roothub node was found (spotted by > Xiaolong Ye's kbuild test robot - thank you for that!) > - moved the call to usb_phy_roothub_power_off() within > hcd_bus_suspend() to make sure that the PHYs are turned off > if the "race with a root-hub wakeup event" condition is met (in > this case the PHYs are turned on again, with the old code we did > break the PHYs internal ref-counting because we never turned the > PHYs off before turning them on again in case of that special > "race with a root-hub wakeup event"). > additionally we're not handling the status returned by > usb_phy_roothub_power_off() anymore (the bus is already turned off > and we tried to turn off all PHYs as well - only the PHYs which > failed to power off will stay in the current state). > thanks to Alan Stern for the suggestion > - removed return value from usb_phy_roothub_power_off() because none > of my code uses it anymore. thanks to Alan Stern for the suggestion > > Changes since v4 at [9]: > - renamed the subject of the cover-letter (old name was: > "initialize (multiple) PHYs in xhci-plat") > - back into RFC status (see below for the reasons) > - dropped Tested-by from Chunfeng Yun (same reasons as RFC status) > - reworded cover-letter and commit messages from "platform-roothub" > to "roothub PHY wrapper" is there a chance you can test v6 of this series on the Mediatek SoCs one more time? in v5 the code was moved from xhci-plat.c to drivers/usb/core/hub.c which should even enable it on non-xHCI controllers. however, I cannot test suspend/resume support on my Meson GXL SoCs - and in addition to that it would be awesome to have confirmation from you that the latest version still works fine on the Mediatek SoCs thank you in advance! > - moved code from drivers/usb/host/platform-roothub.* to > drivers/usb/core/phy.* and the changes to > drivers/usb/host/xhci-plat.c to drivers/usb/core/hcd.c as suggested > by Mathias Nyman (as a benefit this will enable the new logic for > non-xHCI controllers as well - however this was not tested yet) > - rename the structs, function names, etc from platform_roothub_* to > usb_phy_roothub* > > Changes since RFCv3 at [6]: > - moved the DT binding change from patch #3 to patch #1 as suggested > by Rob Herring (and slightly adjusted the commit message to account > for that) > - added Tested-by from Chunfeng Yun (who confirmed that the whole > concept and implementation works fine on Mediatek SoCs - many thanks > again!) to patch #2 > - added Rob Herring's ACK to patches 1 a
Re: [RFC usb-next v5 1/3] dt-bindings: usb: add the documentation for USB root-hub
On Thu, Oct 19, 2017 at 11:25 PM, Martin Blumenstingl
wrote:
>> Does dwc2 also use separate nodes for the roothub? From your
>> description it sounds like it would not be affected by your patch.
> currently it doesn't use separate notes for the roothub - however,
> with this patch it could (although I haven't explicitly tested this)
Ok.
>> Since you used a dtb that already listed an endpoint device below
>> an xhci, that would answer my earlier question of whether it worked
>> before your patch series, and you tested that it still works with your
>> patches applied and the roothub node added in the dtb. Now we
>> just need to make sure we don't break existing dtb files that don't
>> have the roothub node but do have endpoint device nodes.
> the endpoint you're seeing is the root-hub - you can see the full .dts here:
> [0]
>
> maybe my patch description or documentation is not clear - could you
> please explain what makes you think that specifying the root-hub
> didn't work before (so I can update the comments where needed)?
> to sum up what this series does: find the node with reg = <0>; (= the
> root-hub) and get all PHY instances from the child-nodes
> this should not change any existing behavior except if someone had a
> node with reg = <0>; below any USB controller node (which was
> undocumented behavior before my patches)
Maybe I misunderstand what the actual change to the hierarchy
is. Quoting from your example for the new code
+ &usb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ roothub@0 {
+ compatible = "usb1d6b,3", "usb1d6b,2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ port@1 {
+ reg = <1>;
+ phys = <&usb2_phy1>, <&usb3_phy1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
The way I understand it, an endpoing device would now be
located in
&usb1/roothub@0/port@1/hub@2/device@1
where previously it was in
&usb1/port@1/hub@2/device@1
Is that correct?
I don't see any code that can deal with both cases and still
assign the correct of_node pointer to the device device@1 in
the end (maybe it's there and you just need to point me
to the right patch).
The reason why we have to be careful here is that the
Linux device hierarchy is not just derived from DT here, but
it gets created from the physical devices under &usb1
and the 'struct device' hierarchy has to match the DT hierarchy
exactly.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [iMX6Q][CI] EHCI Low-speed device problem
On Thu, Oct 19, 2017 at 10:25:13AM +0200, Lukasz Majewski wrote:
> Hi Peter,
>
> > On Thu, Oct 19, 2017 at 07:47:01AM +0200, Lukasz Majewski wrote:
> > > > > I'm wondering if it is feasible to manually check the XactErr
> > > > > bit and then for example order the soft USB reset (from the
> > > > > root hub)?
> > > > >
> > > > > Or is there any other acceptable in upstream solution?
> > > > >
> > > > > >
> > > > > > > The problem has been described in detail (including screen
> > > > > > > shots from USB analyzer + some further investigations) here:
> > > > > > > https://community.nxp.com/thread/462409
> > > > > >
> > > >
> > > > Lukasz, there is a known issue
> > >
> > > Could you point me to any "Errata" document describing this issue?
> > >
> > > Could you elaborate on it a bit more?
> > >
> >
> > No, it assumes PHY's power is prior to controller's initialization.
>
> Is there any particular time necessary?
I don't know, this info should from IC team, but I think 1ms is enough.
> > > > so for i.mx6, we should not use PORT_PP for PHY's power.
> > >
> > > In our design we do control (with some dedicated USB VBUS switch
> > > IC) the VBUS power with USB_H1_PWR# pin PAD_EIM_D31, which indeed
> > > is the output controlled by PORTSC1's bit 12 (PP).
> >
> > Please configure PAD_EIM_D31 as GPIO instead of USB_PWR_EN.
>
> pinctrl_usbh1_vbus: usbh1_vbus_grp {
> fsl,pins = <
> MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
> >;
> };
>
> It did not help.
>
> I've also setup the regulator API to enable VBUS and then wait ~300ms
> with stable power before we proceed with USB Host further
> initialization.
>
> reg_usbh1_vbus: usb-h1-vbus {
> compatible = "regulator-fixed";
> gpio = <&gpio3 31 GPIO_ACTIVE_LOW>;
Are you really sure it is ACTIVE_LOW?
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usbh1_vbus>;
> regulator-name = "usb_h1_vbus";
> regulator-min-microvolt = <500>;
> regulator-max-microvolt = <500>;
> regulator-enable-ramp-delay = <30>;
> };
>
> &usbh1 {
> vbus-supply = <®_usbh1_vbus>;
> }
>
> > One of USBOTG1_VBUS and USBH1_VBUS can be both USB PHY's power.
> > Usually, it doesn't matter the VBUS powers USB peripheral unless
> > the peripheral really consumes too much current, eg > 500mA, it
> > may have problem, I am not sure, I am not hardware guy.
> >
>
> Could you look into the picture attached to the earlier e-mail and
> comment on Alan's reply (especially about the lack of error indication
> fo XactErr)?
>
>
Please double confirm the VBUS supplies to SoC USB_OTG_VBUS or
USB_H1_VBUS before EHCI goes to initialization. Meanwhile, you can
try to clear USB_LDO current_ilimit bit (0x20c8120, bit 2).
For EHCI error, it is strange, I can't explain.
For hardware (or IC) support, you can consult your FAE.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
