Re: [PATCH] ARM: multi_v7_defconfig: Select CONFIG_USB_ONBOARD_DEV as built-in

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