shell/usb cdc_acm: shell does not work on CDC_ACM

[alexanderwachter]

The shell is not responding on USB CDC_ACM after #31880 got merged.
However, the USB serial device is still working.

I'm on a custom board with an stm32g4.
Reverting the commit from 31880 brings the shell back.

[jfischer-no]

CONFIG_SHELL_BACKEND_SERIAL_INIT_PRIORITY=51 is a possible workaround.

[pabigot]

Yes, this is at least partly due to device_get_binding() now returning null on devices that have not been initialized. We're going to need runtime equivalent to DEVICE_DT_GET() that looks up things by name regardless of whether they're ready to be used.

@galak again we should perhaps slow down on removing label properties.

[pabigot]

FWIW, I can't manage to get samples/subsys/shell/shell_module to run on a CDC ACM before or after #31880 was merged, even with updating the init priority. If anybody can provide clear instructions I'd appreciate it.

[jfischer-no]

FWIW, I can't manage to get samples/subsys/shell/shell_module to run on a CDC ACM before or after #31880 was merged, even with updating the init priority. If anybody can provide clear instructions I'd appreciate it.

I found an old patch that adds shell support to console sample, #32586

[pabigot]

I'm going to call this a configuration error, and so the issue is a question, not a bug or a regression.

The shell UART back end initializes in POST_KERNEL at CONFIG_SHELL_BACKEND_SERIAL_INIT_PRIORITY which defaults to 0.

Most UART devices initialize in PRE_KERNEL_1 at CONFIG_SHELL_BACKEND_SERIAL_INIT_PRIORITY which defaults to 50.

So everything just works as long as serial devices are initialized in an earlier init level.

But CDC ACM device initializes at POST_KERNEL at CONFIG_SHELL_BACKEND_SERIAL_INIT_PRIORITY which defaults to 50.

So the correct fix, if using CDC ACM for shell, is to increase CONFIG_SHELL_BACKEND_SERIAL_INIT_PRIORITY to at least 51 as @jfischer-no identified.

I don't see any obvious way to detect the situation and change the default.

FWIW, the solution prototyped in #32587 also makes it work, but for the same reason that it worked until device_is_ready() got fixed: the device is successfully retrieved before initialization but the operations performed on it appear to either be delayed until the device is ready, or are robust if invoked before the device has been initialized.

Making shell_uart robust in the face of UART devices that can be started late or turned off is a much larger task.

[alexanderwachter]

I can confirm that setting CONFIG_SHELL_BACKEND_SERIAL_INIT_PRIORITY=51 solves the problem. Thanks @pabigot @jfischer-no