[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YYLLf1/R5gJJfo/H@builder.lan>
Date: Wed, 3 Nov 2021 12:48:47 -0500
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@...s.st.com>
Cc: Ohad Ben-Cohen <ohad@...ery.com>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com, julien.massot@....bzh
Subject: Re: [PATCH v6 02/10] rpmsg: create the rpmsg class in core instead
of in rpmsg char
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
Powered by blists - more mailing lists