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 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? Best regards Uwe
Attachment:
signature.asc
Description: PGP signature
