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@xxxxxxxxxxxx> > --- > 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
