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@xxxxxx> > >>>>>>>>>> Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx> > >>>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
