bool "USB Serial Converter verbose debug"
- depends on USB_SERIAL=y
+ depends on USB_SERIAL
help
Say Y here if you want verbose debug messages from the USB Serial
Drivers sent to the kernel debug log.
--
Joe Nardelli
[EMAIL
Richard B. Johnson wrote:
On Mon, 7 Jun 2004, nardelli wrote:
Greg KH wrote:
On Fri, Jun 04, 2004 at 05:34:41PM +0100, Ian Abbott wrote:
On 04/06/2004 15:59, nardelli wrote:
[SNIPPED...]
= drivers/usb/serial/visor.c 1.114 vs edited =
--- 1.114/drivers/usb/serial/visor.cFri Jun 4 07
Greg KH wrote:
On Fri, Jun 04, 2004 at 05:34:41PM +0100, Ian Abbott wrote:
On 04/06/2004 15:59, nardelli wrote:
A related problem with the current implementation is that is easy to
run out of memory by running something similar to this:
# cat /dev/zero > /dev/ttyUSB0
That affects both
^*(&*(# editor not copying tabs - I should have caught that.
Here's another try:
This was prepared against 2.6.7-rc2.
Signed-off-by: Joe Nardelli <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.7-rc2.orig/drivers/usb/serial/ftdi_sio.c
linux-2.6.7-rc2/drivers/usb/serial/ftdi_
Ian Abbott wrote:
On 04/06/2004 15:59, nardelli wrote:
Note that I have not verified any of the below on
hardware associated with drivers/usb/serial/ftdi_sio.c,
only with drivers/usb/serial/visor.c. If anyone has
hardware for this device, I would appreciate your comments.
A memory leak occurs in
/serial/visor.c when the usb device is
unplugged while data is being written to the device. This
patch should clear that up.
This was prepared against 2.6.7-rc2.
Signed-off-by: Joe Nardelli <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.7-rc2.orig/drivers/usb/serial/ftdi_sio.c
linux-2.6
Greg KH wrote:
On Thu, Jun 03, 2004 at 12:43:31PM -0400, nardelli wrote:
I'm looking into possible memory leaks in the visor driver,
and I had a question regarding behavior of error handling on
failed urb submission. From what I understand, when
submitting a urb fails, the completion handler
will be called exactly once, when the USB core and
* Host Controller Driver (HCD) are finished with the URB. When the completion
* function is called, control of the URB is returned to the device
* driver which issued the request. The completion handler may then
* immediately free or reuse
Fri, 2004-05-21 at 16:00, nardelli wrote:
As punishment for not searching the archives, you are required
to test it :-)
Greg KH wrote:
On Fri, May 21, 2004 at 02:56:02PM -0400, Adam C Powell IV wrote:
Greetings,
I've been experiencing crashes immediately following hotsync of a
Handspring Tre
Greg KH wrote:
On Mon, May 24, 2004 at 05:42:54PM -0400, nardelli wrote:
Nah, this is good enough. I've tweaked the patch a bit to keep from
creating a big structure on the stack, and reduced the copy port logic
to something a bit more readable and applied this version. I'll send it
of
Greg KH wrote:
On Mon, May 24, 2004 at 03:38:58PM -0400, nardelli wrote:
nardelli wrote:
1) Whether writing to the 1st or 2nd port, the machine hangs pretty badly
after catting /dev/urandom for more than 1 second or two. This continues
even after catting has stopped, and the device has been
gt;port[0]->interrupt_in_endpointAddress = serial->port[1]->
+ interrupt_in_endpointAddress;
+ serial->port[0]->interrupt_in_buffer = serial->port[1]->
+ interrupt_in_buffer;
+
+ serial->port[1]->read_urb = swap_port.read_urb;
+ serial->port[1]->bulk_in_endpointAddres
-
Joe Nardelli
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?
nardelli wrote:
One more question - my system does not really like it when I redirect /dev/urandom
to either the first or second port. I know that it obviosuly makes no sense to
do such a thing, but is it expected that there should be no problems associated
with this. I'm not finished te
Greg KH wrote:
On Fri, May 21, 2004 at 06:04:46PM -0400, nardelli wrote:
Maybe I spoke too soon here. We have 1 bulk in, 2 bulk out, and 1 interrupt
in endpoint, which by the logic in usb-serial, translates to 2 ports. Only
one of those ports can have a read_urb associated with it, unless we
nardelli wrote:
Greg KH wrote:
@@ -456,7 +460,8 @@ static void visor_close (struct usb_seri
return;
/* shutdown our urbs */
-usb_unlink_urb (port->read_urb);
+if (port->read_urb)
+usb_unlink_urb (port->read_urb);
I really do not think these extra c
Greg KH wrote:
On Fri, May 21, 2004 at 03:51:23PM -0400, nardelli wrote:
Patch is line-wrapped, so I can't apply it :(
Hmmm... I couldn't see the linewrap in the original I sent, or
in test ones that I did. Probably my mail tool, but then it
is getting late on a Friday, which probably
_GET_CONNECTION_INFORMATION (3) and
PALM_GET_EXT_CONNECTION_INFORMATION (4) requests. Both times nothing is
returned.
In any case, when no valid connection info is found, num_ports is initially
set to 0, a warning is logged, and num_ports defaults to
we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--
Joe Na
ead_urb;
+ serial->port[0]->bulk_in_endpointAddress = serial->port[1]->
+ bulk_in_endpointAddress;
+ serial->port[0]->bulk_in_buffer = serial->port[1]->bulk_in_buffer;
+ serial->port[0]->interrupt_in_urb = serial->port[1]->interrupt_in_urb;
+ serial->port[0]->interru
Alan Stern wrote:
On Fri, 21 May 2004, nardelli wrote:
The api for usb_control_msg says, 'If successful, it returns 0, othwise a
negative error number', and I didn't see any other way to figure out how
much data was being returned.
In the current kernel sources, the kerneldoc for
I think it's fishy.
Oops - that does look a little fishy. I'll revisit.
-- Pete
--
Joe Nardelli
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10
Greg KH wrote:
On Thu, May 20, 2004 at 07:08:56PM -0400, nardelli wrote:
Here is a proposed patch for Oops on disconnect in the visor module.
For details of the problem, please see
http://bugzilla.kernel.org/show_bug.cgi?id=2289
I would really appreciate it if anyone that uses this module could
this is
the first patch that I've submitted, please feel free to be brutally
honest regarding content, formatting, etc.
--
Joe Nardelli
[EMAIL PROTECTED]
--- old/linux-2.6.6/drivers/usb/serial/visor.c 2004-05-09 22:32:27.0 -0400
+++ new/linux-2.6.6/drivers/usb/serial/visor.c 2004-05-20
24 matches
Mail list logo
