On Tue 29 Jun 10:00 CDT 2021, Phil Chang wrote: > In some case, the remote processor already boot up on previous state, > but still need register to virtio device, so that exported those APIs. > > Signed-off-by: Phil Chang <phil.chang@xxxxxxxxxxxx> > Signed-off-by: YJ chiang <yj.chiang@xxxxxxxxxxxx> > --- > Hi > > In our case, the remote processor is already boot up in u-boot, > we don't want to boot again or load fw in driver but register to virtio > device for rpmsg. so that needs those API exported. > Furthermore, the rproc_vq_interrupt is exported, so those functions > should be exported also. > Would the recently introduces support in remoteproc for "attaching" to an already running remote processor be useful to you? If you don't need a remoteproc driver, but rather just want e.g. a platform_driver that spawns the appropriate virtio devices, wouldn't virtio_mmio work? Regards, Bjorn > thanks > > drivers/remoteproc/remoteproc_virtio.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c > index 0cc617f76068..e23658a76f5e 100644 > --- a/drivers/remoteproc/remoteproc_virtio.c > +++ b/drivers/remoteproc/remoteproc_virtio.c > @@ -425,6 +425,7 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id) > out: > return ret; > } > +EXPORT_SYMBOL(rproc_add_virtio_dev); > > /** > * rproc_remove_virtio_dev() - remove an rproc-induced virtio device > @@ -440,3 +441,4 @@ int rproc_remove_virtio_dev(struct device *dev, void *data) > unregister_virtio_device(vdev); > return 0; > } > +EXPORT_SYMBOL(rproc_remove_virtio_dev); > -- > 2.18.0 >
