Re: query on usb.c used for testing gadgetfs

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

 



Alan Stern <stern@...> writes:

> 
> On Mon, 19 Apr 2010, Sumit Panchasara wrote:
> 
> > can you describe the path for ioctl() from usb.c to gadgetfs.ko???
> > I mean which routine in gadgetfs.ko will get the ioctl() call from usb.c 
> > and its response back to usb.c.... ?
> > 
> > I put print in ep_ioctl() at gadgetfs but it never comes there on call 
> > to ioctl() at usb.c!!!
> 
> If you call ioctl() for the device file (endpoint 0), the call goes to
> dev_ioctl().  For any other endpoint file, the call goes to ep_ioctl().
> 
> Alan Stern
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


Stumbled across this thread and have come to the same issue.

I've traced through the ioctl() and found that it is hanging in the
get_ready_ep() in the ep_ioctl().  Specifically that the lock is not able to be
acquired on the ep1out.

This would be the same lock acquired in the pending ep_read() sitting there for
data from the host.

What would the recommend way to 'kick' this read thread be to cause it to
release the semaphore?

Thanks,
Ryan


--
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