On 04/17/2010 08:09 PM, Alan Stern wrote:
On Sat, 17 Apr 2010, Sumit Panchasara wrote:
On 04/16/2010 08:13 PM, Alan Stern wrote:
Which tests fail, and why? Can you provide the USB20CV test log?
Alan Stern
All tests starting from set interface fails.
I am not sure what is happening here but if I issue same clr_halt
request on source/sink eps from gadget driver (mv_udc.ko) by capturing
Is mv_udc a gadget driver or a device controller driver?
mv_udc is a device controller driver.
set_interface request then it passes (i.e. without delegating to upper
layers). Here the set interface is happens for interface 0, alt setting 0.
If I delegate it to gadgetfs.ko and subsequently reaches to user space
usb.c which when issues clr_hlt via ioctl and that when comes to
mv_udc.ko module, it fails and stall the eps. Thus all subsequent tests
fails as well.
If mv_udc were a gadget driver then it couldn't be loaded at the same
time as gadgetfs. Hence it must be a device controller driver.
I'm not sure I understand what you're saying. usb.c issues an ioctl to
do a Clear-Halt, and the Clear-Halt request is passed to mv_udc, and
the Clear-Halt fails, and as a result the endpoint gets halted. Is
that right? In other words, the Clear-Halt request ends up doing the
opposite of what it's supposed to do. If that's what you mean, it
indicates there's a bug in mv_udc.
yes, your understand it rightly... i've a very general question...
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!!!
i've changes into usb.c -- autoconfig() routine as per mv_udc controller
driver as follows:
-----------------------------------------------------------------------------------------
} else if (stat (DEVNAME = "mv_udc", &statb) == 0) {
HIGHSPEED = 1;
device_desc.bcdDevice = __constant_cpu_to_le16 (0x0200),
fs_source_desc.bEndpointAddress
= hs_source_desc.bEndpointAddress
= USB_DIR_IN | 1;
EP_IN_NAME = "ep1in";
fs_sink_desc.bEndpointAddress =
hs_sink_desc.bEndpointAddress
= USB_DIR_OUT | 2;
EP_OUT_NAME = "ep2out";
source_sink_intf.bNumEndpoints = 3;
fs_status_desc.bEndpointAddress
= hs_status_desc.bEndpointAddress
= USB_DIR_IN | 3;
EP_STATUS_NAME = "ep3in";
-----------------------------------------------------------------------------------------
Thus the source_thread refers to "ep1in" and sink thread refers to "ep2out".
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
