Re: HID device question.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 4 Sep 2011, Chris Furlough wrote:

> >> Both of these work FINE, telling me that my pointer to the function 
> >> works.
> >>
> >> Then, I register MY fops, which contains my ioctl handler:
> >
> > How do you do that?
> >
> 
> Probably the WRONG way:
> 
> sprintf(pathName, "/bus/usb/%03d/%03d", busNum, deviceNum);
> 
> if((major = register_chrdev(0, pathName, &fops)) < 0)
> {
> 	printk("Cannot register char device [%d]\n", major);
> 	return;
> }
> 
> class_foo = class_create(THIS_MODULE, "foo");
> if (IS_ERR(ptr_err = class_foo))
> {
> 	printk("class create failed\n");
> 	return;
> }
> 
> dev_foo = device_create(class_foo, NULL, MKDEV(major, 0), NULL, pathName);
> if (IS_ERR(ptr_err = dev_foo))
> {
> 	printk("device create failed\n");
> 	class_destroy(class_foo);
> 	return;
> }

I don't see how this is going to override the existing file operations 
for the USB device files.  In particular, your pathName variable has 
nothing to do with actual file paths -- it's just the name of your char 
driver.  Do you have a udev rule to manipulate the entries under 
/dev/bus/usb?

> >> I print out the inode's i_ino, and it matches what I see on the open 
> >> calls,
> >
> > How do you see the open calls?
> >
> 
> I was also claiming the .open calls as well, printing out their info, and 
> then passing them along.  Since I realized that that function existed ONLY 
> to print out data, I removed it from the fops struct.  I now only have read, 
> and ioctl.
> (When I looked at the code for usbdev_open, and saw that IT was populating 
> "file->private_data" with a variable named "ps" that it was building up, I 
> thought that was it, and that I just had to remove my .open claiming from 
> the fops, and it would all work.  Not so!  Still null.
> 
> > Does usbdev_open() get called when a usbfs file is opened?
> 
> Since I removed my claiming of the open file operation, I think it should. 
> Right? 

But the information it receives will be wrong.  The tests it uses near 
the beginning to set dev will fail, because it will be looking at your 
data structures instead of its own.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux