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

[Amit Shah <amit@kernel.org>]

On Thu, 2025-02-13 at 12:55 +0100, Uwe Kleine-König wrote:
> virtio_console.c can make use of REMOTEPROC. Therefore it has several
> tests evaluating
> 
> 	IS_ENABLED(CONFIG_REMOTEPROC)
> 
> . This currently only does the right thing because CONFIG_REMOTEPROC
> cannot be modular. Otherwise the configuration
> 
> 	CONFIG_REMOTEPROC=m
> 	CONFIG_VIRTIO_CONSOLE=y
> 
> would result in a build failure because then
> IS_ENABLED(CONFIG_REMOTEPROC) evaluates to true but still the built-
> in
> virtio_console.o must not use symbols from the remoteproc module.
> 
> To prepare for making REMOTEPROC modular change the tests to use
> IS_REACHABLE() instead of IS_ENABLED() which copes correctly for the
> above case as it evaluates to false then.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> Hello,
> 
> I didn't check what else needs to be done to make CONFIG_REMOTEPROC
> tristate but even if it stays a bool using IS_REACHABLE() is still
> the
> better choice.

It might lead to a false sense of "better" -- the value of IS_ENABLED
is cached in a variable which is determined at compile-time.  That
caching, after this change, moves to driver init-time.  If the rproc
module is loaded after virtio-console is initialized, there's no way
it's going to be used.  Only if the rproc module is loaded before
virtio-console will the rproc functionality be used -- which means that
nothing changed in reality..

To properly detect and use rproc if available would need the rproc
initialization out of virtcons_probe() and into something that happens
either via sysfs for existing ports, or when adding a new port to a
device.  However, the current spec doesn't allow for that, so some more
changes will need to be made to ensure current backwards compat, and a
new specification that allows for a late init of rproc.


		Amit