Istvan De wrote:
Hi!
Sorry for the delay in replying, I was the one who started
this thread on usb-devel.
It seems that the acm driver sets the maximum transfer size to
the wMaxPacketSize field of the relevant endpoint descriptor,
this is maximum 64 bytes for a bulk high speed endpoint.
Fro
Alan Stern <[EMAIL PROTECTED]> said:
> On Mon, 29 Aug 2005, Brian Murphy wrote:
>
> > It seems that the acm driver sets the maximum transfer size to
> > the wMaxPacketSize field of the relevant endpoint descriptor,
> > this is maximum 64 bytes for a bulk hig
Greg Lee wrote:
I wrote my own user space driver which has achieved write
speeds of 900k/s.
900 K bits/sec or 900 K bytes/sec?
Greg
That would be bytes :)
/Brian
---
SF.Net email is Sponsored by the Better Software Confer
Greg Lee wrote:
Currently I've made a preliminary firmware for implementing the
CDC-ACM interface, however as Pavel kindly pointed out for me,
currently only 64Kbyte/sec is achieveable with this driver. I've read
the archives and from the discussions, I suspect that this is
connected to the
Daniel Holth wrote:
Here's a REPORTING-BUGS format problem report for my cdc_acm woes.
PROBLEM: Kernel OOPS when cdc_acm modem is unplugged during a ppp session.
I have a cdc_acm compatible modem. It is a Motorola v66
Alan Stern wrote:
On Thu, 17 Mar 2005, David Brownell wrote:
Well, as far as "list_*_safe" macros go they are actually "safe as far
as deleting an element from the list in the middle of the loop by the
same thread of execution", no more, no less.
That's what I'd been trying to do when it
Hi,
driver core changes are going to take some time so how about this
patch to fix it up
for the moment in (what I think is) a satisfactory manner so we can have
multi.interface
devices working again.
Executive summary:
loop until dependant device list is empty instead of for loop over
chang
Alan Stern wrote:
On Mon, 14 Mar 2005, Brian Murphy wrote:
This was nice in theory and partially fixes the problem (no more crash)
unfortunately
the module removal hangs if the data interface is attempted to be
removed first.
This seems to be because usb_driver_claim_interface is not the
Brian Murphy wrote:
Oliver Neukum wrote:
Could you make a single patch for that?
Regards
Oliver
Here are the patches resubmitted with the exporting of symbols split
off to
a seperate patch.
/Brian
Make sure
Oliver Neukum wrote:
Could you make a single patch for that?
Regards
Oliver
Here are the patches resubmitted with the exporting of symbols split off
to a seperate patch.
/Brian
This increases the reference count on the usb cdc acm control interface
which is referred to
Oliver Neukum wrote:
Could you make a single patch for that?
Regards
Oliver
Here are the patches resubmitted with the exporting of symbols split off
to a seperate patch.
/Brian
Export usb_get_intf and usb_put_intf so that modules can increase
usb interface reference co
Oliver Neukum wrote:
Could you make a single patch for that?
Regards
Oliver
Here are the patches resubmitted with the exporting of symbols split off to
a seperate patch.
/Brian
Make sure the cdc acm driver frees its two interfaces only once independant
of the order they a
Alan Stern wrote:
On Sun, 13 Mar 2005, Brian Murphy wrote:
Hi,
This line in the acm_probe routine
tty_register_device(acm_tty_driver, minor, &intf->dev);
causes the path to the tty created for each acm to be linked to
the usb interface. As long as the device is closed when it is
disco
Hi again,
The CDC ACM driver assumes that the acm_disconnect function is always
called with the control interface as argument but this is not always the
case. If it is called with the data interface first then
acm_disconnect calls usb_driver_release_interface with the data
interface and causes the
Hi,
This line in the acm_probe routine
tty_register_device(acm_tty_driver, minor, &intf->dev);
causes the path to the tty created for each acm to be linked to
the usb interface. As long as the device is closed when it is
disconnected this is no problem but if the tty is open then the
tty deregister
Pete Zaitcev wrote:
On Mon, 28 Feb 2005 19:20:41 +0530, <[EMAIL PROTECTED]> wrote:
When I connect USB device it gives device information like,
configuration, interface, and endpoint descriptors. I need bus, level,
and port information to map device files to particular USB port. []
OK, I thi
Hi,
this removes a warning message which only contains
data which is in any case returned to user space. This message
is especially annoying when polling with short timeouts, filling
up the log files and polluting the console. As agreed with
David Brownell.
/Brian
Signed-off-by: Brian
data-loss patch.
/Brian
Signed-off-by: Brian Murphy <[EMAIL PROTECTED]>
Index: drivers/usb/core/message.c
===
RCS file: /cvs/linux-kernel/drivers/usb/core/message.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2
Hi,
This is my fix for usbfs losing data when the urb
is timed out but already contains data.
/Brian
Signed-off-by: Brian Murphy <[EMAIL PROTECTED]>
Index: drivers/usb/core/message.c
===
RCS file: /cvs/linux-kernel/d
David Brownell wrote:
Did you mean something like this?
Yes, does that work OK for you?
Yes, this fixes the problem (has run through 100 reboots today without
problem).
It would crash after 10-15 reboots before.
/Brian
---
SF email is sp
David Brownell wrote:
On Wednesday 09 February 2005 1:57 pm, Brian Murphy wrote:
Listening to your wishes I have the following:
...
Presumably you think this should be 2 seperate patches (although this
was not entirely clear) part 1 fixing the bug and part 2 fixing the
message?
That'
Listening to your wishes I have the following:
patch1 removing useless warning:
diff -r -u
/home/brm/kernel/linux-2.6.11-rc3.orig/drivers/usb/core/devio.c
drivers/usb/core/devio.c
--- /home/brm/kernel/linux-2.6.11-rc3.orig/drivers/usb/core/devio.c
2005-02-05 10:41:56.0 +0100
+++ driv
David Brownell wrote:
On Wednesday 09 February 2005 11:39 am, Brian Murphy wrote:
David Brownell wrote:
But, rather than just logging a KERN_CRIT error, the better fix would
be to just do what ehci-hcd.c::unlink_async() does and stick that QH
at the end of the reclaim queue, in
I would very much like to see this patch or equivalent in the next
official kernel:
--- linux-2.6.11-rc3.orig/drivers/usb/core/devio.c 2005-02-05
10:41:56.0 +0100
+++ linux-2.6.11-rc3/drivers/usb/core/devio.c 2005-02-07
01:35:11.0 +0100
@@ -661,8 +661,9 @@
}
David Brownell wrote:
But, rather than just logging a KERN_CRIT error, the better fix would
be to just do what ehci-hcd.c::unlink_async() does and stick that QH
at the end of the reclaim queue, in QH_STATE_UNLINK_WAIT. In fact,
can you try just calling unlink_async() there, to see if that behaves?
[EMAIL PROTECTED] wrote:
Hi,
Can you please tell me, is there any way to map between actual USB port
and device files. Its something like
port 1 ->devicefile1
port 2 ->devicefile2
port 3 ->devicefile3
etc
can you please give us some guidelines on this thru which we can able to
do this.
Th
Hi,
in my usblib application I poll a bulk endpoint with a timeout of
1000(ms),
This ends up calling usb_start_wait_urb in drivers/usb/core/message.c
which checks for ECONNRESET (and changes the return code to
ETIMEDOUT) but sometimes (quite often) there is data in the urb even when
ECONNRESET
David Brownell wrote:
On Wednesday 02 February 2005 5:35 am, [EMAIL PROTECTED] wrote:
Hi,
It seems that under some conditions when a usb device is physically
disconnected and there are some pending urbs ehci_endpoint_disable
can loop forever in state QH_STATE_UNLINK.
Hmm, that might explai
Oliver Neukum wrote:
OK but in 2.6.8.1 the endpoint extra info is not searched for class
specific descriptors.
It seems perfectly reasonable to me to put these descriptors after the
endpoint
descriptors.
That is a common (mis)reading. Therefore a fix is in the pipeline and
hopefully in 2.6.9
David Brownell wrote:
On Wednesday 13 October 2004 5:10 am, Brian Murphy wrote:
I have found out the problem is that the usb_parse_configuration
routine does not take account of descriptors which lie after the last
interface descriptor so the extralen parameters are set to 0 even though
there
Hi,
Because of the new method of looking for a union descriptor to detect an ACM
device detection of several modems I have fails.
I have found out the problem is that the usb_parse_configuration
routine does not take account of descriptors which lie after the last
interface descriptor so the extral
31 matches
Mail list logo
