Message-ID: <15729df921fa8718ee173963132a370de6aae9af.camel@kernel.org>
Date: Mon, 17 Feb 2025 11:59:53 +0100
From: Amit Shah <amit@...nel.org>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman
	 <gregkh@...uxfoundation.org>, virtualization@...ts.linux.dev, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] virtio: console: Prepare for making REMOTEPROC modular

On Mon, 2025-02-17 at 11:53 +0100, Amit Shah wrote:
> 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?

... I just saw that virtcons_probe() doesn't have any setup in case of
rproc.  So this last paragraph doesn't apply.

So maybe just adding some notes in the commit log about why this will
end up working, and why rproc usage and tty+multiport usage are
mutually exclusive (and fine) will help.

Thanks,

		Amit

Powered by blists - more mailing lists