> -----Original Message----- > From: Bjorn Andersson [mailto:bjorn.andersson@xxxxxxxxxx] > Sent: Thursday, December 14, 2017 1:37 AM > To: Loic PALLARDY <loic.pallardy@xxxxxx> > Cc: ohad@xxxxxxxxxx; linux-remoteproc@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; Arnaud POULIQUEN <arnaud.pouliquen@xxxxxx>; > benjamin.gaignard@xxxxxxxxxx > Subject: Re: [PATCH v2 03/16] remoteproc: introduce rproc_add_carveout > function > > On Thu 30 Nov 08:46 PST 2017, Loic Pallardy wrote: > > diff --git a/drivers/remoteproc/remoteproc_core.c > b/drivers/remoteproc/remoteproc_core.c > > index f23daf9..279320a 100644 > > --- a/drivers/remoteproc/remoteproc_core.c > > +++ b/drivers/remoteproc/remoteproc_core.c > > @@ -737,6 +737,7 @@ static int rproc_handle_carveout(struct rproc > *rproc, > > carveout->dma = dma; > > carveout->da = rsc->da; > > carveout->release = rproc_release_carveout; > > + carveout->priv = (void *)CARVEOUT_RSC_ALLOCATED; > > I don't fancy the (ab)use of priv to keep track of this, I also don't > see that it's ever used. Please drop it. It was to distinguish carveout defined from resource table and carveout registered by driver. But agree about priv field usage > > [..] > > +int rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry > *mem) > > +{ > > + if (!rproc || !mem) > > + return -EINVAL; > > I don't see this function doing more than adding the item to the list of > carveouts, which can't fail. So let's just rely on the user calling it > with valid references and make it return void. Ok > > > + > > + mem->priv = (void *)CARVEOUT_EXTERNAL; > > + > > + list_add_tail(&mem->node, &rproc->carveouts); > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(rproc_add_carveout); > > 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
