[PATCH 1/2] remoteproc: core: Add rproc OF look-up functions

[Bjorn Andersson]

On Fri 12 Aug 09:37 PDT 2016, Suman Anna wrote:

> Hi Bjorn,
> 
> >> On 08/11/2016 02:31 AM, Lee Jones wrote:
> >>> On Wed, 10 Aug 2016, Suman Anna wrote:
> >>>
> >>>> On 08/10/2016 04:19 PM, Bjorn Andersson wrote:
> >>>>> On Wed 10 Aug 14:04 PDT 2016, Suman Anna wrote:
> >>>>>
> >>>>>> On 08/10/2016 03:40 PM, Bjorn Andersson wrote:
> >>>>>>> On Wed 10 Aug 12:37 PDT 2016, Suman Anna wrote:
> >>>>>>>
> >>>>>>>> Hi Lee, Bjorn,
> >>>>>>>>
> >>>>>>>> On 08/10/2016 12:40 PM, Bjorn Andersson wrote:
> >>>>>>>>> On Tue 19 Jul 08:49 PDT 2016, Lee Jones wrote:
> >>>>>>>>>
> >>>>>>>>>> - of_rproc_by_index(): look-up and obtain a reference to a rproc
> >>>>>>>>>>                        using the DT phandle "rprocs" and a index.
> >>>>>>>>>>
> >>>>>>>>>> - of_rproc_by_name():  lookup and obtain a reference to a rproc
> >>>>>>>>>>                        using the DT phandle "rprocs" and "rproc-names".
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Ludovic Barre <ludovic.barre at st.com>
> >>>>>>>>>> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> >>>>>>>>>> ---
> >>>>>>>>>
> >>>>>>>>> I'm happy with this, so I whipped up a binding document describing our
> >>>>>>>>> two new properties. Waiting for an opinion on that before I merge this.
> 
> One last comment on this is the return code convention change on these
> rproc_get APIs. I am fine in general with returning ERR_PTRs, but most
> of the remoteproc code is using NULL checking for rproc. If you remember
> the discussion back during the hwspinlock DT conversion [1], Ohad
> preferred to return NULL, and that's why even the rproc_get_by_phandle
> was returning NULL. We ought to make this consistent across the board if
> we want to make this switch.
> 

I think it makes sense to return the actual error from these functions,
if nothing else to keep it consistent with other frameworks.

The other case I see returning NULL is rproc_alloc(), which is think is
analog to kmalloc(), so I think that's fine to keep.


Luckily wkup_m3 is the only consumer of this API in the kernel today, so
we shouldn't have any issues wrt changing the return value here.

> regards
> Suman
> 
> [1] http://marc.info/?t=138965891200008

Regards,
Bjorn