Performing an ioctl from the kernel-space

Question

I'm writing a kernel driver that needs to perform an ioctl on another device. I realize this is not the best way to handle the code, but this is just a temporary fix for now. I'm getting back error code -22 (Invalid argument) from my ioctl call in the function, but I don't see what could be wrong with the arguments. Here are the relevant sections of code.

#define GPIO74 "/dev/gpio/74"

struct file* gpio74FD;
  .
  .
  .
gpio74FD = filp_open(GPIO74,O_RDWR,0)
  .
  .
  .
int device_ioctl(struct inode* inode,struct file *file, unsigned int ioctl_num,unsigned long ioctl_param)
{
  .
  .
  .
ret_val = gpio74FD->f_op->ioctl(inode, gpio74FD, GPIO_CONFIG_AS_INP, 0); //returns error code -22 (Invlaid Argument)
  .
  .
  .
return ret_val;
}

I suspect it may have something to do with passing the incorrect inode here, but im not even sure how to get the correct inode if its not the one passed to ioctl from the user space.

Sorry, the title says "user-space" but the body implies kernel space. Is this correct? — JeremyP, Mar 17 '11 at 15:20
Im fairly sure that it is the inode now, as i managed to track it down to the return statement in the other module. I realise that i do need the inode of the gpio module, but im still unclear on how to get a handle to that inode — , Mar 17 '11 at 15:20
yeah that was a typo, it should say kernel space, ill fix that — , Mar 17 '11 at 15:26
can't the inode for a file be found under `gpio74FD->f_dentry->inode`? or something close to that I believe. — Will Tate, Mar 17 '11 at 15:30
ok, i wasn't sure how to get the inode exactly, but gpio74FD->f_dentry->d_inode seems to work ok. I wont know for sure if this solves my total problem until i get a chance to reflash my linux device. Thanks for pointing me in the right direction — , Mar 17 '11 at 15:45

score 1 · Answer 1 · answered Mar 18 '11 at 07:41

Since you are now very deep in "don't do that" hacking territory, adding a few printk to the gpio driver could give you some valuable info.

Another options is to avoid this horrible hack, and switch to a less harmful one : add an exported function to the gpio driver, that you can call from your own module

Performing an ioctl from the kernel-space

1 Answers1

Linked