On Wed, Oct 29, 2014 at 09:39:20AM +1100, Andre Wolokita wrote: > Hi Felipe, > > On 28/10/14 01:26, Felipe Balbi wrote: > > Hi, > > > > On Mon, Oct 27, 2014 at 10:31:42AM +1100, Andre Wolokita wrote: > >> 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? > > > > probably a regression caused by another commit ? Can you try bisecting > > to pin-point what broke it ? Do you remember which was the last kernel > > where this worked ? > > > > I'm working on the ADI trunk of the buildroot distro and it looks like > gadgetfs (inode.c) was added during our last merge. I'll need to do some > testing on 3.17 mainline to see if this problem exists there too or if it's > restricted to our tree. I'll let you know how it goes. oh, so you never tested mainline ? Why are you reporting bugs then ? Didn't you get the memo that this support channel is *only* for latest mainline tree ? cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
