On Wed, Jan 29, 2025 at 10:27:45AM +0530, Ekansh Gupta wrote:
> 
> 
> 
> On 1/27/2025 9:13 PM, Dmitry Baryshkov wrote:
> > On Mon, Jan 27, 2025 at 10:12:36AM +0530, Ekansh Gupta wrote:
> >> Add structure to invoke context parameterms. This structure is meant
> > Nit: for invoke context parameters.
> 
> Ack.
> 
> >
> >> to carry invoke context specific data. This structure is passed to
> >> internal invocation call to save the data in context. Examples of
> >> data intended to part of this structure are: CRC user memory address,
> >> poll timeout for invoke call, call priority etc.
> >>
> >> Signed-off-by: Ekansh Gupta <quic_ekang...@quicinc.com>
> >> ---
> >>  drivers/misc/fastrpc.c | 138 ++++++++++++++++++++++++++++++++++-------
> >>  1 file changed, 117 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> >> index 1a936d462519..c29d5536195e 100644
> >> --- a/drivers/misc/fastrpc.c
> >> +++ b/drivers/misc/fastrpc.c
> >> @@ -254,6 +254,11 @@ struct fastrpc_invoke_ctx {
> >>    struct fastrpc_channel_ctx *cctx;
> >>  };
> >>  
> >> +struct fastrpc_ctx_args {
> >> +  struct fastrpc_invoke_args *args;
> >> +  void __user *crc;
> >> +};
> > Why do we need a separate struct? Can we use fastrpc_invoke_ctx instead?
> 
> As fastrpc_invoke_ctx structure is allocated and returned from 
> fastrpc_context_alloc
> and getting fastrpc_context_free. I was thinking of keeping the user passed
> information in a different structure.

I think we've discussed that previously: don't store user-passed
information. Parse it as necessary and then drop the user data.
This way both old and new invocation types will use the same data struct
internally.

-- 
With best wishes
Dmitry

Reply via email to