Andre Wolokita
2014-10-23 01:05:02 UTC
Hi Felipe,
I'm noticing some strange behaviour in the gadgetfs driver when running
gadgetfs-test; the program fails with the error "ep0 read after poll: Invalid argument".
As far as I understand, an inode is created upon an open() call in gadgetfs-test and
an initial fops is assigned to the struct file that doesn't contain a .read member.
The .write member of this first fops points to dev_config() in usb/gadget/legacy/inode.c.
When user-space write is called for the first time, dev_config() performs a bunch of
configuration stuff before doing "fd->f_op = &ep0_io_operations;". This new
file_operations struct does contain a .read member, which points to ep0_read().
I'm confused as to why when an error occurs when a subsequent read() is called in
gadgetfs-test. I thought that changes to an fops pointer is preserved upon returning to
the user-space caller. How can it be that "fd->f_op = &ep0_io_operations;" clearly changes
the fops pointer, yet these changes aren't reflected when returning to user-space?
Regards,
Andre.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm noticing some strange behaviour in the gadgetfs driver when running
gadgetfs-test; the program fails with the error "ep0 read after poll: Invalid argument".
As far as I understand, an inode is created upon an open() call in gadgetfs-test and
an initial fops is assigned to the struct file that doesn't contain a .read member.
The .write member of this first fops points to dev_config() in usb/gadget/legacy/inode.c.
When user-space write is called for the first time, dev_config() performs a bunch of
configuration stuff before doing "fd->f_op = &ep0_io_operations;". This new
file_operations struct does contain a .read member, which points to ep0_read().
I'm confused as to why when an error occurs when a subsequent read() is called in
gadgetfs-test. I thought that changes to an fops pointer is preserved upon returning to
the user-space caller. How can it be that "fd->f_op = &ep0_io_operations;" clearly changes
the fops pointer, yet these changes aren't reflected when returning to user-space?
Regards,
Andre.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html