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