Hello.
I try connect my ARM linux device to host with Windows XP by USB serial gadget
ACM.
Driver setup normally, and my device is detected properly.
But I don`t know how to send data and receive data? All standart utility are
useless.
What can I do?
Help me please.
Dmitriy.
---
Hi,
Two CD-ROM's (from same vendor) are connected on Linux machine, running 2.4.20
kernel. I am not able to relate the topology of individual CD-ROMs.
# cat /proc/bus/usb/devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00
Alan Stern wrote:
Have you seen this patch?
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112439094723976&w=2
This started quite a bit of extracurricular activity (I installed the
patch and enumeration started in 2.6.12.3; previously it would _never_
get that far). This led Alan to ask m
Alan Stern wrote:
You seem to be saying that the device doesn't
work right when the last packet also contains 512 bytes.
It looks that way. I suspect that the device USB implementation has all
sorts of quirks. I now have a USB capture from the Windows application
that communicates with the de
Alan,
> Why is status set to -131 instead of -ECONNRESET?
ECONNRESET is defined as 131 in linux-2.4.30 mips
tree.
EUNRECOVERABLE isn't defined.
> The log shows everything worked okay (if you ignore
> the problem of the
> illegal status codes) until the computer tried to do
> a 127 KB write.
On Tue, 23 Aug 2005, craig qu wrote:
> Alan,
>
> I dumpped out those 13-byte long packets and found out
> that most of the status byte is 0x00, 0x08 and 0x80. I
> treated 0x08 and 0x80 as valid status as a work
> around, then I am able to read the partition table,
> mount the device and copy a s
On Tue, 23 Aug 2005, craig qu wrote:
> > > len=0xd actual length=0x0 status=0xff7d
> >
> > I don't know what those messages are supposed to
> > mean. Are those status
> > values the error codes from your HCD? What does
> > 0xff7d = -131 =
> > -EUNRECOVERABLE mean?
>
> Those messages we
> > len=0xd actual length=0x0 status=0xff7d
>
> I don't know what those messages are supposed to
> mean. Are those status
> values the error codes from your HCD? What does
> 0xff7d = -131 =
> -EUNRECOVERABLE mean?
Those messages were printed out in function
usb_stor_bulk_msg by myself.
On Tue, 23 Aug 2005 10:52:15 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> Both are correct. The difference is that currently usbmon is unable to
> read data buffers that are DMA-mapped.
There's a patch to fix that (appended).
However, I wonder if this is necessary to write a special dr
On Tue, 23 Aug 2005, Savita H wrote:
>
> Hi there,
>
> As u suggested, i installed Usb monitor module and captured the USB
> transactions. i refered
> /urs/src/linux/Documentation/usb/usbmon.txt file.
>
> Here is the output ...
>
> dac41b00 3258043428 S Bi:002:04 -115 512 <
> dad20380 32580434
The stick replies to the door lock commands with a check condition
(e.g. FAIL status in a normal bulk CSW), but the subsequent REQUEST SENSE
returns all-zero sense. The situation is documented in our Bugzilla,
including usbmon traces.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162559
Th
On Mon, 22 Aug 2005, Andy Stewart wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> HI everybody,
>
> I am not a subscriber - please CC me on any replies. Thanks!
>
> My iAudio G3 (1GB version) works fine on my Vaio laptop with kernel
> 2.6.8.1, but on my other computer (dual opt
On Mon, 22 Aug 2005, Dave North wrote:
> Okay, did it, and I'm attaching three files. The first is the standard
> boot dmesg from /var/log/dmesg.
That part doesn't really matter.
> The second (dmesg.txt) is the dmesg
> buffer after plugging in. Note this has filled the buffer because,
> afte
Hi there,
As u suggested, i installed Usb monitor module and captured the USB
transactions. i refered
/urs/src/linux/Documentation/usb/usbmon.txt file.
Here is the output ...
dac41b00 3258043428 S Bi:002:04 -115 512 <
dad20380 3258043448 S Bi:002:06 -115 512 <
db48be80 3261756782 S Bo:002:02 -1
On Tue, 2005-08-23 at 11:37 +0100, Richard Purdie wrote:
[...]
> which corrects this - I'm not sure if this is the right way to do it and
> am open to comments.
Just C-specific ones - God knows what people will pass as argument:
> +#ifdef CONFIG_PXA27x
> +#define OHCI_GETPORTNUM(x) ((x & RH_A_N
On Tue, 2005-08-23 at 12:43 +0200, Bernd Petrovitsch wrote:
> Just C-specific ones - God knows what people will pass as argument:
>
> > +#ifdef CONFIG_PXA27x
> > +#define OHCI_GETPORTNUM(x) ((x & RH_A_NDP) + 1)
> +#define OHCI_GETPORTNUM(x) (((x) & RH_A_NDP) + 1)
> > +#else
> > +#define OHCI_GET
I've been experimenting with the OHCI interface on the Zaurus SL-C3000
(Spitz) and have found a few things I wouldn't mind opinions on.
Firstly, the NDP register in roothub.a on the PXA270 isn't standard and
the number of ports is really the value of NDP+1. The chip supports
three ports and whils
Hi,
I am using host-host cable having prolific chip with
vendor id 0x067b and product id 0x0001.i am using
2.6.11 kernel patched with 2.6.12-rc5 patch.
I have enabled , USB gadget support (g_ether with
RNDIS) and the usb network adapters --multi-pupose usb
networking framework and prolific 2301
18 matches
Mail list logo
