Re: [PATCH] virtio: console: Prepare for making REMOTEPROC modular

[Amit Shah <amit@kernel.org>]

On Fri, 2025-02-14 at 18:47 +0100, Uwe Kleine-König wrote:
> On Fri, Feb 14, 2025 at 05:55:41PM +0100, Amit Shah wrote:
> > On Fri, 2025-02-14 at 17:52 +0100, Uwe Kleine-König wrote:
> > > Hello Amit,
> > > 
> > > On Fri, Feb 14, 2025 at 05:37:52PM +0100, Amit Shah wrote:
> > > > I'm thinking of the two combinations of interest: REMOTEPROC=m,
> > > > VIRTIO_CONSOLE can be y or m.  Say virtcons_probe() happens
> > > > when
> > > > the
> > > > remoteproc module isn't yet loaded.  Even after later loading
> > > > remoteproc, virtio console won't do anything interesting with
> > > > remoteproc.
> > > 
> > > Where does the interesting thing happen if remoteproc is already
> > > loaded
> > > at that time? I'm not seeing anything interesting in that case
> > > either
> > > ...
> > 
> > The code I pointed to,
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/virtio_console.c#n1993
> > 
> > either enables remoteproc if the module is present; or it enables
> > multiport, but not both at the same time.  If remoteproc isn't
> > present
> > when this probe routine is executed, multiport might get enabled. 
> > And
> > then there's no chance for remoteproc to get enabled.
> 
> The only case where there is a difference between IS_REACHABLE and
> IS_ENABLED is:
> 
> 	CONFIG_REMOTEPROC=m
> 	CONFIG_VIRTIO_CONSOLE=y

Well, also if CONFIG_VIRTIO_CONSOLE=m; and virtio_console.ko is loaded
before remoteproc.ko.

> Iff in this case you never want to test for MULTIPORT (even though
> the
> remoteproc module might never get loaded), then my patch is wrong.
> 
> When creating the patch I thought there is a hard dependency on
> remoteproc (like calling a function that is provided by
> CONFIG_REMOTEPROC). I don't understand how the remoteproc stuff
> interacts with the virtio_console driver, is this something in
> userspace
> which then would also autoload the remoteproc module?

What's happening is that multiport and remoteproc are mutually
exclusive in the virtio_console code.

And, I'm also not sure of how remoteproc loads and configures itself. 
Does loading remoteproc cause a load of virtio_console?  How?

So - based on our discussions, I think your assumptions are:

1. remoteproc will load virtio_console when remoteproc is required
2. virtio_console will never be loaded by itself
3. General virtio_console functionality (including tty and multiport)
is never used when remoteproc is used

I think at least 3 needs more thought/justification why it's a valid
assumption.  Documenting it in the commit msg is fine.

At least assumptions 1 and 2 will cause remoteproc to not function
correctly with virtio_console, despite both of them being loaded
(because they can be loaded in the unexpected order -- virtio_console
before remoteproc).  Do you want to adjust the code so that remoteproc
queries for already-existing virtio_console.ko, triggers the code that
would otherwise be not triggered in virtcons_probe(), and makes
remoteproc functional in that case?

		Amit