s/usb/gadget/g_mass_storage.ko
file=/dev/mmcblk0
insmod: can't insert
'/lib/modules/3.4.4+/kernel/drivers/usb/gadget/g_mass_storage.ko': No such
device
thanks,
victor
CONFIDENTIALITY NOTE:
> > On Fri, Dec 07 2012, victor wrote:
> > I can build linux USB mass storage gadget. When I want to insmod it,
> > the following errors are reported. I have the file g_mass_storage.ko,
> > why can't I insmod the file?
> >
> > # ls /lib/
# insmod kagen2_udc.ko
# insmod g_file_storage.ko file=/dev/mmcblk0
insmod: can't insert 'g_file_storage.ko': No such device
Thanks,
Victor
CONFIDENTIALITY NOTE:
This e-mail and any atta
once it works with usb mass storage gadget.
> --
> balbi
Regards,
victor
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be
protected by le
> > > > >
> > > > > I am working on a new UDC for a new USB chip. The kernel version
> > > > > is 3.4.4. When I insmod the new UDC, it is ok. When I insmod the
> > > > > file
> > >
> > > out of curiosity, do you plan to send kagen2_udc.ko to mainline ?
> > >
> > Yes, it will be sent to mainline onc
c struct platform_driver kagen2_plat_driver = {
.probe =kagen2_plat_probe,
.
};
static int __init kagen2_init (void)
{
return platform_driver_register(&kagen2_plat_driver);
}
Thanks,
victor
=
the
> > > message was sent to a public email list then obviously there are no such
> people.
> > >
> > > So I don't see any problem.
> >
> > Then I guess you missed this unconditional part?:
> >
> > "be aware that any disclosure, copyi
=/dev/mmcblk0
gadget: controller 'kagen2_usb' not recognized
gadget: No serial-number string provided!
gadget: File-backed Storage Gadget, version: 1 September 2010
gadget: NOTE: This driver is deprecated. Consider using g_mass_storage
instead.
gadget: Number of LUNs=1
g_file_storage
nconditional part?:
> > > >
> > > > "be aware that any disclosure, copying, distribution or use of this
> > > > e-mail or any attachment is prohibited. "
> > > >
> > > > This means that victor is deliberately violating his company
&g
usb_gadget_ops
> > structure and added the udc_start() function. What else do I need to
add?
> >
> > Here is the message at console:
> >
> > # insmod kagen2_udc.ko
> > # insmod g_file_storage.ko file=/dev/mmcblk0
> > gadget: controller 'kagen2
n2_udc.ko, and it is not called when usb cable is plugged in. What can
go wrong?
# insmod kagen2_udc.ko
#
# insmod g_file_storage.ko file=/dev/mmcblk0
gadget: No serial-number string pr
Then host PC sends a few more GET_DESCRIPTOR request, and the enumeration
stops. No SCSI_inquiry command is received by the gadget device. In host PC,
the gadget device is identified as USB mass storage device with an
exclamation mark.
The gadget device uses "endpoint 1" for bulk in
Hi,
I am using Linux USB gadget mass storage. I meet with problem in
file_storage.c. The bh->outreq->context in get_next_command() is not equal
to bh.
victor
CONFIDENTIALITY NOTE:
This e-ma
Hi,
In file_storage.c, send_status(), if (transport_is_bbb()), I add the line
bh->inreq->buf = bh -> buf,
and in get_next_command(), if (transport_is_bbb()), I add the line
bh->outreq->context = bh, to make the bh address to be the same.
Is this patch ok?
victor
-O
Hi,
In usb gadget file_storage.c, check_command(), the part "Check that only
command bytes listed in the mask are non-zero" cannot handle the
SCSI_INQUIRY command of 12 01 80 00 FF 00
The code will return EINVAL.
Is this a bug?
Thanks,
victor
-Original Message-----
Fr
same.
>>
>> Is this patch ok?
> What patch? You didn't post a patch, just a description of some changes.
>> victor
>>
>> -Original Message-
>> From: victor [mailto:vic...@keyasic.com]
>> Sent: Wednesday, 31 October, 2012 1:04 PM
>
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
au
our HW documentation. Maybe you're
> using wrong IRQ number ? Who knows. I have no clue how kagen2 works and
> can't help anymore.
>
I find out the IRQ number for usb, and unmask that IRQ number in
interrupt controller. So usb cable is plugged into host PC, the gadget
(which runs on linux) freezes immediately, no error message is printed
out, no device reset.
now i don't know whether linux hang or the hardware hang.
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
defined in storage_common.c, as
"fsg_fs_bulk_out_desc". How to set the names of endpoints so that
usb_ep_autoconfig() can do the right thing?
I use the USBlyzer software on host PC, i can see that SCSI inquiry is
sent out by the host PC, but the gadget device does not receive it,
due to t
>
Replying my email, i set the ep,name to ep1 for bulk out and bulk in
endpoints. The ep_matches() in epautoconf.c is able to auto-configure
the bulk out to endpoint 1.
however, i only see one SCSI_INQUIRY command being sent out, and it is
not received by the gadget device.
thanks,
victor
--
T
t; shows nothing. Should my UDC driver provide the info in
/sys/bus/usb folder?
# ls /sys/bus/usb/
devicesdrivers_autoprobe uevent
driversdrivers_probe
# lsusb -v
#
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
80 06 05 03 09 04 ff 00
g_file_storage gadget: get string descriptor
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
g_file_storage gadget: get device descriptor
.
Thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe lin
> from the fact that Windows asks for the same device and config
> descriptors a few times.
Why is the Windows asking for the same device and config descriptors
several 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
st PC. I am not sure
which part of file_storage.c called ep0_complete(). Please kindly
point out to me. Thanks.
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
iver queue function, i just
added it in and ep0_complete() is called now. The dmesg output is
below.
handle setup GET_DESCRIPTOR, 80, 6 index 0 value 100 len 40
g_file_storage gadget: ep0-setup, length 8:
: 80 06 00 01 00 00 40 00
g_file_storage gadget: get device descriptor
g_fi
lled
3. ep0_queue() is called
4. UDC driver queue function is called
5. UDC driver sends data to ep0 HW buffer
6. UDC driver increments req->actual by the amount of transferred bytes
7. UDC driver call ep0_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
get: get string descriptor
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
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
lete()
>> >
>> > looks correct
>> >
>>
>> Some progress, now i am able to see the dump_msg from ep0_complete().
>> It looks like the enumeration is ok, but the SCSI Inquiry command is
>> not received by the UDC driver. The do_scsi_command() in
>> f
on tracer, there are many
>> ways choose one and spend some time debugging, I'm sure you'll find the
>> bug.
>
> It sounds like the UDC driver now works okay for control transfers but
> not for bulk transfers.
>
Some code in file_storage.c that i cannot
is called to set buffer state to full
3) get_next_command() in gadget driver, is called to read the CBW.
4) do_scsi_command() to process SCSI command encoded in CBW
5) send_status() sends the CSW to host
i see this code snippet in fsg_main_thread(), i cannot understand it,
please tell me what the purpose of this
command() to process SCSI command encoded in CBW
>> 5) send_status() sends the CSW to host
>
> Something like below:
>
> OUT Token -> ISR -> giveback() -> bulk_out_complete() ->
> get_next_command() -> do_scsi_command() -> usb_ep_queue() -> OUT/IN
> Token -
status()
>>
>> For the IN Token, i will just write the data to the HW buffer, and the
>> flow will go to send_status().
>>
>> I use a different USB cable, now the USB gadget is able to receive
>> bulk transfer data from host PC. I am working on the bulk transfer
&g
fsg_dev structure, there are 3 usb_ep: bulk_in, bulk_out, and
>> intr_in. Why is the intr_out endpoint not defined?
>
> because it's not needed. Read the USB Mass Storage Class specification
> from usb.org
Ok. In the gadget driver, it keeps on receiving the same bulk_o
unload data if req->length was zero ?
>
> another bug in your udc driver
In my udc driver, i set the req->length to the number of bytes i
received from HW, which is 31 bytes. Is it necessary to do that? How
to know the gadget driver queued 0-bytes? By
bh->bulk_out_intended_len
of bytes i
>> received from HW, which is 31 bytes. Is it necessary to do that? How
>
> you shouldn't touch req->lenght, you should only update req->actual.
> req->length is readonly for the UDC.
>
>> to know the gadget driver queued 0-bytes? By
>> bh-
00: a1 fe 00 00 00 00 01 00
g_file_storage gadget: get max LUN
g_file_storage gadget: ep0-in, length 1:
: 00
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 a8 48 ed 86 24 00 00 00 80 00 06 12
0010: 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00
g_file_storage gad
Hi,
>> Here are the last two setup data and CBW data received. the
>> get_next_command() is not called when CBW data is received. the
>> bulk_out_complete() wakes up the thread, however, get_next_command()
>> still sleeps. i do not see where req->length is checked in gadget
>> driver.
>>
>> g_file
the linux/usb/gadget.h. The Soc
interrupt controller has problem, so i use a kernel thread to read
from USB controller directly.
> don't reimplement a bunch of infrastructure the kernel already gives you
i don't understand this. please kindly show an example.
> Also, you shouldn't requeue the request yourself, gadget driver owns the
> request.
which request do i requeue? please kindly point that out. 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
= &ep0_in_desc;
}
i read the net2272.c, the net2272_enable() is called by gadget driver
enable_endpoint(). When i run the gadget driver, enable_endpoint() is
called for fsg->bulk_in and fsg->bulk_out. The enable_endpoint() of
fsg->intr_in is not called because transport_is_
s_cbi() is false. So
>> how can the endpoint 0 be enabled?
>
> endpoint 0 has to be always enabled by the UDC driver. Gadget driver
> expects endpoint 0 to be ready.
i read through the net2272.c, i do not see where the endpoint 0 is
enabled. I blindly enable my endpoint zero. i th
&ka_ep->ep, &ep0_in_desc);
>> kagen2_ep_enable(&ka_ep->ep, &ep0_out_desc);
>
> yeah, you need to enabled it during driver initialization
In the udc driver, i can't assign a single ep0 descriptor to both
ep0_in_desc and ep0_out_desc. i think i should sk
x27;t
> set_bulk_out_req_length() work right?
today i changed my udc driver code, now the set_bulk_out_req_length()
sets the bulk_out_intended_length to 512 byte.
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
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(&h, in
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
---
drivers/usb/storage/debug.h | 10 --
1
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
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
--
Changes in v2:
- Completely remove the macro
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
---
drivers/usb/storage/debug.h | 18 +++---
drivers/usb/storage/ene_ub6250.c | 1 -
drivers/usb/storage/freecom.c| 12
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
Sorry, I accidentally pressed Send
On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon 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 6
Hi Felipe,
On Mon, Mar 7, 2016 at 11:13 PM, Felipe Balbi wrote:
>
> Hi,
>
> Victor Dodon writes:
>> [ text/plain ]
>> Sorry, I accidentally pressed Send
>>
>> On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote:
>>> Hi all,
>>>
>
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
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 wr
pty(&dev->ep[2].queue) is true. Where is the
appropriate place to add list entry?
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
d. how to make it to be called by file gadget, in order to
queue the request before ep1 interrupt?
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
not called.
The fsg_main_thread is sleeping in sleep_thread(). How to make it wake
up? is there anything udc driver has to do to wake up fsg_main_thread?
thanks,
victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord..
return rc;
}
How to set "bh->state" to BUF_STATE_EMPTY after the buffer is processed?
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
curlun->unit_attention_data = SS_NO_SENSE;
return -EINVAL;
}
Besides the code snippet, the only place that sets unit_attention data
to SS_NO_SENSE is in handle_exception(). How is UDC driver able to
overcome this problem?
victor
--
To unsubscribe from t
s, the UDC driver calls the request->complete() which in turn calls
the bulk_in_complete(). I am sorry my writing is not clear.
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
e to
overcome this problem? SCSI READ CAPACITY also has the same attention
condition problem. What can i do now?
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
ng log.
>
The problem is READ FORMAT CAPACITIES command is not processed, and no
reply is sent back in response to the command.
the kernel log does not show any error that is related to SCSI commands.
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
command to the queue buffer.
This is a serious problem, what is the way to synchronise UDC driver
and file storage gadget driver for SCSI command bulk transfer?
Regards,
Victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message
Hi,
> On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote:
>> For bulk transfer, the new UDC driver has one problem. When SCSI
>> Inquiry command is received, the UDC driver interrupt routine will
>> receive it first. However, the queue function is not yet called, a
Hi,
On Sat, Mar 16, 2013 at 1:49 AM, Felipe Balbi wrote:
> On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote:
>> On Fri, 15 Mar 2013, Felipe Balbi wrote:
>>
>> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote:
>> > > Hi,
>> >
Hi,
On Wed, Mar 20, 2013 at 10:22 PM, Alan Stern 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 c
er 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
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
n 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,
vi
s 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_e
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.
e 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
ECT_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 byt
dget log.
> Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command
> is 24 byte.
The problem is in UDC driver. i made the change, it is ok 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
quest 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
ndled 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 000
xception 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
000: 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
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 unsubsc
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: i
onfig 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 neve
; 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) {
>
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
from
host cannot wait, so i have to return the latest config value in
response to the 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
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&
; 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_ctrlreq
e 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
e_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
t 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
d 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_e
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 shoul
formance 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
d 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 wrote:
> On Thu, 5 Sep 2013, Victor Leschuk wrote:
>
>> Hello all,
> 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
t;>
>> 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
> U
l image and the will to clean the include/asm/mach
> directory.
SAN People will just need to maintain a custom patch / driver for this.
No reason to delay the progress of mainline.
Acked-By: Andrew Victor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
iver 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
mit 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
gt;> 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?
Thanks,
victor
--
To unsubscribe from this l
uot;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 kno
l 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->
_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:
000
1 - 100 of 161 matches
Mail list logo
