Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> On Thu, Feb 18, 2021 at 10:31:15AM +0000, Ian Abbott wrote:
> > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > Fix the following warning generated by sparse:
> > > 
> > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in assignment (different address spaces)
> > > drivers/staging//comedi/comedi_fops.c:2956:23:    expected unsigned int *chanlist
> > > drivers/staging//comedi/comedi_fops.c:2956:23:    got void [noderef] <asn:1> *
> > > 
> > > compat_ptr() has a return type of "void __user *"
> > > as defined in "include/linux/compat.h"
> > > 
> > > cmd->chanlist is of type "unsigned int *" as defined
> > > in drivers/staging/comedi/comedi.h" in struct
> > > comedi_cmd.
> > > 
> > > Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com>
> > > ---
> > >   drivers/staging/comedi/comedi_fops.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c
> > > index e85a99b68f31..fc4ec38012b4 100644
> > > --- a/drivers/staging/comedi/comedi_fops.c
> > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
> > >   	cmd->scan_end_arg = v32.scan_end_arg;
> > >   	cmd->stop_src = v32.stop_src;
> > >   	cmd->stop_arg = v32.stop_arg;
> > > -	cmd->chanlist = compat_ptr(v32.chanlist);
> > > +	cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist);
> > >   	cmd->chanlist_len = v32.chanlist_len;
> > >   	cmd->data = compat_ptr(v32.data);
> > >   	cmd->data_len = v32.data_len;
> > > 
> > 
> > This patch and the other one in your series clash with commit 9d5d041eebe3
> > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > warnings") by B K Karthik.
> 
> Oh I see. Not sure if this is the right place to ask, but which tree and
> branch should one work with when messing with the code in staging/
> directory? (wanted to avoid such clashes in future)

staging-next is the best one to use from the staging.git tree.  But as
the above commit was merged in 5.9-rc1, way back in July of last year, I
have no idea what tree you are currently using to not hit that...

You should always be able to find the subsystem git trees in the
MAINTAINERS file, or if not, just work off of what is in linux-next as
that should have all subsystem's trees merged into it.

thanks,

greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel