[PATCH 3/3] cmd: add acmconsole command

[Pali Rohár]

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 at 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).

> In our case
> we simply do that in the getc() function, which is only called for
> input consoles in the u-boot mainloop.

This looks like a hack in the current implementation which seems that
also misuse driver model design. At least this should be documented as
this is limitation of functionality.

> An alternative would be to have a u-boot API to register generic
> callbacks to be executed in the mainloop, but this is probably a
> different thread.

I guess that this should be discussed, so some optimal solution for
issue is chosen. Otherwise we will have there second implementation of
"usbtty", which even would not provide all functionality as original
"usbtty" code.

> Also we could possibly live with this 'bug' and simply accept that
> stdout-only configuration will be broken.
> 
> Regards,
> Loic