linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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 10:16:37 -0700	[thread overview]
Message-ID: <CAKZ8rEMGxrvfY6NeSv+3iEWAirFu9D+q-1D6=4H81mkTJGkGgQ@mail.gmail.com> (raw)
In-Reply-To: <CAOMZO5DF0UNtj1q11rYRhpRSZTxp+XLmCvOEev0d+7WO_RBERg@mail.gmail.com>

On Thu, May 2, 2024 at 3:59 PM Fabio Estevam <festevam@gmail.com> 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

Ah, from the discussion my impression was that CONFIG_USB=y and
CONFIG_USB_ONBOARD_DEV=m works, but not  CONFIG_USB=m and
CONFIG_USB_ONBOARD_DEV=m, good we clarified that.

Is the rootfs by chance on a USB device and that prevents the
onboard_usb_dev module from being loaded?

You could add debug logs to hub_probe(), onboard_dev_init() and
onboard_dev_probe() to get more information.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-03 17:17 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 [this message]
2024-05-03 17:51                       ` Fabio Estevam
2024-05-03 20:11                     ` Matthias Kaehlcke
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='CAKZ8rEMGxrvfY6NeSv+3iEWAirFu9D+q-1D6=4H81mkTJGkGgQ@mail.gmail.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).