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
