()
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
Signed-off-by: Al Borchers [EMAIL PROTECTED]
--
--- a/drivers/usb/serial/io_edgeport.c 2007-06-13 18:35:25.0 +0200
+++ b/drivers/usb/serial/io_edgeport.c 2007-06-13 18:36:04.0 +0200
@@ -3046,11
Oleg --
Quoting Oleg Verych [EMAIL PROTECTED]:
1) sysfsless usb-reconfiguration
I will test you patch again with the current kernel. We can
make it work, patching usb-serial if needed.
2) fw loader.
I have a patch from Multitech with support for new
devices and the firmware loader as an
Greg --
Some further cleanup after Oliver's patch to update the tty
buffering. The input buffer is not used at all anymore, so
I removed it.
This applies to 2.6.22-rc2 _after_ Oliver's patch, Digi
AccelePort adapted to new tty buffering.
-- Al
Signed-off-by: Al Borchers [EMAIL PROTECTED
Thanks. I will look at this patch this weekend.
-- Al
Quoting Oliver Neukum [EMAIL PROTECTED]:
Hi,
this fixes the flushing trouble due to its own buffering for this driver.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
---
Thanks. I will look at this one, too, this weekend.
-- Al
Quoting Oliver Neukum [EMAIL PROTECTED]:
Hi,
you are submitting an URB with GFP_KERNEL holding a spinlock.
In this case the spinlock can be dropped earlier.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL
get to it.
-- Al
Quoting Oliver Neukum [EMAIL PROTECTED]:
Am Montag, 2. April 2007 13:25 schrieb Al Borchers:
Oleg --
Quoting Oleg Verych [EMAIL PROTECTED]:
OK, then i must recheck, why it works for me. Maybe it's just another
sysfs crap, because i tested on rc5 without any
-interface drivers.
Cc: Linus Torvalds [EMAIL PROTECTED]
Cc: Al Borchers [EMAIL PROTECTED]
Signed-off-by: Oleg Verych [EMAIL PROTECTED]
---
This tiny change uses new interface merged in 2.6.19 (yet author of
it didn't find this driver to fix).
Greg KH waits driver's author ack, while i already
Oleg --
Quoting Oleg Verych [EMAIL PROTECTED]:
OK, then i must recheck, why it works for me. Maybe it's just another
sysfs crap, because i tested on rc5 without any of it enabled.
You will only see the problem if you have more than one usb serial
device. Plug in the first device, then plug in
Greg, Oleg --
Quoting Greg KH [EMAIL PROTECTED]:
So please, just be patient. Wait for Al to forward it to me, with his
signed-off-by: and then I'll add it to my trees.
Sorry I have been slow. I will test this patch and get it
to you this weekend. Oleg made the changes I asked for and
it
Oleg --
I tried this on 3410 and 5052 with and without firmware--worked
great.
Please
1) Change return value to 1, rather than 0xO1E and 0xA1B.
(Clever, but it will just confuse readers.)
2) Drop (void) cast on usb_driver_set_configuration.
3) Resend the patch with a signed-off line.
Greg --
Thanks. We will decide between .h and request_firmware and get you
a patch.
-- Al
Quoting Greg KH [EMAIL PROTECTED]:
On Fri, Mar 02, 2007 at 02:56:42AM -0600, Al Borchers wrote:
(resend with subject)
Greg --
Multitech has 5 new ti_usb_3410_5052 devices that all need
Oleg --
Quoting Oleg Verych [EMAIL PROTECTED]:
pp-by: Oleg Verych
---
i.e. no more uGLYdev with sysfs
Alan, i'm looking forward to deal with this crutch :-E
drivers/usb/serial/ti_usb_3410_5052.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index:
Oleg --
Ah... Now I see 0x01E and 0xA1B. Clever.
-- Al
Quoting Oleg Verych [EMAIL PROTECTED]:
pp-by: Oleg Verych
---
i.e. no more uGLYdev with sysfs
Alan, i'm looking forward to deal with this crutch :-E
drivers/usb/serial/ti_usb_3410_5052.c |6 +++---
1 file changed, 3
Greg --
Multitech has 5 new ti_usb_3410_5052 devices that all need
special firmware.
Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
driver as .h files? Or should I use request_firmware?
Obviously including them in the driver would be easier for users,
and that is what
(resend with subject)
Greg --
Multitech has 5 new ti_usb_3410_5052 devices that all need
special firmware.
Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
driver as .h files? Or should I use request_firmware?
Obviously including them in the driver would be easier
at http://www.brimson.com/downloads/ti_usb_multitech-1.1.tgz
to see how I want this done. I will submit this patch myself in a few days.
-
/* Defines */
-#define TI_DRIVER_VERSIONv0.9
+#define TI_DRIVER_VERSIONv0.92
#define TI_DRIVER_AUTHOR Al Borchers [EMAIL PROTECTED
Oleg --
Where are the whitespace-cleanup.patch and the req_firm.patch?
I have some time now to test things.
-- Al
Quoting Oleg Verych [EMAIL PROTECTED]:
On Sun, Jan 28, 2007 at 11:09:27PM +, Oleg Verych wrote:
Hallo, Al.
After your comments (mostly minor) about patch, you've said,
Oleg --
Quoting Oleg Verych [EMAIL PROTECTED]:
On 12/16/06, Al Borchers [EMAIL PROTECTED] wrote:
* We can't remove the compiled in firmware--that would break things
until users get and install the firmware images.
* What I did in my patch at
www.brimson.com/downloads/ti_usb_multitech
Oleg --
Quoting Oleg Verych [EMAIL PROTECTED]:
On 12/16/06, Al Borchers [EMAIL PROTECTED] wrote:
* +#define TI_3410_EZ430_ID 0xF430 /* TI ez430 development
tool
*/
Where do you use this?
Shiny new device from TI, don't you know? You've lost nothing MSP430
Design
Oleg --
Some comments. I will be away until next Tuesday, when I can do
more with this.
* We can't remove the compiled in firmware--that would break things
until users get and install the firmware images.
* What I did in my patch at www.brimson.com/downloads/ti_usb_multitech-1.1.tgz
is to
Oleg --
I will look at it tonight.
(The driver is not orphaned, though I have limited
time to work on it.)
-- Al
Quoting Oleg Verych [EMAIL PROTECTED]:
On 12/14/06, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2006 at 11:10:46PM +0200, Oleg Verych wrote:
Hallo. Due to very big
Quoting Alan Stern [EMAIL PROTECTED]:
Mister Greg, how to change configuration _inside_ the driver? Device
was made to be
working on second usb config after one reconnect/device change, i've
lost whole day
trying to make something with that. After all, usb_set_configuration()
isn't
Pete --
Thanks for checking with us. Looks good to me.
One minor thing, I would prefer sizeof(string) to 30, but
it is not crucial.
-- Al
Quoting Pete Zaitcev [EMAIL PROTECTED]:
Clean up the unicode handling in io_edgeport. Make get_string size-limited.
Signed-off-by: Pete Zaitcev [EMAIL
Carles Pina i Estany wrote:
On Aug/01/2005, [EMAIL PROTECTED] wrote:
I would like to communicate from Linux (device driver) to Windows
(host) using USB serial (without load acm=1 option in module).
(I have to do in this way)
That's too bad then. I don't think you can make it talk to
Windows
Greg --
Thanks for the comments.
I am sending updated TI USB 3410/5052 driver patches in
the next three messages (the one big patch hasn't yet made
it through to the list). The patch is also available at
http://www.brimson.com/downloads/ti_usb_3410_5052_2.6.10-rc2-bk13.patch
These patches are
Pete Zaitcev wrote:
Hmm. I always felt this better, because otherwise you allow your code
to look pasqual-ish, when the language dictates the textual order.
I agree. A top down order to the code seems easier to read to me.
-- Al
---
SF email is
Greg --
This patch adds the gadget serial documentation.
Please apply.
Thanks,
-- Al
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff -urN -X dontdiff
linux-2.6.10-rc2-bk3.orig/Documentation/usb/gadget_serial.txt
linux-2.6.10-rc2-bk3.new/Documentation/usb/gadget_serial.txt
--- linux-2.6.10
count was mistakenly
decremented. Now rmmod --wait works correctly.
* The tty-driver_data pointer is never set to NULL once
the port is open. Before there was a small window when
it was mistakenly set to NULL for an already open port.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
--- linux
.
- Cleared the write_urb pointer after freeing it, to prevent oops on
failed open.
- Cleared the txfifo.fifo pointer after freeing it, to prevent double
free on failed open.
- Simplified rounding the baud rate divisor.
- Added some error messages.
Signed-off-by: Al Borchers [EMAIL PROTECTED
closing wait as a module parameter, it is 40 seconds by default.
- Simplified rounding the baud rate divisor.
- Added some error messages.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff -ur -X dontdiff linux-2.6.10-rc1-bk20.orig/drivers/usb/serial/io_ti.c
linux-2.6.10-rc1-bk20.new/drivers
Greg KH wrote:
On Thu, Nov 11, 2004 at 03:46:23AM -0600, Al Borchers wrote:
- Added ION_SETMODE ioctl to set 232 or 485 mode for Edgeport 4s.
NO NO NO!
I agree completely--the ioctl came from 2.4 and I just did not
have time to fix it. I will remove the ioctl and resend the
patch, then add
parameter, it is 40 seconds by default.
- Simplified rounding the baud rate divisor.
- Added some error messages.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff -ur -X dontdiff linux-2.6.10-rc1-bk20.orig/drivers/usb/serial/io_ti.c
linux-2.6.10-rc1-bk20.new/drivers/usb/serial/io_ti.c
--- linux
Bill Rugolsky Jr. wrote:
The dropped newline problem with OPOST + ONLCR, describe by Joe Philipps
...
Is a fix for this problem likely soon(ish), or would a hackish workaround be
acceptable for inclusion upstream?
One solution to this problem is to use a write buffer. This has been
done in
Greg --
This patch fixes a problem in usbserial open/close. If
the first open of a usbserial port fails, kref_put is
called twice on serial-kref--once in the error handling
in open and once in close, which is called even though
the open failed.
This patch does the put only in the failed open in
Greg --
This patch does not correctly handle failures from try_module_get
or usb_serial_get_by_index. Please ignore this patch--I will send
a better one later.
Thanks,
-- Al
--- linux-2.6.10-rc1-bk14.orig/drivers/usb/serial/usb-serial.c 2004-11-05 01:35:08.0 -0600
+++
[EMAIL PROTECTED] wrote:
After trying the usb serial driver on linux-2.4.20, I found the max speed
is about 120kbytes/sec, My windows side driver is modified against
bulkusb(one sample of Windows DDK), I transfer a 2.2M file from window to
smartphone(pxa27x) with usb serial driver. It took about
Lonnie --
Lonnie Mendez wrote:
If that is all you guys can see wrong, I will resubmit it.
Great to have a new USB serial driver. Thanks. Here are some
comments...
Cypress_write function allocates a new urb for each write.
Without any limit on how much memory your driver can use, it
could
.
- Simplified rounding the baud rate divisor.
- Added some error messages.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff -urp -X dontdiff linux-2.6.9-rc3.orig/drivers/usb/serial/io_ti.c
linux-2.6.9-rc3.new/drivers/usb/serial/io_ti.c
--- linux-2.6.9-rc3.orig/drivers/usb/serial/io_ti.c 2004
usb_kill_urb instead of synchronous usb_unlink_urb.
- Simplified rounding the baud rate divisor.
- Added some error messages.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
--- linux-2.6.9-rc3.orig/drivers/usb/serial/io_edgeport.c 2004-10-04
22:52:09.114749968 -0500
+++ linux-2.6.9-rc3.new/drivers
Alan Cox wrote:
On Gwe, 2004-10-01 at 19:14, Al Borchers wrote:
* The tty layer could use a semaphore so the USB serial set_termios could
sleep until the new termios settings have taken effect before returning.
This seems to be the right choice and is the change I will implement.
Great! Thanks
Alan Cox wrote:
In a waiting case the driver will get
-chars_in_buffer
until it returns zero
-wait_until_sent
-change_termios
which serializes with respect to the one writer. If you have a writer
during a termios change by another well tough luck, you lose and I've
no
2.6.9-rc3 changes the locking in the tty_ioctl.c function
change_termios(). It gets a spin_lock_irqsave(tty_termios_lock,...)
before calling the tty driver's set_termios function.
This means that the drivers' set_termios functions cannot sleep.
Unfortunately, many USB serial drivers' set_termios
Pete Zaitcev wrote:
Al Borchers did explain why sending X-OFF in the driver was
appropriate once upon a time.
I don't remember talking about this and couldn't find it in a
quick google--can you point me to it?
but perhaps you would wish to preserve that technique after you
examined his message
Sam King wrote:
I found a bug where the io_ti.c driver calls schedule while in an
interrupt. The problem stems from usbserial.c allowing a
serial_throttle call proceed while in an interrupt, which results in
sending a urb to clear the CTS bit of the usb serial port, and thus a
call to schedule.
David Brownell wrote:
I'll include it; there's another patch of Alex's that I want to
test too (for a problem Al Borchers reported, and I think
I've probably seen too -- system hang).
I finally found some time to test out Alex's patch. It fixed the
problem I was seeing. I as able to disconnect
[EMAIL PROTECTED] wrote:
Yes, but for reading/writing they should be the same.
But it's definitely different behavior. With ACM I was able to
establish a connection (data loss, due to no flow control, but that's expected),
and I could send both ways. Without ACM, I _never_ saw this. The
/show_bug.cgi?id=2459. Close after
disconnect no longer tries to communicate with the device.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
--- linux-2.6.9-rc1.orig/drivers/usb/serial/digi_acceleport.c 2004-08-14
05:55:31.0 -0500
+++ linux-2.6.9-rc1.new/drivers/usb/serial/digi_acceleport.c
disconnect no longer tries to communicate with the device.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
--- linux-2.6.9-rc1.orig/drivers/usb/serial/digi_acceleport.c 2004-08-14
05:55:31.0 -0500
+++ linux-2.6.9-rc1.new/drivers/usb/serial/digi_acceleport.c2004-09-03
03:43
Stefan --
[EMAIL PROTECTED] wrote:
I want to use the plain (non ACM) stuff if possible. All testing
below is for the non-acm stuff, which should be the simpler case
anyway, isn't it?
Yes, but for reading/writing they should be the same.
Another problem ist that IMHO the NULLing of the
David Eriksson wrote:
Has anyone added tty_hangup to the usb-serial core yet?
Here is a patch you can experiment with. This is for 2.6.9-rc1;
it adds calls to tty_hangup on all ports of a usb-serial device
that has been disconnected.
Not sure if this is what is needed for ipaq or any other
buffer when closing.
- Added a wait for the data to drain from the
device hardware buffer when closing.
- Cleared the driver write buffer when closing.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff --exclude-from=dontdiff -urp linux-2.6.9-rc1.tmp/drivers/usb/serial/pl2303.c
linux-2.6.9-rc1
already writing, after closing the port
while writing was in progress.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff --exclude-from=dontdiff -urp linux-2.6.9-rc1.orig/drivers/usb/serial/pl2303.c
linux-2.6.9-rc1.new/drivers/usb/serial/pl2303.c
--- linux-2.6.9-rc1.orig/drivers/usb/serial/pl2303.c
Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]:
Ouch. That explains things. Cat hung after some time, and I got
gs_flush_chars: NULL port pointer
gs_recv_packet: port=0, bad tty magic
Messages at some point. g_serial hung after that. Reconnect solved that.
That does not look like a flow
Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]:
Where is this driver? The one in 2.6.8.1 does not have
a use_acm parameter.
A patch to add acm support to g_serial for 2.6.8.1 was posted here 8/17.
http://sourceforge.net/mailarchive/forum.php?thread_id=5350555forum_id=5398
-- Al
.
This document and the the gadget serial driver itself are
Copyright (C) 2004 by Al Borchers ([EMAIL PROTECTED]).
If you have questions, problems, or suggestions for this driver
please contact Al Borchers at [EMAIL PROTECTED]
Prerequisites
-
Versions of the gadget serial driver
David Brownell wrote:
Hmm, one of my comments was that the .inf file (and docs) should
go into Documentation/usb so that it's more accessible!
I only had to remove the .inf attachment to get past linux-usb-devel
mail filters. The gserial.inf file is included in the text of the
documentation I
Alex --
Alex Sanks wrote:
So, I've got a patch that:
- Updates reset logic to ensure that endpoint toggle and halt bits only get
cleared on endpoints other than ep0 to fix an extremely unlikely (but
possible) exposure should a setup packet come in after we've checked the
reset status but
decrementing
the open count.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
-- Al
diff -urp --exclude-from=dontdiff
linux-2.6.8.1.gserial_autoconf/drivers/usb/gadget/Makefile
linux-2.6.8.1/drivers/usb/gadget/Makefile
--- linux-2.6.8.1.gserial_autoconf/drivers/usb/gadget/Makefile 2004-08-16
14
ids and no longer included in IO Networks
version of usbvend.h.
- Removed the 1 port device from the io_edgeport driver--this
device is a parallel port handled by the usblp driver.
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff -urp linux-2.6.8-rc4.orig/drivers/usb/serial
Alan Stern wrote:
I've got a Netchip 2280 board (http://www.netchip.com). It's a PCI card
with a high-speed USB device interface, and there's a driver for it in the
USB gadgets directory (net2280).
is it expensive?
I don't know what price they're currently charging, but it's not going to
be
a different kernel. Should I
submit this and future gadget serial changes to you
or Greg or both?
Thanks,
-- Al
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff -ur --exclude-from=dontdiff linux-2.6.7/drivers/usb/gadget/Makefile
linux-2.6.7-gserial/drivers/usb/gadget/Makefile
--- linux-2.6.7
Phil Dibowitz wrote:
Al Borchers wrote:
Is
the app using ppp to connect with the phone, by any chance?
Nope ...
Then probably the app is opening the port O_NONBLOCK but not
expecting short writes.
The program is called multisync and its the IrMC plugin that talks to
my phone, ...
Thanks
.
This patch fixed problems with getty for Olaf Hering and
with hotsync for Phil Dibowitz.
Let me know if you want changes.
Thanks,
-- Al
Signed-off-by: Al Borchers [EMAIL PROTECTED]
diff --exclude-from=diff.exclude -ur linux-2.6.7/drivers/usb/serial/pl2303.c
linux-2.6.7-ion/drivers/usb/serial
Phil --
Phil Dibowitz wrote:
That works.
Great news!
I would still like to understand the causes of the problem.
Can you tell me what application you were using to sync with
the phone?--I would like to look at the source code. Is
the app using ppp to connect with the phone, by any chance?
-- Al
Willem --
Willem Riede wrote:
Does anyone have an Edgeport/4 working with 2.6.7 (to be precise,
I'm using FC3-T1's kernel 2.6.7-1.492smp)?
I get the following oops when I plug it in: ...
I saw the same problem with FC2 2.6.6-1.435.2.3, but I do not
see it in the official 2.6.7 from kernel.org.
Olaf --
Olaf Hering wrote:
Thanks Al!. Works perfectly, even with agetty.
Good news! Thanks for testing it.
Greg, would you accept this patch? It is the
same code we use in the io_ti driver and similar
to the gadget serial code.
-- Al
---
This
Olaf --
Olaf Hering wrote:
Hmm, I'm not sure how to translate that to LANG=diff
Here is one such translation--a patch to 2.6.7 to add a
circular buffer to the pl2303 USB serial driver.
I tested it briefly and it solved the dropped newline
problem--I used agetty to test it as you described
in your
Olaf Hering wrote:
Here is a dmesg debug output, rm has an agetty connected, screen
connected via keyspan. I dont get any newlines.
S0:12345:respawn:/sbin/agetty -L 9600 keyspan screen
agetty sttys the port to onlcr (map newline to carriage-return
newline). However, the pl2303 cannot do this; it
Olaf --
Olaf Hering wrote:
I have the keyspan working now, and its
directly connected to a PL2303 adapter on the same box.
writing to the PL2303 and reading from the keyspan leads to garbage
output. Sometimes the newline is repeated to fill the dd blocksize,
somethings I get the 'foo' filecontent
Jaako --
Jaakko Niemi wrote:
Next, does anyone have ideas why an Edgeport/4 using the io_ti
driver does not work with 2.4.26 untill I unplug the box and
plug it in again? Same ohci hardware.
I saw a similar problem on the Edgeport 421--don't know
if that is related to the problem you are seeing
Jaakko --
Jaakko Niemi wrote:
Next, does anyone have ideas why an Edgeport/4 using the io_ti
driver does not work with 2.4.26 untill I unplug the box and
plug it in again? Same ohci hardware.
One other thing to check--the Edgeport 4 is actually 2 2 port
devices behind an embedded hub.
support, or Peter Berger [EMAIL PROTECTED],
+ * or Al Borchers [EMAIL PROTECTED].
+ *
* Version history:
*
* 2003_04_03 al borchers
@@ -274,7 +278,7 @@
/*
* Version Information
*/
-#define DRIVER_VERSION v2.3
+#define DRIVER_VERSION v2.3a
#define DRIVER_AUTHOR Greg Kroah-Hartman [EMAIL
:45:15.0 -0500
@@ -23,6 +23,10 @@
* Edgeport/4D8
* Edgeport/8i
*
+ * For questions or problems with this driver, contact Inside Out
+ * Networks technical support, or Peter Berger [EMAIL PROTECTED],
+ * or Al Borchers [EMAIL PROTECTED].
+ *
* Version history:
*
* 2003_04_03 al
On Tue, 15 Jun 2004, Al Borchers wrote:
I will make this change and try to test it out on OHCI.
I have made the change to defer the submit_urb in the
interrupt callback and tested on OHCI. The driver no
longer locks when opening a port, and I can send some
data in both directions. However
Jaakko Niemi wrote:
I have couple different problems with two different Edgeport boxes,
which are hooked into a Dell PowerEdge 1750 with ServerWorks OSB4/CSB5
ohci usb controller, running 2.4.26 without any patches.
First, with older Edgeport/8, if I try to access any of /dev/ttyUSBx
devices,
Johannes Erdfelt wrote:
UHCI had a similar problem. We just created a list of completions and
added the URB to that list and then called the completions later in the
interrupt with no locks held.
And it looks like OHCI does something similar for bulk, control, and
one-shot interrupt urbs. But
David Brownell wrote:
And 2.6 cleans up that locking wierdness, as well as others.
Though to be honest, I don't remember this as a 2.4 issue; is
that from those recent OHCI changes?
I don't know the history, but these changes (the ohci_lock spin
lock and postponing the callback or not until after
Pete Zaitcev wrote:
Please rerun your tests on 2.4.26 and report me the results. I worked
around this problem for 2.4 already, so it's not an issue anymore.
It is still there--see the oops below. Can you tell me what changes
were made that might affect this problem?
You can see that in usbserial
Pete --
Pete Zaitcev wrote:
Pete Zaitcev wrote:
Please rerun your tests on 2.4.26 and report me the results. I worked
around this problem for 2.4 already, so it's not an issue anymore.
It is still there--see the oops below. Can you tell me what changes
were made that might affect this problem?
I
Pete --
It does look like this solves the out of order writes, but
at the expense of allocating a buffer for every write and
delaying the write until the helper gets scheduled. It
also needs GFP_ATOMIC kmallocs. I fear this overhead will
hurt performance. (We just recently had a customer who
Greg --
Here is a simple patch that adds a low_level_locking
flag to the usb_serial_device_type so that a USB
serial driver can indicate that it does its own
locking and does not want to use the usbserial
semaphore. Any driver that does not explicitly
set this flag will get the default behavior.
Greg --
Also, I still plan to backport the USB serial locking from 2.6 to
2.4, if you will accept that.
This late in the 2.4 development cycle, I don't really know. If it
fixes real bugs, probably. Otherwise I doubt it.
As we have talked about before, the semaphore in usbserial write leads
to an
Greg --
Greg KH wrote:
Speaking of which, I'm getting a lot of complaints from users of the
latest devices that they do not work with the current kernel code. It
looks like you and Peter are offering up a kernel patch to help some
people with this.
Care to send it to me, as I am getting tired of
Greg --
Just read about udev. Exactly the sort of thing we need.
Unfortunately not many IO Networks customers are using 2.6
yet.
I understand why you wouldn't want to change the 2.4
usbserial to do this sort of thing.
How about io_edgeport and io_ti driver bug fixes and
enhancements for 2.4--are
,
-- Al
--- usbserial.c.origMon May 10 17:32:30 2004
+++ usbserial.c Mon May 10 23:17:28 2004
@@ -3,7 +3,7 @@
*
* Copyright (C) 1999 - 2002 Greg Kroah-Hartman ([EMAIL PROTECTED])
* Copyright (C) 2000 Peter Berger ([EMAIL PROTECTED])
- * Copyright (C) 2000 Al Borchers ([EMAIL PROTECTED
Greg --
There is a problem in usbserial.c in serial_write (and
possibly other usbserial functions) that causes an
oops--Scheduling in interrupt.
I think this is the same problem we talked about a few
months ago, but now I see the cause of the oops. It is
not in the usb serial drivers
Greg --
Greg KH wrote:
I agree. We can either use Pete's patch, or work on backporting the 2.6
code to 2.4 (no semaphores, and any locking that is needed must be
handled by the individual drivers.)
Thanks for the pointer to Pete's patch--I did a quick search
before posting but did not find
Greg --
Greg KH wrote:
I agree. Care to do the port? :)
Sure. I won't be able to start on until after
Feb 5, though.
-- Al
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
Roman --
roman pielaszek wrote:
I found your USB Zyxel omni 56k plus driver on the web. It was version
for kernel 2.2.18.
Do you have any idea how to run this modem on newer kernels (RedHet 9 =
2.4.20-8)?
I was unable to compile your file omniplus.c on 2.4.20. Besides, in RH9
distribution,
Julian --
Julian Back wrote:
I have been testing the g_serial serial gadget with my superh_udc driver
on the 2.4.21 kernel. It works when I send data from the host to the
device but when I send from the device to the host I get extra characters.
Example:
device# echo 1234 /dev/ttygs0
Dave --
Here is a patch for gadget serial for 2.4 that fixes
the wait_cond_interruptible_timeout macro and the
debug defined but not used warning.
This is against bk://kernel.bkbits.net/db/linux/gadget-2.4.
Thanks,
-- Al# This is a BitKeeper generated patch for the following project:
# Project
Greg KH wrote:
On Mon, Sep 08, 2003 at 11:08:52AM -0500, Borchers, Al (C)(STP) wrote:
Try adding a wake_up_interruptible(tty-read_wait) in usbserial.c
usb_serial_disconnect().
Hm, that might work, I'll have to try that sometime soon...
You will also need to somehow tell the tty subsystem
Joshua Wise wrote:
We certainly should have a serial gadget.
In progress. Progress is in the handhelds.org CVS repository, as 'char.c'.
I have also started writing a USB gadget serial device.
It has the usual tty driver interface so it will look
like a normal serial port to user space. Looks
Greg KH wrote:
But I don't think the log shows this happening, right?
Right--I do not understand what is happening in the
logs. I am interested in investigating more.
I was trying to clarify what was happening with
opost processing and why the write has to succeed.
Actually, if write()
Dave, Greg --
I think this is one problem with OPOST ONLCR and the
pl2303 usb usb driver (and other usb serial drivers)--
Look at the write_chan in n_tty.c. It calls opost_block()
to write a block of characters up to the first '\n', then
opost() to write the '\r' and '\n', using two calls to
Forgot to explain that opost calls write_room to see
if there is room to write two characters when it
wants to write \r\n. pl2303 says sure, there is
room. opost then writes '\r' and '\n' in two
separate writes, expecting that there is room for
both, but the second write fails.
pl2303 and
96 matches
Mail list logo
