From: Ruud Linders <kernelml@xs4all.nl>
To: Daniel Mack <daniel@caiaq.de>
Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman <gregkh@suse.de>,
Johan Hovold <jhovold@gmail.com>, Alan Cox <alan@linux.intel.com>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH] usb-serial/ftdi_sio: fix DTR/RTS line modes
Date: Sun, 06 Jun 2010 11:33:06 +0200 [thread overview]
Message-ID: <4C0B6B52.5050702@xs4all.nl> (raw)
In-Reply-To: <20100603115727.GY2695@buzzloop.caiaq.de>
On 06/03/2010 01:57 PM, Daniel Mack wrote:
> On Thu, Jun 03, 2010 at 01:55:02PM +0200, Daniel Mack wrote:
>> Call set_mctrl() and clear_mctrl() according to the flow control mode
>> selected. This makes serial communication for FT232 connected devices
>> work when CRTSCTS is not set.
>>
>> This fixes a regression introduced by 4175f3e31 ("tty_port: If we are
>> opened non blocking we still need to raise the carrier"). This patch
>> calls the low-level driver's dtr_rts() function which consequently sets
>> TIOCM_DTR | TIOCM_RTS. A later call to set_termios() without CRTSCTS in
>> cflags, however, does not reset these bits, and so data is not actually
>> sent out on the serial wire.
>>
>> Signed-off-by: Daniel Mack <daniel@caiaq.de>
>> Cc: Greg Kroah-Hartman <gregkh@suse.de>
>> Cc: Johan Hovold <jhovold@gmail.com>
>> Cc: Alan Cox <alan@linux.intel.com>
>> Cc: linux-usb@vger.kernel.org
>
> Oops. I forgot to Cc: stable@kernel.org.
> This is in fact broken since 2.6.31-something.
>
>
>
>
>> ---
>> drivers/usb/serial/ftdi_sio.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
>> index 050211a..79dd1ae 100644
>> --- a/drivers/usb/serial/ftdi_sio.c
>> +++ b/drivers/usb/serial/ftdi_sio.c
>> @@ -2005,6 +2005,8 @@ static void ftdi_set_termios(struct tty_struct *tty,
>> "urb failed to set to rts/cts flow control\n");
>> }
>>
>> + /* raise DTR/RTS */
>> + set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
>> } else {
>> /*
>> * Xon/Xoff code
>> @@ -2052,6 +2054,8 @@ static void ftdi_set_termios(struct tty_struct *tty,
>> }
>> }
>>
>> + /* lower DTR/RTS */
>> + clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
>> }
>> return;
>> }
>> --
>> 1.7.1
>>
> --
Hmm, I tried this patch on plain 2.6.34 but still have a problem.
As you indicated since 2.6.31-something something is broken.
I'm using a receive only device (http://rfxcom.com/receivers.htm)
which works fine until the system becomes more busy, usually it runs
almost idle and all is fine.
However, when this happens, it appears the received characters get
buffered somewhere as nothing seems to get through or is delayed for
many minutes.
When I then =write= a character to the serial device
echo > /dev/ttyUSB0
the data is received in sudden burst, seems no data is actually lost
just seriously delayed.
Any ideas ?
next prev parent reply other threads:[~2010-06-06 9:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-03 11:55 [PATCH] usb-serial/ftdi_sio: fix DTR/RTS line modes Daniel Mack
2010-06-03 11:32 ` Alan Cox
2010-06-03 12:23 ` Daniel Mack
2010-06-03 11:57 ` Daniel Mack
2010-06-03 14:27 ` Greg KH
2010-06-03 16:21 ` Gene Heskett
2010-06-03 16:26 ` Greg KH
2010-06-03 16:53 ` Gene Heskett
2010-06-06 9:33 ` Ruud Linders [this message]
2010-06-06 9:44 ` Daniel Mack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0B6B52.5050702@xs4all.nl \
--to=kernelml@xs4all.nl \
--cc=alan@linux.intel.com \
--cc=daniel@caiaq.de \
--cc=gregkh@suse.de \
--cc=jhovold@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox