From: Matthias Kaehlcke <mka@chromium.org>
To: Fabio Estevam <festevam@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Alexander Stein <alexander.stein@ew.tq-group.com>,
Fabio Estevam <festevam@denx.de>,
linux-arm-kernel@lists.infradead.org,
Mark Brown <broonie@kernel.org>,
javier.carrasco@wolfvision.net
Subject: Re: [PATCH] ARM: multi_v7_defconfig: Select CONFIG_USB_ONBOARD_DEV as built-in
Date: Fri, 3 May 2024 20:11:42 +0000 [thread overview]
Message-ID: <ZjVE_i8wAn_YDird@google.com> (raw)
In-Reply-To: <CAOMZO5DF0UNtj1q11rYRhpRSZTxp+XLmCvOEev0d+7WO_RBERg@mail.gmail.com>
On Thu, May 02, 2024 at 07:58:57PM -0300, Fabio Estevam wrote:
> Hi Matthias,
>
> On Thu, May 2, 2024 at 6:45 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> > It is also not clear to me why things would be broken with
> > CONFIG_USB=y CONFIG_USB_ONBOARD_DEV=m, but not with CONFIG_USB=m. It
> > doesn't seem to be an universal issue, I can't repro it locally.
>
> This issue happens on an imx6q-udoo board.
>
> multi_v7_defconfig has CONFIG_USB=y and CONFIG_USB_ONBOARD_DEV=m:
> https://storage.kernelci.org/next/master/next-20240502/arm/multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y/gcc-10/lab-broonie/baseline-imx6q-udoo.html
>
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: new full-speed USB device number 3 using ci_hdrc
> usb 1-1: device descriptor read/64, error -71
> usb 1-1: device descriptor read/64, error -71
> usb usb1-port1: attempt power cycle
> usb 1-1: new full-speed USB device number 4 using ci_hdrc
> usb 1-1: device not accepting address 4, error -71
> usb 1-1: new full-speed USB device number 5 using ci_hdrc
> usb 1-1: device not accepting address 5, error -71
> usb usb1-port1: unable to enumerate USB device
>
> imx_v6_v7_defconfig has CONFIG_USB=y and CONFIG_USB_ONBOARD_DEV=y:
> https://storage.kernelci.org/next/master/next-20240502/arm/imx_v6_v7_defconfig/gcc-10/lab-broonie/baseline-imx6q-udoo.html
>
> In this case, the USB Wifi chip connected to the USB2514 hub is
> correctly detected:
>
> usb 1-1.3: new high-speed USB device number 3 using ci_hdrc
> usb 1-1.3: New USB device found, idVendor=148f, idProduct=5370, bcdDevice= 1.01
> usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1.3: Product: 802.11 n WLAN
> usb 1-1.3: Manufacturer: Ralink
> usb 1-1.3: SerialNumber: 1.0
Here are some debug logs from my side with CONFIG_USB_ONBOARD_DEV=m:
[ 0.755965] DBG: hub_probe: adding onboard pdevs
[ 0.756204] DBG: hub_probe: done
[ 0.756618] DBG: hub_probe: adding onboard pdevs
[ 0.756621] DBG: hub_probe: done
[ 8.094539] DBG: onboard_dev_init
[ 9.141729] DBG: onboard_dev_probe
[ 9.142237] DBG: onboard_dev_probe (done)
[ 9.142428] DBG: onboard_dev_init (done)
The root hub adds the onboard pdev at 0.75..., but the onboard_dev
module is only loaded more than 7s later (and probed even later). In
the meantime there are no errors of failed enumerations as seen on
the imx6q-udoo.
I wonder if the problem could be that the sense resistors of the hub
on the imx6q-udoo are always active and not only when the hub is
powered, indicating the controller the presence of a device, which
results in an attempt to enumerate it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-05-03 20:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 14:02 [PATCH] ARM: multi_v7_defconfig: Select CONFIG_USB_ONBOARD_DEV as built-in Fabio Estevam
2024-04-29 22:09 ` Fabio Estevam
2024-04-30 6:28 ` Alexander Stein
2024-04-30 7:52 ` Arnd Bergmann
2024-04-30 19:53 ` Fabio Estevam
2024-04-30 20:24 ` Arnd Bergmann
2024-05-01 23:04 ` Fabio Estevam
2024-05-02 14:49 ` Matthias Kaehlcke
2024-05-02 18:37 ` Arnd Bergmann
2024-05-02 21:45 ` Matthias Kaehlcke
2024-05-02 22:58 ` Fabio Estevam
2024-05-03 17:16 ` Matthias Kaehlcke
2024-05-03 17:51 ` Fabio Estevam
2024-05-03 20:11 ` Matthias Kaehlcke [this message]
2024-05-03 21:13 ` Fabio Estevam
2024-05-06 14:54 ` Matthias Kaehlcke
2024-05-06 15:04 ` Mark Brown
2024-05-06 15:58 ` Matthias Kaehlcke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjVE_i8wAn_YDird@google.com \
--to=mka@chromium.org \
--cc=alexander.stein@ew.tq-group.com \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=festevam@denx.de \
--cc=festevam@gmail.com \
--cc=javier.carrasco@wolfvision.net \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).