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
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
---
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 --
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 ag
This morning I received and email from ZyXEL about specs for
the Omni.net USB ISDN TA.
... / ZyXEL wrote:
> Thanks for your using ZyXEL product. We are willing to help the Linux user.
> Allen is our product manager of Omni.net usb. He will help you get the spec.
So we may get some specs for this
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
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
y comments,
-- 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
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
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 s
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 t
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
bou
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.
T
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
see my patch 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_VERSION"v0.9"
> +#define TI_DRIVER_VERSION"v0.92"
>
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: linux-2
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,
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 I
(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 fo
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
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.
Thank
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
interface for usb-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'
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
I can 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 ju
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]>
> --
>
> --- a/drivers
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 Neuku
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 Borche
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
e remaining users of usb_unlink_urb()
>
> 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_edgepo
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 the
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 simi
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() does
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. Lo
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 sub
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
Here is a small patch to bk://kernel.bkbits.net/db/linux/gadget-2.6
to fix up the "debug defined but not used error message".
Greg KH wrote:
> Here's a patch against the latest 2.6 tree that adds the gadget serial
> driver.
Thanks.
> I still think theres some more cleanup that this driver can u
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/tt
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
> distribut
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 v
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
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()
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 u
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 di
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 dev
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 themselves,
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
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, the
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 OHCI
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 t
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
: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:
*
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 D
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. Sometimes
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
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:
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 e
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
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.
Phil --
Phil Dibowitz wrote:
Jul 24 00:24:37 rider kernel: drivers/usb/serial/pl2303.c: pl2303_write
- length = 64, data = 83 00 48 01 00 45 00 74 00 65 00 6c 00 65 00 63 00
6f 00 6d 00 2f 00 70 00 62 00 2f 00 6c 00 75 00 69 00 64 00 2f 00 30 00
30 00 30 00 30 00 30 00 31 00 30 00 30 00 30 00 30
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
r logins over getty.
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.
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
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, ...
Than
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 ver
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/
se, rather than just 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
.
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 are
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 ju
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
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=5350555&forum_id=5398
-- Al
---
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
e to write,
reporting "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
---
driver
write 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/pl23
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 purpose
/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/
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.c2004-0
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 tty->driver_d
[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 gadget->hos
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.
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.
Th
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
[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 18
Alan Cox wrote:
How much of a problem is this, would it make more sense to make the
termios locking also include a semaphore to serialize driver side events
and not the spin lock ?
Its a design decision for the tty layer. You should choose whatever is
best there and the drivers will have to adapt.
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 a
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
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
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 potent
conds by default.
- 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/driv
open.
- Used 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
+++
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
+++ linux-2.6.10-rc1-bk14
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 pl230
module use 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 Bor
ers.
- 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 PRO
efault.
- Added 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-
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 rese
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/usb/serial/io_ti
100 matches
Mail list logo