On Tue 02 Nov 12:11 CDT 2021, Arnaud POULIQUEN wrote: > On 11/2/21 5:38 PM, Bjorn Andersson wrote: > > On Tue 02 Nov 08:23 PDT 2021, Arnaud POULIQUEN wrote: > >> On 11/1/21 5:57 PM, Bjorn Andersson wrote: > >>> On Fri 22 Oct 07:54 CDT 2021, Arnaud Pouliquen wrote: [..] > >>>> @@ -296,6 +298,19 @@ __poll_t rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp, > >>>> } > >>>> EXPORT_SYMBOL(rpmsg_poll); > >>>> > >>>> +/** > >>>> + * rpmsg_get_class() - get reference to the sysfs rpmsg class > >>>> + * > >>>> + * This function return the pointer to the "rpmsg" class created by the rpmsg core. > >>>> + * > >>>> + * Returns the struct class pointer > >>>> + */ > >>>> +struct class *rpmsg_get_class(void) > >>> > >>> What value does this helper function add? Can't we just expose > >>> rpmsg_class directly? > >> > >> look to me cleaner to not expose directly the rpmsg_class in rpmsg.h as this > >> variable is read only for rpmsg services. > >> > > > > The pointer is read only, but the object isn't. So I think it's cleaner > > to just share the pointer in the first place. > > > > But that said, looking at this a little bit more, I don't think there's > > any guarantee that class_create() has been executed before > > rpmsg_ctrl_probe() is being invoked. > > class_create is called in in the rpmsg_init (rpmsg_core.c). as RPMSG_CTRL and > RPMSG_CHAR depend on RPMSG config this use case should not occurs, or did I miss > something? > Specifying "depends on RPMSG" in the Kconfig doesn't directly impact the load order. But in expanding my question I realized that rpmsg_ctrl_probe() will only ever be invoked if rpmsg_ctrldev_init() was able to call register_rpmsg_drive(), which in turn depends on rpmsg_init() having initialized rpmsg_bus of the driver_register() will fail. So we should be good. Thanks, Bjorn
