On Mon, Apr 08, 2013 at 06:13:42PM +0100, Ian Abbott wrote: > On 2013-04-08 16:54, H Hartley Sweeten wrote: > >On Friday, April 05, 2013 9:52 PM, Ian Abbott wrote: > >>On 06/04/13 00:07, H Hartley Sweeten wrote: > >>>The struct file_operations (*read) and (*write) operations expect the > >>>buffer to be a __user space pointer. > >>> > >>>Currently the (*write) operations in this driver cause this warning: > >>>warning: incorrect type in argument 2 (different address spaces) > >>> expected char const [noderef] <asn:1>*<noident> > >>> got unsigned char [usertype] *buf > >>> > >>>And the (*read) operations cause this warning: > >>>warning: incorrect type in argument 2 (different address spaces) > >>> expected char [noderef] <asn:1>*<noident> > >>> got unsigned char *<noident> > >>> > >>>Use __force to cast the buffer to a __user pointer to suppress the > >>>warnings. > >> > >>The sparse warnings are probably helpful in this case. They indicate > >>the driver is doing something wrong! Using __force just masks the problem. > > > >Normally I would agree, but in this case I don't think so. > > > >The tty read/write in this driver is not directly initiated by user space and we > >don't have a __user buffer to pass to the read/write functions. > > > >I guess the kernel buffers could be copied to __user buffers, use that buffer, > >then copy the data back to the kernel buffer, but that seems like unnecessary > >overhead. > > > >Take a look at __kernel_write() in fs/read_write.c for a similar example that > >is already in the kernel. > > Okay, I suppose the set_fs(KERNEL_DS) calls let you pass kernel > memory pointers in place of user memory pointers, so the driver > isn't doing anything wrong, it's just using deep magic. It's not all that "deep", it's just ugly :( Sad that we need a serial driver to send data back into the kernel, but it kind of makes sense. greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel