Hi Pali,
On Tue, 16 Nov 2021 at 20:36, Pali Rohár pali@kernel.org wrote:
Hello!
On Tuesday 16 November 2021 20:05:07 Loic Poulain wrote:
Hi Pali,
Sorry for the late reply,
On Mon, 27 Sept 2021 at 22:04, Pali Rohár pali@kernel.org wrote:
On Thursday 19 August 2021 13:13:06 Loic Poulain wrote:
This command allows to start CDC ACM function and redirect console (stdin, stdout, stderr) to USB (acmconsole start). The console can then be accessed through the USB host for debugging purpose. The host can stop the session (acmconsole stop) to revert back console to serial and unregister CDC ACM USB function.
Hello!
Could you rather implement this CDC ACM gadget in a way that calling 'setenv stdout cdc_acm' (or 'setenv stdout usbtty') would do this console redirect? Like it is supported for current usbtty or vga output code.
Then this acmconsole command would not be needed at all.
Yes, that would be good, but AFAIR I restricted this cdc_acm usage to this command because we can't have fine grained control like e.g. using cdc_acm as stdout only, when used, it should necessarily be STDIN (at least). The reason is because of the single-tasking nature of u-boot, and the fact that we need to poll the USB controller for events via the 'usb_gadget_handle_interrupts()' function.
There was already discussion that custom commands for activating drivers are against driver model design. See: https://lore.kernel.org/u-boot/20211026151742.42b0fcfa@thinkpad/
So I think that there should not be any driver specific command which just activates device (in this case console).
That's a bit different here since it's not a standard device/peripheral driver but a USB function, which is something the 'user' can decide to enable or not, all the other USB functions have dedicated commands AFAIK. It's not clear otherwise at which place we should register the acm_console? should it be unconditionally registered at init?
Regards, Loic