Re: query on usb.c used for testing gadgetfs

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

 



On 04/15/2010 07:31 PM, Alan Stern wrote:
On Thu, 15 Apr 2010, Sumit Panchasara wrote:

Hi,

I have question regarding usb.c file available on
http://www.linux-usb.org/gadget/usb.c. I am using it to debug Ch9 tests
failures from USB20CV software running on Windows host while attaching
dev board configured as device to it.

The source code has handle_control() routine with case for SET_INTERFACE
control requests from gadgetfs module through event GADGETFS_SETUP.

Now this particular case has following lines of code:
----------------------------------------------------------------------------------------------------
if (ioctl (source_fd, GADGETFS_CLEAR_HALT)<  0) {
      status = errno;
      perror ("reset source fd");
}
if (ioctl (sink_fd, GADGETFS_CLEAR_HALT)<  0) {
      status = errno;
      perror ("reset sink fd");
}
----------------------------------------------------------------------------------------------------

My question is, if handle_control() is envoked from ep0 thread with
parent fd, what is a reason to pass "source_fd" and "sink_fd" in ioctl
calls above? Why it is not only 'fd'?
fd is the file descriptor for endpoint 0.  If fd were the first
argument to the ioctl's, the kernel would clear a halt condition on
endpoint 0.  But that isn't what the code wants to accomplish -- it
wants to clear halt conditions on the source and sink bulk endpoints.
Hence it has to pass source_fd and sink_fd to the ioctl's.

  Isn't control request handling
should be done on ep0 fd instead of source/sink fd?
Not if handling the control request requires the gadget driver to
affect other endpoints.

If I replace 'source/sink fd' with 'fd' coming with handle_control()
call, it gets captured at gadgetfs and subsequently request goes to my
dev board controller driver as well. With this I am able to pass Ch9
tests from USB20CV software running on Windows Host and configuring my
dev board as device to it.
Can you pass the Ch9 tests without changing the original code?

Is it okay to propose change as follows in usb.c file?
----------------------------------------------------------------------------------------------------
@@ -1476,13 +1476,9 @@

                  /* just reset toggle/halt for the interface's endpoints */
                  status = 0;
-               if (ioctl (source_fd, GADGETFS_CLEAR_HALT)<  0) {
+               if (ioctl (fd, GADGETFS_CLEAR_HALT)<  0) {
                          status = errno;
-                       perror ("reset source fd");
-               }
-               if (ioctl (sink_fd, GADGETFS_CLEAR_HALT)<  0) {
-                       status = errno;
-                       perror ("reset sink fd");
+                       perror ("reset fd");
                  }
                  /* FIXME eventually reset the status endpoint too */
                  if (status)
----------------------------------------------------------------------------------------------------
No, this is wrong.

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


Email Scanned for Virus&  Dangerous Content by : www.CleanMailGateway.com

No the original code does not passes ch9 tests with gadgetfs.ko and using user mode usb.c.

Although it passes all Ch9 tests with gadger zero driver (g_zero.ko) module over same dev board.

Thanks,
Sumit

--
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________

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