[PATCH 3/3] cmd: add acmconsole command

[Pali Rohár]

On Monday 22 November 2021 11:33:15 Loic Poulain wrote:
> Hi Pali,
> 
> On Tue, 16 Nov 2021 at 20:36, Pali Rohár <pali at 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 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).
> 
> 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?

I really do not know. But for me it could make sense that activation
happens when calling standard "setenv std* cdc_acm" commands...