Issue in ioctl func call of character driver.

[Chetan Nanda]

On Sat, Jun 2, 2012 at 5:45 PM, KARTHIK SEKURU <karthik.sekuru at gmail.com>wrote:

> Hi,
> I am new to kernel device drivers.
>
> I wrote a simple character driver built statically having the fops as
> shown:
>
> *static const struct file_operations mfcfpga65_usb_fops = {*
> * .owner = THIS_MODULE,*
> * .open = mfcfpga65_usb_open,*
> * .read = mfcfpga65_usb_read,*
> * .unlocked_ioctl = mfcfpga65_usb_ioctl,*
> * .release = mfcfpga65_usb_close,*
> *};*
>
> All the driver registrations are done properly.
>
> I wrote a sample application to test these drivers implementing open,read
> and ioctl calls.
>
> open and read are working fine whereas ioctl is not behaving as expected.
>
> The application code is as shown:
>
> *int main()*
> *{*
> * printf("Enterred main function : \n");*
> * int fd=0,ret=0;*
> * char buff[80]="";*
> * *
> * fd=open("/dev/usbmod",O_RDONLY);*
> * if(fd<0) *
> * {*
> * printf("fd value is less than 0\n");*
> * }*
> * *
> * printf("fd :%d\n",fd);*
> * *
> * ret=read(fd,buff,10);*
> * buff[ret]='\0';*
> *
> *
> *        printf("The commands passed are %d and
>  %d\n",IOCTL_USB_READ,IOCTL_USB_OPEN );*
> * ret = ioctl(fd,IOCTL_USB_READ);*
> * ret = ioctl(fd,IOCTL_USB_OPEN); *
> *
> *
> * close(fd);*
> *}*
>
> The cmds in ioctl are defined in seperate header file which is included in
> driver as well as in the applicatin.That definations are as shown
>
> *#define MFCFPGA65_NUM 254*
> *
> *
> *#define IOCTL_USB_OPEN           _IO(MFCFPGA65_NUM,0)*
> *#define IOCTL_USB_READ           _IO(MFCFPGA65_NUM,1)*
> *#define IOCTL_USB_WRITE          _IO(MFCFPGA65_NUM,2)*
>
>
> The IOCTL call in driver does nothing except printk in each switch case
> showing to which case statement it entered .This ioctls implementation in
> driver  is as shown below:
>
> *static long mfcfpga65_usb_ioctl(struct inode *inode, struct file *file,
> unsigned int iocmd,*
> * unsigned long ioarg)*
>

Syntax for unlocked ioctl is different then what you are using, there is no
'inode' parameter in the new syntax.
Try with the below line, hopefully it will fix the error you are getting:
*static long mfcfpga65_usb_ioctl *(struct file *file, unsigned int cmd_in,
unsigned long arg)

*{*
> *   *
> * void __user *arg = (void __user *)ioarg;*
> * unsigned int* stream;*
> * unsigned int size;*
> * *
> * printk(KERN_INFO "In IOCTL function of USB character driver with cmd as
> %d : \n",iocmd);*
> * *
> * printk(KERN_INFO "The switch case cmds are %d %d
> %d\n",IOCTL_USB_OPEN,IOCTL_USB_READ,IOCTL_USB_WRITE);*
> *
> *
> * switch (iocmd) {*
> *
> *
> * case IOCTL_USB_OPEN:*
> * *
> * printk(KERN_INFO "In IOCTL case1 of USB character driver: \n");*
> * return 0;*
> * break;*
> * *
> * case IOCTL_USB_READ:*
> * *
> * printk(KERN_INFO "In IOCTL case2 of USB character driver: \n");*
> * return 0;*
> *         break;*
> * *
> * case IOCTL_USB_WRITE:*
> * *
> * printk(KERN_INFO "In IOCTL case3 of USB character driver: \n");*
> * return 0;*
> *            break;*
> * *
> *    }*
> *}*
>
> From application i made sure that i am passing proper cmd arguments.The
> control goes to the ioctl function call in driver but doesn't go to the
> proper switch cases.
>
> This is because the iocmd argument received in the ioctl implementation is
> getting corrupted i.e eventhough from application i am passing *IOCTL_USB_READ
> , **IOCTL_USB_OPEN *parameters,when i check them in
> ioctl function in drivers the values are changed and through printk in the
> ioctl i could see that the iocmd received in the function is 4096 value
> which doesn't match to IOCTL_USB_READ or
> IOCTL_USB_OPEN.
>
> Please let me know how can the command argument passes via ioctl call in
> application is modified/corrupted before it reaches the actual ioctl
> implementation in drivers.
>
>
Thanks,
Chetan Nanda


> thanks,
> Karthik.
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120602/ed523697/attachment.html