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

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Apr 30, 2024, at 08:28, Alexander Stein wrote:
> Am Dienstag, 30. April 2024, 00:09:52 CEST schrieb Fabio Estevam:
>> Hi Arnd,
>> 
>> On Mon, Apr 8, 2024 at 11:03 AM Fabio Estevam <festevam@gmail.com> wrote:
>> >
>> > From: Fabio Estevam <festevam@denx.de>
>> >
>> > Selecting CONFIG_USB_ONBOARD_DEV as a module may cause the following
>> > run-time error when probing a USB2514 hub on a imx6q-udoo board:
>> >
>> > usb 1-1: device not accepting address 5, error -71
>> > usb usb1-port1: unable to enumerate USB device
>> >
>> > Fix this issue by selecting CONFIG_USB_ONBOARD_DEV as built-in so
>> > that the USB hub reset line and clock can be activated earlier.
>> >
>> > Signed-off-by: Fabio Estevam <festevam@denx.de>
>> > ---
>> > Here is the imx6q-udoo boot log from Mark's farm that shows the problem:
>> >
>> > https://storage.kernelci.org/next/master/next-20240408/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6dl-udoo.html
>
> Despite the change to the defconfig. If this driver causes problems when
> being built as module, shouldn't it be bool instead of tristate then?

It does sound like this is something the kernel should be able to
get to work properly in some form, but I don't think making it
a 'bool' symbol is the correct answer here: if CONFIG_USB is
set to =m, it would be impossible to include USB_ONBOARD_DEV
in this case.

Fabio, can you explain how making it built-in addresses the
problem here? I assume this is related to probe order, so I
wonder if it's just a matter of making the usb hub driver
properly handle -EPROBE_DEFER until the onboard dev has been
initialized.

     Arnd

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