Bug in cdc-acm: variable struct usb_cdc_parsed_header h may be used uninitialized in acm_probe.

[Victor Sologoubov]

Bug in cdc-acm: variable struct usb_cdc_parsed_header h may be used
uninitialized in acm_probe.

In kernel 4.8.

/* handle quirks deadly to normal probing*/
if (quirks == NO_UNION_NORMAL)

...

goto skip_normal_probe;
}

we bypass call to

cdc_parse_cdc_header(, intf, buffer, buflen);

but later use h in

if (h.usb_cdc_country_functional_desc) { /* export the country data */


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A bug related with UPS

[Victor Porton]

If this is a bug in the UPS, you can make a workaround in Linux.

It is known that rebooting the computer helps. So there should be a way
to do the same without rebooting, automatically.

On Sat, 2016-04-16 at 12:01 -0400, Alan Stern wrote:
> On Sat, 16 Apr 2016, Victor Porton wrote:
> 
> > Sometimes my UPS (Advice) starts beeping every 20 seconds or so
> > (electricity is not turned off and the computer continues to work).
> > 
> > See
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820837
> > 
> > UPS model is Advice PRS850.
> > 
> > Note that I am NOT subscribed to this mailing list!
> 
> The error messages in your log mean that the UPS stopped replying to 
> the computer.  This seems like a bug in the UPS, not in the computer.
> 
> Also, all those messages about your keyboard being disabled and
> reconnected indicate that the cable connection between the computer
> and
> keyboard isn't very good.
> 
> Alan Stern
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A bug related with UPS

[Victor Porton]

Sometimes my UPS (Advice) starts beeping every 20 seconds or so
(electricity is not turned off and the computer continues to work).

See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820837

UPS model is Advice PRS850.

Note that I am NOT subscribed to this mailing list!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 001/001] MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER Fix trivial typo in constant name EP_MODE_AUTOREG_NONE

[Antonio Victor Hilario]

Hi, Sergei,

You are correct.  I had only thought to submit the least number of changes to 
eliminate the problem.

A better fix is to make the leading part of the names EP_MODE_AUTOREQ 
consistent for the [mode] parameter to cppi41_set_autoreq_mode( struct 
cppi41_dma_channel *cppi41_channel, unsigned mode ), as follows:

---
--- linux-3.18.29/drivers/usb/musb/musb_cppi41.c2016-03-18 
02:09:52.0 +0800
+++ linux-3.18.1/drivers/usb/musb/musb_cppi41.c 2016-03-30 19:58:31.486965871 
+0800
@@ -9,9 +9,9 @@

#define RNDIS_REG(x) (0x80 + ((x - 1) * 4))

-#define EP_MODE_AUTOREG_NONE   0
-#define EP_MODE_AUTOREG_ALL_NEOP   1
-#define EP_MODE_AUTOREG_ALWAYS 3
+#define EP_MODE_AUTOREQ_NONE   0
+#define EP_MODE_AUTOREQ_ALL_NEOP   1
+#define EP_MODE_AUTOREQ_ALWAYS 3

#define EP_MODE_DMA_TRANSPARENT 0
#define EP_MODE_DMA_RNDIS   1
@@ -396,19 +396,19 @@ static bool cppi41_configure_channel(str

/* auto req */
cppi41_set_autoreq_mode(cppi41_channel,
-   EP_MODE_AUTOREG_ALL_NEOP);
+   EP_MODE_AUTOREQ_ALL_NEOP);
} else {
musb_writel(musb->ctrl_base,
RNDIS_REG(cppi41_channel->port_num), 0);
cppi41_set_dma_mode(cppi41_channel,
EP_MODE_DMA_TRANSPARENT);
cppi41_set_autoreq_mode(cppi41_channel,
-   EP_MODE_AUTOREG_NONE);
+   EP_MODE_AUTOREQ_NONE);
}
} else {
/* fallback mode */
cppi41_set_dma_mode(cppi41_channel, EP_MODE_DMA_TRANSPARENT);
-   cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREG_NONE);
+   cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
len = min_t(u32, packet_sz, len);
}
cppi41_channel->prog_len = len;
---


> On 30 Mar 2016, at 19:29, Sergei Shtylyov 
> <sergei.shtyl...@cogentembedded.com> wrote:
> 
> Hello.
> 
> On 3/30/2016 1:56 AM, Antonio Victor Hilario wrote:
> 
>> I'd been using kernel 3.18.10-29 on a set of Beaglebone Black boards, and 
>> had found and corrected this on my local build tree.
>> 
>> Kernel build fails when the source file drivers/usb/musb/musb_cppi41.c is 
>> built, with these kernel options enabled:
>> 
>> CONFIG_USB_MUSB_HDRC=y
>> CONFIG_USB_TI_CPPI41_DMA=y
>> 
>> The build fails with these errors, due to a misspelled constant name 
>> EP_MODE_AUTOREQ_NONE:
>> 
>> drivers/usb/musb/musb_cppi41.c: In function 'cppi41_dma_channel_abort':
>> drivers/usb/musb/musb_cppi41.c:544:43: error: 'EP_MODE_AUTOREQ_NONE' 
>> undeclared (first use in this function)
>>   cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
>>   ^
>> drivers/usb/musb/musb_cppi41.c:544:43: note: each undeclared identifier is 
>> reported only once for each function it appears in
>> scripts/Makefile.build:257: recipe for target 
>> 'drivers/usb/musb/musb_cppi41.o' failed
>> make[3]: *** [drivers/usb/musb/musb_cppi41.o] Error 1
>> scripts/Makefile.build:402: recipe for target 'drivers/usb/musb' failed
>> make[2]: *** [drivers/usb/musb] Error 2
>> scripts/Makefile.build:402: recipe for target 'drivers/usb' failed
>> make[1]: *** [drivers/usb] Error 2
>> Makefile:937: recipe for target 'drivers' failed
>> 
>> Signed-off-by:  Antonio VA Hilario <avahila...@gmail.com>
>> ---
>> 
>> --- drivers/usb/musb/musb_cppi41.c   2016-03-18 02:09:52.0 +0800
>> +++ ../../linux-3.18.29/drivers/usb/musb/musb_cppi41.c   2016-02-08 
>> 13:30:43.334822382 +0800
>> @@ -541,7 +541,7 @@ static int cppi41_dma_channel_abort(stru
>>  csr &= ~MUSB_TXCSR_DMAENAB;
>>  musb_writew(epio, MUSB_TXCSR, csr);
>>  } else {
>> -cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
>> +cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREG_NONE);
> 
>  That simply doesn't make sense. Need to rename the #define, the typo is 
> there.
> 
> MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 001/001] MUSB Fix trivial typo in constant name EP_MODE_AUTOREG_NONE

[Antonio Victor Hilario]

Kernel build for an ARM target (Beaglebone Black) fails when the source file 
drivers/usb/musb/musb_cppi41.c is built, with these kernel options enabled:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_TI_CPPI41_DMA=y

The build fails with these errors, due to a misspelled constant name 
EP_MODE_AUTOREQ_NONE:

drivers/usb/musb/musb_cppi41.c: In function 'cppi41_dma_channel_abort':
drivers/usb/musb/musb_cppi41.c:544:43: error: 'EP_MODE_AUTOREQ_NONE' undeclared 
(first use in this function)
 cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
 ^
drivers/usb/musb/musb_cppi41.c:544:43: note: each undeclared identifier is 
reported only once for each function it appears in
scripts/Makefile.build:257: recipe for target 'drivers/usb/musb/musb_cppi41.o' 
failed
make[3]: *** [drivers/usb/musb/musb_cppi41.o] Error 1
scripts/Makefile.build:402: recipe for target 'drivers/usb/musb' failed
make[2]: *** [drivers/usb/musb] Error 2
scripts/Makefile.build:402: recipe for target 'drivers/usb' failed
make[1]: *** [drivers/usb] Error 2
Makefile:937: recipe for target 'drivers' failed

Signed-off-by:  Antonio VA Hilario 
---

--- drivers/usb/musb/musb_cppi41.c  2016-03-18 02:09:52.0 +0800
+++ ../../linux-3.18.29/drivers/usb/musb/musb_cppi41.c  2016-02-08 
13:30:43.334822382 +0800
@@ -541,7 +541,7 @@ static int cppi41_dma_channel_abort(stru
csr &= ~MUSB_TXCSR_DMAENAB;
musb_writew(epio, MUSB_TXCSR, csr);
} else {
-   cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
+   cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREG_NONE);

/* delay to drain to cppi dma pipeline for isoch */
udelay(250);

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB host port {,performance} issues with Beaglebone

[Victor Dodon]

Hi Felipe,

On Mon, Mar 7, 2016 at 11:13 PM, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Victor Dodon <printe...@chromium.org> writes:
>> [ text/plain ]
>> Sorry, I accidentally pressed Send
>>
>> On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon <printe...@chromium.org> wrote:
>>> Hi all,
>>>
>>> I have some performance issues with the host port on a Beaglebone
>>> board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
>>> still persists. Running a fio test with 64k random reads from a USB
>>> flash drive yields a maximum of 14402.01 KiB/s (115216.08 Kb/s). The
>>> 3.14 and 4.1 kernels where build with CONFIG_TI_CPPI41_DMA=y. I was
>>> able to get a much better performance on the client USB port by
>>> enabling fifo double buffering. Iperf over a gigabit connection and a 
>>> Ethernet
>>> to USB adapter plugged in the host port gives a maximum of 180Mbit/s with 
>>> fifo
>>> double buffering enabled for the ep1 and ep2.
>>>
>>> Are there any known performance issues in the musb driver? For my use
>>> case I need
>>> a higher bandwidth and I would like to improve the host controller,
>>> but I'm a beginner in Kernel hacking and I would appreciate some help,
>>> tips or any cues to start.
>>>
>>> I also found a few problems with the host port. For example:
>>> Using the setup described above (gigabit connection and a Ethernet
>>> to USB adapter plugged in the host port and with a running iSCSI
>>> initiator on the BB,
>>> in usb/musb/musb_core.c if I change mode_4_cfg to enable double
>>> buffering, and I restart the board while doing a dd from the disk
>>> mounted with iSCSI, the kernel stops at:
>>
>> *if I enable double buffering for both RX and TX for only for ep 1
>> then the kernel stops at:
>>
>> [  233.930764] blk_update_request: I/O error, dev sda, sector 1620736
>> [  234.451076] musb-hdrc musb-hdrc.1.auto: remove, state 1
>> [  234.469702] usb usb1: USB disconnect, device number 1
>> [  234.492716] init: iscsid main process (466) killed by TERM signal
>> [  234.510663] usb 1-1: USB disconnect, device number 2
>> [  234.533235] usb 1-1.1: USB disconnect, device number 3
>> [  234.555153] usb 1-1.3: USB disconnect, device number 4
>> [  234.586962] musb-hdrc musb-hdrc.1.auto: USB bus 1 deregistered
>> [  234.606098] reboot: Restarting system
>>
>> if I enable double buffering for RX and TX for ep 1 and 2, only when
>
> you mean you're using FIFO_RXTX ? IIRC, that's only for Isochronous
> endpoints.

No, I use:
static struct musb_fifo_cfg mode_4_cfg[] = {
{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, .mode = BUF_DOUBLE, },
{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, .mode = BUF_DOUBLE, },
{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 512,  },
{ .hw_ep_num = 2, .style = FIFO_RX, .maxpacket = 512, },
...

in the first case, and:

static struct musb_fifo_cfg mode_4_cfg[] = {
{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, .mode = BUF_DOUBLE, },
{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, .mode = BUF_DOUBLE, },
{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 512,  .mode = BUF_DOUBLE, },
{ .hw_ep_num = 2, .style = FIFO_RX, .maxpacket = 512, .mode = BUF_DOUBLE, },

in the second, with a few changes in the last endpoint to fit in 16k.

>
> I'm adding Bin (current MUSB maintainer) to see if he has anything to
> say.
>
> ps: 4.1 is still too old, can you try v4.4 or v4.5-rc6 ?

Ok, I will try the newer kernels.

Thank you very much,
Victor Dodon.

>
>> logging in to the target, the network connectivity fails, I after some
>> time I got:
>>
>> [   92.176028] udevd[98]: worker [803] /devices/platform/hos
>> t0/session1/target0:0:0/0:0:0:0/block/sda/sda1 timeout; kill it
>> [   92.190702] udevd[98]: seq 1480
>> '/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda1'
>> killed
>> [   92.202237] udevd[98]: worker [805]
>> /devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a2
>> timeout; kill it
>> [   92.216125] udevd[98]: seq 1481
>> '/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda2'
>> killed
>> [   92.226088] udevd[98]: worker [806]
>> /devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a3
>> timeout; kill it
>> [   92.240727] udevd[98]: seq 1482
>> '/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda3'
>> killed
>> [   92.252076] udevd[98]: worker [807]
>> /devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a4
>> tim

Re: USB host port {,performance} issues with Beaglebone

[Victor Dodon]

Sorry, I accidentally pressed Send

On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon <printe...@chromium.org> wrote:
> Hi all,
>
> I have some performance issues with the host port on a Beaglebone
> board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
> still persists. Running a fio test with 64k random reads from a USB
> flash drive yields a maximum of 14402.01 KiB/s (115216.08 Kb/s). The
> 3.14 and 4.1 kernels where build with CONFIG_TI_CPPI41_DMA=y. I was
> able to get a much better performance on the client USB port by
> enabling fifo double buffering. Iperf over a gigabit connection and a Ethernet
> to USB adapter plugged in the host port gives a maximum of 180Mbit/s with fifo
> double buffering enabled for the ep1 and ep2.
>
> Are there any known performance issues in the musb driver? For my use
> case I need
> a higher bandwidth and I would like to improve the host controller,
> but I'm a beginner in Kernel hacking and I would appreciate some help,
> tips or any cues to start.
>
> I also found a few problems with the host port. For example:
> Using the setup described above (gigabit connection and a Ethernet
> to USB adapter plugged in the host port and with a running iSCSI
> initiator on the BB,
> in usb/musb/musb_core.c if I change mode_4_cfg to enable double
> buffering, and I restart the board while doing a dd from the disk
> mounted with iSCSI, the kernel stops at:

*if I enable double buffering for both RX and TX for only for ep 1
then the kernel stops at:

[  233.930764] blk_update_request: I/O error, dev sda, sector 1620736
[  234.451076] musb-hdrc musb-hdrc.1.auto: remove, state 1
[  234.469702] usb usb1: USB disconnect, device number 1
[  234.492716] init: iscsid main process (466) killed by TERM signal
[  234.510663] usb 1-1: USB disconnect, device number 2
[  234.533235] usb 1-1.1: USB disconnect, device number 3
[  234.555153] usb 1-1.3: USB disconnect, device number 4
[  234.586962] musb-hdrc musb-hdrc.1.auto: USB bus 1 deregistered
[  234.606098] reboot: Restarting system

if I enable double buffering for RX and TX for ep 1 and 2, only when
logging in to the target, the network connectivity fails, I after some
time I got:

[   92.176028] udevd[98]: worker [803] /devices/platform/hos
t0/session1/target0:0:0/0:0:0:0/block/sda/sda1 timeout; kill it
[   92.190702] udevd[98]: seq 1480
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda1'
killed
[   92.202237] udevd[98]: worker [805]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a2
timeout; kill it
[   92.216125] udevd[98]: seq 1481
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda2'
killed
[   92.226088] udevd[98]: worker [806]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a3
timeout; kill it
[   92.240727] udevd[98]: seq 1482
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda3'
killed
[   92.252076] udevd[98]: worker [807]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a4
timeout; kill it
[   92.265958] udevd[98]: seq 1483
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda4'
killed
[   92.276066] udevd[98]: worker [811]
/devices/platform/host0/session1/target0:0:0/0:0:0:1/block/sdb ti
meout; kill it
[   92.290420] udevd[98]: seq 1477
'/devices/platform/host0/session1/target0:0:0/0:0:0:1/block/sdb' kill
ed
[   92.299911] udevd[98]: worker [813]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a5
timeout; kill it
[   92.314794] udevd[98]: seq 1484
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda5'
killed
[   92.326211] udevd[98]: worker [814]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a6
timeout; kill it
[   92.340026] udevd[98]: seq 1485
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda6'
killed
[   92.350116] udevd[98]: worker [815]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a7
timeout; kill it
[   92.364315] udevd[98]: seq 1486
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda7'
killed
[   92.374220] udevd[98]: worker [816]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a8
timeout; kill it
[   92.388688] udevd[98]: seq 1487
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda8'
killed
[   92.399953] udevd[98]: worker [817]
/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sd a9
timeout; kill it
[   92.413449] udevd[98]: seq 1488
'/devices/platform/host0/session1/target0:0:0/0:0:0:0/block/sda/sda9'
killed
[  110.497428] [ cut here ]
[  110.501976] WARNING: CPU: 0 PID: 842 at
../../../../../tmp/portage/sys-kernel/kernel-beaglebone-4_1-4
.1.18/work/kernel-beaglebone-4_1-4.1.18/drivers/dma/cppi41.c:611
cppi41_stop_chan+0x26c/0x2d0()
[  110.518903] Modules linked in: r8152 iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi uinpu

USB host port {,performance} issues with Beaglebone

[Victor Dodon]

Hi all,

I have some performance issues with the host port on a Beaglebone
board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
still persists. Running a fio test with 64k random reads from a USB
flash drive yields a maximum of 14402.01 KiB/s (115216.08 Kb/s). The
3.14 and 4.1 kernels where build with CONFIG_TI_CPPI41_DMA=y. I was
able to get a much better performance on the client USB port by
enabling fifo double buffering. Iperf over a gigabit connection and a Ethernet
to USB adapter plugged in the host port gives a maximum of 180Mbit/s with fifo
double buffering enabled for the ep1 and ep2.

Are there any known performance issues in the musb driver? For my use
case I need
a higher bandwidth and I would like to improve the host controller,
but I'm a beginner in Kernel hacking and I would appreciate some help,
tips or any cues to start.

I also found a few problems with the host port. For example:
Using the setup described above (gigabit connection and a Ethernet
to USB adapter plugged in the host port and with a running iSCSI
initiator on the BB,
in usb/musb/musb_core.c if I change mode_4_cfg to enable double
buffering, and I restart the board while doing a dd from the disk
mounted with iSCSI, the kernel stops at:


Kind regards,
Victor Dodon.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: storage: remove the US_DEBUG macro

[Victor Dodon]

Get rid of the US_DEBUG macro and use instead empty inline function definitions
when CONFIG_USB_STORAGE_DEBUG is not defined

Signed-off-by: Victor Dodon <dodonvic...@gmail.com>
---
 drivers/usb/storage/debug.h  | 18 +++---
 drivers/usb/storage/ene_ub6250.c |  1 -
 drivers/usb/storage/freecom.c| 12 
 drivers/usb/storage/transport.c  |  2 --
 drivers/usb/storage/usb.c|  2 +-
 5 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/storage/debug.h b/drivers/usb/storage/debug.h
index 6b365ce..50070f0 100644
--- a/drivers/usb/storage/debug.h
+++ b/drivers/usb/storage/debug.h
@@ -52,9 +52,22 @@ void usb_stor_show_sense(const struct us_data *us, unsigned 
char key,
 unsigned char asc, unsigned char ascq);
 __printf(2, 3) void usb_stor_dbg(const struct us_data *us,
 const char *fmt, ...);
-
-#define US_DEBUG(x)x
 #else
+static inline void _usb_stor_show_command(const struct us_data *us,
+  struct scsi_cmnd *srb)
+{
+}
+#define usb_stor_show_command(us, srb) \
+   do { if (0) _usb_stor_show_command(us, srb); } while (0)
+
+static inline void _usb_stor_show_sense(const struct us_data *us,
+   unsigned char key, unsigned char asc,
+   unsigned char ascq)
+{
+}
+#define usb_stor_show_sense(us, key, asc, ascq)\
+   do { if (0) _usb_stor_show_sense(us, key, asc, ascq); } while 0
+
 __printf(2, 3)
 static inline void _usb_stor_dbg(const struct us_data *us,
 const char *fmt, ...)
@@ -62,7 +75,6 @@ static inline void _usb_stor_dbg(const struct us_data *us,
 }
 #define usb_stor_dbg(us, fmt, ...) \
do { if (0) _usb_stor_dbg(us, fmt, ##__VA_ARGS__); } while (0)
-#define US_DEBUG(x)
 #endif
 
 #endif
diff --git a/drivers/usb/storage/ene_ub6250.c b/drivers/usb/storage/ene_ub6250.c
index f3cf4ce..73cfd84 100644
--- a/drivers/usb/storage/ene_ub6250.c
+++ b/drivers/usb/storage/ene_ub6250.c
@@ -2296,7 +2296,6 @@ static int ene_transport(struct scsi_cmnd *srb, struct 
us_data *us)
int result = 0;
struct ene_ub6250_info *info = (struct ene_ub6250_info *)(us->extra);
 
-   /*US_DEBUG(usb_stor_show_command(us, srb)); */
scsi_set_resid(srb, 0);
if (unlikely(!(info->SD_Status.Ready || info->MS_Status.Ready))) {
result = ene_init(us);
diff --git a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c
index 3f2b089..9c37175 100644
--- a/drivers/usb/storage/freecom.c
+++ b/drivers/usb/storage/freecom.c
@@ -44,6 +44,10 @@ MODULE_LICENSE("GPL");
 
 #ifdef CONFIG_USB_STORAGE_DEBUG
 static void pdump(struct us_data *us, void *ibuffer, int length);
+#else
+static inline void pdump(struct us_data *us, void *ibuffer, int length)
+{
+}
 #endif
 
 /* Bits of HD_STATUS */
@@ -245,7 +249,7 @@ static int freecom_transport(struct scsi_cmnd *srb, struct 
us_data *us)
memcpy (fcb->Atapi, srb->cmnd, 12);
memset (fcb->Filler, 0, sizeof (fcb->Filler));
 
-   US_DEBUG(pdump(us, srb->cmnd, 12));
+   pdump(us, srb->cmnd, 12);
 
/* Send it out. */
result = usb_stor_bulk_transfer_buf (us, opipe, fcb,
@@ -267,7 +271,7 @@ static int freecom_transport(struct scsi_cmnd *srb, struct 
us_data *us)
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
 
-   US_DEBUG(pdump(us, (void *)fst, partial));
+   pdump(us, (void *)fst, partial);
 
/* The firmware will time-out commands after 20 seconds. Some commands
 * can legitimately take longer than this, so we use a different
@@ -308,7 +312,7 @@ static int freecom_transport(struct scsi_cmnd *srb, struct 
us_data *us)
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
 
-   US_DEBUG(pdump(us, (void *)fst, partial));
+   pdump(us, (void *)fst, partial);
}
 
if (partial != 4)
@@ -365,7 +369,7 @@ static int freecom_transport(struct scsi_cmnd *srb, struct 
us_data *us)
usb_stor_dbg(us, "Waiting for status\n");
result = usb_stor_bulk_transfer_buf (us, ipipe, fst,
FCM_PACKET_LENGTH, );
-   US_DEBUG(pdump(us, (void *)fst, partial));
+   pdump(us, (void *)fst, partial);
 
if (partial != 4 || result > USB_STOR_XFER_SHORT)
return USB_STOR_TRANSPORT_ERROR;
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 5e67f63..2f883a8 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -784,9 +784,7 @@ Retry_Sense:
usb_stor_dbg

[PATCH v2] usb: storage: use usb_store_dbg instead of US_DEBUGPX

[Victor Dodon]

The US_DEBUGPX macro uses printk without specifying a kernel log level, so
the default kernel log level is used, which may not match LOGLEVEL_DEBUG
used in usb_stor_dbg. Remove the macro and use usb_store_dbg instead.

Signed-off-by: Victor Dodon <printe...@chromium.org>
--
Changes in v2:
  - Completely remove the macro instead of using printk_emit
  - Change all uses of US_DEBUGPX to usb_stor_dbg
---
 drivers/usb/storage/debug.c  | 12 
 drivers/usb/storage/debug.h  |  3 ---
 drivers/usb/storage/sddr09.c | 18 +-
 3 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/storage/debug.c b/drivers/usb/storage/debug.c
index 57bf3ad..5a12c03 100644
--- a/drivers/usb/storage/debug.c
+++ b/drivers/usb/storage/debug.c
@@ -57,7 +57,6 @@
 void usb_stor_show_command(const struct us_data *us, struct scsi_cmnd *srb)
 {
char *what = NULL;
-   int i;
 
switch (srb->cmnd[0]) {
case TEST_UNIT_READY: what = "TEST_UNIT_READY"; break;
@@ -153,10 +152,8 @@ void usb_stor_show_command(const struct us_data *us, 
struct scsi_cmnd *srb)
default: what = "(unknown command)"; break;
}
usb_stor_dbg(us, "Command %s (%d bytes)\n", what, srb->cmd_len);
-   usb_stor_dbg(us, "bytes: ");
-   for (i = 0; i < srb->cmd_len && i < 16; i++)
-   US_DEBUGPX(" %02x", srb->cmnd[i]);
-   US_DEBUGPX("\n");
+   usb_stor_dbg(us, "bytes: %*ph\n", min_t(int, srb->cmd_len, 16),
+(const unsigned char *)srb->cmnd);
 }
 
 void usb_stor_show_sense(const struct us_data *us,
@@ -174,11 +171,10 @@ void usb_stor_show_sense(const struct us_data *us,
if (what == NULL)
what = "(unknown ASC/ASCQ)";
 
-   usb_stor_dbg(us, "%s: ", keystr);
if (fmt)
-   US_DEBUGPX("%s (%s%x)\n", what, fmt, ascq);
+   usb_stor_dbg(us, "%s: %s (%s%x)\n", keystr, what, fmt, ascq);
else
-   US_DEBUGPX("%s\n", what);
+   usb_stor_dbg(us, "%s: %s\n", keystr, what);
 }
 
 void usb_stor_dbg(const struct us_data *us, const char *fmt, ...)
diff --git a/drivers/usb/storage/debug.h b/drivers/usb/storage/debug.h
index f525203..6b365ce 100644
--- a/drivers/usb/storage/debug.h
+++ b/drivers/usb/storage/debug.h
@@ -53,7 +53,6 @@ void usb_stor_show_sense(const struct us_data *us, unsigned 
char key,
 __printf(2, 3) void usb_stor_dbg(const struct us_data *us,
 const char *fmt, ...);
 
-#define US_DEBUGPX(fmt, ...)   printk(fmt, ##__VA_ARGS__)
 #define US_DEBUG(x)x
 #else
 __printf(2, 3)
@@ -63,8 +62,6 @@ static inline void _usb_stor_dbg(const struct us_data *us,
 }
 #define usb_stor_dbg(us, fmt, ...) \
do { if (0) _usb_stor_dbg(us, fmt, ##__VA_ARGS__); } while (0)
-#define US_DEBUGPX(fmt, ...)   \
-   do { if (0) printk(fmt, ##__VA_ARGS__); } while (0)
 #define US_DEBUG(x)
 #endif
 
diff --git a/drivers/usb/storage/sddr09.c b/drivers/usb/storage/sddr09.c
index b746036..79224fc 100644
--- a/drivers/usb/storage/sddr09.c
+++ b/drivers/usb/storage/sddr09.c
@@ -1102,24 +1102,24 @@ static int
 sddr09_get_wp(struct us_data *us, struct sddr09_card_info *info) {
int result;
unsigned char status;
+   const char *wp_fmt;
 
result = sddr09_read_status(us, );
if (result) {
usb_stor_dbg(us, "read_status fails\n");
return result;
}
-   usb_stor_dbg(us, "status 0x%02X", status);
if ((status & 0x80) == 0) {
info->flags |= SDDR09_WP;   /* write protected */
-   US_DEBUGPX(" WP");
+   wp_fmt = " WP";
+   } else {
+   wp_fmt = "";
}
-   if (status & 0x40)
-   US_DEBUGPX(" Ready");
-   if (status & LUNBITS)
-   US_DEBUGPX(" Suspended");
-   if (status & 0x1)
-   US_DEBUGPX(" Error");
-   US_DEBUGPX("\n");
+   usb_stor_dbg(us, "status 0x%02X%s%s%s%s\n", status, wp_fmt,
+status & 0x40 ? " Ready" : "",
+status & LUNBITS ? " Suspended" : "",
+status & 0x01 ? " Error" : "");
+
return 0;
 }
 
-- 
2.7.0.rc3.207.g0ac5344

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: storage: make US_DEBUGPX print with LOGLEVEL_DEBUG

[Victor Dodon]

On Sun, Feb 14, 2016 at 05:20:21PM -0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2016 at 04:13:43PM -0800, Victor Dodon wrote:
> > The US_DEBUGPX macro uses printk without specifying a kernel log level, so
> > the default kernel log level is used, which may not match LOGLEVEL_DEBUG
> > used in usb_stor_dbg. Use printk_emit with LOGLEVEL_DEBUG instead.
> > 
> > Signed-off-by: Victor Dodon <printe...@chromium.org>
> > ---
> >  drivers/usb/storage/debug.h | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> Can you just get rid of US_DEBUGPX() entirely please?  It shouldn't be
> needed anymore, just use usb_stor_dbg() instead.

Using usb_stor_dbg() instead of US_DEBUGPX() in
usb_stor_show_command() prints one byte per line with the full syslog
header, like this:

7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876236] Command
TEST_UNIT_READY (6 bytes)
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876242] bytes: 
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876249]  00
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876255]  00
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876261]  00
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876267]  00
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876273]  00
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876279]  00
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876285]

instead of the desired:

7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876236] Command
TEST_UNIT_READY (6 bytes)
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876242] bytes: 
7,0,Feb 16 14:30:41,ubuntu,kernel:,[  422.876249]  00 00 00 00 00 00

this is why I think the US_DEBUGPX() macro is still needed.

Regards,
Victor Dodon.

> 
> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: storage: make US_DEBUGPX print with LOGLEVEL_DEBUG

[Victor Dodon]

The US_DEBUGPX macro uses printk without specifying a kernel log level, so
the default kernel log level is used, which may not match LOGLEVEL_DEBUG
used in usb_stor_dbg. Use printk_emit with LOGLEVEL_DEBUG instead.

Signed-off-by: Victor Dodon <printe...@chromium.org>
---
 drivers/usb/storage/debug.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/storage/debug.h b/drivers/usb/storage/debug.h
index f525203..fc1c02f 100644
--- a/drivers/usb/storage/debug.h
+++ b/drivers/usb/storage/debug.h
@@ -43,6 +43,7 @@
 #define _DEBUG_H_
 
 #include 
+#include 
 
 #define USB_STORAGE "usb-storage: "
 
@@ -53,7 +54,8 @@ void usb_stor_show_sense(const struct us_data *us, unsigned 
char key,
 __printf(2, 3) void usb_stor_dbg(const struct us_data *us,
 const char *fmt, ...);
 
-#define US_DEBUGPX(fmt, ...)   printk(fmt, ##__VA_ARGS__)
+#define US_DEBUGPX(fmt, ...)   \
+   printk_emit(0, LOGLEVEL_DEBUG, NULL, 0, fmt, ##__VA_ARGS__)
 #define US_DEBUG(x)x
 #else
 __printf(2, 3)
@@ -64,7 +66,11 @@ static inline void _usb_stor_dbg(const struct us_data *us,
 #define usb_stor_dbg(us, fmt, ...) \
do { if (0) _usb_stor_dbg(us, fmt, ##__VA_ARGS__); } while (0)
 #define US_DEBUGPX(fmt, ...)   \
-   do { if (0) printk(fmt, ##__VA_ARGS__); } while (0)
+   do {\
+   if (0)  \
+   printk_emit(0, LOGLEVEL_DEBUG, NULL, 0, \
+   fmt, ##__VA_ARGS__);\
+   } while (0)
 #define US_DEBUG(x)
 #endif
 
-- 
2.7.0.rc3.207.g0ac5344

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FTDI driver in Linux

[Victor Ashik]

Please check below

15.10.2014 18:00, Johan Hovold пишет:

[ Adding linux-usb to CC. ]

On Wed, Oct 15, 2014 at 03:55:15PM +0400, Victor Ashik wrote:

Hello Johan,

Sorry for asking you directly, I found your address in the top comment of
ftdi_sio.c in Linux sources.  I think that you know a short answer to my
question. Sorry for a long explanation below, I am trying to be as specific
as possible.

I am trying to get my decade-old FTDI 8U100AX-based USB-serial converter
working with Linux. I checked that it works with NetBSD and does not work
with Linux.

On Linux I see error messages in dmesg:
[53627.263480] ftdi_sio ttyUSB0: Unable to read latency timer: -32
[53627.264295] ftdi_sio ttyUSB0: Unable to write latency timer: -32


The driver should still work even if the device doesn't support setting
the latency timer.


RX/DX leds on connected via USB-Serial analog modem are blinking very fast
and I do not get correct response from the modem to AT commands.

I am trying to realize what is going on by looking at the code. I found
that my defice may require the extra byte transmitted with the data:

https://github.com/juanfra684/netbsd-src/blob/b00c2cff78f467ead9e6468be4379e23bfc8c33f/sys/dev/usb/uftdi.c#L221

  Was that this support dropped from the code? Or was it there at all?

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/serial/ftdi_sio.c?id=refs/tags/v3.17#n1915


No, we're still supposed to support the legacy SIO type of devices,
although that code doesn't get much testing I'm afraid.

But let's start with verifying that the type is actually detected.

Could you post the kernel log from when plugging the device in along
with the lsusb -v output for it?

[83986.455025] usb 1-1.2: New USB device found, idVendor=0403, 
idProduct=8372
[83986.455029] usb 1-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[83986.455031] usb 1-1.2: Product: USB Serial Converter
[83986.455032] usb 1-1.2: Manufacturer: FTDI
[83986.455033] usb 1-1.2: SerialNumber: FT00026B
[83986.472948] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[83986.472972] usb 1-1.2: Detected SIO
[83986.472974] usb 1-1.2: Number of endpoints 2
[83986.472975] usb 1-1.2: Endpoint 1 MaxPacketSize 64
[83986.472976] usb 1-1.2: Endpoint 2 MaxPacketSize 64
[83986.472977] usb 1-1.2: Setting MaxPacketSize 64
[83986.473150] ftdi_sio ttyUSB0: Unable to read latency timer: -32
[83986.473626] ftdi_sio ttyUSB0: Unable to write latency timer: -32
[83986.473673] usb 1-1.2: FTDI USB Serial Device converter now attached 
to ttyUSB0


 Bus 001 Device 010: ID 0403:8372 Future Technology Devices 
International, Ltd FT8U100AX Serial Port

Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x0403 Future Technology Devices International, Ltd
  idProduct  0x8372 FT8U100AX Serial Port
  bcdDevice0.01
  iManufacturer   1
  iProduct2
  iSerial 3
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  2
bmAttributes 0x20
  (Missing must-be-set bit!)
  (Bus Powered)
  Remote Wakeup
MaxPower   60mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  2
  iInterface  2
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FTDI driver in Linux

[Victor Ashik]

16.10.2014 14:02, Johan Hovold пишет:

On Thu, Oct 16, 2014 at 12:47:05PM +0400, Victor Ashik wrote:

  Wed, Oct 15, 2014 at 6:00 PM, Johan Hovold jo...@kernel.org wrote:



No, we're still supposed to support the legacy SIO type of devices,
although that code doesn't get much testing I'm afraid.

But let's start with verifying that the type is actually detected.

Could you post the kernel log from when plugging the device in along
with the lsusb -v output for it?


[83986.455025] usb 1-1.2: New USB device found, idVendor=0403,
idProduct=8372
[83986.455029] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[83986.455031] usb 1-1.2: Product: USB Serial Converter
[83986.455032] usb 1-1.2: Manufacturer: FTDI
[83986.455033] usb 1-1.2: SerialNumber: FT00026B
[83986.472948] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[83986.472972] usb 1-1.2: Detected SIO


So the type is indeed detected correctly.


[83986.472974] usb 1-1.2: Number of endpoints 2
[83986.472975] usb 1-1.2: Endpoint 1 MaxPacketSize 64
[83986.472976] usb 1-1.2: Endpoint 2 MaxPacketSize 64
[83986.472977] usb 1-1.2: Setting MaxPacketSize 64
[83986.473150] ftdi_sio ttyUSB0: Unable to read latency timer: -32
[83986.473626] ftdi_sio ttyUSB0: Unable to write latency timer: -32
[83986.473673] usb 1-1.2: FTDI USB Serial Device converter now attached to
ttyUSB0


Are you able to verify if rx or tx works separately, e.g. by connecting
to a working serial port and setting up two terminal sessions? Remember
to try with flow control disabled on both ends as well.

Also could you post a log from when opening, reading/writing and closing
the device? Make sure to enable debugging in usb-serial core as well.
Using echo and cat (e.g. echo hello /dev/ttyUSB0) can suffice as
long the port has been properly set up.


[91798.346109] usbserial: unknown parameter 'debug' ignored
[91798.346489] usbcore: registered new interface driver usbserial
[91798.346512] usbcore: registered new interface driver usbserial_generic
[91798.346531] usbserial: USB Serial support registered for generic
[91803.034148] ftdi_sio: unknown parameter 'debug' ignored
[91803.034572] usbcore: registered new interface driver ftdi_sio
[91803.034695] usbserial: USB Serial support registered for FTDI USB 
Serial Device

[91803.034757] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[91803.034898] usb 1-1.2: Detected SIO
[91803.034901] usb 1-1.2: Number of endpoints 2
[91803.034902] usb 1-1.2: Endpoint 1 MaxPacketSize 64
[91803.034904] usb 1-1.2: Endpoint 2 MaxPacketSize 64
[91803.034906] usb 1-1.2: Setting MaxPacketSize 64
[91803.035940] ftdi_sio ttyUSB0: Unable to read latency timer: -32
[91803.036435] ftdi_sio ttyUSB0: Unable to write latency timer: -32
[91803.036711] usb 1-1.2: FTDI USB Serial Device converter now attached 
to ttyUSB0
[91806.063117] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set 
databits/stopbits/parity

[91806.063467] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[91806.063806] ftdi_sio ttyUSB0: urb failed to clear flow control
[91806.064545] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[91806.064914] ftdi_sio ttyUSB0: urb failed to clear flow control
[91806.065289] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[91806.065662] ftdi_sio ttyUSB0: urb failed to set to rts/cts flow control
[91806.066036] ftdi_sio ttyUSB0: failed to get modem status: -32
[91806.066414] ftdi_sio ttyUSB0: urb failed to set to rts/cts flow control
[91812.841711] ftdi_sio ttyUSB0: failed to get modem status: -32
[91812.842077] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[91812.842437] ftdi_sio ttyUSB0: urb failed to clear flow control
[91812.842788] ftdi_sio ttyUSB0: failed to get modem status: -32
[91812.843160] ftdi_sio ttyUSB0: error from flowcontrol urb

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FTDI driver in Linux

[Victor Ashik]

16.10.2014 14:02, Johan Hovold пишет:

On Thu, Oct 16, 2014 at 12:47:05PM +0400, Victor Ashik wrote:

  Wed, Oct 15, 2014 at 6:00 PM, Johan Hovold jo...@kernel.org wrote:



No, we're still supposed to support the legacy SIO type of devices,
although that code doesn't get much testing I'm afraid.

But let's start with verifying that the type is actually detected.

Could you post the kernel log from when plugging the device in along
with the lsusb -v output for it?


[83986.455025] usb 1-1.2: New USB device found, idVendor=0403,
idProduct=8372
[83986.455029] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[83986.455031] usb 1-1.2: Product: USB Serial Converter
[83986.455032] usb 1-1.2: Manufacturer: FTDI
[83986.455033] usb 1-1.2: SerialNumber: FT00026B
[83986.472948] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[83986.472972] usb 1-1.2: Detected SIO


So the type is indeed detected correctly.


[83986.472974] usb 1-1.2: Number of endpoints 2
[83986.472975] usb 1-1.2: Endpoint 1 MaxPacketSize 64
[83986.472976] usb 1-1.2: Endpoint 2 MaxPacketSize 64
[83986.472977] usb 1-1.2: Setting MaxPacketSize 64
[83986.473150] ftdi_sio ttyUSB0: Unable to read latency timer: -32
[83986.473626] ftdi_sio ttyUSB0: Unable to write latency timer: -32
[83986.473673] usb 1-1.2: FTDI USB Serial Device converter now attached to
ttyUSB0


Are you able to verify if rx or tx works separately, e.g. by connecting
to a working serial port and setting up two terminal sessions? Remember
to try with flow control disabled on both ends as well.

Also could you post a log from when opening, reading/writing and closing
the device? Make sure to enable debugging in usb-serial core as well.
Using echo and cat (e.g. echo hello /dev/ttyUSB0) can suffice as
long the port has been properly set up.

I captured a data exchange between NetBSD and a modem via USB, on NetBSD 
I issued commands:


cu -l /dev/ttyUSB0 -s 38400
AT+FCLASS?

and got a resonse:

0

OK

Here is a hex dump of a packet with letter A from host to a device:

   c0 03 12 06 01 88 ff ff 53 03 02 0c 01 00 2d 00  S.-.
0010   95 a1 3f 54 00 00 00 00 2a f4 0d 00 8d ff ff ff  ..?T*...
0020   02 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0040   05 41.A

This is an echoed A back from the modem:

   c0 03 12 06 01 88 ff ff 43 03 82 0c 01 00 2d 00  C.-.
0010   95 a1 3f 54 00 00 00 00 2a 91 0e 00 00 00 00 00  ..?T*...
0020   03 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00  
0030   00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00  
0040   31 60 41 1`A

Please check the capture file attached.
Hope this helps.


netbsd-modem-AT+FCLASS.pcapng
Description: application/pcapng

Re: 03f0:521d Hewlett-Packard (HP hs3110)

[Stanescu Victor]

Hello,

As I have started this discussion, I'd like to assure you that I'm 
willing to do any tests you want/need in order to clarify it. Even a 
teamviewer session can be an option if needed.

Thanks,
Victor

On 07/23/2014 11:52 AM, Bjørn Mork wrote:
 Lars Melin lars...@gmail.com writes:
 On 2014-07-23 04:17, Dan Williams wrote:
 On Tue, 2014-07-22 at 14:02 +, Stanescu Victor wrote:
 Hello,

 This device works perfectly with usbserial generic, loaded with forced
 vendor/product parameters. Can you please add it to the proper driver?

 T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  7 Spd=480 MxCh= 0
 D:  Ver= 2.00 Cls=ff(vend.) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
 P:  Vendor=03f0 ProdID=521d Rev=00.01
 S:  Manufacturer=Hewlett-Packard
 S:  Product=HP hs3110 HSPA+ Mobile Broadband Device
 This device appears to be a Huawei jungo-type rebrand, given the
 drivers:

 %HP3110MDMDeviceDesc% = DevInstall, USBCDCACM\VID_03F0PID_521DMI_00
 %HP3110PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_03F0PID_521DMI_01
 %HP3110DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_03F0PID_521DMI_02
 interface 3 is standard USB_CLASS_CSCID
 %HP3110ECMDeviceDesc% = ew_juwwanecm.ndi, USBCDCECM\VID_03F0PID_521DMI_04
 %HP3110GNSSDeviceDesc% = GPS_DevInstall, USBCDCACM\VID_03F0PID_521DMI_05

 03F0:541D (3114) has the same USB layout and same drivers.

 So interfaces 0, 1, 2, and 5 should be driven by 'option', and interface
 4 by one of the ECM/NCM drivers, but I'm not sure here.

 Bjorn, any idea where this one should go?  The Windows drivers make a
 distinction between ew_jucdcncm.ndi and ew_jucdcecm.ndi, and this
 device falls in the ecm part.  So not sure it's appropriate for
 huawei_cdc_ncm?

 Dan
 The interface attributes ff/02/07 is used by Huawei for QMI single
 interface (combined ctrl and data) so it should go into the qmi_wwan
 driver
 I'm sure I've asked this before, but my memory (aka Google) is
 completely useless due to too many similar, but still different,
 discussions...

 So I just have to ask again: Are we positively sure that this firmware
 supports QMI? We probably do not want to add any non-QMI device to
 qmi_wwan because that will just make things unnecessarily complicated
 for userspace.

 AFAIK, Huawei use ff/01/07 for Qualcomm ECM (i.e. QMI functions).
 ff/02/07 is, as noted above, used for Jungo ECM.  We do not know exactly
 what that means wrt management (or I do not know at least, possibly
 because I've forgotten). But what I do know is that the Jungo NCM
 products do not speak QMI.  They have an embedded AT command management
 channel instead.  Is this the same for Jungo ECM?

 The serial functions should be pretty straight forward though.  Only
 question there is whether we should add them as device specific, or make
 them vendor specific (like they are for the Huawei vendor ID)?



 Bjørn
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h����G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�

Re: 03f0:521d Hewlett-Packard

[Stanescu Victor]

victor@victor-laptop:~$ lsusb -vd 03f0:521d

Bus 002 Device 007: ID 03f0:521d Hewlett-Packard
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass  255 Vendor Specific Class
   bDeviceSubClass 2
   bDeviceProtocol 1
   bMaxPacketSize064
   idVendor   0x03f0 Hewlett-Packard
   idProduct  0x521d
   bcdDevice0.01
   iManufacturer   5 Hewlett-Packard
   iProduct4 HP hs3110 HSPA+ Mobile Broadband Device
   iSerial 0
   bNumConfigurations  2
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength  337
 bNumInterfaces  6
 bConfigurationValue 1
 iConfiguration  2 configuration 0
 bmAttributes 0xa0
   (Bus Powered)
   Remote Wakeup
 MaxPower  500mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   3
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass  2
   bInterfaceProtocol  1
   iInterface  0
   ** UNRECOGNIZED:  05 24 00 10 01
   ** UNRECOGNIZED:  04 24 02 03
   ** UNRECOGNIZED:  05 24 01 00 00
   ** UNRECOGNIZED:  05 24 06 00 00
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes3
   Transfer TypeInterrupt
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0040  1x 64 bytes
 bInterval   5
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x82  EP 2 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x01  EP 1 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber1
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass  2
   bInterfaceProtocol  2
   iInterface  0
   ** UNRECOGNIZED:  05 24 00 10 01
   ** UNRECOGNIZED:  04 24 02 02
   ** UNRECOGNIZED:  05 24 01 00 01
   ** UNRECOGNIZED:  05 24 06 01 01
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x83  EP 3 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x02  EP 2 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber2
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass  2
   bInterfaceProtocol  3
   iInterface  0
   ** UNRECOGNIZED:  05 24 00 10 01
   ** UNRECOGNIZED:  04 24 02 02
   ** UNRECOGNIZED:  05 24 01 00 02
   ** UNRECOGNIZED:  05 24 06 02 02
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x84  EP 4 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x03  EP 3 OUT
 bmAttributes2
   Transfer TypeBulk

Re: 03f0:521d Hewlett-Packard (HP hs3110)

[Stanescu Victor]

root@victor-laptop:~# modprobe qmi_wwan
root@victor-laptop:~# dmesg
[ 6005.900671] usbcore: registered new interface driver cdc_wdm
[ 6005.902682] usbcore: registered new interface driver qmi_wwan
root@victor-laptop:~# echo 03f0 521d  
/sys/bus/usb/drivers/qmi_wwan/new_id
root@victor-laptop:~# dmesg
[ 6005.900671] usbcore: registered new interface driver cdc_wdm
[ 6005.902682] usbcore: registered new interface driver qmi_wwan
[ 6023.507185] qmi_wwan 2-6:1.0: cdc-wdm0: USB WDM device
[ 6023.507419] qmi_wwan 2-6:1.0 wwan0: register 'qmi_wwan' at 
usb-:00:14.0-6, WWAN/QMI device, 02:b2:8c:7a:5d:55
[ 6023.508210] qmi_wwan: probe of 2-6:1.1 failed with error -22
[ 6023.509177] qmi_wwan: probe of 2-6:1.2 failed with error -22
[ 6023.509871] qmi_wwan 2-6:1.3: cdc-wdm1: USB WDM device
[ 6023.510099] qmi_wwan 2-6:1.3 wwan1: register 'qmi_wwan' at 
usb-:00:14.0-6, WWAN/QMI device, 02:b2:8c:7a:5d:55
[ 6023.511420] qmi_wwan 2-6:1.4: cdc-wdm2: USB WDM device
[ 6023.511604] qmi_wwan 2-6:1.4 wwan2: register 'qmi_wwan' at 
usb-:00:14.0-6, WWAN/QMI device, 58:2c:80:13:92:63
[ 6023.512094] qmi_wwan: probe of 2-6:1.5 failed with error -22
root@victor-laptop:~# ifconfig -a
[...]
wwan0 Link encap:Ethernet  HWaddr 02:b2:8c:7a:5d:55
   BROADCAST MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wwan1 Link encap:Ethernet  HWaddr 02:b2:8c:7a:5d:55
   BROADCAST MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wwan2 Link encap:Ethernet  HWaddr 58:2c:80:13:92:63
   BROADCAST MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@victor-laptop:~# qmicli -d /dev/cdc-wdm0 --device-open-version-info 
--wds-noop
error: couldn't open the QmiDevice: Transaction timed out
root@victor-laptop:~# echo -e ATI\r  /dev/cdc-wdm0
root@victor-laptop:~# cat /dev/cdc-wdm0
[frozen]

On 07/23/2014 12:16 PM, Bjørn Mork wrote:
 cat /dev/cdc-wdm0

Re: 03f0:521d Hewlett-Packard (HP hs3110)

[Stanescu Victor]

/dev/cdc-wdm2 doesn't work. Further more, instead of freezing at cat, it 
freezes from echo.

Ctrl-c doesn't stop the frozen echo.

On 07/23/2014 12:45 PM, Bjørn Mork wrote:
 Stanescu Victor victor.stane...@gtsce.com writes:

 root@victor-laptop:~# modprobe qmi_wwan
 root@victor-laptop:~# dmesg
 [ 6005.900671] usbcore: registered new interface driver cdc_wdm
 [ 6005.902682] usbcore: registered new interface driver qmi_wwan
 root@victor-laptop:~# echo 03f0 521d 
 /sys/bus/usb/drivers/qmi_wwan/new_id
 root@victor-laptop:~# dmesg
 [ 6005.900671] usbcore: registered new interface driver cdc_wdm
 [ 6005.902682] usbcore: registered new interface driver qmi_wwan
 [ 6023.507185] qmi_wwan 2-6:1.0: cdc-wdm0: USB WDM device
 [ 6023.507419] qmi_wwan 2-6:1.0 wwan0: register 'qmi_wwan' at
 usb-:00:14.0-6, WWAN/QMI device, 02:b2:8c:7a:5d:55
 Right.  I was hoping you would have the usb-serial driver bound to this
 and the other serial functions so you avoided this.  But it's not really
 a problem, just a bit confusing.  You have to adjust the tests a bit.


 [ 6023.508210] qmi_wwan: probe of 2-6:1.1 failed with error -22
 [ 6023.509177] qmi_wwan: probe of 2-6:1.2 failed with error -22
 [ 6023.509871] qmi_wwan 2-6:1.3: cdc-wdm1: USB WDM device
 [ 6023.510099] qmi_wwan 2-6:1.3 wwan1: register 'qmi_wwan' at
 usb-:00:14.0-6, WWAN/QMI device, 02:b2:8c:7a:5d:55
 [ 6023.511420] qmi_wwan 2-6:1.4: cdc-wdm2: USB WDM device
 [ 6023.511604] qmi_wwan 2-6:1.4 wwan2: register 'qmi_wwan' at
 usb-:00:14.0-6, WWAN/QMI device, 58:2c:80:13:92:63

 This is the only possible candidate.  So you should do all testing on
 the wwan2 and /dev/cdc-wdm2 devices.

 root@victor-laptop:~# qmicli -d /dev/cdc-wdm0 --device-open-version-info
 --wds-noop
 error: couldn't open the QmiDevice: Transaction timed out
 root@victor-laptop:~# echo -e ATI\r  /dev/cdc-wdm0
 root@victor-laptop:~# cat /dev/cdc-wdm0
 [frozen]
 Please repeat this using the /dev/cdc-wdm2 instead.  The frozen output
 can be cancelled by ctrl+C



 Bjørn
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h����G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�

Re: 03f0:521d Hewlett-Packard

[Stanescu Victor]

Unfortunately this did nothing. Not even some dmesg output.

I have tried restarting network-manager but there was also nothing.

I don't have a wwan interface by default. Only when manually loading 
usbserial I can wwdial using pppd (manually).

On 07/23/2014 12:29 PM, Bjørn Mork wrote:
 Stanescu Victor victor.stane...@gtsce.com writes:

 victor@victor-laptop:~$ lsusb -vd 03f0:521d
 [..]
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber4
 bAlternateSetting   1
 bNumEndpoints   3

 Yup, there's the expected 3 endpoint altsetting.



 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength  129
   bNumInterfaces  3
   bConfigurationValue 2
   iConfiguration  3 configuration 1
   bmAttributes 0xa0
 (Bus Powered)
 Remote Wakeup
   MaxPower  500mA
   Interface Association:
 bLength 8
 bDescriptorType11
 bFirstInterface 0
 bInterfaceCount 2
 bFunctionClass  2 Communications
 bFunctionSubClass  14
 bFunctionProtocol   0
 iFunction   0
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   1
 bInterfaceClass 2 Communications
 bInterfaceSubClass 14
 bInterfaceProtocol  0
 iInterface  0
 CDC Header:
   bcdCDC   1.10
 CDC MBIM:
   bcdMBIMVersion   1.00
   wMaxControlMessage   1024
   bNumberFilters   16
   bMaxFilterSize   20
   wMaxSegmentSize  1500
   bmNetworkCapabilities 0x20
 8-byte ntb input size
 And this was what I was hoping for in the 2nd configuration.  You should
 be able to use this with the cdc_mbim driver and a very recent
 ModemMananager without adding any device IDs.

 But I don't understand how you ended up with Linux selecting cfg #1 by
 default? I thought Linux would prefer cfg #2 here because the first
 interface has a proper class.  Strange.  In any case, you should be able
 to switch to it by using

   echo 2   /sys/bus/usb/devices/x-y/bConfigurationValue

 where 'x-y' is the bus and port the device is connected to.



 Bjørn

03f0:521d Hewlett-Packard

[Stanescu Victor]

Hello,

This device works perfectly with usbserial generic, loaded with forced 
vendor/product parameters. Can you please add it to the proper driver?

T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
P:  Vendor=03f0 ProdID=521d Rev=00.01
S:  Manufacturer=Hewlett-Packard
S:  Product=HP hs3110 HSPA+ Mobile Broadband Device
C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 
Driver=usbserial_generic
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=02 
Driver=usbserial_generic
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=03 
Driver=usbserial_generic
I:  If#= 3 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 
Driver=usbserial_generic
I:  If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=07 Driver=(none)
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 
Driver=usbserial_generic

Thanks,
Victor Stanescu--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Nokia 305 should be treated as unusual dev.

[Victor A. Santos]

Asha 305 as 502 should be treated as unusual 'US_FL_MAX_SECTORS_64'.


diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index f4a8229..6eee0ce 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -234,6 +234,13 @@ UNUSUAL_DEV(  0x0421, 0x0495, 0x0370, 0x0370,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_MAX_SECTORS_64 ),
 
+/* Patch submitted by Victor A. Santos victoraur.san...@gmail.com */
+UNUSUAL_DEV(  0x0421, 0x05af, 0x0742, 0x0742,
+   Nokia,
+   305,
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_MAX_SECTORS_64),
+
 /* Patch submitted by Mikhail Zolotaryov le...@lebon.org.ua */
 UNUSUAL_DEV(  0x0421, 0x06aa, 0x1110, 0x1110,
Nokia,


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Nokia 305 should be treated as unusual dev.

[Victor A. Santos]

On Sat, 2014-04-26 at 08:08 -0700, Greg KH wrote:
 On Sat, Apr 26, 2014 at 11:00:52AM -0300, Victor A. Santos wrote:
  Asha 305 as 502 should be treated as unusual 'US_FL_MAX_SECTORS_64'.
  
  
  diff --git a/drivers/usb/storage/unusual_devs.h
  b/drivers/usb/storage/unusual_devs.h
  index f4a8229..6eee0ce 100644
  --- a/drivers/usb/storage/unusual_devs.h
  +++ b/drivers/usb/storage/unusual_devs.h
  @@ -234,6 +234,13 @@ UNUSUAL_DEV(  0x0421, 0x0495, 0x0370, 0x0370,
  USB_SC_DEVICE, USB_PR_DEVICE, NULL,
  US_FL_MAX_SECTORS_64 ),
   
  +/* Patch submitted by Victor A. Santos victoraur.san...@gmail.com */
  +UNUSUAL_DEV(  0x0421, 0x05af, 0x0742, 0x0742,
  +   Nokia,
  +   305,
  +   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
  +   US_FL_MAX_SECTORS_64),
  +
   /* Patch submitted by Mikhail Zolotaryov le...@lebon.org.ua */
   UNUSUAL_DEV(  0x0421, 0x06aa, 0x1110, 0x1110,
  Nokia,
  
 
 
 I need a Signed-off-by: line in order to be able to apply this to the
 kernel tree.  See the kernel file, Documentation/SubmittingPatches for
 what this means, and then can you resend it, with that information?
 
 thanks,
 
 greg k-h

diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index f4a8229..6eee0ce 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -234,6 +234,13 @@ UNUSUAL_DEV(  0x0421, 0x0495, 0x0370, 0x0370,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_MAX_SECTORS_64 ),
 
+/* Patch submitted by Victor A. Santos victoraur.san...@gmail.com */
+UNUSUAL_DEV(  0x0421, 0x05af, 0x0742, 0x0742,
+   Nokia,
+   305,
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_MAX_SECTORS_64),
+
 /* Patch submitted by Mikhail Zolotaryov le...@lebon.org.ua */
 UNUSUAL_DEV(  0x0421, 0x06aa, 0x1110, 0x1110,
Nokia,

Signed-off-by: Victor A. Santos victoraur.san...@gmail.com

-- 
Victor A. Santos victoraur.san...@gmail.com

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Nokia 305 should be treated as unusual dev

[Victor A. Santos]

Signed-off-by: Victor A. Santos victoraur.san...@gmail.com
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index f4a8229..6eee0ce 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -234,6 +234,13 @@ UNUSUAL_DEV(  0x0421, 0x0495, 0x0370, 0x0370,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_MAX_SECTORS_64 ),
 
+/* Patch submitted by Victor A. Santos victoraur.san...@gmail.com */
+UNUSUAL_DEV(  0x0421, 0x05af, 0x0742, 0x0742,
+   Nokia,
+   305,
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_MAX_SECTORS_64),
+
 /* Patch submitted by Mikhail Zolotaryov le...@lebon.org.ua */
 UNUSUAL_DEV(  0x0421, 0x06aa, 0x1110, 0x1110,
Nokia,



--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 It looks like you didn't add the dump_stack() call to the UDC driver's
 queue function.  You need to add it.

The attached is the log of dump_stack() call in the UDC driver queue
function, for the last few USB request in the USBCV device descriptor
test – addressed state. From the log, after Set-Config request is
received, the UDC driver queue function is not called. That function
is called after Get-Config request is received.

 I also share the pseudo code of the setup data valid processing, i
 suspect it may be related to the problem:

 receive setup data valid interrupt
 find out the usb request field (bmRequestType, bRequest, wValue,
 wIndex, wLength)
 if (USB_CLEAR_FEATURE_REQUEST)
   call usb_ep_queue()

 Don't you need to handle this in the hardware, just like
 USB_SET_FEATURE_REQUEST?

USB_SET_FEATURE_REQUEST is handled in software.

Thanks,
victor
[   83.61] : 80 06 00 02 00 00 09 00
[   83.61] fsg_setup call ep0_queue Backtrace: 
[   83.61] [c020c0fc] (dump_backtrace+0x0/0x110) from [c03eee04] 
(dump_stack+0x18/0x1c)
[   83.61]  r6:0002 r5:c0d6f600 r4:c0da69c0 r3:bf02fa10
[   83.61] [c03eedec] (dump_stack+0x0/0x1c) from [bf02fa2c] 
(kagen2_ep_queue+0x1c/0x7b4 [kagen2_udc])
[   83.61] [bf02fa10] (kagen2_ep_queue+0x0/0x7b4 [kagen2_udc]) from 
[bf0390b8] (ep0_queue+0x28/0x60 [g_file_storage])
[   83.61] [bf039090] (ep0_queue+0x0/0x60 [g_file_storage]) from 
[bf038e10] (fsg_setup+0x3a0/0x3d8 [g_file_storage])
[   83.61]  r5:c0e23e98 r4:c0d6f600
[   83.61] [bf038a70] (fsg_setup+0x0/0x3d8 [g_file_storage]) from 
[bf02f8c0] (kagen2_irq+0x388/0x4d8 [kagen2_udc])
[   83.61] [bf02f538] (kagen2_irq+0x0/0x4d8 [kagen2_udc]) from 
[c0249644] (handle_irq_event_percpu+0x30/0x178)
[   83.61]  r7:0020 r6: r5:c049af70 r4:c0da6840
[   83.61] [c0249614] (handle_irq_event_percpu+0x0/0x178) from 
[c02497ec] (handle_irq_event+0x60/0x7c)
[   83.61] [c024978c] (handle_irq_event+0x0/0x7c) from [c024bcac] 
(handle_edge_irq+0x114/0x16c)
[   83.61]  r6:f5006000 r5: r4:c049af70 r3:f5006000
[   83.61] [c024bb98] (handle_edge_irq+0x0/0x16c) from [c0249054] 
(generic_handle_irq+0x28/0x38)
[   83.61]  r4:0020 r3:c024bb98
[   83.61] [c024902c] (generic_handle_irq+0x0/0x38) from [c0209c2c] 
(handle_IRQ+0x68/0x8c)
[   83.61]  r4:0020 r3:0040
[   83.61] [c0209bc4] (handle_IRQ+0x0/0x8c) from [c0208410] 
(asm_do_IRQ+0x10/0x14)
[   83.61]  r5:0013 r4:bf02f500
[   83.61] [c0208400] (asm_do_IRQ+0x0/0x14) from [c0208f14] 
(__irq_svc+0x34/0xbc)
[   83.61] Exception stack(0xc0e23f60 to 0xc0e23fa8)
[   83.61] 3f60:  4000 0288001f c2886000 c0df2c00 c0df2c00 
bf02f4d8 0013
[   83.61] 3f80:    c0e23fbc c0e22000 c0e23fa8 
4001 bf02f500
[   83.61] 3fa0: 0013 
[   83.61] [bf02f4d8] (chkbusy_thread+0x0/0x60 [kagen2_udc]) from 
[c022f868] (kthread+0x94/0xa0)
[   83.61]  r4:c0d75d58 r3:
[   83.61] [c022f7d4] (kthread+0x0/0xa0) from [c021913c] 
(do_exit+0x0/0x6f0)
[   83.61]  r6:c021913c r5:c022f7d4 r4:c0d75d58
[   83.61] ept0 in queue len 0x9, buffer 0xc0d6f800
[   83.61] : 09 02 20 00 01 01 04 c0 01
[   83.62] : 80 08 00 00 00 00 01 00
[   83.62] g_file_storage gadget: get configuration 1 1
[   83.62] fsg_setup call ep0_queue Backtrace: 
[   83.62] [c020c0fc] (dump_backtrace+0x0/0x110) from [c03eee04] 
(dump_stack+0x18/0x1c)
[   83.62]  r6:c0da69c0 r5:c0d6f600 r4:c0da69c0 r3:bf02fa10
[   83.62] [c03eedec] (dump_stack+0x0/0x1c) from [bf02fa2c] 
(kagen2_ep_queue+0x1c/0x7b4 [kagen2_udc])
[   83.62] [bf02fa10] (kagen2_ep_queue+0x0/0x7b4 [kagen2_udc]) from 
[bf0390b8] (ep0_queue+0x28/0x60 [g_file_storage])
[   83.62] [bf039090] (ep0_queue+0x0/0x60 [g_file_storage]) from 
[bf038e10] (fsg_setup+0x3a0/0x3d8 [g_file_storage])
[   83.62]  r5:c0e23e98 r4:c0d6f600
[   83.62] [bf038a70] (fsg_setup+0x0/0x3d8 [g_file_storage]) from 
[bf02f8c0] (kagen2_irq+0x388/0x4d8 [kagen2_udc])
[   83.62] [bf02f538] (kagen2_irq+0x0/0x4d8 [kagen2_udc]) from 
[c0249644] (handle_irq_event_percpu+0x30/0x178)
[   83.62]  r7:0020 r6: r5:c049af70 r4:c0da6840
[   83.62] [c0249614] (handle_irq_event_percpu+0x0/0x178) from 
[c02497ec] (handle_irq_event+0x60/0x7c)
[   83.62] [c024978c] (handle_irq_event+0x0/0x7c) from [c024bcac] 
(handle_edge_irq+0x114/0x16c)
[   83.62]  r6:f5006000 r5: r4:c049af70 r3:f5006000
[   83.62] [c024bb98] (handle_edge_irq+0x0/0x16c) from [c0249054] 
(generic_handle_irq+0x28/0x38)
[   83.62]  r4:0020 r3:c024bb98
[   83.62] [c024902c] (generic_handle_irq+0x0/0x38) from [c0209c2c] 
(handle_IRQ+0x68/0x8c)
[   83.62]  r4:0020 r3:0040
[   83.62] [c0209bc4] (handle_IRQ+0x0/0x8c) from [c0208410] 
(asm_do_IRQ+0x10/0x14)
[   83.62]  r5:0013 r4:bf02f500
[   83.62] [c0208400] (asm_do_IRQ+0x0/0x14

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 The text capture is incomplete.  It is missing lots of packets.  In
 particular, it is missing all the packets between 202489 and 202502.

The missing packets are NAK, I added the NAK after Set-Config setup
stage. I hide the NAK when i export the packet capture to text format.

 Also, I don't understand the Dir H(S) part of the capture lines.
 What do they mean?  They are present on every packet.

Dir stands for direction, H is high speed, S is super speed.

 This was never the issue.  I'm sure the DATA1 packet of the Set-Config
 was sent before the Get-Config request.  The real question is whether
 the DATA1 packet was sent before the Set-Config request had been fully
 processed.

 To get more information, try adding

 msleep(100);

 just before the final return rc; line in do_set_config().  We should
 be able to see in the analyzer log if this 100-ms delay is present.

After i added msleep(100) just before final line in do_set_config(),
the USB enumeration fails to complete normally.

 Here's a second test you can try.  In handle_exception(), the
 FSG_STATE_CONFIG_CHANGE case, comment out the

 ep0_queue(fsg);

 line.  Without that line the Set-Config request should time out,
 because the gadget will never complete the status stage.  If the
 request does complete normally, it will prove that the UDC driver isn't
 working right.

After i comment out the ep0_queue(fsg) in FSG_STATE_CONFIG_CHANGE case
of handle_exception(), the request does complete, but takes more time
to complete. And UDC driver queue function is still being called after
the Set-Config request.

Thanks,
Victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Low performance of g_mass_storage virtual usb device

[Victor Leschuk]

Hello all,

I have recently faced a performance problem with usb gadget emulated
USB flash drive. It is working fine except for very low performance.

I use a 4Gb file, created by dd and created a ext2 or vfat (tried
both) partition on it. Than I mount it using the following command
sequence:

--
# modprobe dummy_hcd is_super_speed=1 # I tried is_high_speed=1, and
no parameter too
# modprobe g_mass_storage file=/home/del/img/flash stall=0 # tried w/o
stall=0 too
# mount /dev/sdc1 /mnt/tmp
--

After that I get /dev/sdc and /dev/sdc1 devices created without any
errors in dmesg:

--
[1256700.986581] usb 3-1: reset high-speed USB device number 5 using dummy_hcd
[1256701.022551]  gadget: high-speed config #1: Linux File-Backed Storage
[1256701.242481] usb 3-1: reset high-speed USB device number 5 using dummy_hcd
[1256701.278422]  gadget: high-speed config #1: Linux File-Backed Storage
[1256701.422339]  gadget: high-speed config #1: Linux File-Backed Storage
[1256934.915697] usb 3-1: reset high-speed USB device number 5 using dummy_hcd
[1256934.951628]  gadget: high-speed config #1: Linux File-Backed Storage
[1256935.915155] usb 3-1: reset high-speed USB device number 5 using dummy_hcd
[1256935.951090]  gadget: high-speed config #1: Linux File-Backed Storage
[1256936.095018]  gadget: high-speed config #1: Linux File-Backed Storage
[1317073.396892] usb-storage 3-1:1.0: Quirks match for vid 0525 pid a4a5: 1
[1317073.396995] scsi53 : usb-storage 3-1:1.0
[1317074.411883] scsi 53:0:0:0: Direct-Access LinuxFile-CD
Gadget   0302 PQ: 0 ANSI: 2
[1317074.412669] sd 53:0:0:0: Attached scsi generic sg3 type 0
[1317074.431910] sd 53:0:0:0: [sdc] 8388608 512-byte logical blocks:
(4.29 GB/4.00 GiB)
[1317074.443816] sd 53:0:0:0: [sdc] Write Protect is off
[1317074.443821] sd 53:0:0:0: [sdc] Mode Sense: 0f 00 00 00
[1317074.455839] sd 53:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[1317074.551757]  sdc: sdc1
[1317074.683704] sd 53:0:0:0: [sdc] Attached SCSI removable disk
--

The problem is that IO performance is very poor. Writing 200Mb file
takes quite a while:

--
$ ls -lh file
-rw-rw-r-- 1 root del 206M Sep  4 09:34 file
$ time sudo cp file /mnt/tmp/
real11m59.618s
user0m0.000s
sys 0m0.260s
--


Which is about 300K/sec. However the same file on the same system is
copied to a real USB flash in less than a minute. Looks like it is
emulating a USB 1.1 controller, not USB 2.0...

iotop shows something like this:

--
 TID  PRIO  USER DISK READ  DISK WRITE  SWAPIN IOCOMMAND
 9986 be/4 root0.00 B/s  262.05 K/s  0.00 % 99.86 % cp file /mnt/tmp/
20651 be/4 root   51.77 K/s  238.95 K/s  0.00 % 93.23 % [file-storage]
--

Can anything be done to improve the performance of
g_mass_storage-emulated USB drive?

PS: I am using kernel

--
$ uname -rm
3.2.0-4-686-pae i686
--

Thanks in advance.

--
Victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Low performance of g_mass_storage virtual usb device

[Victor Leschuk]

Hello, thanks for the answer. Maybe I sound stupid but how can I tell
g_mass_storage which controller to use? If I unload dummy_hcd and then
try to modprobe g_mass_storage I get an error no such device.

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 003: ID 046d:c050 Logitech, Inc. RX 250 Optical Mouse
Bus 002 Device 004: ID 046d:c31d Logitech, Inc.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Thanks in advance.

--
Victor

On Thu, Sep 5, 2013 at 5:58 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Thu, 5 Sep 2013, Victor Leschuk wrote:

 Hello all,

 I have recently faced a performance problem with usb gadget emulated
 USB flash drive. It is working fine except for very low performance.

 I use a 4Gb file, created by dd and created a ext2 or vfat (tried
 both) partition on it. Than I mount it using the following command
 sequence:

 --
 # modprobe dummy_hcd is_super_speed=1 # I tried is_high_speed=1, and
 no parameter too
 # modprobe g_mass_storage file=/home/del/img/flash stall=0 # tried w/o
 stall=0 too
 # mount /dev/sdc1 /mnt/tmp
 --

 After that I get /dev/sdc and /dev/sdc1 devices created without any
 errors in dmesg:

 --
 [1256700.986581] usb 3-1: reset high-speed USB device number 5 using 
 dummy_hcd
 [1256701.022551]  gadget: high-speed config #1: Linux File-Backed Storage
 [1256701.242481] usb 3-1: reset high-speed USB device number 5 using 
 dummy_hcd
 [1256701.278422]  gadget: high-speed config #1: Linux File-Backed Storage
 [1256701.422339]  gadget: high-speed config #1: Linux File-Backed Storage
 [1256934.915697] usb 3-1: reset high-speed USB device number 5 using 
 dummy_hcd
 [1256934.951628]  gadget: high-speed config #1: Linux File-Backed Storage
 [1256935.915155] usb 3-1: reset high-speed USB device number 5 using 
 dummy_hcd
 [1256935.951090]  gadget: high-speed config #1: Linux File-Backed Storage
 [1256936.095018]  gadget: high-speed config #1: Linux File-Backed Storage
 [1317073.396892] usb-storage 3-1:1.0: Quirks match for vid 0525 pid a4a5: 
 1
 [1317073.396995] scsi53 : usb-storage 3-1:1.0
 [1317074.411883] scsi 53:0:0:0: Direct-Access LinuxFile-CD
 Gadget   0302 PQ: 0 ANSI: 2
 [1317074.412669] sd 53:0:0:0: Attached scsi generic sg3 type 0
 [1317074.431910] sd 53:0:0:0: [sdc] 8388608 512-byte logical blocks:
 (4.29 GB/4.00 GiB)
 [1317074.443816] sd 53:0:0:0: [sdc] Write Protect is off
 [1317074.443821] sd 53:0:0:0: [sdc] Mode Sense: 0f 00 00 00
 [1317074.455839] sd 53:0:0:0: [sdc] Write cache: enabled, read cache:
 enabled, doesn't support DPO or FUA
 [1317074.551757]  sdc: sdc1
 [1317074.683704] sd 53:0:0:0: [sdc] Attached SCSI removable disk
 --

 The problem is that IO performance is very poor. Writing 200Mb file
 takes quite a while:

 --
 $ ls -lh file
 -rw-rw-r-- 1 root del 206M Sep  4 09:34 file
 $ time sudo cp file /mnt/tmp/
 real11m59.618s
 user0m0.000s
 sys 0m0.260s
 --


 Which is about 300K/sec. However the same file on the same system is
 copied to a real USB flash in less than a minute. Looks like it is
 emulating a USB 1.1 controller, not USB 2.0...

 iotop shows something like this:

 --
  TID  PRIO  USER DISK READ  DISK WRITE  SWAPIN IOCOMMAND
  9986 be/4 root0.00 B/s  262.05 K/s  0.00 % 99.86 % cp file /mnt/tmp/
 20651 be/4 root   51.77 K/s  238.95 K/s  0.00 % 93.23 % [file-storage]
 --

 Can anything be done to improve the performance of
 g_mass_storage-emulated USB drive?

 PS: I am using kernel

 --
 $ uname -rm
 3.2.0-4-686-pae i686
 --

 Thanks in advance.

 This has nothing to do with g_mass_storage.

 What you are seeing is low performance of dummy-hcd.  dummy-hcd depends
 strongly on the timer setting; it won't really work properly unless you
 have CONFIG_HZ set to 1000.  In general, the performance of dummy-hcd
 doesn't matter because it is meant only for testing.

 If you use g_mass_storage with a real USB device controller, you should
 find that it performs much better.

 Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 Victor, if you can get hold of a USB bus analyzer, you would be able to
 see directly when the DATA1 packet does or does not get sent.

I am in the process of getting a USB bus analyzer.

 No -- the problem is that the UDC completes the Set-Config request
 before it should.  In other words, it sends the DATA1 packet when it
 really should send a NAK packet.

In the status stage of Set-Config request, i make the driver sends the
NAK packet after it receives the IN packet. However, the next
Get-Config request is still sent out by host. With the USB bus
analyzer, hopefully i can verify the packets.

 Why haven't you turned on CONFIG_PRINTK_TIME on your gadget system?  I
 have asked you several times to do this.  Without CONFIG_PRINTK_TIME,
 there is no way to tell how long it took to reach this spot.

Ok. I will turn CONFIG_PRINTK_TIME on for debugging.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 However, the USB-2 spec says (section 9.2.6.4) that devices should be
 able to carry out requests with no Data stage (such as Set-Config)
 within 50 ms.  Does your gadget really take longer than that to handle
 the exception?

 To find out, collect a usbmon trace showing what happens when your new
 driver is plugged into a Linux host.

  I have set the NAK and
 stall the endpoint 0 after receiving Set-Config request, however,

 That doesn't make sense.  Stalling the endpoint means sending a STALL
 packet.  You can't send both a STALL and a NAK.

 Get-Config request is still sent out by USBCV host immediately.

 There should be at least a 50-ms delay, unless the UDC driver is doing
 something wrong.

 The latest usbmon trace is attached. From the trace, the timing is
 within 50ms from Set-Config request to the next request.

 Does your gadget really take longer than that to handle the exception?
 Yes, i think there is a delay before gadget calls the
 handle_exception() routine. So the problem is before
 handle_exception() of Set-Config request is called, the next request
 is sent out already by the host. So if the next request is Get-Config,
 it will not return the latest config value.

As can be seen in the gadget driver log below, after Set-Config
request is received, another two more requests are received before
handle_exception() is called. If there is a way to call
handle_exception() immediately after Set-Config request, it would be
very helpful.

g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
and stall endpoint
g_file_storage gadget: ep0-setup, length 8:
: 80 06 04 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x1a, buffer 0xc1297800
ep0_complete
g_file_storage gadget: ep0-in, length 26:
: 1a 03 53 00 65 00 6c 00 66 00 2d 00 70 00 6f 00
0010: 77 00 65 00 72 00 65 00 64 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 05 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x1a, buffer 0xc1297800
ep0_complete
g_file_storage gadget: ep0-in, length 26:
: 1a 03 4d 00 61 00 73 00 73 00 20 00 53 00 74 00
0010: 6f 00 72 00 61 00 67 00 65 00
handle_exception begin
handle_exception wait until
handle_exception old_state 4
g_file_storage gadget: set interface 0
g_file_storage gadget: high-speed config #1
FSG_STATE_CONFIG_CHANGE 19 21 0
g_file_storage gadget: in handle_exception loop

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 May i know which part of the do_set_config() or do_set_interface() has
 to be run in process context?

 Well, it's not exactly true that the routine has to run in process
 context.  More accurately, it has to run at a time when the main thread
 isn't using any of the endpoints or request structures, because
 do_set_interface() deallocates the requests and disables the endpoints.

 For example, if the main thread was in the middle of executing a SCSI
 command, do_set_config() would have to wait until it finished.  The
 easiest way to do this is by the exception technique.  That way
 do_set_config() is called by the main thread itself, so it knows the
 main thread isn't using those structures.

Thanks. The USBCV test has tight timing requirement. Once Set-Config
request is sent out, USBCV sends out Get-Config request to get the
config value immediately. At that time, gadget driver has not yet done
the handle_exception. So Get-Config request returns old config value,
and USBCV declares the test failed. Please see the log below.

Is there any way to speed up the handle_exception or to ask the USBCV
host to not send out Get-Config immediately? I have set the NAK and
stall the endpoint 0 after receiving Set-Config request, however,
Get-Config request is still sent out by USBCV host immediately.

g_file_storage gadget: ep0-setup, length 8:
: 00 09 00 00 00 00 00 00
g_file_storage gadget: set configuration
NAK and stall endpoint
g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
ept0 in queue len 0x1, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 1:
: 01
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 89d40868
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 68 08 d4 89 00 00 00 00 00 00 0a 35
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE;  Dc=10, Dn=0;
Hc=10, Hn=0
attention condition
g_file_storage gadget: after calling do_scsi_command
handle_exception begin
handle_exception wait until
handle_exception old_state 4
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
FSG_STATE_CONFIG_CHANGE 52 53 0
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: in fsg-running loop

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 However, the USB-2 spec says (section 9.2.6.4) that devices should be
 able to carry out requests with no Data stage (such as Set-Config)
 within 50 ms.  Does your gadget really take longer than that to handle
 the exception?

 To find out, collect a usbmon trace showing what happens when your new
 driver is plugged into a Linux host.

  I have set the NAK and
 stall the endpoint 0 after receiving Set-Config request, however,

 That doesn't make sense.  Stalling the endpoint means sending a STALL
 packet.  You can't send both a STALL and a NAK.

 Get-Config request is still sent out by USBCV host immediately.

 There should be at least a 50-ms delay, unless the UDC driver is doing
 something wrong.

The latest usbmon trace is attached. From the trace, the timing is
within 50ms from Set-Config request to the next request.

 Does your gadget really take longer than that to handle the exception?
Yes, i think there is a delay before gadget calls the
handle_exception() routine. So the problem is before
handle_exception() of Set-Config request is called, the next request
is sent out already by the host. So if the next request is Get-Config,
it will not return the latest config value.

Thanks,
victor


usbmon_july12.log
Description: Binary data

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 Yes, this should be the root cause. For the setup stage of Set-Config
 request, the UDC driver can handle it well. But for the status stage
 of Set-Config request, somehow it is not handled correctly. When UDC
 driver receives the endpoint 0 IN token, it only clears the interrupt
 request. It will not send the Data1 packet unless usb_ep_queue() is
 called.

 And yet it _does_ send the packet before usb_ep_queue() is called.

I am still studying how Data1 packet is sent out, from the log,
usb_ep_queue() is not called, i have no idea now.

 DELAYED_STATUS tells fsg_setup() not to call ep0_queue().  It means
 that the request isn't finished yet, so the status isn't known.  The
 status will be reported later, when the request is finished.

 handle_exception() is used for things that cannot be carried out in
 interrupt context.  fsg_setup() runs in an interrupt handler, so it
 can't call do_set_config() or do_set_interface() -- those routines need
 to run in process context.  Therefore the USB_REQ_SET_CONFIGURATION
 code raises an exception; when the fsg thread handles the exception, it
 calls do_set_config().

May i know which part of the do_set_config() or do_set_interface() has
to be run in process context?

Thanks,
Victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 I can't tell what's going on in your log.  Look at the
 FSG_STATE_CONFIG_CHANGE case in handle_exception().  Here's the code:

 rc = do_set_config(fsg, new_config);
 if (fsg-ep0_req_tag != exception_req_tag)
 break;
 if (rc != 0)// STALL on errors
 fsg_set_halt(fsg, fsg-ep0);
 else// Complete the status stage
 ep0_queue(fsg);
 break;

 It calls do_set_config().  After that, fsg-ep0_req_tag should be equal
 to exception_req_tag and rc should be equal to 0.  Therefore the code
 will call ep0_queue(), which calls usb_ep_queue().

 I found out from printk, the fsg-ep0_req_tag and exception_req_tag
 are not equal, and rc is 0. In standard_setup_req(), case
 USB_REQ_SET_CONFIGURATION, once i add the following code

 if (w_value == 0)
 fsg-config = 0;

 just before the break; statement, the Device Descriptor
 Test-Addressed State  can pass. It seems that Get-Config request from
 host cannot wait, so i have to return the latest config value in
 response to the request.

 Thanks,
 victor

In fact, the Device Descriptor Test-Addressed State sometimes
passes, sometimes fails after my modification. What is the reason of
DELAYED_STATUS in USB_REQ_SET_CONFIGURATION, and the use of
handle_exception() to call do_set_config()?

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 Than either there is a bug in the UDC (or the UDC driver), or else the
 host doesn't wait for the Set-Config request to complete before sending
 the next request.  What were the values of fsg-ep0_req_tag and
 exception_req_tag?

From the printk added, the values of fsg-ep0_req_tag and exception_req_tag 
are:

fsg-ep0_req_tag  163,  exception_req_tag 161
fsg-ep0_req_tag  168,  exception_req_tag 167
fsg-ep0_req_tag  176,  exception_req_tag 173

 By searching through the code in file_storage.c, you can easily see
 that fsg-ep0_req_tag gets set in only one place: the first line of
 fsg_setup().  It is a counter -- it goes up by one every time a new
 SETUP packet is received, marking the start of a new control transfer.

 You can also see that handle_exception() sets exception_req_tag to
 the value of fsg-exception_req_tag, and raise_exception() sets
 fsg-exception_req_tag to the value of fsg-ep0_req_tag.  This means
 that exception_req_tag holds the counter value as of the time the
 exception started.

 If the values are different, it means that another control transfer
 started (fsg_setup() was called) between the time when the original
 exception was raised and the time when it was handled.  If the UDC is
 working correctly, the only way for this to happen is if the host sends
 another control request without waiting for the first one to finish.

  and rc is 0. In standard_setup_req(), case
 USB_REQ_SET_CONFIGURATION, once i add the following code

 if (w_value == 0)
 fsg-config = 0;

 just before the break; statement, the Device Descriptor
 Test-Addressed State  can pass. It seems that Get-Config request from
 host cannot wait, so i have to return the latest config value in
 response to the request.

 Almost certainly, the problem is that the UDC told the host that the
 Set-Config request was finished before it should have.  The host
 thought the request was finished, so it sent the next request -- the
 Get-Config -- but the gadget driver was still carrying out the
 Set-Config.

Yes, this should be the root cause. For the setup stage of Set-Config
request, the UDC driver can handle it well. But for the status stage
of Set-Config request, somehow it is not handled correctly. When UDC
driver receives the endpoint 0 IN token, it only clears the interrupt
request. It will not send the Data1 packet unless usb_ep_queue() is
called.

Somehow, before handle_exception() gets the chance to call
do_set_config(), host sends next request.

 DELAYED_STATUS tells fsg_setup() not to call ep0_queue().  It means
 that the request isn't finished yet, so the status isn't known.  The
 status will be reported later, when the request is finished.

 handle_exception() is used for things that cannot be carried out in
 interrupt context.  fsg_setup() runs in an interrupt handler, so it
 can't call do_set_config() or do_set_interface() -- those routines need
 to run in process context.  Therefore the USB_REQ_SET_CONFIGURATION
 code raises an exception; when the fsg thread handles the exception, it
 calls do_set_config().

 When your UDC driver calls the gadget driver's .setup() function, how
 does it handle the return value?

The code is as below:

status = dev-driver-setup(dev-gadget, usb_ctrlrequest);
if (status  0)
{
dev-protocol_stall = 1;
}
else if (status == (DELAYED_STATUS))
{
/*NAK the IN packet from host*/
}

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 No, that's not right.  Set-Config has only two stages, Setup and
 Status; there is no Data stage.  The flow is:

 Host Device
 - Setup Packet --- |
 - Data0 Packet --- |== Setup stage
  Ack Packet -- |

 - In Packet -- |
  Data1 Packet  |== Status stage
 - Ack Packet - |


 ACK the Status stage of an OUT control transfer, is it referring to
 the Third ACK packet? So UDC driver should ACK only after Data1 packet
 is sent via the usb_ep_queue()?

 I meant the Data1 packet above.  The UDC driver should not send this
 packet until the gadget driver tells it to (by calling usb_ep_queue).
 Until then, it should send NAK in respond to the In packet.

Is the Data1 packet above containing no data, such as this?

  PID   !PID  CRC

I do not see the gadget driver calling usb_ep_queue() for sending the
Data1 packet. Please see the log below. Is there similar code in
net2280.c handle_stat0_irqs() that handles Set-Config?

g_file_storage gadget: ep0-setup, length 8:
: 00 09 00 00 00 00 00 00
g_file_storage gadget: set configuration
after kagen2_ep_queue
kagen2_ep_queue 31 64 31
[kagen2_ep_queue] 43425355 899e1008
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 08 10 9e 89 00 00 00 00 00 00 0a 35
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE;  Dc=10, Dn=0;
Hc=10, Hn=0
g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
ept0 in queue len 0x1, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 1:
: 01
attention condition

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 No, i don't see that (Set-Config request with a config value of 0)

 Well, then I don't know where the problem is, but obviously the problem
 occurred before the gadget driver was involved.  Either the host sent a
 wrong packet, or more likely the UDC received the packet incorrectly.

Yes, UDC driver has bug. After modifying it, it can receive Set-Config
request with a config value of 0. However, the device descriptor test
- addressed state still fails.

Please see the attached log. The Set-Config request with a config
value of 0 is the second last USB request sent from the host. The last
USB request is Get-Config, which still returns config value of 1.

Thanks,
victor
# dmesg -c
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
exit C
ept0 in queue len 0x12, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
USB_RECIP_DEVICE 0x2
fa is 0x2
exit A
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
handle_exception begin
handle_exception wait until
handle_exception old_state 4
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 20 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x20, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 32:
: 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06
0010: 50 05 07 05 81 02 40 00 00 07 05 01 02 40 00 00
g_file_storage gadget: set interface 0
g_file_storage gadget: full-speed config #1
g_file_storage gadget: in handle_exception loop
[start_transfer] 43425355 899e1008
ept1 out queue len 0x40, buffer 0xc0c44000
before kagen2_ep_queue
g_file_storage gadget: disconnect or port reset
after kagen2_ep_queue
kagen2_ep_queue 31 64 31
[kagen2_ep_queue] 43425355 899e1008
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 08 10 9e 89 00 00 00 00 00 00 0a 35
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE;  Dc=10, Dn=0;  Hc=10, 
Hn=0
attention condition
g_file_storage gadget: after calling do_scsi_command
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
exit C
ept0 in queue len 0x12, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
USB_RECIP_DEVICE 0x2
fa is 0x2
exit A
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 No, i don't see that (Set-Config request with a config value of 0)

 Well, then I don't know where the problem is, but obviously the problem
 occurred before the gadget driver was involved.  Either the host sent a
 wrong packet, or more likely the UDC received the packet incorrectly.

 Yes, UDC driver has bug. After modifying it, it can receive Set-Config
 request with a config value of 0. However, the device descriptor test
 - addressed state still fails.

 Please see the attached log. The Set-Config request with a config
 value of 0 is the second last USB request sent from the host. The last
 USB request is Get-Config, which still returns config value of 1.

In gadget driver, do_set_config(), if new_config is 0, the new_config
is not processed. So config value of zero will never be saved by
gadget driver. Isn't it?

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Victor Yeo]

Hi,

 Yes, UDC driver has bug. After modifying it, it can receive Set-Config
 request with a config value of 0. However, the device descriptor test
 - addressed state still fails.

 Please see the attached log. The Set-Config request with a config
 value of 0 is the second last USB request sent from the host. The last
 USB request is Get-Config, which still returns config value of 1.

 This looks like another bug in the UDC driver.  It performs the Status
 stage of the Set-Config request before the gadget driver has finished
 carrying out the request.

 Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req()
 returns DELAYED_STATUS.  As a result, fsg_setup() does not call
 ep0_queue(), and so usb_ep_queue() doesn't get called.  The UDC driver
 is not supposed to ACK the Status stage of an OUT control transfer
 until usb_ep_queue() is called.

May i verify my understanding of Set-Config request packet flow?

Host   Device
--Setup Packet
--Data0 Packet
-Ack Packet-

-- In Packet 
 Data1 Packet 
- Ack Packet -

- Out Packet 
- Data1 Packet 
 Ack Packet -

ACK the Status stage of an OUT control transfer, is it referring to
the Third ACK packet? So UDC driver should ACK only after Data1 packet
is sent via the usb_ep_queue()?

 In gadget driver, do_set_config(), if new_config is 0, the new_config
 is not processed. So config value of zero will never be saved by
 gadget driver. Isn't it?

 Look at do_set_config():

 /* Disable the single interface */
 if (fsg-config != 0) {
 DBG(fsg, reset config\n);
 fsg-config = 0;
 rc = do_set_interface(fsg, -1);
 }

 /* Enable the interface */
 if (new_config != 0) {
 ...
 }
 return rc;

 So if new_config is 0, fsg-config remains set to 0 and the
 deconfiguration is processed by the do_set_interface() call.

Understand now. Thanks.

victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 g_file_storage gadget: ep0-setup, length 8:
 : 00 09 01 00 00 00 00 00
 g_file_storage gadget: set configuration

 Yes, that is a Set-Config request with configuraiton value 1.  You
 probably got hold of the wrong part of the log.  Elsewhere there should
 be a Set-Config request with a config value of 0.

No, i don't see that (Set-Config request with a config value of 0)

 g_file_storage gadget: ep0-setup, length 8:
 : 80 08 00 00 00 00 01 00
 g_file_storage gadget: get configuration
 g_file_storage gadget: ep0-in, length 1:
 : 01

 This is the correct response following the request above.

 You can test the gadget's behavior with a Linux host.  To send a
 Set-Config request with value N, do

 echo N /sys/bus/usb/devices/.../bConfigurationValue

 where the ... part is replaced with the gadget's device path.

When i use echo 0  /sys/bus/usb/devices/.../bConfigurationValue,
there is no activity in gadget and UDC driver, and the gadget
disappear from Linux host.

If i use echo 1  /sys/bus/usb/devices/.../bConfigurationValue, the
gadget is re-enumerated and re-appear in Linux host.

I also observe in gadget driver, there is only one config descriptor
with bConfigurationValue of 1. Is bConfigurationValue of 0 meant to
disble the device?

Thanks,
Victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 You should not be concerned about variables in the gadget driver.  The
 problem is in the UDC driver.

 For some examples of what the UDC driver needs to do, look at
 handle_control_request() in drivers/usb/gadget/dummy_hcd.c or the
 switch (u.r.bRequest) statement of handle_stat0_irqs() in
 drivers/usb/gadget/net2280.c.

 Alan Stern


I find some clue. From USB 2.0 Compliance Test Spec, quoted:

Address State:
1.  Put the device in the configured state following the procedure below.
2.  Issue a valid Set Configuration command to the device with
configuration value zero.
3.  Issue a valid Get Configuration command to the device and verify
that device responds with zero.

I think the address state test in USB2CV fails because
Set-Configuration actually set config #1 and Get-Configuration returns
config #1. See the usb requests log below. It seems that the Set
Configuration command from USB2CV is issued with config value of one.
Isn't it?

g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration

g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
g_file_storage gadget: ep0-in, length 1:
: 01

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I re-attach the usbmon log. If possible, please show me which line
 indicates that usb_ep_set_wedge routine is not working, or how to look
 for the clue. Is it from the control transfer line?

 Here's an example:

 f4148f80 308532 S Bo:1:011:1 -115 31 = 55534243 0600 c000 
 861a 003f00c0   00
 f4148f80 308652 C Bo:1:011:1 0 31 
 f14c5600 308676 S Bi:1:011:1 -115 192 
 f14c5600 3087787651 C Bi:1:011:1 -121 16 = 0f00 080a0400  
 f4148f80 3087787674 S Bi:1:011:1 -115 13 
 f4148f80 3087803018 C Bi:1:011:1 0 13 = 55534253 0600 b000 00

 The last line should have failed with a -32 error code, because the IN
 endpoint is supposed to be halted at this point.

  I think the GET_STATUS request is not handled by the gadget driver. Isn't 
  it so?
 
  That's right.  Get-Status, Set-Feature, and Clear-Feature requests must
  be handled by the UDC driver.
 
  Alan Stern

The fsg-state in gadget driver,  is used for exception handling. Is
there any variable to track the USB device state of Figure 9-1 of the
USB 2.0 Spec? Now the gadget driver does not pass the USB2.0 CV - Get
Device Descriptor - Address State test. So i am trying to find more
information.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 The problem is in UDC driver. i made the change, it is ok now.

 Good.  I noticed that the usb_ep_set_wedge routine still isn't working
 right.  You might try to fix that.

 Alan Stern


Ok, is the usb_ep_set_wedge routine not working? I can't see that in
the log file.

Now, in USB 2.0 CV test, there is an error about GET_STATUS request,
as shown below.

g_file_storage gadget: ep0-setup, length 8:
: 82 00 00 00 81 00 02 00
g_file_storage gadget: unknown control req 82.00 v i0081 l2
handle_setup status -95

I think the GET_STATUS request is not handled by the gadget driver. Isn't it so?

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Ok, is the usb_ep_set_wedge routine not working? I can't see that in
 the log file.

 It is not working.  This can be seen in the usbmon log.

I re-attach the usbmon log. If possible, please show me which line
indicates that usb_ep_set_wedge routine is not working, or how to look
for the clue. Is it from the control transfer line?

 Now, in USB 2.0 CV test, there is an error about GET_STATUS request,
 as shown below.

 g_file_storage gadget: ep0-setup, length 8:
 : 82 00 00 00 81 00 02 00
 g_file_storage gadget: unknown control req 82.00 v i0081 l2
 handle_setup status -95

 I think the GET_STATUS request is not handled by the gadget driver. Isn't it 
 so?

 That's right.  Get-Status, Set-Feature, and Clear-Feature requests must
 be handled by the UDC driver.

 Alan Stern


Should the UDC driver handle Get-Status before or after the call to fsg_setup()?

thanks,
victor
f2e9da80 3086290883 S Ci:1:001:0 s a3 00  0001 0004 4 
f2e9da80 3086290911 C Ci:1:001:0 0 4 = 0001
f2e9da80 3086290919 S Ci:1:001:0 s a3 00  0002 0004 4 
f2e9da80 3086290923 C Ci:1:001:0 0 4 = 0001
f2e9da80 3086290927 S Ci:1:001:0 s a3 00  0003 0004 4 
f2e9da80 3086290931 C Ci:1:001:0 0 4 = 0001
f2e9da80 3086290936 S Ci:1:001:0 s a3 00  0004 0004 4 
f2e9da80 3086290940 C Ci:1:001:0 0 4 = 0001
f2e9da80 3086290944 S Ci:1:001:0 s a3 00  0005 0004 4 
f2e9da80 3086290958 C Ci:1:001:0 0 4 = 03050400
f2e9da80 3086290963 S Ci:1:001:0 s a3 00  0006 0004 4 
f2e9da80 3086290967 C Ci:1:001:0 0 4 = 0001
f6816a80 3086290972 S Ii:1:001:1 -115:2048 4 
f2e9da80 3086291359 S Ci:1:001:0 s a3 00  0005 0004 4 
f2e9da80 3086291366 C Ci:1:001:0 0 4 = 03050400
f2e9da80 3086291372 S Co:1:001:0 s 23 01 0012 0005  0
f2e9da80 3086291378 C Co:1:001:0 0 0
f2e9d100 3086307426 S Ci:1:001:0 s a3 00  0005 0004 4 
f2e9d100 3086307441 C Ci:1:001:0 0 4 = 0305
f2e9d100 3086307450 S Ci:1:003:0 s 80 00   0002 2 
f2e9d100 3086307599 C Ci:1:003:0 0 2 = 0300
f2e9d100 3086308101 S Co:1:003:0 s 00 01 0001   0
f2e9d100 3086308971 C Co:1:003:0 0 0
f2e9d100 3086308995 S Ci:1:003:0 s a3 00  0001 0004 4 
f2e9d100 3086309344 C Ci:1:003:0 0 4 = 0001
f2e9d100 3086309362 S Ci:1:003:0 s a3 00  0002 0004 4 
f2e9d100 3086309718 C Ci:1:003:0 0 4 = 01010100
f2e9d100 3086309736 S Co:1:003:0 s 23 01 0010 0002  0
f2e9d100 3086310093 C Co:1:003:0 0 0
f2e9d100 3086310110 S Ci:1:003:0 s a3 00  0003 0004 4 
f2e9d100 3086310466 C Ci:1:003:0 0 4 = 0001
f2e9d100 3086310478 S Ci:1:003:0 s a3 00  0004 0004 4 
f2e9d100 3086310842 C Ci:1:003:0 0 4 = 0001
f3369680 3086414872 S Ii:1:003:1 -115:2048 1 
f33a1c00 3086414952 S Ci:1:003:0 s a3 00  0002 0004 4 
f33a1c00 3086415358 C Ci:1:003:0 0 4 = 0101
f33a1c00 3086415413 S Co:1:003:0 s 23 03 0016 0002  0
f33a1c00 3086415717 C Co:1:003:0 0 0
f33a1c00 3086415763 S Co:1:003:0 s 23 03 0004 0002  0
f33a1c00 3086416093 C Co:1:003:0 0 0
f33a1600 3086430814 S Ci:1:003:0 s a3 00  0002 0004 4 
f33a1600 3086431836 C Ci:1:003:0 0 4 = 03011000
f3369680 3086450282 C Ii:1:003:1 0:2048 1 = 04
f3369680 3086450297 S Ii:1:003:1 -115:2048 1 
f33fa980 3086486796 S Co:1:003:0 s 23 01 0014 0002  0
f33fa980 3086487826 C Co:1:003:0 0 0
f33fa980 3086487934 S Ci:1:000:0 s 80 06 0100  0040 64 
f33fa980 3086488571 C Ci:1:000:0 0 18 = 12010002 0040 2505a5a4 33030102 0001
f33fa980 3086488632 S Co:1:003:0 s 23 03 0004 0002  0
f33fa980 3086488943 C Co:1:003:0 0 0
f33fa080 3086503390 S Ci:1:003:0 s a3 00  0002 0004 4 
f33fa080 3086503964 C Ci:1:003:0 0 4 = 03011000
f4147b80 3086558950 S Co:1:003:0 s 23 01 0014 0002  0
f4147b80 3086559441 C Co:1:003:0 0 0
f4147b80 3086559513 S Co:1:000:0 s 00 05 000b   0
f4147b80 3086559683 C Co:1:000:0 0 0
f2eeba00 3086578950 S Ci:1:011:0 s 80 06 0100  0012 18 
f2eeba00 3086580189 C Ci:1:011:0 0 18 = 12010002 0040 2505a5a4 33030102 0001
f2eeba00 3086580259 S Ci:1:011:0 s 80 06 0600  000a 10 
f2eeba00 3086580806 C Ci:1:011:0 0 10 = 0a060002 0040 0100
f2eeba00 3086580883 S Ci:1:011:0 s 80 06 0200  0009 9 
f2eeb500 3086580900 S Co:1:003:0 s 23 03 0016 0202  0
f2eeb500 3086581180 C Co:1:003:0 0 0
f2eeba00 3086581558 C Ci:1:011:0 0 9 = 09022000 010104c0 01
f2eeba00 3086581604 S Ci:1:011:0 s 80 06 0200  0020 32 
f2eeba00 3086582182 C Ci:1:011:0 0 32 = 09022000 010104c0 01090400 00020806 
50050705 81024000 00070501 0240
f2eeba00 3086582259 S Ci:1:011:0 s 80 06 0300  00ff 255 
f2eeba00 3086582933 C Ci:1:011:0 0 4 = 04030904
f2eeba00 3086583014 S Ci:1:011:0 s 80 06 0302 0409 00ff 255 
f2eeba00 3086583558 C Ci:1:011:0 0 54 = 36034600 69006c00 65002d00 62006100 
63006b00 65006400 20005300 74006f00
f2eeba00 3086583633 S Ci:1:011:0 s 80 06 0301 0409 00ff 255 
f2eeba00 3086584558 C Ci:1:011:0 0 58 = 3a034c00 69006e00 75007800 20003300 
2e003400 2e003400 2b002000 77006900
f2eeba00 3086584905 S Co:1:011:0 s 00 09 0001   0
f2eeba00 3086585055 C Co:1:011:0 0 0

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Yes, i see the bad characters in the log file. I apologize for that,
 my eyes was in pain after looking thru the log files and did not
 notice that when i attached the log file.

 The good news is i can get gadget to work with Lenovo x100e on Ubuntu
 and Windows. The change is adding more delay after writing to endpoint
 one IN FIFO register,  for the case of writing more than the endpoint
 buffer size. However, the gadget only work on high-speed mode. If i
 disable ehci_hcd driver in Ubuntu (force it to be full speed), the
 same problem of SCSI_READ_10 command asking 4096 bytes and gadget
 returning the data, and gadget reset, still happens.

I can bring up the gadget in full speed mode now, so the SCSI_READ_10
command problem is fixed. It is caused by an error interfacing to
hardware.

Now there is another problem with SCSI_MODE_SELECT_6 command, when in
full speed mode, the data for SCSI_MODE_SELECT_6 command is 72 byte,
and somehow the gadget is reset. Is it because gadget is not able to
handle the amount of data? Please see the attached gadget log.
Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command
is 24 byte.

Thanks,
victor
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
USB_RECIP_DEVICE
fa is 0x3
exit A
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
exit C
ept0 in queue len 0x12, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
handle_exception begin
handle_exception wait until
handle_exception old_state 4
g_file_storage gadget: set interface 0
g_file_storage gadget: full-speed config #1
EP1 OUT IRQ 0x28
ept0 in queue len 0x0, buffer 0xc128f800
g_file_storage gadget: in handle_exception loop
[start_transfer] 800 0
ept1 out queue len 0x40, buffer 0xc134
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 64 31
EP1 OUT IRQ 0x28
[kagen2_ep_queue] 43425355 87a68008
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 08 80 a6 87 18 00 00 00 00 00 06 15
0010: 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: MODE SELECT(6);  Dc=6, Do=24;  Hc=6, Ho=24
attention condition
[start_transfer] 43425355 87a68008
ept1 out queue len 0x40, buffer 0xc134
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 24 64 24
before kagen2_ep_queue
g_file_storage gadget: disconnect or port reset
after kagen2_ep_queue
kagen2_ep_queue 48 64 24
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 72 64 24
[kagen2_ep_queue] 800 0
g_file_storage gadget: bulk-out, length 72:
: 00 00 00 08 00 00 00 00 00 00 02 00 08 0a 00 00
0010: ff ff 00 00 ff ff ff ff 00 00 00 00 00 00 00 5f
0020: c1 9f 75 00 58 1d 00 00 00 00 00 00 02 00 00 00
0030: 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00
0040: 80 00 29 5f 22 e8 c2 4e
g_file_storage gadget: bulk_out_complete -- 0, 72/24
g_file_storage gadget: before calling send_status
g_file_storage gadget: sending command-failure status
g_file_storage gadget:   sense data: SK x06, ASC x29, ASCQ x00;  info x0
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 08 80 a6 87 18 00 00 00 01
[start_transfer] 53425355 87a68008
exit C
ept1 in queue len 0xd, buffer 0xc135
0: 0x53425355
4: 0x87a68008
8: 0x18
bulk_in_complete -- 0, 13/13
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 There is a mistake in the previous log file, because the fifo size is
 still set to 512 byte. Now i change it to 64 byte if it is Full speed.

 The FIFO size should always be set to the value in the endpoint
 descriptor, no matter what speed the connection is.

 The log file are attached.

 The log shows that your 64-byte transfers don't work very well.  The
 first one didn't send any bytes.  The second one sent only 4 bytes.
 And each of the ones after that sent 0 bytes.

 Alan Stern

 PS: Something was very wrong with the log file you posted.  It is full
 of bad characters.  You can it here:

Yes, i see the bad characters in the log file. I apologize for that,
my eyes was in pain after looking thru the log files and did not
notice that when i attached the log file.

The good news is i can get gadget to work with Lenovo x100e on Ubuntu
and Windows. The change is adding more delay after writing to endpoint
one IN FIFO register,  for the case of writing more than the endpoint
buffer size. However, the gadget only work on high-speed mode. If i
disable ehci_hcd driver in Ubuntu (force it to be full speed), the
same problem of SCSI_READ_10 command asking 4096 bytes and gadget
returning the data, and gadget reset, still happens.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I did another usbmon capture from the moment usb cable is plugged into
 the Ubuntu x100e laptop. This time the usbmon does not have -75 error.
 When the SCSI_READ_10 command request for 4096 bytes of data, and the
 data is returned by the gadget, usbmon simply shows -108 error. The
 gadget driver log and usbmon trace are attached.

 Again, the -108 indicates that the host controller disabled the port.
 The usbmon trace confirms this.  I think the most common reason for
 disabling a port in this way is that the device tried to transmit a
 packet across a microframe boundary.

 The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break
 the 4096 bytes of data into 8 chunks of 512 bytes, before returning
 them to Ubuntu. I guess it would not be the root cause, won't it?

 It's hard to say without looking at the signals on the wire.  Are you
 certain the hardware really is sending 512 bytes for each chunk?
 That's why you need to use a bus analyzer -- to see what's actually
 going on.

I have an important finding. When the problem (SCSI_READ_10 command
reads 4096 bytes of data, causing gadget to reset) happens, the PC
shows that the gadget is detected as Full-speed device, but gadget
reports that it is set to High-speed from:

g_file_storage gadget: high-speed config #1

This is printed from do_set_config() in file_storage.c. In UDC driver,
it is hardcorded to high speed in UDC driver start function. I changed
it to be set depending on hardware value. Now it is:

g_file_storage gadget: full-speed config #1

However, in usbmon, the SCSI_READ_10 command still requests for 4096
bytes of data, and this causes gadget to reset. Please see the gadget
log, and usbmon trace, and host dmesg log.

Thanks,
Victor
[ 3427.328908] usb 1-5.2: new full speed USB device using ehci_hcd and address 7
[ 3427.421804] usb 1-5.2: not running at top speed; connect to a high speed hub
[ 3427.455274] usb-storage 1-5.2:1.0: Quirks match for vid 0525 pid a4a5: 1
[ 3427.457117] scsi3 : usb-storage 1-5.2:1.0
[ 3428.896784] usb 1-5.2: reset full speed USB device using ehci_hcd and 
address 7

f33fa400 1314593130 C Ci:1:007:0 0 9 = 09022000 010104c0 01
f33fa400 1314593147 S Ci:1:007:0 s 80 06 0200  0020 32 
f33fa400 1314593752 C Ci:1:007:0 0 32 = 09022000 010104c0 01090400 00020806 
50050705 81024000 00070501 0240
f33fa400 1314593791 S Ci:1:007:0 s 80 06 0300  00ff 255 
f33fa400 1314594502 C Ci:1:007:0 0 4 = 04030904
f33fa400 1314594519 S Ci:1:007:0 s 80 06 0302 0409 00ff 255 
f33fa400 1314595120 C Ci:1:007:0 0 54 = 36034600 69006c00 65002d00 62006100 
63006b00 65006400 20005300 74006f00
f33fa400 1314595918 S Ci:1:007:0 s 80 06 0301 0409 00ff 255 
f33fa400 1314596884 C Ci:1:007:0 0 58 = 3a034c00 69006e00 75007800 20003300 
2e003400 2e003400 2b002000 77006900
f33fa400 1314597660 S Co:1:007:0 s 00 09 0001   0
f33fa400 1314598122 C Co:1:007:0 0 0
f33fa400 1314599768 S Ci:1:007:0 s 80 06 0304 0409 00ff 255 
f33fa400 1314612251 C Ci:1:007:0 0 26 = 1a035300 65006c00 66002d00 70006f00 
77006500 72006500 6400
f2e1ee00 1314612435 S Ci:1:007:0 s 80 06 0305 0409 00ff 255 
f2e1ee00 1314613115 C Ci:1:007:0 0 26 = 1a034d00 61007300 73002000 53007400 
6f007200 61006700 6500
f33a1380 1315254841 S Co:1:003:0 s 23 03 0016 0302  0
f33a1380 1315255168 C Co:1:003:0 0 0
f2e1e400 1315646807 S Ci:1:007:0 s a1 fe   0001 1 
f2e1e400 1315647355 C Ci:1:007:0 0 1 = 00
f2e1e400 1315655086 S Bo:1:007:1 -115 31 = 55534243 0100 2400 8612 
0024   00
f2e1e400 1315655351 C Bo:1:007:1 0 31 
f2ed1a00 1315655414 S Bi:1:007:1 -115 36 
f2ed1a00 1315657108 C Bi:1:007:1 0 36 = 0202 1f00 4c696e75 78202020 
46696c65 2d53746f 72204761 64676574
f2e1e400 1315657185 S Bi:1:007:1 -115 13 
f2e1e400 1315666355 C Bi:1:007:1 0 13 = 55534253 0100  00
f2e1e400 1315708514 S Bo:1:007:1 -115 31 = 55534243 0200  0600 
   00
f2e1e400 1315708845 C Bo:1:007:1 0 31 
f2e1e400 1315708919 S Bi:1:007:1 -115 13 
f2e1e400 1315718221 C Bi:1:007:1 0 13 = 55534253 0200  01
f2e1e400 1315718323 S Bo:1:007:1 -115 31 = 55534243 0300 1200 8603 
0012   00
f2e1e400 1315718460 C Bo:1:007:1 0 31 
f2ed1700 1315718501 S Bi:1:007:1 -115 18 
f2ed1700 1315728467 C Bi:1:007:1 0 18 = 7600 000a  2900 
f2e1e400 1315728630 S Bi:1:007:1 -115 13 
f2e1e400 1315737728 C Bi:1:007:1 0 13 = 55534253 0300  00
f2e1e400 1315738087 S Bo:1:007:1 -115 31 = 55534243 0400  0600 
   00
f2e1e400 1315738959 C Bo:1:007:1 0 31 
f2e1e400 1315739098 S Bi:1:007:1 -115 13 
f2e1e400 1315748116 C Bi:1:007:1 0 13 = 55534253 0400  00
f2e1e400 1315748392 S Bo:1:007:1 -115 31 = 55534243 0500 0800 8a25 
   00
f2e1e400 1315748596 C Bo:1:007:1 0 31 
f33faa00 1315748619 S Bi:1:007:1 -115 8 
f33faa00 1315758231 C Bi:1:007:1 0 8

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 The usbmon trace shows lots of errors.  All those -75 (EOVERFLOW)
 status codes mean that the gadget sent a packet that was too large,
 i.e., more than 512 bytes.  This happened in all the READ(10) commands
 except the last one -- none of them succeeded in transferring any data.

 After the last READ(10) command was sent, the usbmon trace shows that
 the host's USB port got disabled.  Maybe because of the too-long
 packets.  Whatever the reason, that's why the ESHUTDOWN error occurred.

 The gadget's log does indeed show that the last READ(10) was received
 twice.  The second time is a bug in the UDC driver.  No command was
 sent by the host, so the driver should not have reported that a command
 was received.

 Alan Stern


I did another usbmon capture from the moment usb cable is plugged into
the Ubuntu x100e laptop. This time the usbmon does not have -75 error.
When the SCSI_READ_10 command request for 4096 bytes of data, and the
data is returned by the gadget, usbmon simply shows -108 error. The
gadget driver log and usbmon trace are attached.

The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break
the 4096 bytes of data into 8 chunks of 512 bytes, before returning
them to Ubuntu. I guess it would not be the root cause, won't it?

thanks,
victor
# dmesg -c
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
USB_RECIP_DEVICE
fa is 0x2
exit A
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 06 00 00 0a 00
g_file_storage gadget: get device qualifier
ept0 in queue len 0xa, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 10:
: 0a 06 00 02 00 00 00 40 01 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 20 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x20, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 32:
: 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06
0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 03 00 00 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x4, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 4:
: 04 03 09 04
g_file_storage gadget: ep0-setup, length 8:
: 80 06 02 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x36, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 54:
: 36 03 46 00 69 00 6c 00 65 00 2d 00 62 00 61 00
0010: 63 00 6b 00 65 00 64 00 20 00 53 00 74 00 6f 00
0020: 72 00 61 00 67 00 65 00 20 00 47 00 61 00 64 00
0030: 67 00 65 00 74 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 01 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x3a, buffer 0xc128f800
ep0_complete
g_file_storage gadget: ep0-in, length 58:
: 3a 03 4c 00 69 00 6e 00 75 00 78 00 20 00 33 00
0010: 2e 00 34 00 2e 00 34 00 2b 00 20 00 77 00 69 00
0020: 74 00 68 00 20 00 6b 00 61 00 67 00 65 00 6e 00
0030: 32 00 5f 00 75 00 73 00 62 00
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
handle_exception begin
handle_exception wait until
handle_exception old_state 4
g_file_storage gadget: set interface 0
g_file_storage gadget: high-speed config #1
g_file_storage gadget: ep0-setup, length 8:
: 80 06 04 03 09 04 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x1a, buffer 0xc128f800
ep0_complete

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 The hardware handles Set Address request, and i can see the address of
 the USB gadget being shown in Windows host. Here i attach the gadget
 driver log for the Device Descriptor Test - Addressed State. The
 test just failed after Get Configuration request.

 I can't tell what's wrong.  You will have to use a USB bus analyzer.

Ok. Today i tested the same mass storage gadget driver on Lenovo x100e
Ubuntu. There is a strange problem. After SCSI_READ_10 command data is
returned to the Ubuntu host. The gadget driver says:

g_file_storage gadget: reset config
g_file_storage gadget: reset interface

Then the same process to get descriptors and receive SCSI commands are
repeated. Is the SCSI_READ_10 command or something else causing the
problem? Please see the attached gadget driver log.

Thanks,
Victor
[start_transfer] 0 0
ept1 out queue len 0x200, buffer 0xc134
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 12
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28
0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: READ(10);  Dc=10, Di=4096;  Hc=10, Hi=4096
g_file_storage gadget-lun0: file read 4096 @ 0 - 4096
[start_transfer] 0 0
ept1 in queue len 0x1000, buffer 0xc134
len_num 4096, iter_num 0
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 3584, iter_num 1
0: 0x6d903ceb 
4: 0x736f646b 
8: 0x7366 
c: 0x10402 
len_num 3072, iter_num 2
0: 0xf8 
4: 0xfff0 
8: 0x0 
c: 0x0 
len_num 2560, iter_num 3
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 2048, iter_num 4
0: 0xf8 
4: 0xfff0 
8: 0x0 
c: 0x0 
len_num 1536, iter_num 5
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 1024, iter_num 6
0: 0x6f007442 
4: 0x7000 
8: 0xf00 
c: 0xc100 
len_num 512, iter_num 7
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 bulk_in_complete -- 0, 4096/4096
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 12 00 00 00 00 00 00 00 00
[start_transfer] 53425355 12
ept1 in queue len 0xd, buffer 0xc0c5c000
0: 0x53425355
4: 0x12
8: 0x0
bulk_in_complete -- 0, 13/13
[start_transfer] 0 0
ept1 out queue len 0x200, buffer 0xc134
before kagen2_ep_queue
g_file_storage gadget: disconnect or port reset
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 12
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28
0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: READ(10);  Dc=10, Di=4096;  Hc=10, Hi=4096
g_file_storage gadget-lun0: file read 4096 @ 0 - 4096
g_file_storage gadget: after calling do_scsi_command
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128b800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: disconnect or port reset
handle_exception begin
handle_exception wait until
handle_exception old_state 5
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
USB_RECIP_DEVICE
function address is 0x5d
exit A
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc128b800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 06 00 00 0a 00
g_file_storage gadget: get device qualifier
ept0 in queue len 0xa, buffer 0xc128b800
ep0_complete
g_file_storage gadget: ep0-in, length 10:
: 0a 06 00 02 00 00 00 40 01 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc128b800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 20 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x20, buffer 0xc128b800
ep0_complete
g_file_storage gadget: ep0-in, length 32:
: 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06
0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 03 00 00 ff 00
g_file_storage gadget: get string descriptor
ept0 in queue len 0x4, buffer 0xc128b800
ep0_complete
g_file_storage gadget: ep0-in, length 4:
: 04 03 09 04
g_file_storage gadget: ep0-setup

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Another possibility is to set up a virtual Windows system inside your
 Linux host.  Then try running the USB CV program on the virtual
 machine, and use usbmon on the host system to capture the USB traffic.

 I don't know if that will work, but it might.

Thanks. i will find a way to setup the virtual Windows inside Linux host.

 Ok. Today i tested the same mass storage gadget driver on Lenovo x100e
 Ubuntu. There is a strange problem. After SCSI_READ_10 command data is
 returned to the Ubuntu host. The gadget driver says:

 g_file_storage gadget: reset config
 g_file_storage gadget: reset interface

 Then the same process to get descriptors and receive SCSI commands are
 repeated. Is the SCSI_READ_10 command or something else causing the
 problem? Please see the attached gadget driver log.

 Perhaps you will recognize this answer (I have sent it several times
 before): I can't tell what is happening without seeing _both_ the log
 file on the gadget _and_ the usbmon trace on the host.

 Alan Stern


Yes, the matching gadget log and usbmon trace are attached in this
email. From the usbmon trace, the error (-108) is ESHUTDOWN from
SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10
command is received twice. First time it is ok, second time it causes
some problem. Which side could cause the ESHUTDOWN error?

Thanks,
victor
[start_transfer] 43425355 35
ept1 out queue len 0x200, buffer 0xc0c44000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 36
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 36 00 00 00 12 00 00 00 80 00 06 03
0010: 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: REQUEST SENSE;  Dc=6, Di=18;  Hc=6, Hi=18
g_file_storage gadget: bulk-in, length 18:
: 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00
0010: 00 00
[start_transfer] 60070 a00
ept1 in queue len 0x12, buffer 0xc0c44000
0: 0x60070
4: 0xa00
8: 0x0
c: 0x29
bulk_in_complete -- 0, 18/18
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 36 00 00 00 00 00 00 00 00
[start_transfer] 53425355 36
ept1 in queue len 0xd, buffer 0xc1338000
0: 0x53425355
4: 0x36
8: 0x0
bulk_in_complete -- 0, 13/13
[start_transfer] 60070 a00
ept1 out queue len 0x200, buffer 0xc0c44000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 37
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 37 00 00 00 00 10 00 00 80 00 0a 28
0010: 00 00 00 00 18 00 00 08 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: READ(10);  Dc=10, Di=4096;  Hc=10, Hi=4096
g_file_storage gadget-lun0: file read 4096 @ 12288 - 4096
[start_transfer] 0 0
ept1 in queue len 0x1000, buffer 0xc0c44000
len_num 4096, iter_num 0
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 3584, iter_num 1
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 3072, iter_num 2
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 2560, iter_num 3
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 2048, iter_num 4
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 1536, iter_num 5
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 1024, iter_num 6
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 512, iter_num 7
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 bulk_in_complete -- 0, 4096/4096
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 37 00 00 00 00 00 00 00 00
[start_transfer] 53425355 37
ept1 in queue len 0xd, buffer 0xc1338000
0: 0x53425355
4: 0x37
8: 0x0
bulk_in_complete -- 0, 13/13
[start_transfer] 0 0
ept1 out queue len 0x200, buffer 0xc0c44000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 38
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 38 00 00 00 00 10 00 00 80 00 0a 28
0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: READ(10);  Dc=10, Di=4096;  Hc=10, Hi=4096
g_file_storage gadget-lun0: file read 4096 @ 0 - 4096
[start_transfer] 0 0
ept1 in queue len 0x1000, buffer 0xc0c44000
len_num 4096, iter_num 0
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 3584, iter_num 1
0: 0x6d903ceb 
4: 0x736f646b 
8: 0x7366 
c: 0x10402 
len_num 3072, iter_num 2
0: 0xf8 
4: 0xfff0 
8: 0x0 
c: 0x0 
len_num 2560, iter_num 3
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 2048, iter_num 4
0: 0xf8 
4: 0xfff0 
8: 0x0 
c: 0x0 
len_num 1536, iter_num 5
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 
len_num 1024, iter_num 6
0: 0x6f007442 
4: 0x7000 
8: 0xf00 
c: 0xc100 
len_num 512, iter_num 7
0: 0x0 
4: 0x0 
8: 0x0 
c: 0x0 bulk_in_complete -- 0, 4096/4096
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 38 00 00 00 00 00 00 00 00
[start_transfer] 53425355 38
ept1 in queue len 0xd, buffer 0xc1338000
0: 0x53425355
4: 0x38
8: 0x0
bulk_in_complete -- 0, 13/13
[start_transfer] 0 0
ept1 out queue len 0x200, buffer 0xc0c44000

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Thanks a lot. i understand this part now. Do you notice the Set
 Address request is not seen by the gadget driver? The Set Address
 request is handled by the hardware. Could it be the root cause? As
 gadget driver may expect the address information from the host, and
 for now UDC driver just ignore the Set Address request ?

 That may very well be related to the problem.  Gadget drivers expect
 UDC drivers or UDC hardware to handle Set-Address requests
 automatically.  If your UDC or driver doesn't handle them, it could
 cause a test to fail.

The hardware handles Set Address request, and i can see the address of
the USB gadget being shown in Windows host. Here i attach the gadget
driver log for the Device Descriptor Test - Addressed State. The
test just failed after Get Configuration request.

Another question, in ep0_complete():
if (req-status == 0  req-context)
((fsg_routine_t) (req-context))(fsg);

Is req-context pointing to a function in UDC driver?

Thanks,
victor
# dmesg
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 06 00 00 0a 00
g_file_storage gadget: get device qualifier
ept0 in queue len 0xa, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 10:
: 0a 06 00 02 00 00 00 40 01 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
ept0 in queue len 0x1, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 1:
: 01
g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
ept0 in queue len 0x1, buffer 0xc1289800
ep0_complete
g_file_storage gadget: ep0-in, length 1:
: 01
# 

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 The CV log is attached (Dev_desc_test-Address state.html). Is it helpful?

 It doesn't help very much.  Can you get a more verbose log, one that
 lists all the transfers?

 It looks like the problem could be that the host and the gadget don't
 agree on what packets have been sent and received.  If that's true,
 you may need to use a USB bus analyzer to diagnose it.

Unfortunately, that USB 2.0 command verifier is not able to generate a
more verbose log.

 The g_file_storage gadget: in handle_exception loop is from the DBG
 that i added in fsg_main_thread(). I also attach an updated gadget log
 file, which corresponds to the CV log. I cannot figure out this part
 of the code about handle_exception(). Is a signal received and
 handle_exception() is supposed to perform some action?

 if (exception_in_progress(fsg) || signal_pending(current)) {
 handle_exception(fsg);
 DBG(fsg, in handle_exception loop\n);
 continue;
 }

 Okay, now I understand.  The in handle_exception loop line in the log
 is from an exception that happened earlier, before the
 Get-Config-Descriptor request.  The exception was caused by the
 preceding request, Set-Config: The USB_REQ_SET_CONFIGURATION case in
 standard_setup_req() calls raise_exception().  The handle_exception()
 routine then does the real work of changing the configuration, by
 calling do_set_config().  The Get-Config-Descriptor request just
 happened to arrive before your DBG line was executed.

Thanks a lot. i understand this part now. Do you notice the Set
Address request is not seen by the gadget driver? The Set Address
request is handled by the hardware. Could it be the root cause? As
gadget driver may expect the address information from the host, and
for now UDC driver just ignore the Set Address request ?

victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 When i run USB 2.0 Command Verifier on file gadget and UDC driver, an
 error in Command Verifier says Device must support being set to
 Addressed/Configured state.  Does it mean the gadget cannot support
 putting device in addressed state or configured state, as in
 supporting the Set Address and Set Configuration requests?

 I don't know what it means.  The gadget _does_ support being set to the
 Addressed and Configured states.  If it didn't support these things,
 you would not have been able to test it at all.

 Alan Stern


The gadget log when Command Verifier says Device must support being
set to Addressed/Configured state is attached. The log shows get
device descriptor, get configuration descriptor, and set configuration
requests are received. I see nothing wrong in gadget log. Does the log
indicate any problem that corresponds to the error message in Command
Verifier?

Thanks,
victor
# dmesg
g_file_storage gadget: disconnect or port reset
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 8a47aaf8
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 f8 aa 47 8a 00 00 00 00 00 00 0a 35
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE;  Dc=10, Dn=0;  Hc=10, 
Hn=0
attention condition
g_file_storage gadget: after calling do_scsi_command
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: disconnect or port reset
g_file_storage gadget: in handle_exception loop
g_file_storage gadget: in fsg-running loop
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
USB_RECIP_DEVICE
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
g_file_storage gadget: set interface 0
g_file_storage gadget: high-speed config #1
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 20 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x20, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 32:
: 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06
0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01
g_file_storage gadget: in handle_exception loop
[start_transfer] 43425355 8a47aaf8
ept1 out queue len 0x200, buffer 0xc0c44000
before kagen2_ep_queue
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
ept0 in queue len 0x12, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 06 00 00 0a 00
g_file_storage gadget: get device qualifier
ept0 in queue len 0xa, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 10:
: 0a 06 00 02 00 00 00 40 01 00
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 09 00
g_file_storage gadget: get configuration descriptor
ept0 in queue len 0x9, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 9:
: 09 02 20 00 01 01 04 c0 01
g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
ept0 in queue len 0x1, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 1:
: 01
g_file_storage gadget: ep0-setup, length 8:
: 80 08 00 00 00 00 01 00
g_file_storage gadget: get configuration
ept0 in queue len 0x1, buffer 0xc1289800
g_file_storage gadget: ep0-in, length 1:
: 01
# 

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

On Thu, May 30, 2013 at 10:44 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Thu, 30 May 2013, victor yeo wrote:

 I tested the g_zero with USB 2.0 Command Verifier. After the Command
 Verifier is run, the UDC gadget driver queue function is continuously
 being called, and the linux command prompt is frozen. Please see the
 attached UDC driver log. It looks like endpoint 1 in direction is
 called by USB 2.0 Command Verifier continuously. Is this weird?

 I don't know.

 You can't tell what's going on just by looking at the gadget.  You have
 to know what the host is doing as well.

 Alan Stern

When i run USB 2.0 Command Verifier on file gadget and UDC driver, an
error in Command Verifier says Device must support being set to
Addressed/Configured state.  Does it mean the gadget cannot support
putting device in addressed state or configured state, as in
supporting the Set Address and Set Configuration requests?

Thanks,
Victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Ok. What other gadget driver can i test with UDC driver? Is it the
 mass storage driver (mass_storage.c)?

 That is essentially the same as g_file_storage.  But there are lots of
 others.  You should start with g_zero and run the testusb suite.  See

 http://www.linux-usb.org/gadget/

 and

 http://www.linux-usb.org/usbtest/

 for more information.  Those web pages are pretty old and somewhat out
 of date, but they still have useful stuff.

I tested the g_zero with USB 2.0 Command Verifier. After the Command
Verifier is run, the UDC gadget driver queue function is continuously
being called, and the linux command prompt is frozen. Please see the
attached UDC driver log. It looks like endpoint 1 in direction is
called by USB 2.0 Command Verifier continuously. Is this weird?

thanks,
victor
# insmod kagen2_udc.ko 
kagen2_init
kagen2_plat_probe 1
kagen2_plat_probe 5
kagen2_plat_probe 6, 0xc2886000 0x1000
read pclk  scu 7 irqmask ffbd 7fff
val is 0x0
val is 0x8
check USB_OTGST 0x51000801 
check USB_OTGIRQ 0x51000810 
check USB_IRQINIT 0x70007 
check USB_OTGFSM 0xa1d191f 
check USB_OTGCTRL 0x51300801 
kagen2_plat_probe 8
register irq 32
kagen2_init 0
# insmod g_zero.ko 
bind
epname ep1
epname ep1
epname ep1
epname ep1
 gadget: Gadget Zero, version: Cinco de Mayo 2008
 gadget: zero ready
usb_gadget_udc_start
0xbf0386b8 0xbf0364c8
kagen2_start
0xbf0386b8 0xbf0364c8
0xc12d2cf0 0xbf030eb0
usb_gadget_connect
# ept0 in queue len 0x12, buffer 0xc12d3000
USB_RECIP_DEVICE
exit A
ept0 in queue len 0x12, buffer 0xc12d3000
ept0 in queue len 0x9, buffer 0xc12d3000
ept0 in queue len 0x4, buffer 0xc12d3000
ept0 in queue len 0x42, buffer 0xc12d3000
ept0 in queue len 0x20, buffer 0xc12d3000
ept0 in queue len 0x4, buffer 0xc12d3000
ept0 in queue len 0x18, buffer 0xc12d3000
ept0 in queue len 0x4, buffer 0xc12d3000
ept0 in queue len 0x18, buffer 0xc12d3000
ept0 in queue len 0x20, buffer 0xc12d3000
ept0 in queue len 0xa, buffer 0xc12d3000
ept0 in queue len 0x9, buffer 0xc12d3000
ept0 in queue len 0x20, buffer 0xc12d3000
ept0 in queue len 0x4, buffer 0xc12d3000
ept0 in queue len 0x3a, buffer 0xc12d3000
ept0 in queue len 0x18, buffer 0xc12d3000
ept0 in queue len 0x42, buffer 0xc12d3000
ept0 in queue len 0x2a, buffer 0xc12d3000
ept0 in queue len 0x2a, buffer 0xc12d3000
ept0 in queue len 0x12, buffer 0xc12d3000
USB_RECIP_DEVICE
exit A
ept0 in queue len 0x12, buffer 0xc12d3000
ept0 in queue len 0x9, buffer 0xc12d3000
zero gadget: high-speed config #3: source/sink
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7
ept1 in queue len 0x1000, buffer 0xc180d000
len_num 4096, iter_num 0
len_num 3584, iter_num 1
len_num 3072, iter_num 2
len_num 2560, iter_num 3
len_num 2048, iter_num 4
len_num 1536, iter_num 5
len_num 1024, iter_num 6
len_num 512, iter_num 7

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Is it possible to
 contribute the code to Linux community?

 Yes.  But first you should test it with other gadget drivers, not just
 g_file_storage.

Ok. What other gadget driver can i test with UDC driver? Is it the
mass storage driver (mass_storage.c)?
Has the g_file_storage passed the USB 2.0 Command Verifier test?

 On the other hand, i run the USB 2.0 command verifier to test the
 gadget, the gadget crashes at BOS descriptor test. I think the gadget
 is not able to handle BOS descriptor, is the gadget driver setup
 function returning negative error code for BOS descriptor?

 The crash dump you attached contained this line:

 PC is at kagen2_irq+0x290/0x3bc [kagen2_udc]

 This means the crash occurred inside the UDC driver, not the gadget
 driver.

Yes, the problem was solved just now.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Yes, it is silly. The hardware interrupt is not being generated for
 every SCSI command received, so the driver has to poll. I put the
 polling code in a thread, and this dilemma is fixed.

 Are you sure about this?  If it is correct, you should _fix_ the
 interrupt problem.  Don't try to work around it by creating a new
 thread.

 Figure out why there isn't an interrupt.  Does your driver forget to
 set an interrupt-enable bit?

 I still observe the SCSI_WRITE_10 command time out sometimes. When
 time out happens, the gadget log shows:

 g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442
 g_file_storage gadget: bulk-in set wedge

 Is it because the gadget expects 31 byte command, but 512 byte data is
 received instead?

 No.  It is because kagen2_ep_queue returned _before_ a new command was
 received, probably as a result of your polling thread.  Since there was
 no new command, the data in the buffer was wrong.

 The full UDC/gadget log is attached. Hope it is useful. If not, i will
 add in more printk statements.

 You can see the problem in the log:

 g_file_storage gadget: bulk-in, length 13:
 : 55 53 42 53 50 00 00 00 00 00 00 00 00
 [start_transfer] 53425355 50
 ept1 in queue len 0xd, buffer 0xc0c3c000
 0: 0x53425355
 4: 0x50
 8: 0x0
 bulk_in_complete -- 0, 13/13

 That was the end of the previous command.  Now the gadget waits for a
 new command to arrive.

 [start_transfer] 6f007442 7000
 ept1 out queue len 0x200, buffer 0xc1338000
 before kagen2_ep_queue
 after kagen2_ep_queue
 kagen2_ep_queue 512 512 512
 [kagen2_ep_queue] 6f007442 7000

 kagen2_ep_queue returned but there was no interrupt.  This means no new
 data was received, so the old data is still in the buffer.

 g_file_storage gadget: bulk_out_complete -- 0, 512/31
 g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442
 g_file_storage gadget: bulk-in set wedge

 That 0x6f007442 is the old data from the previous command, as you can
 see from the log messages (it is the same data that was present when
 kagen2_ep_queue was called).


Now the UDC driver is working on both Linux and Windows host, meaning
the read/write operation is ok. I still use the polling method,
because waiting for interrupt is not reliable. Is it possible to
contribute the code to Linux community?

On the other hand, i run the USB 2.0 command verifier to test the
gadget, the gadget crashes at BOS descriptor test. I think the gadget
is not able to handle BOS descriptor, is the gadget driver setup
function returning negative error code for BOS descriptor?

Thanks,
victor
g_file_storage gadget: high-speed config #1
Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0204000
[] *pgd=
Internal error: Oops - BUG: 817 [#1] PREEMPT ARM
Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core 
ka2000_sdio ka2000_sdhc
CPU: 0Not tainted  (3.4.4+ #43)
PC is at kagen2_irq+0x290/0x3bc [kagen2_udc]
LR is at handle_irq_event_percpu+0x30/0x178
pc : [bf02f704]lr : [c02496d0]psr: 6093
sp : c132de98  ip : 0002  fp : c132debc
r10:   r9 :   r8 : 
r7 : 0020  r6 : 0002  r5 : 0201  r4 : c12a8c00
r3 :   r2 : 0001  r1 : c12a8d1c  r0 : 
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005717f  Table: 0130c000  DAC: 0017
Process chkbusy_t (pid: 121, stack limit = 0xc132c270)
Stack: (0xc132de98 to 0xc132e000)
de80:   0080 0002
dea0: c12b9840 c049cf70  0020 c132dee4 c132dec0 c02496d0 bf02f484
dec0: c049cf70 c132c000 c12b9840 c132df94   c132df04 c132dee8
dee0: c0249878 c02496b0 f5006000 c049cf70  f5006000 c132df1c c132df08
df00: c024bd38 c0249828 c024bc24 0020 c132df34 c132df20 c02490e0 c024bc34
df20: 0040 0020 c132df4c c132df38 c0209c2c c02490c8 bf02f8c0 0013
df40: c132df5c c132df50 c0208410 c0209bd4 c132dfbc c132df60 c0208f14 c0208410
df60:  4000 0288001f c2886000 c12a8c00 c12a8c00 bf02f894 0013
df80:    c132dfbc c132c000 c132dfa8 4001 bf02f8c0
dfa0: 0013   c128dd58 c132dff4 c132dfc0 c022f8f4 bf02f8a4
dfc0: c128dd58  c12a8c00  c132dfd0 c132dfd0  c128dd58
dfe0: c022f860 c02191c8  c132dff8 c02191c8 c022f870 08f0 0402
Backtrace: 
[bf02f474] (kagen2_irq+0x0/0x3bc [kagen2_udc]) from [c02496d0] 
(handle_irq_event_percpu+0x30/0x178)
 r7:0020 r6: r5:c049cf70 r4:c12b9840
[c02496a0] (handle_irq_event_percpu+0x0/0x178) from [c0249878] 
(handle_irq_event+0x60/0x7c)
[c0249818] (handle_irq_event+0x0/0x7c) from [c024bd38] 
(handle_edge_irq+0x114/0x16c)
 r6:f5006000 r5: r4:c049cf70 r3:f5006000
[c024bc24] (handle_edge_irq+0x0/0x16c) from [c02490e0] 
(generic_handle_irq+0x28/0x38)
 r4:0020 r3:c024bc24
[c02490b8] (generic_handle_irq+0x0/0x38) from [c0209c2c] 
(handle_IRQ+0x68/0x8c)
 r4

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I am able to solve the SCSI command timeout problem by adding a code
 to check the hardware register busy bit continuously, in
 kagen2_ep_queue():

 do {
   read_hardware_register_busy_bit
 } while (hardware_is_busy)

 This is silly.  Drivers shouldn't poll in this way.  That's what
 interrupts are for.

 however, it causes the linux prompt to be non-responsive because the
 checking hardware register code is run continuously. If i add a
 schedule() to the do-while loop, the kagen2_ep_queue() will not be
 continued. How to go about fixing this dilemma?

 I can't say much more without seeing the code.  However, you should not
 need to wait for the hardware to do something -- instead the interrupt
 handler routine should be called when the hardware is finished.

Yes, it is silly. The hardware interrupt is not being generated for
every SCSI command received, so the driver has to poll. I put the
polling code in a thread, and this dilemma is fixed.

I still observe the SCSI_WRITE_10 command time out sometimes. When
time out happens, the gadget log shows:

g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442
g_file_storage gadget: bulk-in set wedge

Is it because the gadget expects 31 byte command, but 512 byte data is
received instead?

The full UDC/gadget log is attached. Hope it is useful. If not, i will
add in more printk statements.

Thanks,
victor
EP1 OUT IRQ 0x28
[start_transfer] f8 6005fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4d
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4d 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 04 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10);  Dc=10, Do=512;  Hc=10, Ho=512
[start_transfer] 43425355 4d
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] f8 fff0
g_file_storage gadget-lun0: file write 512 @ 2048 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4d 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4d
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4d
8: 0x0
bulk_in_complete -- 0, 13/13
EP1 OUT IRQ 0x28
[start_transfer] f8 fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4e
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4e 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 06 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10);  Dc=10, Do=512;  Hc=10, Ho=512
[start_transfer] 43425355 4e
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] 6f007442 7000
g_file_storage gadget-lun0: file write 512 @ 3072 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4e 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4e
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4e
8: 0x0
bulk_in_complete -- 0, 13/13
EP1 OUT IRQ 0x28
[start_transfer] 6f007442 7000
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4f
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4f 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 02 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10);  Dc=10, Do=512;  Hc=10, Ho=512
[start_transfer] 43425355 4f
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] f8 fff0
g_file_storage gadget-lun0: file write 512 @ 1024 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4f 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4f
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4f
8: 0x0
bulk_in_complete -- 0, 13/13
[start_transfer] f8 fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
EP1 OUT IRQ 0x28
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
EP1 OUT IRQ 0x28
[kagen2_ep_queue] 43425355 50
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 50 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 06 00 00 01 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: WRITE(10);  Dc=10, Do=512;  Hc=10, Ho=512
[start_transfer] 43425355 50
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] 6f007442 7000
g_file_storage gadget-lun0: file write 512 @ 3072 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Thanks! Indeed, the req-buf pointer was the one causing the crash
 problem. It happened when combining multiple 512 bytes data. I have
 fixed this bug.

 Now my UDC driver is almost ready. That is probably one more SCSI
 command timeout problem remaining, i am adding more printk to UDC
 driver and studying it.

I am able to solve the SCSI command timeout problem by adding a code
to check the hardware register busy bit continuously, in
kagen2_ep_queue():

do {
  read_hardware_register_busy_bit
} while (hardware_is_busy)

however, it causes the linux prompt to be non-responsive because the
checking hardware register code is run continuously. If i add a
schedule() to the do-while loop, the kagen2_ep_queue() will not be
continued. How to go about fixing this dilemma?

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 When copying a file to the USB gadget, sometimes the USB gadget will
 hang, sometimes the USB gadget will crash, sometimes the copy is ok.

 From the UDC driver log, when the USB gadget crashes, the host is
 sending 16384 bytes of data. It seems that bulk_out_complete() is not
 able to handle it.

 [c03282ec] (dev_printk+0x0/0x3c) from [bf035924]
 (bulk_out_complete+0xc4/0x1a8 [g_file_storage])
  r3:152a0e00 r2:a020d0e5
 [bf02fac4] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from
 [bf035f9c] (bulk_in_complete+0x24c/0x1010 [g_file_storage])

 The meaning of printk of kagen2_ep_queue 512 16384 512 in UDC driver log:
 ka_req-req.actual is 512
 ka_req-req.length is 16384
 length from hardware FIFO is 512

 Please see the attached UDC driver log and corresponding usbmon trace.

 I think the log says that bulk_out_complete() crashed when trying to
 dereference a NULL pointer.  Maybe req-buf, maybe req-context, maybe
 something else.

 But you already know that bulk_out_complete() crashed; you don't need
 me to tell you that.

 What you _do_ need is to find out why the crash occurred.  This means
 finding out which pointer is NULL.

Thanks! Indeed, the req-buf pointer was the one causing the crash
problem. It happened when combining multiple 512 bytes data. I have
fixed this bug.

Now my UDC driver is almost ready. That is probably one more SCSI
command timeout problem remaining, i am adding more printk to UDC
driver and studying it.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Another question from the bulk_out_complete() printout which is shown
 below. The req-actual is 512 byte. The bh-bulk_out_intended_length
 is 31. Is this a bug?

 g_file_storage gadget: get_next_command
 [start_transfer] 6f007442 7000
 ept1 out queue len 0x200, buffer 0xc133
 kagen2_ep_queue 512 512 512
 g_file_storage gadget: bulk_out_complete -- 0, 512/31
 .

 Well, it's a mistake.  It might be a bug.

 If the host really did send a 13-byte packet then it's definitely a
 bug.  But if the host sent a 512-byte packet then something else is
 wrong; it would mean the gadget was expecting a CBW packet but the host
 sent something else.

 Alan Stern

When copying a file to the USB gadget, sometimes the USB gadget will
hang, sometimes the USB gadget will crash, sometimes the copy is ok.

From the UDC driver log, when the USB gadget crashes, the host is
sending 16384 bytes of data. It seems that bulk_out_complete() is not
able to handle it.

[c03282ec] (dev_printk+0x0/0x3c) from [bf035924]
(bulk_out_complete+0xc4/0x1a8 [g_file_storage])
 r3:152a0e00 r2:a020d0e5
[bf02fac4] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from
[bf035f9c] (bulk_in_complete+0x24c/0x1010 [g_file_storage])

The meaning of printk of kagen2_ep_queue 512 16384 512 in UDC driver log:
ka_req-req.actual is 512
ka_req-req.length is 16384
length from hardware FIFO is 512

Please see the attached UDC driver log and corresponding usbmon trace.

Thanks,
victor
bulk_in_complete -- 0, 512/512
bulk_in_complete -- 0, 13/13
kagen2_ep_queue 31 512 31
bulk_in_complete -- 0, 512/512
bulk_in_complete -- 0, 13/13
kagen2_ep_queue 31 512 31
EP1 OUT IRQ 0x28
ep1_out: RX DMA done : NULL REQ on OUT EP-1
bulk_in_complete -- 0, 512/512
bulk_in_complete -- 0, 13/13
kagen2_ep_queue 31 512 31
EP1 OUT IRQ 0x28
ep1_out: RX DMA done : NULL REQ on OUT EP-1
kagen2_ep_queue 512 16384 512
kagen2_ep_queue 1024 16384 512
kagen2_ep_queue 1536 16384 512
kagen2_ep_queue 2048 16384 512
kagen2_ep_queue 2560 16384 512
kagen2_ep_queue 3072 16384 512
kagen2_ep_queue 3584 16384 512
kagen2_ep_queue 4096 16384 512
kagen2_ep_queue 4608 16384 512
kagen2_ep_queue 5120 16384 512
kagen2_ep_queue 5632 16384 512
kagen2_ep_queue 6144 16384 512
kagen2_ep_queue 6656 16384 512
kagen2_ep_queue 7168 16384 512
kagen2_ep_queue 7680 16384 512
kagen2_ep_queue 8192 16384 512
kagen2_ep_queue 8704 16384 512
kagen2_ep_queue 9216 16384 512
kagen2_ep_queue 9728 16384 512
kagen2_ep_queue 10240 16384 512
kagen2_ep_queue 10752 16384 512
kagen2_ep_queue 11264 16384 512
kagen2_ep_queue 11776 16384 512
kagen2_ep_queue 12288 16384 512
kagen2_ep_queue 12800 16384 512
kagen2_ep_queue 13312 16384 512
kagen2_ep_queue 13824 16384 512
kagen2_ep_queue 14336 16384 512
kagen2_ep_queue 14848 16384 512
kagen2_ep_queue 15360 16384 512
kagen2_ep_queue 15872 16384 512
kagen2_ep_queue 16384 16384 512
Unable to handle kernel NULL pointer dereference at virtual address 0004
pgd = c0204000
[0004] *pgd=
Internal error: Oops - BUG: 17 [#1] PREEMPT ARM
Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core 
ka2000_sdio ka2000_sdhc
CPU: 0Not tainted  (3.4.4+ #43)
PC is at dev_driver_string+0x30/0x44
LR is at __dev_printk+0x38/0x68
pc : [c0327ef8]lr : [c03280c4]psr: 2093
sp : c1333c08  ip : c1333c18  fp : c1333c14
r10: c0c38000  r9 : c12a0e34  r8 : 0001
r7 : c1289600  r6 : c129ec00  r5 : c1333c44  r4 : c129edd0
r3 : 0004  r2 : c1333c44  r1 : c129ec00  r0 : c129ec00
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005717f  Table: 01308000  DAC: 0017
Process file-storage-ga (pid: 123, stack limit = 0xc1332270)
Stack: (0xc1333c08 to 0xc1334000)
3c00:   c1333c3c c1333c18 c03280c4 c0327ed8 c0208eb8 c0208564
3c20: c129edd0 c12a0e00 c12896bc 0200 c1333c5c c1333c40 c0328320 c032809c
3c40: 0001 a020d0e5 c1333c4c c1333c64 c1333eb4 c1333c68 bf035924 c0328300
3c60: a020d0e5 152a0e00 152a0e00 c1333c78   000a 6013
3c80: c0c38000 c12a0e34 20313320 34660a3e 32613231 32203034 32323434 31363639
3ca0: 20532033 323a6942 3435303a 2d20313a 20353131 36393034 660a3c20 61323134
3cc0: 20303432 32343432 37313435 43203534 3a694220 35303a32 20313a34 30342030
3ce0: 3d203639 30303020 30303030 30302030 30303030 30203030 30303030 20303030
3d00: 30303030 30303030 30303020 30303030 30302030 30303030 30203030 30303030
3d20: 20303030 30303030 30303030 6166640a 34313936 34322030 34353234 34323831
3d40: 42205320 3a323a69 3a343530 312d2031 31203531 0a3c2033 36616664 30343139
3d60: 34343220 38343532 20323934 69422043 303a323a 313a3435 31203020 203d2033
3d80: 33353535 33353234 30613520 30303030 30302030 30303030 30203030 66640a30
3da0: 31393661 32203034 35323434 38353834 20532037 323a6f42 3435303a 2d20313a
3dc0: 20353131 3d203133 35353520 34323433 62352033 30303030 30203030 30303130
3de0: 20303030 30303038 38326130 30303020 30303030 30382033 30303030 30203830
3e00: 30303030 20303030 30303030 640a3030 39366166 20303431 32343432 37383435

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 All I can tell is that the gadget got hung after receiving the second
 WRITE command.  Can you figure out where it got hung and why?

 Victor, you don't seem to get the big pattern that keeps repeating
 here.  Every time something does wrong, you tell me about it.  Then I
 point out that you didn't include any debugging information, so you
 send part of a log.  Then I point out that you didn't send the entire
 log, or you didn't send logs for both the gadget and the host.  You end
 up losing a day or two each time this happens.

 There's a very simple lesson: When you're asking for help in debugging
 a problem, _always_ include _all_ the data that might be relevant.

 Here's another lesson, which I have pointed out a few times before but
 you still don't seem to have understood: When you want to know where
 your driver is hanging up, put a bunch of printk statements in it, at
 all the important spots.  Then you'll be able to see, in the log, the
 last printk that was executed before the hang.  That will tell you
 where the problem is.

Thanks. I will add more printk statements gradually. Now i discover if
i write to a large text file ( 48k) on USB gadget, linux will crash.
The full log of UDC and gadget driver when linux crashes, and
corresponding usbmon trace are attached. If these logs are not
helpful, i shall add more printk.

thanks,
victor
bulk_in_complete -- 0, 13/13
bulk_in_complete -- 0, 13/13
EP1 OUT IRQ 0x28
ep1_out: RX DMA done : NULL REQ on OUT EP-1
Unable to handle kernel paging request at virtual address 4000
pgd = c0204000
[4000] *pgd=
Internal error: Oops - BUG: 817 [#1] PREEMPT ARM
Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core 
ka2000_sdio ka2000_sdhc
CPU: 0Not tainted  (3.4.4+ #41)
PC is at th, wValue, wIndex;
unsigned int rdata, rdata1;

// setup data valid
val = readl(dev-base_addr + 0+0xfb0/0x199c [kagen2_udc]
LR is at console_unlock+0x208/0x218
pc : [bf03000c]lr : [c0216824]psr: 2093
sp : c1347c68  ip : c1347b98  fp : c1347eb4
r10: c1328000  r9 : c12b4db4  r8 : 0001
r7 : c12fedd0  r6 : 0200  r5 : c1346000  r4 : c12b4d80
r3 :   r2 : 0001  r1 : 015bb795  r0 : 4000
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005717f  Table: 01314000  DAC: 0017
Process file-storage-ga (pid: 122, stack limit = 0xc1346270)
Stack: (0xc1347c68 to 0xc1348000)
7c60:   0200 c1347c78   000a 6013
7c80: c1328000 c12b4db4 4f203150 50205455 0a474e49 61760909 203d206c 64616572
7ca0: 6564286c 623e2d76 5f657361 72646461 30202b20 63383178 090a3b29 6c617609
7cc0: 203d2620 7830 3030 0a3b 61760909 3d7c206c 30783020 30323030
7ce0: 3b303030 090a0909 69727709 286c6574 2c6c6176 76656420 61623e2d 615f6573
7d00: 20726464 7830202b 29633831 7d090a3b 6c65090a 69206573 76282066 3d206c61
7d20: 7830203d 0a293832 700a7b09 746e6972 4522286b 4f203150 49205455 30205152
7d40: 5c782578 202c226e 296c6176 09090a3b 70652f2f 756f5f31 65642874 0a3b2976
7d60: 73740909 74654c6b 4253555f 7461642e 203d2061 736e7528 656e6769 6f6c2064
7d80: 6429676e 0a3b7665 61740909 656c6b73 63735f74 75646568 2628656c 4c6b7374
7da0: 555f7465 3b294253 09090a0a 206c6176 6572203d 286c6461 2d766564 7361623e
7dc0: 64615f65 2b207264 31783020 3b293061 7d090a09 6c65090a 69206573 76282066
7de0: 3d206c61 7830203d 0a293432 090a7b09 452f2f09 69203150 5249206e 09090a51
7e00: 206c6176 6572203d 286c6461 2d766564 7361623e 64615f65 2b207264 31783020
7e20: 3b293838 7609090a 26206c61 7830203d  3030 09090a3b 206c6176
7e40: 30203d7c 30303078 30303030 09093b32 7709090a 65746972 6176286c 64202c6c
7e60: 3e2d7665 65736162 6464615f 202b2072 38317830 0a3b2938 090a0909 65090a7d
7e80: 2065736c 28206669 c03ef7b0 c12b4d80 c12fedd0 c1289600 c12896f8 c12896e0
7ea0: 7e00 c1346018 c1347eec c1347eb8 bf035f9c bf02fa88 c12896dc 
7ec0: c1289700 c1289600 00c8c000 c12896dc  c1289700 c1289600 00c8c000
7ee0: c1347f54 c1347ef0 bf036b14 bf035e64 c12896e0 000a c1347f04 c0209bd4
7f00: c1347fbc be00 7e00 0001 00c8c000  00c88000 
7f20: 0001 005f c12896dc c1289600  0001 005f c12896dc
7f40:  c1346018 c1347fbc c1347f58 bf038ce8 bf0368d8 bf03a316 bf03a29f
7f60: 0015 c127ea80 c1347f8c c1347f78 c02349c8 c1289604 c13207e0 c1320540
7f80: c1347fac c1347f90 c03f2fc0 c02365d0 c1337e00 c1337e00 c1289600 bf037bc0
7fa0: 0013    c1347ff4 c1347fc0 c022f8f4 bf037bd0
7fc0: c1337e00  c1289600  c1347fd0 c1347fd0  c1337e00
7fe0: c022f860 c02191c8  c1347ff8 c02191c8 c022f870  
Backtrace: 
[bf02fa78] (th, wValue, wIndex;
unsigned int rdata, rdata1;

// setup data valid
val = readl(dev-base_addr + 0+0xa1c/0x199c [kagen2_udc]) from 
[bf035f9c] (bulk_in_complete+0x24c/0x1010

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Thanks. I will add more printk statements gradually. Now i discover if
 i write to a large text file ( 48k) on USB gadget, linux will crash.
 The full log of UDC and gadget driver when linux crashes, and
 corresponding usbmon trace are attached. If these logs are not
 helpful, i shall add more printk.

 Unfortunately, I can't get anything useful out of the UDC driver crash
 log.

 It looks like the crash occurred somewhere inside the do_write()
 routine.  Perhaps within the call to start_transfer(), or perhaps
 within the vfs_write() call.

 Alan Stern


Just curious. The crash log shows the following UDC driver code which
is responsible to receive endpoint 0 setup data. However, the host PC
is sending SCSI_WRITE_10 command at the time of the crash. These two
does not correlate, right?

unsigned int rdata, rdata1;

// setup data valid
val = readl(dev-base_addr + 0+0xfb0/0x199c [kagen2_udc]

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Ok, i just fixed the last three bytes in the bulk-out transfer
 problem. Please see below for the log. Now the last three bytes are
 read correctly. After SCSI_WRITE_10 is received, the gadget driver
 prints g_file_storage gadget: disconnect or port reset, it means USB
 reset interrupt is received by the UDC driver. I don't know why USB
 reset interrupt is triggered.

 Then you need to figure out why.  Have you checked the dmesg log and
 usbmon trace on the host?

 Incidentally, for debugging it will help if you enable
 CONFIG_PRINTK_TIME in the gadget's kernel.

Thanks, i will enable the CONFIG_PRINTK_TIME. Nonetheless, now the
gadget driver and UDC driver are able to process some SCSI_WRITE_10
commands (i ignore the USB reset interrupt in UDC driver). Please see
the attached usbmon log. Will the log help?

Thanks,
victor


scsi_write_10_again04.log
Description: Binary data

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Obviously this disconnect or port reset message is related to the
 EP1 OUT IRQ 0x28 line above.  But why?  It looks like another bug.

 I see you still haven't fixed the last three bytes in the bulk-out
 transfer.

Ok, i just fixed the last three bytes in the bulk-out transfer
problem. Please see below for the log. Now the last three bytes are
read correctly. After SCSI_WRITE_10 is received, the gadget driver
prints g_file_storage gadget: disconnect or port reset, it means USB
reset interrupt is received by the UDC driver. I don't know why USB
reset interrupt is triggered.

[start_transfer]  
ept1 out queue len 0x200, buffer 0xc1298000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 f5 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 01 00 00 01 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: WRITE(10);  Dc=10, Do=512;  Hc=10, Ho=512
[start_transfer] 43425355 f5
ept1 out queue len 0x200, buffer 0xc1298000
g_file_storage gadget: disconnect or port reset
g_file_storage gadget: do_scsi_command
unlink (ep1) pio
kagen2_set_halt 1 0
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/512
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: handle_exception
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  That's right.  Interrupts can occur at almost any time (on
  multiprocessor systems they can occur even when interrupts are disabled
  on some of the CPUs).

 I am confused. I add the spinlock functions to kagen2_ep_queue function.

   spin_lock_irqsave(dev-lock, flags);
   ..
   spin_unlock_irqrestore(dev-lock, flags);

 When kagen2_ep_queue function is called, the error BUG: scheduling
 while atomic: swapper/0/0x0002 occurs. I test the same spinlock
 functions in other device module. It is ok in other device module.

 While the function holds a spinlock, it is not allowed to sleep.

 The BUG occurs because kagen2_ep_queue must call some function that can
 sleep.  But since you did not provide the rest of the BUG message
 (including the stack trace), I can't tell what function it calls.

The BUG: scheduling while atomic is solved. Need to add extra
spinlock functions for req-complete() as below:
spin_unlock(dev-lock);
req-complete(ep, req);
spin_lock(dev-lock);

Now, the SCSI_WRITE_10 command is received but the data is not
received. There is disconnect or port reset after SCSI_WRITE_10
command. Please see below:

[start_transfer] 613e2d71 61757463
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 f6 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 01 00 00 01 00 00 00 00 80 b7 21
EP1 OUT IRQ 0x28
g_file_storage gadget: disconnect or port reset
g_file_storage gadget: SCSI command: WRITE(10);  Dc=10, Do=512;  Hc=10, Ho=512
[start_transfer] 43425355 f6
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: do_scsi_command
unlink (ep1) pio
kagen2_set_halt 1 0
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/512
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: handle_exception


g_file_storage gadget: do_scsi_command is from extra DBG statement
that i added in file_storage.c.

if (do_scsi_command(fsg) || finish_reply(fsg))
{
DBG(fsg, do_scsi_command\n);
continue;
}

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  It is likely that this bug occurs because you don't use a spinlock in
  kagen2_ep_queue.  Does the interrupt handler routine use a spinlock?

 Spinlock is Not used in interrupt handler routine.

 Then that's the reason for this bug.

 [start_transfer] 53425355 10d
 ept1 out queue len 0x200, buffer 0xc1304000
 g_file_storage gadget: bulk-out, length 31:

 Is the kagen2_ep_queue function gotten interrupted here? So the
 kagen2_ep_queue and interrupt routine need spinlock for
 synchronisation?

 That's right.  Interrupts can occur at almost any time (on
 multiprocessor systems they can occur even when interrupts are disabled
 on some of the CPUs).

I am confused. I add the spinlock functions to kagen2_ep_queue function.

  spin_lock_irqsave(dev-lock, flags);
  ..
  spin_unlock_irqrestore(dev-lock, flags);

When kagen2_ep_queue function is called, the error BUG: scheduling
while atomic: swapper/0/0x0002 occurs. I test the same spinlock
functions in other device module. It is ok in other device module.

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 How the UDC driver know when the request is really complete?

 An OUT request is really complete when either:

 The total number of bytes copied into req.buffer (i.e.,
 req.actual) is equal to req.length, or

 The number of bytes received in the last packet is smaller
 than ep.maxpacket.

I made some changes regarding req.actual. Now the UDC driver still
cannot process SCSI_WRITE_10 command. Please see the attached UDC
driver log when i try to write to a text file. There should be three
SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and
SCSI_WRITE_10. SCSI_WRITE_10 is not received properly.

Thanks,
victor
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 0d 01 00 00 12 00 00 00 80 00 06 03
0010: 00 00 00 12 00 00 00 00 00 00 00 00 c3 63 4a
g_file_storage gadget: SCSI command: REQUEST SENSE;  Dc=6, Di=18;  Hc=6, Hi=18
g_file_storage gadget: bulk-in, length 18:
: 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00
0010: 00 00
[start_transfer] 60070 a00
ept1 in queue len 0x12, buffer 0xc1344000
0: 0x60070
4: 0xa00
8: 0x0
c: 0x29
bulk_in_complete -- 0, 18/18
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 0d 01 00 00 00 00 00 00 00
[start_transfer] 53425355 10d
ept1 in queue len 0xd, buffer 0xc1304000
0: 0x53425355
4: 0x10d
8: 0x0
bulk_in_complete -- 0, 13/13
EP1 OUT IRQ 0x28
ep1_out: RX DMA done : NULL REQ on OUT EP-1
[start_transfer] 60070 a00
ept1 out queue len 0x200, buffer 0xc1344000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 0e 01 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 c3 63 4a
g_file_storage gadget: SCSI command: TEST UNIT READY;  Dc=6, Dn=0;  Hc=6, Hn=0
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 0e 01 00 00 00 00 00 00 00
[start_transfer] 53425355 10e
ept1 in queue len 0xd, buffer 0xc1344000
0: 0x53425355
4: 0x10e
8: 0x0
bulk_in_complete -- 0, 13/13
EP1 OUT IRQ 0x28
ep1_out: RX DMA done : NULL REQ on OUT EP-1
[start_transfer] 53425355 10d
ept1 out queue len 0x200, buffer 0xc1304000
g_file_storage gadget: bulk-out, length 31:
EP1 OUT IRQ 0x28
epnum 1 in 0 len 0 512 0
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
g_file_storage gadget: bulk_out_complete -- 0, 0/31
g_file_storage gadget: invalid CBW: len 0 sig 0x43425355
g_file_storage gadget: bulk-in set wedge
g_file_storage gadget: get_next_command
[start_transfer] 43425355 10f
ept1 out queue len 0x200, buffer 0xc1304000

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I made some changes regarding req.actual. Now the UDC driver still
 cannot process SCSI_WRITE_10 command. Please see the attached UDC
 driver log when i try to write to a text file. There should be three
 SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and
 SCSI_WRITE_10. SCSI_WRITE_10 is not received properly.

 No, it isn't.  Here's what the log says:

 EP1 OUT IRQ 0x28
 ep1_out: RX DMA done : NULL REQ on OUT EP-1
 [start_transfer] 53425355 10d
 ept1 out queue len 0x200, buffer 0xc1304000
 g_file_storage gadget: bulk-out, length 31:

 This is from bulk_out_complete, when the WRITE(10) was received.

 EP1 OUT IRQ 0x28
 epnum 1 in 0 len 0 512 0
 g_file_storage gadget: bulk-out, length 0:

 This line indicates a bug.  It means the UDC driver called
 bulk_out_complete again, even though the previous request was no longer
 queued and no new requests had been submitted yet.

 It is likely that this bug occurs because you don't use a spinlock in
 kagen2_ep_queue.  Does the interrupt handler routine use a spinlock?

Spinlock is Not used in interrupt handler routine.

[start_transfer] 53425355 10d
ept1 out queue len 0x200, buffer 0xc1304000
g_file_storage gadget: bulk-out, length 31:

Is the kagen2_ep_queue function gotten interrupted here? So the
kagen2_ep_queue and interrupt routine need spinlock for
synchronisation?

EP1 OUT IRQ 0x28
epnum 1 in 0 len 0 512 0
g_file_storage gadget: bulk-out, length 0:

 Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT
 READY commands weren't received correctly either.  The last three bytes
 in each command should be 0, but they aren't.  They are: c3 63 4a.
 Where did those values come from?

Yes, i haven't noticed the c3 63 4a. Clearly the last three bytes
should be zero. Maybe the UDC driver has a bug (Do the last 3 bytes
matter for file gadget? ). Here is the usbmon trace that corresponds
to the UDC log. It is the proof that the last three bytes are zero.

Thanks,
victor


scsi_write_10_again02.log
Description: Binary data

Re: [PATCH] usb/gadget: Add options to build only functions modules

[victor]

unsubscribe linux-usb


CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee), be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Please see the attached kagen2_ep_queue(). As long as it is called, it
 will queue the request and read packets from hardware, in the same
 if-else branch for bulk out endpoint. The interrupt handler will NOT
 accept packet if request is NOT queued. If request is queued,
 interrupt handler will accept the packet.

 This code is wrong.  See what happens when a request for ep1-out is
 submitted:

   /* ep1 OUT endpoint */
   else if (in == 0)
 {
   // read from EP1 OUT buffer
   if (num == 1)
 {
   unsigned int val;
   unsigned int val_arr[8];
   int i;

   // get byte count from hardware
   val = readl(dev-base_addr + 0x008);
   len = val  0xFF;

 Why do you expect there to be any data in the hardware FIFO at this
 point?  You said that the hardware will not accept any data if a
 request is not queued.  Well, before this point the request wasn't
 queued, so there shouldn't be any data.

I am sorry for unclear writing. What i mean is: If a request is not
queued, the hardware will still accept data, but interrupt controller
will not read the data from the hardware FIFO.


   // read from hardware fifo1 data
   for (i = 0; i  len/4; i++)
   {
   val_arr[i] = readl(dev-base_addr + 0x084);
   }

 val_arr is declared as an array of 8 unsigned ints.  That means its
 total size is 32 bytes.  What happens if len  32?  You will end up
 overwriting part of the stack.

Yes! This is a bug. I only thought about the 31 byte CBW for bulk out
endpoint. I forgot about the SCSI_WRITE_10 command. Thanks!!

   list_add_tail(ka_req-queue, ka_ep-queue);

   ka_req-req.actual = len;
   memcpy(ka_req-req.buf, val_arr[0], len);

   ka_req-req.complete(ka_ep-ep, ka_req-req);

 You should not call req.complete until the request really is complete.
 For example, what happens here if the host hasn't sent any packets yet?
 Or what happens if req is waiting to receive 1024 bytes but the host
 has sent only 512 bytes so far?

How the UDC driver know when the request is really complete?

 Also, all the data gets copied _twice_: once from the hardware FIFO
 into val_arr, and then again from val_arr into req.buf.  That's a waste
 of time; the data should be copied directly from the FIFO into req.buf.

Agree.

 2) Repeatedly (many many times), the same SCSI_READ_10 command is
 received by UDC driver, processed by gadget driver, and UDC driver
 sends out data and CSW to host. On usbmon trace, only one instance of
 the SCSI_READ_10 is observed.

 This is probably because you are copying the same data from the FIFO to
 req.buffer many times.

I am curious about it. After data is read from FIFO, the FIFO will
become empty. Still cannot figure out how the same data is read from
the FIFO many times.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 This is the stack dump when the completion routine is called without
 an interrupt occurring first, is it useful?

 Backtrace:
 [c020c0fc] (dump_backtrace+0x0/0x110) from [c03ef5e4] 
 (dump_stack+0x18/0x1c)
  r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
 [c03ef5cc] (dump_stack+0x0/0x1c) from [bf02fecc]
 (kagen2_ep_queue+0x520/0x598 [kagen2_udc])
 [bf02f9ac] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from
 [bf036068] (fsg_lun_open+0x578/0x1278 [g_file_storage])
 [bf035f20] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from
 [bf037cd4] (fsg_main_thread+0x10c/0x155c [g_file_storage])
  r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600
 [bf037bc8] (fsg_main_thread+0x0/0x155c [g_file_storage]) from
 [c022f8f4] (kthread+0x94/0xa0)
 [c022f860] (kthread+0x0/0xa0) from [c02191c8] (do_exit+0x0/0x6f0)
  r6:c02191c8 r5:c022f860 r4:c1327e00

 This shows that kagen2_ep_queue() calls kareq-req.complete.  Perhaps
 indirectly, through another function.  If this is true then it's
 probably a bug.  You should check it out.

Yes, the kagen2_ep_queue() calls req-req.complete directly. I thought
this is necessary to pass the packets to gadget driver for processing?
req-req.complete is mapped to bulk_out_complete() or
bulk_in_complete().

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Yes, the kagen2_ep_queue() calls req-req.complete directly. I thought
 this is necessary to pass the packets to gadget driver for processing?

 It is necessary to call req.complete when the request has _completed_!
 That's why the callback is named complete!

 req-req.complete is mapped to bulk_out_complete() or
 bulk_in_complete().

 A bulk-out request isn't complete until the data has been received from
 the host.  A bulk-in request isn't complete until the data has been
 sent to the host (or at least copied into a hardware buffer).

 kagen2_ep_queue() gets called when the bulk-out request is submitted,
 right?  So the request is not complete at that time.  It isn't complete
 until the host has sent the data.  After all, if you haven't received
 the packets from the host yet, how can you pass the packets to the
 gadget driver for processing?

 Alan Stern


For bulk out endpoint, I code the kagen2_ep_queue() to read the
packets from the USB hardware, then call bulk_out_complete() via
req-req.complete. Is this the correct way?

Or i should only read the bulk out endpoint when bulk-out endpoint
interrupt is received?

thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 While kagen2_ep_queue() is running, there shouldn't be any packets in
 the USB hardware.  The hardware should refuse to accept any packets,
 sending NAKs back to the host, until a request has been submitted and
 queued.

 When the request is queued, that's when you should tell the hardware to
 accept data from the host.  After that, each time a packet arrives from
 the host, either the hardware or the UDC driver should store the packet
 data in the request's buffer.  When the buffer is full or a short
 packet is received (the UDC driver's interrupt handler will know when
 this happens) then the UDC driver should call req.complete.

Please see the attached kagen2_ep_queue(). As long as it is called, it
will queue the request and read packets from hardware, in the same
if-else branch for bulk out endpoint. The interrupt handler will NOT
accept packet if request is NOT queued. If request is queued,
interrupt handler will accept the packet.

Somehow, there is still timing problem in UDC driver and it is hard to
pin down the root cause. It could be due to interaction of UDC driver
queue() and gadget driver fsg_main_thread() main loop.

1) When writing to gen2 gadget, SCSI_READ_10 or or SCSI_REQUEST_SENSE
commands are received by UDC driver, but gadget did not process the
commands. (cannot get past get_next_command() in fsg_main_thread)

2) Repeatedly (many many times), the same SCSI_READ_10 command is
received by UDC driver, processed by gadget driver, and UDC driver
sends out data and CSW to host. On usbmon trace, only one instance of
the SCSI_READ_10 is observed.

3) More severe case, if removing one printk statement in
bulk_in_complete(), USB gadget device cannot be recognised by host.

Thanks,
victor
static int kagen2_ep_queue(struct usb_ep *ep,
struct usb_request *req, gfp_t gfp_flags)
{
	struct kagen2_ep *ka_ep;
	struct kagen2_request *ka_req;
	struct kagen2 * dev;
	unsigned phys;
	int num, len, in;

	ka_req = container_of(req, struct kagen2_request, req);
	
	if (!req || !req-complete || !req-buf
		|| !list_empty(ka_req-queue))
	{
		printk(exit A\n);
		return -EINVAL;
	}
	ka_ep = container_of(ep, struct kagen2_ep, ep);
	
	if (!ep || (!ka_ep-desc  ka_ep-num != 0))
	{
		printk(exit B\n);
		return -EINVAL;
	}
	dev = ka_ep-dev;

	if (!dev || !dev-driver || dev-gadget.speed == USB_SPEED_UNKNOWN)
	{
		printk(exit C\n);
		return -ESHUTDOWN;
	}
	num = ka_ep-desc-bEndpointAddress  USB_ENDPOINT_NUMBER_MASK;
	in = (ka_ep-desc-bEndpointAddress  USB_DIR_IN) != 0;
	phys = (unsigned)req-buf;
	len = req-length;

	printk(KERN_DEBUG ept%d %s queue len 0x%x, buffer 0x%x\n,
		num, in ? in : out, len, phys);

	/* ep0 IN endpoint */
	if ((len  0)  (num == 0)  (in != 0))
	{
		req-actual = 0;
ep0_in(phys, len, dev);
		req-actual += len;
		req-complete(ep, req);
		list_del_init(ka_req-queue);
		return 0;	
	}
	/* ep1 IN endpoint */
	else if ((len = 0)  (num == 1)  (in != 0))
	{
		req-actual = 0;
		ep1_in(phys, len, dev);
		req-actual += len;
		req-complete(ep, req);
		list_del_init(ka_req-queue);
		return 0;	
	}
	/* ep1 OUT endpoint */
	else if (in == 0)
{
		// read from EP1 OUT buffer
		if (num == 1)
{
			unsigned int val;
			unsigned int val_arr[8];
			int i;

	// get byte count from hardware
	val = readl(dev-base_addr + 0x008);
		len = val  0xFF;

	// read from hardware fifo1 data
	for (i = 0; i  len/4; i++)
		{
	val_arr[i] = readl(dev-base_addr + 0x084);
		}

			list_add_tail(ka_req-queue, ka_ep-queue);

			ka_req-req.actual = len;
			memcpy(ka_req-req.buf, val_arr[0], len);

			ka_req-req.complete(ka_ep-ep, ka_req-req);
			list_del_init(ka_req-queue);
			 
// clear hardware OUT1CS register
val = readl(dev-base_addr + 0x008);
val = 0x00ff;
writel(val, dev-base_addr + 0x008);
		}
}
	return 0;
}

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I change that in UDC driver queue function, adding in a length check:

 if (len  0)
 {
 ka_req-req.complete(ka_ep-ep, 
 ka_req-req);
 list_del_init(ka_req-queue);
 }

 What is len?  Is it the packet size?  If it is then this check is
 wrong, because the UDC driver must accept zero-length packets.

Yes, it is packet size. So UDC driver must accept zero-length packets
sent from USB host?

 Just before the line that calls ka_req-req.complete, add:

 WARN_ON(!victor_test);
 victor_test = 0;

 Then you'll get a stack dump every time the completion routine is
 called without an interrupt occurring first.  The stack dump will help
 you to figure out why this is going wrong and where the problem is.

This is the stack dump when the completion routine is called without
an interrupt occurring first, is it useful?

Backtrace:
[c020c0fc] (dump_backtrace+0x0/0x110) from [c03ef5e4] (dump_stack+0x18/0x1c)
 r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
[c03ef5cc] (dump_stack+0x0/0x1c) from [bf02fecc]
(kagen2_ep_queue+0x520/0x598 [kagen2_udc])
[bf02f9ac] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from
[bf036068] (fsg_lun_open+0x578/0x1278 [g_file_storage])
[bf035f20] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from
[bf037cd4] (fsg_main_thread+0x10c/0x155c [g_file_storage])
 r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600
[bf037bc8] (fsg_main_thread+0x0/0x155c [g_file_storage]) from
[c022f8f4] (kthread+0x94/0xa0)
[c022f860] (kthread+0x0/0xa0) from [c02191c8] (do_exit+0x0/0x6f0)
 r6:c02191c8 r5:c022f860 r4:c1327e00

 Here's an example.  This shows the port status immediately after the
 first port reset in the April 22 usbmon trace:

 f2f4f740 1985276053 S Ci:2:002:0 s a3 00  0004 0004 4 
 f2f4f740 1985276154 C Ci:2:002:0 0 4 = 03011000

 The 01 in the second byte of the response indicates full speed.  If
 the connection were high speed, the second byte would be 05.  See
 Section 11.24.2.7 in the USB-2.0 specification, and especially the
 description of bit 10 in Table 11-21 and 11.24.2.7.1.8.

Thanks, i found the bit 10 in Table 11-21 Port Status Field.

0 = Full-speed device attached to this port.
1 = High-speed device attached to this port.

victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Here is a full log from the beginning which shows another problem.
 When the SCSI_READ_10 command below is received, there is a disconnect
 or port reset which causes the (-32) broken pipe problem.

 You really need to fix the old problems before worrying about new
 problems.  The set_halt still isn't working, and the UDC continues to
 continues to call bulk_out_complete multiple times without receiving
 any packets.

I change that in UDC driver queue function, adding in a length check:

if (len  0)
{
ka_req-req.complete(ka_ep-ep, ka_req-req);
list_del_init(ka_req-queue);
}

However, i still observe the SCSI command being received by UDC and
gadget driver, but not processed by gadget driver.

For the UDC and gadget driver log, it looks like the flow cannot get
past get_next_command() of fsg_main_thread(). The log is attached.

[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command

The same SCSI command as seen on usbmon log:

f2f4fe40 3842078083 S Bo:2:050:1 -115 31 = 55534243 0900 
0600    00
f2f4fe40 3842078159 C Bo:2:050:1 0 31 
f2f4fe40 3842078182 S Bi:2:050:1 -115 13 
f2f4fe40 3872633965 C Bi:2:050:1 -104 0


 It would be easier to maintain a stable link if the UDC connected at
 high speed in the first place.  The usbmon log shows that the
 connection was at full speed (12 Mb/s), not high speed (480 Mb/s) --
 which means that this line:

 g_file_storage gadget: high-speed config #1

 in the gadget log indicates another bug in the UDC driver.  It told the
 gadget driver that the connection was high speed, but the connection
 really was full speed.

How to read from usbmon log that the connection was at full speed?

Thanks,
victor
# dmesg
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
g_file_storage gadget: get_next_command
[start_transfer] 43425355 9
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I modified the UDC driver to send out zero length data packet. Now the
 linux host is able to see the USB gadget as a mass storage device and
 read from USB gadget. However, writing to USB gadget fails. The
 SCSI_WRITE_10 command often receives (-104). The usbmon trace showing
 this failure is attached. Is the bulk-out endpoint unable to receive
 command and data continuously, due to error in UDC driver?

 It looks like the data gets received okay.  I can't tell what's going
 wrong because you did not post the gadget log showing the WRITE
 commands.

When writing to USB gadget from Linux host, the SCSI_WRITE_10 command
is sent out from the Linux host, but the USB gadget receives zero
length packet. And after a long wait of 30 seconds, the Linux host
resets the connection (-104). The usbmon trace and the UDC driver log
are attached.

g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31

I think UDC driver receives the zero length packet on bulk out endpoint.

Thanks,
victor
# dmesg
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c0007g_file_storage gadget: 
bulk_out_complete -- 0, 0/31

g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/31
[start_transfer] 43425355 c5
ept1 out queue len 0x200, buffer 0xc133c000
g_file_storage gadget: bulk-out, length 0:


usbmon_write_gadget2.log
Description: Binary data

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 From the usbmon trace and driver log, i can only see that TEST UNIT
 READY command is sent out but UDC driver does not receive it. May i
 ask, under what circumstances, is gadget driver calling
 start_transfer() to schedule reading from bulk-out endpoint ?

 file_storage.c calls start_transfer() whenever it expects the host to
 send a bulk-out packet.  These times include:

 When the gadget is waiting for the host to send a CBW packet
 containing a SCSI command;

I think the get_next_command() calls start_transfer() to read the next
CBW. After unknown command 0xa1 is received, and if UDC driver doesn't
halt the endpoint, why the get_next_command() does not call
start_transfer() to read the next CBW? Somehow, i don't understand.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I think the get_next_command() calls start_transfer() to read the next
 CBW. After unknown command 0xa1 is received, and if UDC driver doesn't
 halt the endpoint, why the get_next_command() does not call
 start_transfer() to read the next CBW? Somehow, i don't understand.

 I think that the previous call to start_transfer() never returned.
 Probably because the usb_ep_queue() routine got hung up.  Therefore
 get_next_command() wasn't executed.

 Here's an extract from the log you posted, showing the 0xa1 command:

 [start_transfer] f 40a08
 ept1 out queue len 0x200, buffer 0xc12ac000
 g_file_storage gadget: bulk-out, length 31:
 : 55 53 42 43 12 00 00 00 00 02 00 00 80 00 0c a1
 0010: 08 2e 00 01 00 00 00 00 ec 00 00 00 f8 9e 34
 bulk_out_complete -- 0, 31/31
 g_file_storage gadget: SCSI command: Unknown xa1;  Dc=12, Du=0;  Hc=12, 
 Hi=512
 g_file_storage gadget: bulk-in, length 0:
 [start_transfer] 43425355 12
 ept1 in queue len 0x0, buffer 0xc12ac000
 g_file_storage gadget: bulk-in set halt

I think here is the problem: the  bulk-in of length 0. This zero
length packet is never sent out nor received by the host. What is this
zero length packet?

 kagen2_set_halt 1 1
 g_file_storage gadget: sending command-failure status
 g_file_storage gadget:   sense data: SK x05, ASC x20, ASCQ x00;  info x0
 g_file_storage gadget: bulk-in, length 13:
 : 55 53 42 53 12 00 00 00 00 02 00 00 01
 [start_transfer] 53425355 12
 ept1 in queue len 0xd, buffer 0xc133c000
 0: 0x53425355
 4: 0x12
 8: 0x200

In comparison, the CSW is sent out and received by the host.

 It looks like the UDC driver get hung up right here, somewhere inside
 the usb_ep_queue() routine.

I think the usb_ep_queue() routine is re-entrant. If one instance of
it hangs, the next instance will not be affected.

 At this point, the host got tired of waiting for the gadget to accept
 the next CBW, so it issued a port reset.

Yes, i fully agree!

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Here are another problem. In usbmon trace, the time difference
 between first SCSI_INQUIRY command and the second TEST_UNIT_READY
 command is large. So i check the driver log file. When SCSI_INQUIRY is
 received, start_transfer() is called, then UDC ep_queue function is
 called, then bulk_out_complete() is called. This sequence is repeated
 many times.

In fact, this problem starts even _before_ the INQUIRY command is
received.  The log shows that the UDC driver calls the
bulk_out_complete routine over and over, even though no packet was
received and ka2000_ack_irq didn't run.  The same thing happens after
the INQUIRY is received.
The UDC driver is not supposed to call bulk_out_complete until a
transfer has completed.
After the gadget was reset, the problem didn't occur any more.

Looking at the log, the UDC driver queue function is called repeatedly
by start_transfer() before SCSI_INQUIRY is received. Is this ok?

[start_transfer] ebfe e5943010
ept1 out queue len 0x200, buffer 0xc133c000
bulk_out_complete -- 0, 0/31

 Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it
 should not be sent at all, and the UDC driver should send the STALL
 packet instead of this CSW?

 No.  As long as the Halt feature is set for the bulk-in endpoint, the
 UDC should send STALL packets.  When the host clears the Halt feature,
 then the UDC should send the CSW packet.

 Just curious, after this 0xa1 is received and bulk-in endpoint is
 halted. The Linux host tries to send TEST_UNIT_READY command, and UDC
 driver could not receive it because endpoint is halted and in reset
 condition.

 That sounds very wrong.  The bulk-IN endpoint was halted, but the TEST
 UNIT READY command is sent to the bulk-OUT endpoint.  There should be
 no problem receiving it.

When debugging the UDC driver halt problem, i disable setting the halt
feature for bulk-in endpoint and does not call fsg_disconnect() when
reset interrupt occurs. Now when unknown SCSI command 0xa1 is
received, the usbmon trace still shows the same error, and subsequent
TEST_UNIT_READY is not received by UDC driver, and (-104) is
connection reset error. It seems that UDC and gadget driver somehow
still reset the USB connection? Driver has to reset the USB connection
when unknown SCSI command is received?

f3a2b7c0 486132750 S Bo:2:060:1 -115 31 = 55534243 1200 0002
8ca1 082e0001  ec00 00
f3a2b7c0 486132805 C Bo:2:060:1 0 31 
f2c92340 486132814 S Bi:2:060:1 -115 512 
f2c92340 486236946 C Bi:2:060:1 -121 13 = 55534253 1200 0002 01
f3a2b7c0 486237000 S Bi:2:060:1 -115 13 
f3a2b7c0 493408020 C Bi:2:060:1 -104 0
.
f3a2b7c0 493652682 S Bo:2:060:1 -115 31 = 55534243 1300 
0600    00
f3a2b7c0 493652755 C Bo:2:060:1 0 31 
f3a2b7c0 493652761 S Bi:2:060:1 -115 13 
f3a2b7c0 503652077 C Bi:2:060:1 -104 0

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Thanks, i print out additional information in gadget driver and UDC
 driver. Here are another problem. In usbmon trace, the time difference
 between first SCSI_INQUIRY command and the second TEST_UNIT_READY
 command is large. So i check the driver log file. When SCSI_INQUIRY is
 received, start_transfer() is called, then UDC ep_queue function is
 called, then bulk_out_complete() is called. This sequence is repeated
 many times.

 In fact, this problem starts even _before_ the INQUIRY command is
 received.  The log shows that the UDC driver calls the
 bulk_out_complete routine over and over, even though no packet was
 received and ka2000_ack_irq didn't run.  The same thing happens after
 the INQUIRY is received.

 The UDC driver is not supposed to call bulk_out_complete until a
 transfer has completed.

 After the gadget was reset, the problem didn't occur any more.

  What is the reason that SCSI_INQUIRY is not processed by
 gadget driver? Is it due to some problem in UDC driver?

 The INQUIRY _was_ processed by the gadget driver.  Yes, the UDC driver
 has a problem; see above.

 After that, i can see when the unknown command 0xa1 is received, the
 UDC driver sets the Halt feature.

 Look at line 1339 of the UDC log file:

 g_file_storage gadget: SCSI command: MODE SENSE(6);  Dc=6, Di=192;  Hc=6, 
 Hi=192
 g_file_storage gadget: bulk-in, length 16:
 : 0f 00 00 00 08 0a 04 00 ff ff 00 00 ff ff ff ff
 [start_transfer] f 40a08
 ept1 in queue len 0x10, buffer 0xc12ac000
 0: 0xf
 4: 0x40a08
 8: 0x
 c: 0x
 ka2000_ack_irq(32)
 bulk_in_complete -- 0, 16/16

 At this point the gadget driver tries to do a set-halt:

 g_file_storage gadget: bulk-in set halt
 kagen2_set_halt 1 1

 When the Halt feature is set, the UDC is supposed to send a STALL
 packet to the host -- but it did not.  Instead it sent this 13-byte
 bulk-IN packet.

 g_file_storage gadget: bulk-in, length 13:
 : 55 53 42 53 08 00 00 00 b0 00 00 00 00
 [start_transfer] 53425355 8
 ept1 in queue len 0xd, buffer 0xc133c000
 0: 0x53425355
 4: 0x8
 8: 0xb0
 bulk_in_complete -- 0, 13/13

 The same thing happened when the 0xA1 command was received:

 g_file_storage gadget: SCSI command: Unknown xa1;  Dc=12, Du=0;  Hc=12, 
 Hi=512
 g_file_storage gadget: bulk-in, length 0:
 [start_transfer] 43425355 12
 ept1 in queue len 0x0, buffer 0xc12ac000
 g_file_storage gadget: bulk-in set halt
 kagen2_set_halt 1 1

 Right here, a STALL packet should have been sent.  It wasn't.

 g_file_storage gadget: sending command-failure status
 g_file_storage gadget:   sense data: SK x05, ASC x20, ASCQ x00;  info x0
 g_file_storage gadget: bulk-in, length 13:
 : 55 53 42 53 12 00 00 00 00 02 00 00 01
 [start_transfer] 53425355 12
 ept1 in queue len 0xd, buffer 0xc133c000
 0: 0x53425355
 4: 0x12
 8: 0x200
 bulk_in_complete -- 0, 13/13

 Instead this packet was sent.

 Alan Stern

Thanks! This packet is the CSW to the unknown SCSI command 0xa1. So it
should not be sent at all, and the UDC driver should send the STALL
packet instead of this CSW?

Just curious, after this 0xa1 is received and bulk-in endpoint is
halted. The Linux host tries to send TEST_UNIT_READY command, and UDC
driver could not receive it because endpoint is halted and in reset
condition. Seems like the set Halt feature is working (but STALL
packet is not sent).

victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I use kernel 3.4.4, the code in handle_stat1_irqs() is as below. There
 is no reset or disconnect member function in struct
 usb_gadget_driver in kernel 3.4.4.

 if (stat  (1  SUSPEND_REQUEST_INTERRUPT)) {
 if (dev-driver-suspend)
 dev-driver-suspend (dev-gadget);
 if (!enable_suspend)
 stat = ~(1  SUSPEND_REQUEST_INTERRUPT);
 } else {
 if (dev-driver-resume)
 dev-driver-resume (dev-gadget);
 /* at high speed, note erratum 0133 */
 }

 Okay.  I have a hard enough time remembering how the kernel works now;
 I can't afford to remember how it worked five releases ago.  :-)

 In the 3.4 kernel, when either a reset or a disconnect occurs, the UDC
 driver should call the gadget driver's -disconnect handler.

  Another usbmon trace showing 3 SCSI_READ_10 command.
 
 This trace shows that the READ(10) commands worked correctly.  Good.
 But it also shows that the gadget did not respond correctly to the 0xA1
 command near the end.  The UDC was supposed to set the Halt feature
 for the bulk-in endpoint and send a STALL packet, but it didn't.

 In gadget driver, when do_scsi_command() receives an unknown command,
 the return value is -EINVAL.

 No, the return value is 0.  Read the last line of do_scsi_command():

 return 0;

  Will this value be returned to UDC
 driver, so that UDC driver can set the Halt feature for the bulk-in
 endpoint and send a STALL packet? For now, UDC driver does not set
 Halt when unknown SCSI command is received.

 Look at finish_reply(), near the end of the DATA_DIR_TO_HOST case:

 /*
  * For Bulk-only, mark the end of the data with a short
  * packet.  If we are allowed to stall, halt the bulk-in
  * endpoint.  (Note: This violates the Bulk-Only Transport
  * specification, which requires us to pad the data if we
  * don't halt the endpoint.  Presumably nobody will mind.)
  */
 else {
 bh-inreq-zero = 1;
 start_transfer(fsg, fsg-bulk_in, bh-inreq,
 bh-inreq_busy, bh-state);
 fsg-next_buffhd_to_fill = bh-next;
 if (mod_data.can_stall)
 rc = halt_bulk_in_endpoint(fsg);
 }

 And read the fist line in halt_bulk_in_endpoint():

 rc = fsg_set_halt(fsg, fsg-bulk_in);

 And finally, read the last line of fsg_set_halt():

 return usb_ep_set_halt(ep);

 That's when your UDC is supposed to set the Halt feature -- when its
 usb_ep_set_halt() function is called.  If the controller is busy at
 this time because the bulk-in buffer is full, and it is unable to set
 the Halt feature, then usb_ep_set_halt() should return -EAGAIN -- see
 the documentation for usb_ep_set_halt in include/linux/usb/gadget.h.

 Alan Stern


Thanks for the detailed write-up. I have checked the UDC driver
set_halt(), it is called by the gadget driver. The full ascii text of
usbmon trace for one usb session is also attached. This usbmon trace
shows a few EOVERFLOW(-75) error. I don't know why EOVERFLOW error
happened.

victor


scsi_read_10_again10.log
Description: Binary data

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Thanks for the detailed write-up. I have checked the UDC driver
 set_halt(), it is called by the gadget driver. The full ascii text of
 usbmon trace for one usb session is also attached. This usbmon trace
 shows a few EOVERFLOW(-75) error. I don't know why EOVERFLOW error
 happened.

 Because your UDC driver sent a packet that was too big.  Here's the
 first example from the trace:

 f3a2b6c0 3633034189 S Bo:2:036:1 -115 31 = 55534243 0600  
 0600    00
 f3a2b6c0 3633034326 C Bo:2:036:1 0 31 
 f3a2b6c0 3633034518 S Bi:2:036:1 -115 13 
 f3a2b6c0 3633040328 C Bi:2:036:1 -75 0

 The first two lines show the host sending a TEST UNIT READY command.
 The third line shows the host waiting for a 13-byte CSW data packet.
 The -75 error means that the UDC sent back a data packet containing
 more than 13 bytes.

 Alan Stern


Thanks, i do not know why UDC sent back a data packet containing more
than 13 bytes in response to TEST UNIT READY command.

Here is another usbmon trace attached in this email. There are two
issues in this usbmon trace. Firstly, the CSW that is sent back in
response to SCSI_READ_10 is wrong (wrong tag).

f2c92340 2379075608 S Bo:2:047:1 -115 31 = 55534243 1100 0010
8a28  0008  00
f2c92340 2379075737 C Bo:2:047:1 0 31 
f2c92ac0 2379075746 S Bi:2:047:1 -115 4096 
f2c92ac0 2382204478 C Bi:2:047:1 0 4096 =   
    
f2c92340 2382204489 S Bi:2:047:1 -115 13 
f2c92340 2382210596 C Bi:2:047:1 0 13 = 55534253 1000  00

Secondly, this CSW shows remote I/O error (-121).

f2c92340 2382422538 S Bo:2:047:1 -115 31 = 55534243 1200 0010
8a28  0008  00
f2c92340 2382422588 C Bo:2:047:1 0 31 
f3a2b5c0 2382422596 S Bi:2:047:1 -115 4096 
f3a2b5c0 2382448965 C Bi:2:047:1 -121 13 = 55534253 1200 0010 01
f2c92340 2382448977 S Bi:2:047:1 -115 13 

I am lost. Every time i connect Linux host to the USB gadget,
different error scenario is shown in usbmon.

victor


scsi_read_10_again11.log
Description: Binary data

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Earlier, i used file=/dev/mmcblk0p1. Now i use
 file=/mnt/sd/backing_file. This backing_file is a dummy file system
 that i created. I attached two jpeg files. One show the MBR and Boot
 Sector of the backing_file. Another shows the usbmon of the Linux Host

 Why did you send jpeg files?  Plain text files are a lot easier to work
 with.  Now I can't copy and paste the lines from your files into this
 email message.  :-(

 PC. I also attached the udc log which shows the MBR and Boot Sector
 content which are read from the backing_file.

 The UDC log indicates that the MBR and boot sectors were read
 correctly.

  From the usbmon jpeg,
 that first SCSI_READ_10 command got a overflow error, the second
 SCSI_READ_10 command got a connection reset error. Is the overflow
 error occurred because the host PC cannot handle the data returned
 from the gadget device?

 The usbmon log shows that the host sent the gadget a READ(10) command
 for 8 sectors, which 4096 bytes.  It then requested a 4096-byte
 transfer on the bulk-in endpoint, expecting the gadget to reply with
 eight packets, each containing 512 bytes (because the bulk-in
 wMaxPacketSize is 512).

 But the gadget did not reply correctly.  The UDC sent a data packet
 containing only 256 bytes, instead of 512 bytes.  The overflow occurred
 when it sent a second data packet, again containing the wrong number of
 bytes.

  Call the gadget driver's -reset handler.  If the -reset pointer is
  NULL, call the -disconnect handler instead.  See the code in
  net2280.c's handle_stat1_irqs() as an example.
 
  Alan Stern
 

 i read the net2280.c code. Is it the usb_reset() function, called by
 stop_activity()? I am sorry if i understand incorrectly.

 No, it is the handle_stat1_irqs() function, as I wrote above.  In
 particular, this part of the code, which handles both disconnects and
 resets:

 if (disconnect || reset) {
 stop_activity(dev, dev-driver);
 ep0_start(dev);
 spin_unlock(dev-lock);
 if (reset  dev-driver-reset)
 (dev-driver-reset)(dev-gadget);
 else
 (dev-driver-disconnect)(dev-gadget);
 spin_lock(dev-lock);
 return;
 }


I use kernel 3.4.4, the code in handle_stat1_irqs() is as below. There
is no reset or disconnect member function in struct
usb_gadget_driver in kernel 3.4.4.

if (stat  (1  SUSPEND_REQUEST_INTERRUPT)) {
if (dev-driver-suspend)
dev-driver-suspend (dev-gadget);
if (!enable_suspend)
stat = ~(1  SUSPEND_REQUEST_INTERRUPT);
} else {
if (dev-driver-resume)
dev-driver-resume (dev-gadget);
/* at high speed, note erratum 0133 */
}


 Another usbmon trace showing 3 SCSI_READ_10 command.

This trace shows that the READ(10) commands worked correctly.  Good.
But it also shows that the gadget did not respond correctly to the 0xA1
command near the end.  The UDC was supposed to set the Halt feature
for the bulk-in endpoint and send a STALL packet, but it didn't.

In gadget driver, when do_scsi_command() receives an unknown command,
the return value is -EINVAL. Will this value be returned to UDC
driver, so that UDC driver can set the Halt feature for the bulk-in
endpoint and send a STALL packet? For now, UDC driver does not set
Halt when unknown SCSI command is received.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Now i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the
 SCSI_READ_10 command is still not working properly.

 What makes you think that?

Because the SCSI_READ_10 is able to read the MBR from the backing
file, and after that, SCSI_READ_10 reads all zeroes (fails to read
boot sector).

 g_file_storage gadget: ep0-setup, length 8:
 : 80 06 00 01 00 00 40 00
 g_file_storage gadget: get device descriptor

 But something is definitely wrong here.  Before sending this
 Get-Device-Descriptor request, the host should have done a USB port
 reset.  Either the host isn't performing the reset correctly or else
 your UDC driver didn't inform g_file_storage when the reset occurred.

Yes, the UDC driver didn't inform g_file_storage when the reset
occurred. What is to be done to inform g_file_storage when the reset
occurs?

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  the parameter is file=/dev/mmcblk0p1

 Perhaps you have already realized this...  mmcblk0p1 is the first
 partition of the mmcblk0 device.  Block 0 of the partition is the boot
 sector, not the MBR.  The MBR is block 0 of the mmcblk0 device.  So
 perhaps you really meant to use:

 file=/dev/mmcblk0

 I see a problem here. The first 32 bytes of the boot sector is
 correct. The rest of the bytes are , which is wrong. See the
 usbmon trace below.


 Are you certain this is wrong?  All those 0's could be unoccupied
 entries in a FAT.

 For testing purpose, i would like to create a backing file, and then
 use it with g_file_storage, such as below:

 # modprobe g_file_storage file=/tmp/backing_file

 Can i use an ordinary text file as the backing file?

 I find a link which contains answers to my question above.

 http://www.linux-usb.org/gadget/file_storage.html


Now i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the
SCSI_READ_10 command is still not working properly.

See the gadget log below. The g_file_storage gadget receives SCSI
command: Unknown xa1 from the Linux host near the end of the log.
Something is wrong.

Thanks,
victor

g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 12 00
g_file_storage gadget: get device descriptor
g_file_storage gadget: ep0-in, length 18:
: 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02
0010: 00 01
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 02 00 00 20 00
g_file_storage gadget: get configuration descriptor
g_file_storage gadget: ep0-in, length 32:
: 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06
0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01
g_file_storage gadget: ep0-setup, length 8:
: 00 09 01 00 00 00 00 00
g_file_storage gadget: set configuration
0010: 00 00 00 24 00 00 00 00 00 00 00 00 07 00 00
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: set interface 0
g_file_storage gadget: high-speed config #1
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 02 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00
g_file_storage gadget: SCSI command: TEST UNIT READY;  Dc=6, Dn=0;  Hc=6, Hn=0
attention condition
g_file_storage gadget: sending command-failure status
g_file_storage gadget:   sense data: SK x06, ASC x29, ASCQ x00;  info x0
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 02 00 00 00 00 00 00 00 01
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 03 00 00 00 12 00 00 00 80 00 06 03
0010: 00 00 00 12 00 00 00 00 00 00 00 00 74 f9 02
g_file_storage gadget: SCSI command: REQUEST SENSE;  Dc=6, Di=18;  Hc=6, Hi=18
g_file_storage gadget: bulk-in, length 18:
: 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00
0010: 00 00
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 03 00 00 00 00 00 00 00 00
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 04 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 74 f9 02
g_file_storage gadget: SCSI command: TEST UNIT READY;  Dc=6, Dn=0;  Hc=6, Hn=0
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 04 00 00 00 00 00 00 00 00
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 05 00 00 00 24 00 00 00 80 00 06 12
0010: 00 00 00 24 00 00 00 00 00 00 00 00 74 f9 02
g_file_storage gadget: SCSI command: INQUIRY;  Dc=6, Di=36;  Hc=6, Hi=36
g_file_storage gadget: bulk-in, length 36:
: 00 00 02 02 1f 00 00 00 4c 69 6e 75 78 20 20 20
0010: 46 69 6c 65 2d 53 74 6f 72 20 47 61 64 67 65 74
0020: 30 33 33 33
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 05 00 00 00 00 00 00 00 00
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 06 00 00 00 00 00 00 00 00 00 06 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 74 f9 02
g_file_storage gadget: SCSI command: TEST UNIT READY;  Dc=6, Dn=0;  Hc=6, Hn=0
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 06 00 00 00 00 00 00 00 00
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 07 00 00 00 08 00 00 00 80 00 0a 25
0010: 00 00 00 00 00 00 00 00 00 00 00 00 74 f9 02
g_file_storage gadget: SCSI command: READ CAPACITY;  Dc=10, Di=8;  Hc=10, Hi=8
g_file_storage gadget: bulk-in, length 8:
: 00 00 07 ff 00 00 02 00
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 07 00 00 00 00 00 00 00 00
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 08 00 00 00 c0 00 00 00 80 00 06 1a
0010: 00 3f 00 c0 00 00 00 00 00 00 00 00 74 f9 02
g_file_storage gadget: SCSI command: MODE SENSE(6);  Dc=6, Di=192;  Hc=6, Hi=192
g_file_storage gadget: bulk-in, length 16:
: 0f 00 00 00 08 0a 04 00 ff ff 00 00 ff ff ff ff
g_file_storage gadget: bulk-in set halt
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 08 00 00 00 b0 00 00 00

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  It looks like the data is wrong, but I have no way of knowing what the
  data actually should be.  Only you know that.
 
  f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
  8a28  0008  00
  f31a9740 4037054176 C Bo:2:071:1 0 31 
  f4a555c0 4037054184 S Bi:2:071:1 -115 4096 
  f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000
  02402e11 0200 00f8 3f00ff00 0020
 
  Is this different from what you have in the first 32 bytes of your
  backing file?  If it is then your UDC driver is not sending the correct
  buffer data to the host.

 The first 32 bytes data is correct. It is the first 32 bytes content
 of the FAT boot record. I observed further, when first SCSI_READ_10
 command is sent with LBA of zero, and the file_offset_tmp of
 vfs_read() in do_read() is passed in as 0. It reaches SD driver with
 argument of 0x2002, . Somehow, the address got passed wrongly in the
 processing of it. In this case, 0x2000 is the FAT boot sector.
 Shouldn't gadget driver read from MBR (master boot record) as LBA of
 zero corresponds to MBR?

 The gadget driver reads from whatever you tell it to read.  When you
 load g-file-storage, what parameters do you put in the modprobe
 command?

 Alan Stern


 the parameter is file=/dev/mmcblk0p1

I see a problem here. The first 32 bytes of the boot sector is
correct. The rest of the bytes are , which is wrong. See the
usbmon trace below.

f59e13c0 2704842730 S Bo:2:007:1 -115 31 = 55534243 2100 0080
8a28 0020 0040  00
f59e13c0 2704842836 C Bo:2:007:1 0 31 
f319db40 2704842846 S Bi:2:007:1 -115 4096 
f59e16c0 2704842848 S Bi:2:007:1 -115 4096 
f59e14c0 2704842850 S Bi:2:007:1 -115 4096 
f59e1240 2704842851 S Bi:2:007:1 -115 4096 
f59e15c0 2704842852 S Bi:2:007:1 -115 4096 
f59e1340 2704842853 S Bi:2:007:1 -115 4096 
f59e12c0 2704842854 S Bi:2:007:1 -115 4096 
f59e1540 2704842855 S Bi:2:007:1 -115 4096 
f319db40 2705432226 C Bi:2:007:1 0 4096 = e52d424f 4f542020 42494e20
1886fc80 7c417c41 838a 7b410300 94b80200
f59e16c0 2705432230 C Bi:2:007:1 0 4096 =   
    
f59e14c0 2705432231 C Bi:2:007:1 0 4096 =   
    
f59e1240 2705432231 C Bi:2:007:1 0 4096 =   
    
f59e15c0 2705432232 C Bi:2:007:1 0 4096 =   
    
f59e1340 2705432233 C Bi:2:007:1 0 4096 =   
    
f59e12c0 2705432234 C Bi:2:007:1 0 4096 =   
    
f59e1540 2705432234 C Bi:2:007:1 0 4096 =   
    
f59e13c0 2705432244 S Bi:2:007:1 -115 13 
f59e13c0 2705438346 C Bi:2:007:1 0 13 = 55534253 2100  00

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  the parameter is file=/dev/mmcblk0p1

 Perhaps you have already realized this...  mmcblk0p1 is the first
 partition of the mmcblk0 device.  Block 0 of the partition is the boot
 sector, not the MBR.  The MBR is block 0 of the mmcblk0 device.  So
 perhaps you really meant to use:

 file=/dev/mmcblk0

 I see a problem here. The first 32 bytes of the boot sector is
 correct. The rest of the bytes are , which is wrong. See the
 usbmon trace below.


 Are you certain this is wrong?  All those 0's could be unoccupied
 entries in a FAT.

For testing purpose, i would like to create a backing file, and then
use it with g_file_storage, such as below:

# modprobe g_file_storage file=/tmp/backing_file

Can i use an ordinary text file as the backing file?

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  the parameter is file=/dev/mmcblk0p1

 Perhaps you have already realized this...  mmcblk0p1 is the first
 partition of the mmcblk0 device.  Block 0 of the partition is the boot
 sector, not the MBR.  The MBR is block 0 of the mmcblk0 device.  So
 perhaps you really meant to use:

 file=/dev/mmcblk0

 I see a problem here. The first 32 bytes of the boot sector is
 correct. The rest of the bytes are , which is wrong. See the
 usbmon trace below.


 Are you certain this is wrong?  All those 0's could be unoccupied
 entries in a FAT.

 For testing purpose, i would like to create a backing file, and then
 use it with g_file_storage, such as below:

 # modprobe g_file_storage file=/tmp/backing_file

 Can i use an ordinary text file as the backing file?

I find a link which contains answers to my question above.

http://www.linux-usb.org/gadget/file_storage.html

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Here is the fresh usbmon trace. Four SCSI commands are shown. The
 first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10
 command has LBA of 0x00ed2900, which is wrong. Somehow, the first
 SCSI_READ_10 command got the wrong data, i think. Isn't it?

 It looks like the data is wrong, but I have no way of knowing what the
 data actually should be.  Only you know that.

 f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
 8a28  0008  00
 f31a9740 4037054176 C Bo:2:071:1 0 31 
 f4a555c0 4037054184 S Bi:2:071:1 -115 4096 
 f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000
 02402e11 0200 00f8 3f00ff00 0020

 Is this different from what you have in the first 32 bytes of your
 backing file?  If it is then your UDC driver is not sending the correct
 buffer data to the host.

The first 32 bytes data is correct. It is the first 32 bytes content
of the FAT boot record. I observed further, when first SCSI_READ_10
command is sent with LBA of zero, and the file_offset_tmp of
vfs_read() in do_read() is passed in as 0. It reaches SD driver with
argument of 0x2002, . Somehow, the address got passed wrongly in the
processing of it. In this case, 0x2000 is the FAT boot sector.
Shouldn't gadget driver read from MBR (master boot record) as LBA of
zero corresponds to MBR?

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  It looks like the data is wrong, but I have no way of knowing what the
  data actually should be.  Only you know that.
 
  f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
  8a28  0008  00
  f31a9740 4037054176 C Bo:2:071:1 0 31 
  f4a555c0 4037054184 S Bi:2:071:1 -115 4096 
  f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000
  02402e11 0200 00f8 3f00ff00 0020
 
  Is this different from what you have in the first 32 bytes of your
  backing file?  If it is then your UDC driver is not sending the correct
  buffer data to the host.

 The first 32 bytes data is correct. It is the first 32 bytes content
 of the FAT boot record. I observed further, when first SCSI_READ_10
 command is sent with LBA of zero, and the file_offset_tmp of
 vfs_read() in do_read() is passed in as 0. It reaches SD driver with
 argument of 0x2002, . Somehow, the address got passed wrongly in the
 processing of it. In this case, 0x2000 is the FAT boot sector.
 Shouldn't gadget driver read from MBR (master boot record) as LBA of
 zero corresponds to MBR?

 The gadget driver reads from whatever you tell it to read.  When you
 load g-file-storage, what parameters do you put in the modprobe
 command?

 Alan Stern


the parameter is file=/dev/mmcblk0p1

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Thanks. Working on this problem now. Another problem observed for
 SCSI_READ_10 command, when reading from the SD card, the gadget driver
 never sends the MBR address, the FAT boot record address, the start of FAT
 address, and the start of FAT cluster address to the SD card driver.

 The gadget doesn't make up addresses by itself.  It always sends the
 address the host tells it to send.

 The
 address sent by gadget driver is wrong.

 Then the address sent by the host is wrong.

 However, I suspect you are mistaken.  In your usbmon trace earlier, the
 very first READ(10) command had a logical block address of 0.  That is
 the address of the MBR.  If the driver hadn't failed at that point, the
 host would have gone on to ask for the address of the boot sector and
 other things.

 Yes, the very first READ(10) command has a logical block address of 0
 (as shown below). I will generate the  fresh usbmon trace the next
 day, i do not have access to the platform now.

 f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010
 8a28  0008  00


Here is the fresh usbmon trace. Four SCSI commands are shown. The
first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10
command has LBA of 0x00ed2900, which is wrong. Somehow, the first
SCSI_READ_10 command got the wrong data, i think. Isn't it?

f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
8a28  0008  00
f31a9740 4037054176 C Bo:2:071:1 0 31 
f4a555c0 4037054184 S Bi:2:071:1 -115 4096 
f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000
02402e11 0200 00f8 3f00ff00 0020
f31a9740 4037108476 S Bi:2:071:1 -115 13 
f31a9740 4037114564 C Bi:2:071:1 0 13 = 55534253 0c00  00
f31a9740 4037114722 S Bo:2:071:1 -115 31 = 55534243 0d00 
0600    00
f31a9740 4037114801 C Bo:2:071:1 0 31 
f31a9740 4037114805 S Bi:2:071:1 -115 13 
f31a9740 4037121303 C Bi:2:071:1 0 13 = 55534253 0d00  00
f31a9740 4037121388 S Bo:2:071:1 -115 31 = 55534243 0e00 0800
8a25    00
f31a9740 4037121550 C Bo:2:071:1 0 31 
f4a552c0 4037121559 S Bi:2:071:1 -115 8 
f4a552c0 4037127426 C Bi:2:071:1 0 8 = 00ed29c7 0200
f31a9740 4037127435 S Bi:2:071:1 -115 13 
f31a9740 4037133064 C Bi:2:071:1 0 13 = 55534253 0e00  00
f31a9740 4037133100 S Bo:2:071:1 -115 31 = 55534243 0f00 0010
8a28 ed29 0008  00
f31a9740 4037133176 C Bo:2:071:1 0 31 
f4a552c0 4037133184 S Bi:2:071:1 -115 4096 
f4a552c0 4037184441 C Bi:2:071:1 0 4096 =   
    
f31a9740 4037184453 S Bi:2:071:1 -115 13 
f31a9740 4037190564 C Bi:2:071:1 0 13 = 55534253 0f00  00

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Thanks. Working on this problem now. Another problem observed for
 SCSI_READ_10 command, when reading from the SD card, the gadget driver
 never sends the MBR address, the FAT boot record address, the start of FAT
 address, and the start of FAT cluster address to the SD card driver.

 The gadget doesn't make up addresses by itself.  It always sends the
 address the host tells it to send.

 The
 address sent by gadget driver is wrong.

 Then the address sent by the host is wrong.

 However, I suspect you are mistaken.  In your usbmon trace earlier, the
 very first READ(10) command had a logical block address of 0.  That is
 the address of the MBR.  If the driver hadn't failed at that point, the
 host would have gone on to ask for the address of the boot sector and
 other things.

Yes, the very first READ(10) command has a logical block address of 0
(as shown below). I will generate the  fresh usbmon trace the next
day, i do not have access to the platform now.

f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010
8a28  0008  00

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Here is the gadget log when receiving SCSI_READ_10 from Linux host.

 g_file_storage gadget: bulk-out, length 31:
 : 55 53 42 43 0f 00 00 00 00 10 00 00 80 00 0a 28
 0010: 00 00 00 00 00 00 00 08 00 00 00 00 e0 f8 02
 SCSI CDB: 28 00 00 00 00 00 00 00 08 00
 g_file_storage gadget: SCSI command: READ(10);  Dc=10, Di=4096;  Hc=10, 
 Hi=4096
  driver read from SD card .
 g_file_storage gadget-lun0: file read 4096 @ 0 - 4096
 READ_10 reply -5   *** printk added by me***
 g_file_storage gadget: bulk-in, length 13:
 : 55 53 42 53 0f 00 00 00 00 00 00 00 00

 This all looks right.

There is a problem with SCSI_READ_10 command if looking at usbmon. I
pasted the usbmon log that starts from SCSI_READ_10. Basically, the
SCSI_READ_10 was received by gadget, processed, sent CSW, followed by
control packets. Then another SCSI_READ_10, sent CSW, followed by
control packets. Then another SCSI_READ_10, but CSW is not received by
host.

There must be problems in the UDC driver. CSW is sent by the UDC
driver but it is not received by the Linux host.

Thanks,
victor

f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010
8a28  0008  00
f59e13c0 3246885582 C Bo:2:046:1 0 31 
f59e15c0 3246885594 S Bi:2:046:1 -115 4096 
f59e15c0 3247150217 C Bi:2:046:1 -75 0
f59e13c0 3247150291 S Bi:2:046:1 -115 13 
f59e13c0 3247150450 C Bi:2:046:1 -75 0
f412a840 3247310347 S Ci:2:046:0 s 80 06 0100  0012 18 
f412a840 3247313216 C Ci:2:046:0 0 18 = 12010002 0040 2505a5a4 33030102 0001
f412a840 3247313226 S Ci:2:046:0 s 80 06 0200  0020 32 
f412a840 3247326452 C Ci:2:046:0 0 32 = 09022000 010104c0 01090400
00020806 50050705 81020002 00070501 02000201
f412a840 3247326511 S Co:2:046:0 s 00 09 0001   0
f412a840 3247339340 C Co:2:046:0 0 0
f59e13c0 3247345346 S Bo:2:046:1 -115 31 = 55534243 0d00 0010
8a28  0008  00
f59e13c0 3247345450 C Bo:2:046:1 0 31 
f59e15c0 3247345461 S Bi:2:046:1 -115 4096 
f59e15c0 3247352463 C Bi:2:046:1 -75 0
f59e13c0 3247352476 S Bi:2:046:1 -115 13 
f59e13c0 3247352712 C Bi:2:046:1 0 0
f59e13c0 3247352720 S Bi:2:046:1 -115 13 
f59e13c0 3247359080 C Bi:2:046:1 0 13 = 55534253 0c00  00
f412a840 3247529347 S Ci:2:046:0 s 80 06 0100  0012 18 
f412a840 3247530463 C Ci:2:046:0 0 18 = 12010002 0040 2505a5a4 33030102 0001
f412a840 3247530476 S Ci:2:046:0 s 80 06 0200  0020 32 
f412a840 3247543866 C Ci:2:046:0 0 32 = 09022000 010104c0 01090400
00020806 50050705 81020002 00070501 02000201
f412a840 3247543906 S Co:2:046:0 s 00 09 0001   0
f412a840 3247556713 C Co:2:046:0 0 0
f59e13c0 3247562349 S Bo:2:046:1 -115 31 = 55534243 0e00 0010
8a28  0008  00
f59e13c0 3247562449 C Bo:2:046:1 0 31 
f59e15c0 3247562460 S Bi:2:046:1 -115 4096 
f59e15c0 3278472491 C Bi:2:046:1 -104 0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 Understand, UDC driver will call driver-setup(), and if the return
 value is negative, UDC driver has to set dev-protocol_stall = 1 and
 maybe call usb_ep_set_halt(). However, the hardware won't be able to
 send out zero length response.

 Don't be silly; of course it can.  Nobody would be foolish enough to
 design a piece of USB hardware that couldn't send a zero-length DATA
 packet.

  I think the purpose of zero length
 response is to get an ACK from the host.

 The purpose of the zero-length response is to complete the Status stage
 of a control-OUT transfer.

Thanks, the halt feature is ok now. The SCSI_READ_10 command has a
problem. The reply value from do_read is -5, which means -EIO. The
for(;;) loop in do_read() was probably broken at if (amount_left ==
0). Is this if-statement valid?

Here is the gadget log when receiving SCSI_READ_10 from Linux host.

g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 0f 00 00 00 00 10 00 00 80 00 0a 28
0010: 00 00 00 00 00 00 00 08 00 00 00 00 e0 f8 02
SCSI CDB: 28 00 00 00 00 00 00 00 08 00
g_file_storage gadget: SCSI command: READ(10);  Dc=10, Di=4096;  Hc=10, Hi=4096
 driver read from SD card .
g_file_storage gadget-lun0: file read 4096 @ 0 - 4096
READ_10 reply -5   *** printk added by me***
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 0f 00 00 00 00 00 00 00 00

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  In the log file, is there any invalid request received on endpoint 0?
 
  In the usbmon file there is.  It is this line:
 
  f4ae6f40 1217192721 S Co:2:018:0 s 21 ff    0

 ok, i will add code to UDC to instruct hardware to send NAK upon
 receiving invalid request on endpoint 0. Does it mean that UDC driver
 has to check for invalid request on endpoint 0?

 No.  The UDC driver has no way to know whether a request is valid or
 not.  Read the description of the setup member of the
 usb_gadget_driver structure in the header file.


I read that. The setup member of the usb_gadget_driver structure is
pointing to fsg_setup, in file_storage.c. The fsg_setup() function
handles the request on endpoint 0. So how could UDC driver know when
to send NAK?

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  ok, i will add code to UDC to instruct hardware to send NAK upon
  receiving invalid request on endpoint 0. Does it mean that UDC driver
  has to check for invalid request on endpoint 0?
 
  No.  The UDC driver has no way to know whether a request is valid or
  not.  Read the description of the setup member of the
  usb_gadget_driver structure in the header file.
 

 I read that. The setup member of the usb_gadget_driver structure is
 pointing to fsg_setup, in file_storage.c. The fsg_setup() function
 handles the request on endpoint 0. So how could UDC driver know when
 to send NAK?

 When an invalid request is received, the gadget is supposed to send
 STALL, not NAK.  See the last two lines of the setup description:

  *  USB byte order. Called in_interrupt; this may not sleep.  Driver
  *  queues a response to ep0, or returns negative to stall.

 Driver ...  returns negative to stall.  That's how the UDC driver
 knows whether to send a STALL packet -- if the setup callback returns a
 negative value.

 Also, it looks like you didn't read this paragraph in the description
 of usb_ep_queue():

  * Control endpoints ... after getting a setup() callback, the driver queues
  * one response (even if it would be zero length).  That enables the
  * status ack, after transferring data as specified in the response.  Setup
  * functions may return negative error codes to generate protocol stalls.
  * (Note that some USB device controllers disallow protocol stall responses
  * in some cases.)  When control responses are deferred (the response is
  * written after the setup callback returns), then usb_ep_set_halt() may be
  * used on ep0 to trigger protocol stalls.  Depending on the controller,
  * it may not be possible to trigger a status-stage protocol stall when the
  * data stage is over, that is, from within the response's completion
  * routine.

 Notice especially the fourth line.

 Alan Stern


Understand, UDC driver will call driver-setup(), and if the return
value is negative, UDC driver has to set dev-protocol_stall = 1 and
maybe call usb_ep_set_halt(). However, the hardware won't be able to
send out zero length response. I think the purpose of zero length
response is to get an ACK from the host.

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

 I have a serial console to access the platform. Today i use Linux as
 USB host. The log of the usb gadget is attached (gadget-log.txt).

 The Linux usbmon log file is also attached (usbmon-log.txt). Hopefully
 the log data will be useful.

 It looks like you cut out a lot of information from the gadget log.
 Please don't do that.

 The logs show that your driver still has several bugs.  For example,
 the start of the gadget log shows that the driver thinks it received a
 bunch of packets on the bulk-out endpoint, but the usbmon log shows
 that the host never sent these packets.

 Your driver does not set the Halt feature for the bulk-in endpoint when
 it is supposed to.  It doesn't even respond with NAK when it receives
 an invalid request on endpoint 0.

 When asked to transmit 4096 bytes of data, your driver sent a packet
 containing more than 512 bytes.


I do not know when to set the Halt feature for the bulk-in endpoint. I
see gadget code have this line printed out:
g_file_storage gadget: bulk-in set halt

In the log file, is there any invalid request received on endpoint 0?

Regards,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

  First you have to figure out why it isn't working.  What does the
  debugging information show?

 Here is some debugging information:

 receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20
 receive SET_CONFIGURATION, 0, 9 index 0 value 1 len 0
 set curlun-unit_attention_data to SS_NO_SENSE
 do_set_config() is called because of FSG_STATE_CONFIG_CHANGE
 do_set_interface() is called
 set curlun-unit_attention_data to SS_RESET_OCCURRED
 receive *UNKNOWN*, a1, fe index 0 value 0 len 1
 receive SCSI Inquiry
 receive SCSI read format capacities, get attention condition,
 curlun-unit_attention_data is 062900 (SS_RESET_OCCURRED)

 Up to this point, everything is normal.  We need to see what happens
 next.


After the SS_RESET_OCCURRED attention condition, the debug information is:

start_transfer is called
the driver queue function is called
start_transfer is called
the driver queue function is called to send out CSW of 13 bytes
driver receive EP1 IN interrupt
bulk_in_complete is called
get_next_command is called
driver receive setup data valid interrupt
receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20
.many control transfers..

May i know if everything is normal here?

Thanks,
victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[victor yeo]

Hi,

On Wed, Mar 20, 2013 at 10:22 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Wed, 20 Mar 2013, victor yeo wrote:

 Thanks, i add processing the pending data from FIFO after queue was
 called. The UDC driver can process the SCSI INQUIRY command and SCSI
 READ FORMAT CAPACITIES command now.

 In the processing of SCSI READ FORMAT CAPACITIES command, there is
 attention condition. Then the bulk transfer stops completely and
 control transfer is repeated.

 What control transfer?

those get descriptor requests.

 How can i solve it?

 First you have to figure out why it isn't working.  What does the
 debugging information show?

Here is some debugging information:

receive GET_DESCRIPTOR, 80, 6 index 0 value 200 len 20
receive SET_CONFIGURATION, 0, 9 index 0 value 1 len 0
set curlun-unit_attention_data to SS_NO_SENSE
do_set_config() is called because of FSG_STATE_CONFIG_CHANGE
do_set_interface() is called
set curlun-unit_attention_data to SS_RESET_OCCURRED
receive *UNKNOWN*, a1, fe index 0 value 0 len 1
receive SCSI Inquiry
receive SCSI read format capacities, get attention condition,
curlun-unit_attention_data is 062900 (SS_RESET_OCCURRED)

The gadget code is able to process SCSI Inquiry because it does not
fulfill the if-condition:

if (curlun  curlun-unit_attention_data != SS_NO_SENSE  
fsg-cmnd[0] != INQUIRY 
fsg-cmnd[0] != REQUEST_SENSE) {

Why is curlun-unit_attention_data set to SS_RESET_OCCURRED?

Regards,
Victor
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html