should RTS init in serial core be tied to CRTSCTS

should RTS init in serial core be tied to CRTSCTS

[Mike Frysinger]

the console= bootcmd allows for controlling of the initial state of
flow control by adding/omitting the 'r' suffix ... however, the
uart_startup() function in serial_core.c always calls down into the
serial driver with TIOCM_RTS:
static int uart_startup(...) {
...
            /*
             * Setup the RTS and DTR signals once the
             * port is open and ready to respond.
             */
            if (info->tty->termios->c_cflag & CBAUD)
                uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
...

shouldnt TIOCM_RTS be passed down only when the 'r' is appended to the
boot cmdline ?  perhaps like this:
uart_set_mctrl(port, (info->flags & UIF_CTS_FLOW ? TIOCM_RTS : 0) | TIOCM_DTR);
assuming too that TIOCM_DTR should always be set ...
-mike

Re: should RTS init in serial core be tied to CRTSCTS

[Robin Getz]

On Thu 1 Mar 2007 19:03, Mike Frysinger pondered:
> the console= bootcmd allows for controlling of the initial state of
> flow control by adding/omitting the 'r' suffix ... however, the
> uart_startup() function in serial_core.c always calls down into the
> serial driver with TIOCM_RTS:
> static int uart_startup(...) {
> ...
>             /*
>              * Setup the RTS and DTR signals once the
>              * port is open and ready to respond.
>              */
>             if (info->tty->termios->c_cflag & CBAUD)
>                 uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
> ...
>
> shouldnt TIOCM_RTS be passed down only when the 'r' is appended to the
> boot cmdline ?  perhaps like this:
> uart_set_mctrl(port, (info->flags & UIF_CTS_FLOW ? TIOCM_RTS : 0) |
> TIOCM_DTR); assuming too that TIOCM_DTR should always be set ...

This would help a similar problem I am having. Simply using a serial console 
with Flow control enabled, turns flow control on. 

If the application wants the capability to turn Flow control on later, without 
booting with it on, the current code does not allow this...

Was this the intended use the the 'console=...r'?

Thanks
-Robin

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> the console= bootcmd allows for controlling of the initial state of
> flow control by adding/omitting the 'r' suffix ...

The console command *only* sets the state for the kernel's use of one
serial port.  It does not affect any other serial port, so tying
random RTS behaviours into that command line option is absolutely
silly.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: should RTS init in serial core be tied to CRTSCTS

[Robin Getz]

On Sun 4 Mar 2007 14:46, Russell King pondered:
> On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
>  > the console= bootcmd allows for controlling of the initial state of
>  > flow control by adding/omitting the 'r' suffix ...
>
>  The console command *only* sets the state for the kernel's use of one
>  serial port.  It does not affect any other serial port, so tying
>  random RTS behaviours into that command line option is absolutely
>  silly.

I have one serial port in the system, it shares console, and the 
communications port for the application. (But I guess that is besides the 
point).

When the common serial core initialises the UART, and sees that it has the 
capability to do HW flow control - it enables it, asserting the pin, even if 
I don't want it at that moment in time.

The real issue is that there is some legacy equipment, which gets confused if 
it sees glitches on RTS (which happens today, when serial core init asserts 
RTS, and then the the main application turns it off)...

How do I set the set up the UART, so RTS is avaliable, but not enabled?

Thanks
-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Sun, Mar 04, 2007 at 03:42:25PM -0500, Robin Getz wrote:
> On Sun 4 Mar 2007 14:46, Russell King pondered:
> > On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> >  > the console= bootcmd allows for controlling of the initial state of
> >  > flow control by adding/omitting the 'r' suffix ...
> >
> >  The console command *only* sets the state for the kernel's use of one
> >  serial port.  It does not affect any other serial port, so tying
> >  random RTS behaviours into that command line option is absolutely
> >  silly.
> 
> I have one serial port in the system, it shares console, and the 
> communications port for the application. (But I guess that is besides the 
> point).

In which case communications over that port could be unreliable.
What if the kernel decides to spit out a message in the middle of
your applications data transfer?

If you're using a serial port for a data application, don't make it
the kernel console.

> When the common serial core initialises the UART, and sees that it has the 
> capability to do HW flow control - it enables it, asserting the pin, even if 
> I don't want it at that moment in time.
> 
> The real issue is that there is some legacy equipment, which gets confused if 
> it sees glitches on RTS (which happens today, when serial core init asserts 
> RTS, and then the the main application turns it off)...
> 
> How do I set the set up the UART, so RTS is avaliable, but not enabled?

No idea, sorry.  It's not something any Linux kernel version has ever
supported, and since I no longer do serial support it's not something
I'd be involved with anymore.

All I will say is that thinking about keying such a decision off the
kernel console= parameter is absolutely silly - the console= parameter
has nothing to do with the serial port's userspace settings.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: should RTS init in serial core be tied to CRTSCTS

[Mike Frysinger]

On 3/4/07, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> > the console= bootcmd allows for controlling of the initial state of
> > flow control by adding/omitting the 'r' suffix ...
>
> The console command *only* sets the state for the kernel's use of one
> serial port.  It does not affect any other serial port, so tying
> random RTS behaviours into that command line option is absolutely
> silly.

true ... so ignoring the original motivation for change i posted, is
it really correct for the serial core to be forcing TIOCM_RTS at uart
startup even though the uart doesnt have CTSRTS flow control enabled ?
 in other words, my change is agnostic of the console, and is done for
all uarts ... it should prob have a similar change in uart_shutdown()
though ...
-mike

RE: should RTS init in serial core be tied to CRTSCTS

[Tosoni]

> true ... so ignoring the original motivation for change i posted, is
> it really correct for the serial core to be forcing TIOCM_RTS at uart
> startup even though the uart doesnt have CTSRTS flow control enabled ?
>  in other words, my change is agnostic of the console, and is done for
> all uarts ... it should prob have a similar change in uart_shutdown()
> though ...
> -mike

All UNIX drivers historically set RTS and DTR upon opening, and Windows
drivers do the same... and this behaviour must be kept for compatibility I
think...

The only way I can imagine to keep RTS low on opens on selected ports, would
be to set up a parameter in /proc or /sys ? maybe its management could be
added to setserial ?

I have a similar problem with many RS485 cards, when the port is opened the
card takes the RS485 bus until RTS is turned back down by the opening
process.

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote:
> On 3/4/07, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> >On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> >> the console= bootcmd allows for controlling of the initial state of
> >> flow control by adding/omitting the 'r' suffix ...
> >
> >The console command *only* sets the state for the kernel's use of one
> >serial port.  It does not affect any other serial port, so tying
> >random RTS behaviours into that command line option is absolutely
> >silly.
> 
> true ... so ignoring the original motivation for change i posted, is
> it really correct for the serial core to be forcing TIOCM_RTS at uart
> startup even though the uart doesnt have CTSRTS flow control enabled ?
> in other words, my change is agnostic of the console, and is done for
> all uarts ... it should prob have a similar change in uart_shutdown()
> though ...

No idea - it's something that Linux has always done.  Neither do I have
any idea if changing it will break anyones setup.  However, since I don't
maintain serial anymore, I'm not about to start playing about with this
trying to find out.

Feel free to submit a patch to akpm to leave RTS alone when CRTSCTS is
not set.  I'd recommend that it sits in -mm for about 6 months to really
get an idea if it breaks anything.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: should RTS init in serial core be tied to CRTSCTS

[Mike Frysinger]

On 3/5/07, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote:
> > On 3/4/07, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > >On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> > >> the console= bootcmd allows for controlling of the initial state of
> > >> flow control by adding/omitting the 'r' suffix ...
> > >
> > >The console command *only* sets the state for the kernel's use of one
> > >serial port.  It does not affect any other serial port, so tying
> > >random RTS behaviours into that command line option is absolutely
> > >silly.
> >
> > true ... so ignoring the original motivation for change i posted, is
> > it really correct for the serial core to be forcing TIOCM_RTS at uart
> > startup even though the uart doesnt have CTSRTS flow control enabled ?
> > in other words, my change is agnostic of the console, and is done for
> > all uarts ... it should prob have a similar change in uart_shutdown()
> > though ...
>
> No idea - it's something that Linux has always done.  Neither do I have
> any idea if changing it will break anyones setup.  However, since I don't
> maintain serial anymore, I'm not about to start playing about with this
> trying to find out.

ok, i was going by Documentation/serial/driver:
... any questions you have should be directed to <rmk@arm.linux.org.uk>
guessing that should be updated ? :)

> Feel free to submit a patch to akpm to leave RTS alone when CRTSCTS is
> not set.  I'd recommend that it sits in -mm for about 6 months to really
> get an idea if it breaks anything.

sounds good to me, thanks
-mike

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

"Mike Frysinger" <vapier.adi@gmail.com> writes:

>            /*
>             * Setup the RTS and DTR signals once the
>             * port is open and ready to respond.
>             */
>            if (info->tty->termios->c_cflag & CBAUD)
>                uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
> ...
>
> shouldnt TIOCM_RTS be passed down only when the 'r' is appended to the
> boot cmdline ?

How would it be useful?

CRTSCTS is for CTS only (i.e., the transmission is paused when CTS is
inactive), not for RTS. DTR and RTS should be active when the port is
open even without CRTSCTS (= without handshaking), it's used for
various purposes such as providing +12V to the device (and two pins
can supply more power than one - sure, it isn't the best idea).

I wouldn't touch that.
-- 
Krzysztof Halasa

Re: should RTS init in serial core be tied to CRTSCTS

[Robin Getz]

On Tue 6 Mar 2007 15:40, Krzysztof Halasa pondered:
> "Mike Frysinger" <vapier.adi@gmail.com> writes:
>  >            /*
>  >             * Setup the RTS and DTR signals once the
>  >             * port is open and ready to respond.
>  >             */
>  >            if (info->tty->termios->c_cflag & CBAUD)
>  >                uart_set_mctrl(port, TIOCM_RTS | TIOCM_DTR);
>  > ...
>  >
>  > shouldnt TIOCM_RTS be passed down only when the 'r' is appended to the
>  > boot cmdline ?
>
>  How would it be useful?

It is useful on (broken) legacy serial equipment, where RTS should be 
completely under the applications control.

Glitches on RTS aren't acceptable, and confuse some devices.

>  CRTSCTS is for CTS only (i.e., the transmission is paused when CTS is
>  inactive), not for RTS. DTR and RTS should be active when the port is
>  open even without CRTSCTS (= without handshaking),

That depends on the equipment that you are attached to. Some very early 
(broken) systems actually invert the meaning of RTS, so while the kernel 
thinks it is "opening" the port, it actually closes it...

>  it's used for 
>  various purposes such as providing +12V to the device (and two pins
>  can supply more power than one - sure, it isn't the best idea).

I understand - the request wasn't to change the default operation - just add a 
method of controlling things, so those minority of people who want the 
control can have it.

-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

Robin Getz <rgetz@blackfin.uclinux.org> writes:

> It is useful on (broken) legacy serial equipment, where RTS should be 
> completely under the applications control.
>
> Glitches on RTS aren't acceptable, and confuse some devices.

Does that mean you can't use TIOCMSET, TIOCM_RTS etc?

> I understand - the request wasn't to change the default operation - just
> add a 
> method of controlling things, so those minority of people who want the 
> control can have it.

No problem as long as open without CRTSCTS raises RTS by default.
-- 
Krzysztof Halasa

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

2007/3/7, Krzysztof Halasa <khc@pm.waw.pl>:
> Robin Getz <rgetz@blackfin.uclinux.org> writes:
>
> > It is useful on (broken) legacy serial equipment, where RTS should be
> > completely under the applications control.
> >
> > Glitches on RTS aren't acceptable, and confuse some devices.
>
> Does that mean you can't use TIOCMSET, TIOCM_RTS etc?

No. It is possible to use TIOCMSET only after open syscall. Between
open and ioctl syscals RTS will be asserted. Sometimes it is not
acceptable behaviour.

-Oleksiy

Re: should RTS init in serial core be tied to CRTSCTS

[Robin Getz]

On Wed 7 Mar 2007 07:46, Krzysztof Halasa pondered:
> Robin Getz <rgetz@blackfin.uclinux.org> writes:
> > It is useful on (broken) legacy serial equipment, where RTS should be
> > completely under the applications control.
> >
> > Glitches on RTS aren't acceptable, and confuse some devices.
>
> Does that mean you can't use TIOCMSET, TIOCM_RTS etc?
>
> > I understand - the request wasn't to change the default operation -
>
> just
>
> > add a
> > method of controlling things, so those minority of people who want the
> >
> > control can have it.
>
> No problem as long as open without CRTSCTS raises RTS by default.

Right - so the question is where to manage the default state? I was thinking 
in the resource might be a good idea, but there isn't really a good place for 
it. (You could re-use some bits if flags, but I think that would not be a 
good idea).

-Robin

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

2007/3/7, Robin Getz <rgetz@blackfin.uclinux.org>:
> Right - so the question is where to manage the default state? I was thinking
> in the resource might be a good idea, but there isn't really a good place for
> it. (You could re-use some bits if flags, but I think that would not be a
> good idea).

/proc/tty/driver/uartN/settings?

-Oleksiy

Re: should RTS init in serial core be tied to CRTSCTS

[Robin Getz]

On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> 2007/3/7, Robin Getz <rgetz@blackfin.uclinux.org>:
> > Right - so the question is where to manage the default state? I was
> > thinking in the resource might be a good idea, but there isn't really a
> > good place for it. (You could re-use some bits if flags, but I think that
> > would not be a good idea).
>
> /proc/tty/driver/uartN/settings?
>

That would let you change things are run time, but the problem is at boot 
time. A default setting needs to be set, so when things initialize, and proc 
does not exist yet, it is still set properly...

-Robin

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> > 2007/3/7, Robin Getz <rgetz@blackfin.uclinux.org>:
> > > Right - so the question is where to manage the default state? I was
> > > thinking in the resource might be a good idea, but there isn't really a
> > > good place for it. (You could re-use some bits if flags, but I think that
> > > would not be a good idea).
> >
> > /proc/tty/driver/uartN/settings?
> >
> 
> That would let you change things are run time, but the problem is at boot 
> time. A default setting needs to be set, so when things initialize, and proc 
> does not exist yet, it is still set properly...

I disagree.  "proc does not exist yet" - the only time that applies is
long before userspace as active.

As I've said already, having a console on the same port as your application
program is just asking for trouble.  All bets are off - the kernel _will_
corrupt your data stream in random places.

Don't do it - it will _NEVER_ be reliable.

Never, ever, mix kernel consoles with application serial ports.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: should RTS init in serial core be tied to CRTSCTS

[Carl-Daniel Hailfinger]

Hi,

On 08.03.2007 14:48, Russell King wrote:
> As I've said already, having a console on the same port as your application
> program is just asking for trouble.  All bets are off - the kernel _will_
> corrupt your data stream in random places.
> 
> Don't do it - it will _NEVER_ be reliable.
> 
> Never, ever, mix kernel consoles with application serial ports.

Unless you want two machines to monitor each other via serial console and
each of them has only one serial port. It's not perfect, but it works well
enough despite all claims to the contrary.

Regards,
Carl-Daniel

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Thu, Mar 08, 2007 at 03:16:08PM +0100, Carl-Daniel Hailfinger wrote:
> Hi,
> 
> On 08.03.2007 14:48, Russell King wrote:
> > As I've said already, having a console on the same port as your application
> > program is just asking for trouble.  All bets are off - the kernel _will_
> > corrupt your data stream in random places.
> > 
> > Don't do it - it will _NEVER_ be reliable.
> > 
> > Never, ever, mix kernel consoles with application serial ports.
> 
> Unless you want two machines to monitor each other via serial console and
> each of them has only one serial port. It's not perfect, but it works well
> enough despite all claims to the contrary.

That's fine - you're not sending application specific data which could
be corrupted by an inopportune kernel message.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> writes:

> Unless you want two machines to monitor each other via serial console and
> each of them has only one serial port. It's not perfect, but it works well
> enough despite all claims to the contrary.

Sure, if you don't need "input" (only "console logger" function and
not "initial input/output terminal"). It has nothing to do with the
RTS "problem", though.

BTW: reasonably working, standard-compliant USB-RS232 converters
cost $15 or so. Unfortunately not that all machines have USB ports.

I agree with Russell - mixing kernel console and application's
port is asking for trouble.

OTOH I wonder what does the device in question require WRT the
serial port and WRT RTS line in particular.
I know there are some half-duplex converters which drive RTS only
while sending and which require CTS to send. They are perhaps a bit
broken and require some CSMA-alike retransmissions etc.

I don't know if one can expect RTS to stay low all the time. Even
a simple /sbin/setserial from /etc/rc.* would drive it high for
a moment. I'm afraid the only way which makes sense may be using
a customized plug.
-- 
Krzysztof Halasa

RE: should RTS init in serial core be tied to CRTSCTS

[Tosoni]

Krzysztof Halasa wrote:

> OTOH I wonder what does the device in question require WRT the
> serial port and WRT RTS line in particular.
> I know there are some half-duplex converters which drive RTS only
> while sending and which require CTS to send.

As far as I know in the old times this was the *standard* way to use a modem
(per CCITT V24), and even nowadays many modems can handle this method for
transmit, to stay compatible with the standard.

Think of radio modems. Some are inherently half duplex.

> They are perhaps a bit broken <snip>
No, no, they apply an old standard. Probably they are old as well.
>
> I don't know if one can expect RTS to stay low all the time. Even
> a simple /sbin/setserial from /etc/rc.* would drive it high for
> a moment. I'm afraid the only way which makes sense may be using
> a customized plug.

It's a pity that Linux (or Unixes) never handled RTS this way.
I feel that the /proc or sysfs solutions are the best to alter this well
established default in this driver. It would not break existing installed
hardware.

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

"Tosoni" <jp.tosoni@acksys.fr> writes:

>> OTOH I wonder what does the device in question require WRT the
>> serial port and WRT RTS line in particular.
>> I know there are some half-duplex converters which drive RTS only
>> while sending and which require CTS to send.
>
> As far as I know in the old times this was the *standard* way to use a modem
> (per CCITT V24), and even nowadays many modems can handle this method for
> transmit, to stay compatible with the standard.

I think it wasn't standard for real modems as they were full-duplex
(even these 1200/75 or what was that) but it was for other devices
such as current loops (which were frequently half-duplex).

I've seen such devices quite recently, perhaps ~ 10 years ago.
OTOH I think even "current" PC BIOSes use such signaling.

> Think of radio modems. Some are inherently half duplex.

Sure. But /dev/ttyS* ports are full-duplex, with CRTSCTS or without,
so they don't use such handshaking.

>> They are perhaps a bit broken <snip>
> No, no, they apply an old standard. Probably they are old as well.

I was thinking of a particular piece of hardware and it was definitely
broken a bit. "Selective compliance", maybe.

> It's a pity that Linux (or Unixes) never handled RTS this way.
> I feel that the /proc or sysfs solutions are the best to alter this well
> established default in this driver. It would not break existing installed
> hardware.

/proc is probably no-no.

For such signaling, it would perhaps be better to invent another flag,
similar to CRTSCTS. The driver would, of course, need some real code
for that.
-- 
Krzysztof Halasa

RE: should RTS init in serial core be tied to CRTSCTS

[Tosoni]

Krzysztof Halasa wrote:

> "Tosoni" <jp.tosoni@acksys.fr> writes:
> > As far as I know in the old times this was the *standard*
> way to use a modem
> > (per CCITT V24), and even nowadays many modems can handle
> this method for
> > transmit, to stay compatible with the standard.
>
> I think it wasn't standard for real modems as they were full-duplex
> (even these 1200/75 or what was that) but it was for other devices
> such as current loops (which were frequently half-duplex).
>

It has always been the standard for all modems. The mistake comes from the
fact that the serial ports has been used extensively to drive things which
are *not* modems (say, printers and VT100 consoles on Unix systems). Such
devices did not need the standard-specified RTS function.

CCITT V24 says about RTS: "...this signal drives the DCE and sets it to
transmit data..." (translated from french)
CCITT V24 does not constraint the DCE to being half or full duplex.
CCITT V24 says nothing about using RTS to handle flow control.

> I've seen such devices quite recently, perhaps ~ 10 years ago.
> OTOH I think even "current" PC BIOSes use such signaling.

Even Windows implements the CCITT view of RTS, via a flag named "RTS_TOGGLE"

>
> > Think of radio modems. Some are inherently half duplex.
>
> Sure. But /dev/ttyS* ports are full-duplex, with CRTSCTS or without,
> so they don't use such handshaking.

A full duplex port can be used for both full- and half- duplex. A half
duplex modem cannot be used on a full-duplex-only port. So Linux should be
adapted to the standard, since we cannot adapt the standard to Linux.

> /proc is probably no-no.

Then sysfs sounds good to me.

>
> For such signaling, it would perhaps be better to invent another flag,
> similar to CRTSCTS. The driver would, of course, need some real code
> for that.

Another flag would help to drive modems, yes. But it would not help keeping
RTS low at open, because we need to open the port (which raises RTS) in
order to set the flag. Hence the need for an extra parameter in sysfs.

Best regards,
Jean-Pierre Tosoni

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

"Tosoni" <jp.tosoni@acksys.fr> writes:

> It has always been the standard for all modems.

Look, I've been using various modems for many years, starting with
self-made 300 bps one and there were basically 3 options:
- no flow control at all (no buffering etc), RTS/CTS disabled/missing,
- XON/XOFF flow control, RTS/CTS disabled/missing,
- RTS/CTS handshaking with RTS = modem can send to computer (with
  option to ignore RTS) and CTS = computer can send to modem.

> The mistake comes from the
> fact that the serial ports has been used extensively to drive things which
> are *not* modems (say, printers and VT100 consoles on Unix systems). Such
> devices did not need the standard-specified RTS function.

VT100 and printers are DTE, connections between DTE (without help
of DCE) are obviously non-standard.

> CCITT V24 says about RTS: "...this signal drives the DCE and sets it to
> transmit data..." (translated from french)
> CCITT V24 does not constraint the DCE to being half or full duplex.
> CCITT V24 says nothing about using RTS to handle flow control.

Circuit 105 - Request to send
Direction: To DCE
Signals on this circuit control the data channel transmit function
of the DCE. The ON condition causes the DCE to assume the data channel
transmit mode. The OFF condition causes the DCE to assume the data
channel non-transmit mode, when all data transferred on circuit 103
have been transmitted.

What do you think are "data channel transmit mode" and "non-transmit"
mode? Obviously the standard doesn't know if it's a radiomodem, RS-485
style multipoint bus or something else but it's clearly half-duplex -
full-duplex devices are always in "transmit" and "receive" mode
simultaneously.

Does your modem drop carrier when RTS goes?

V.24 assumes DTE is always able to receive data. While it's probably
the case with PC and Linux, it may not be true with all DTE. With
strict V.24 DTE has not way to say "I can't take data, stop
transmitting". Now imagine connecting a serial printer to a PC
with a pair of DCE.

>> I've seen such devices quite recently, perhaps ~ 10 years ago.
>> OTOH I think even "current" PC BIOSes use such signaling.
>
> Even Windows implements the CCITT view of RTS, via a flag named "RTS_TOGGLE"

Great, meanwhile we don't have it here, but that only means nobody
is really interested in it.

>> For such signaling, it would perhaps be better to invent another flag,
>> similar to CRTSCTS. The driver would, of course, need some real code
>> for that.
>
> Another flag would help to drive modems, yes.

Which modems, exactly? Normal modems work perfectly fine with current
CRTSCTS and this RTS toggling could only confuse them.
A flag alone is no help for half-duplex devices, they would need
a complete handshaking code.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: should RTS init in serial core be tied to CRTSCTS

[Tosoni]

Krzysztof Halasa wrote:

> > It has always been the standard for all modems.
>
> Look, I've been using various modems for many years, starting with
> self-made 300 bps one and there were basically 3 options:
> - no flow control at all (no buffering etc), RTS/CTS disabled/missing,
> - XON/XOFF flow control, RTS/CTS disabled/missing,
> - RTS/CTS handshaking with RTS = modem can send to computer (with
>   option to ignore RTS) and CTS = computer can send to modem.

Well, I know well that nowadays all modems use RTS for RX handshake or dont
use it altogether.
But the original meaning was not this (see below), and there are still
devices out there that rely on the original meaning. Should Linux ignore
them ?

>
> > The mistake comes from the
> > fact that the serial ports has been used extensively to
> drive things which
> > are *not* modems (say, printers and VT100 consoles on Unix
> systems). Such
> > devices did not need the standard-specified RTS function.
>
> VT100 and printers are DTE, connections between DTE (without help
> of DCE) are obviously non-standard.

Yes.

>
> > CCITT V24 says about RTS: "...this signal drives the DCE
> and sets it to
> > transmit data..." (translated from french)
> > CCITT V24 does not constraint the DCE to being half or full duplex.
> > CCITT V24 says nothing about using RTS to handle flow control.
>
> Circuit 105 - Request to send
> Direction: To DCE
> Signals on this circuit control the data channel transmit function
> of the DCE. The ON condition causes the DCE to assume the data channel
> transmit mode. The OFF condition causes the DCE to assume the data
> channel non-transmit mode, when all data transferred on circuit 103
> have been transmitted.

Thank you for pointing out the correct text.
You can see that in this text, RTS is used for the transmit function, not
receive. So RX handshake with RTS is nonstandard. But I agree it is in wide
use.

>
> What do you think are "data channel transmit mode" and "non-transmit"
> mode? Obviously the standard doesn't know if it's a radiomodem, RS-485
> style multipoint bus or something else but it's clearly half-duplex -
> full-duplex devices are always in "transmit" and "receive" mode
> simultaneously.

If the standard assumed half-duplex, it would say so.
In fact, in its paragraph 1.3 the standard says explicitely that it can be
used for 4-wires lines. Do you think you need four wires for half-duplex
operation ?

The standard specifies a behaviour that works in both cases (half and full
duplex).

I agree that nowadays, it's important only for half-duplex. But half-duplex
devices *do* exist ! And they rely on this use of RTS.

>
> Does your modem drop carrier when RTS goes?
>
> V.24 assumes DTE is always able to receive data. While it's probably
> the case with PC and Linux, it may not be true with all DTE. With
> strict V.24 DTE has not way to say "I can't take data, stop
> transmitting". Now imagine connecting a serial printer to a PC
> with a pair of DCE.

That is true, I agree that V.24 does not address flow control: this is
because V.24 is a DTE-to-DCE interface (part of layer 1), not a DTE-to-DTE
interface. This is why XON-XOFF has been designed.
It is assumed (remember that the standard is old) that the modem does not
have significant buffering. So it does not need flow control by itself. This
is not the case for the modems which compress data, for example.

>
> >> I've seen such devices quite recently, perhaps ~ 10 years ago.
> >> OTOH I think even "current" PC BIOSes use such signaling.
> >
> > Even Windows implements the CCITT view of RTS, via a flag
> named "RTS_TOGGLE"
>
> Great, meanwhile we don't have it here, but that only means nobody
> is really interested in it.

In fact, there where many requests in the past to handle this, but they did
not make it to the drivers/serial sources.
	For example there is a ioctl TIOCSERSETRS485 in the architecture that does
exactly this.
	Also I saw several people asking questions as to how to handle this from
user space in a reliable way and the answers were always unsatisfactory
(because of scheduling delays).
	Also, recent OXFORD UART components added this in the hardware. Do you
think OXFORD would add hardware features that nobody care about ? We have
customers that care about a lot. Unfortunately there is not way in the Linux
8250 driver to activate this feature. And when I offered to add it, I was
put off by the serial maintainer, for the (bad) reason below.

>
> >> For such signaling, it would perhaps be better to invent
> another flag,
> >> similar to CRTSCTS. The driver would, of course, need some
> real code
> >> for that.
> >
> > Another flag would help to drive modems, yes.
>
> Which modems, exactly? Normal modems work perfectly fine with current
> CRTSCTS and this RTS toggling could only confuse them.

All the bunch of half-duplex serial devices, like radio modems and
pseudo-modems driving an half duplex bus (which are in *wide* use in the
industry)

> A flag alone is no help for half-duplex devices, they would need
> a complete handshaking code.

Not true.
This is also the view of the former maintainer of drivers/serial. But
obviously neither of you used half duplex devices before.
There is no need for handshake, since half duplex is used in master/slave
situations. And I can insure you, that Windows handles this very well, using
only the above-mentioned RTS_TOGGLE flag.

> --
> Krzysztof Halasa
>

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

"Tosoni" <jp.tosoni@acksys.fr> writes:

>> A flag alone is no help for half-duplex devices, they would need
>> a complete handshaking code.
>
> Not true.
> This is also the view of the former maintainer of drivers/serial.

It's just reality. If your IC in question does this in hardware
- fine, but you still have to support it in the driver, adding
a #define XXX doesn't help.

"Code talks".

> But
> obviously neither of you used half duplex devices before.

This is your "not true". I was using them, though they weren't
modems.

> There is no need for handshake, since half duplex is used in master/slave
> situations.

Not necesarily, there are CSMA/CD-style designs as well as token-ring
style.

> And I can insure you, that Windows handles this very well, using
> only the above-mentioned RTS_TOGGLE flag.

That means the DCE does all the buffering and handshaking. I'd say
it's not common, most devices are simpler.
-- 
Krzysztof Halasa

RE: should RTS init in serial core be tied to CRTSCTS

[Tosoni]

Krzysztof Halasa wrote:

> It's just reality. If your IC in question does this in hardware
> - fine, but you still have to support it in the driver, adding
> a #define XXX doesn't help.
<sigh>
The reality is: the need exists, it does not break the driver, other OSs
support it, Linux does not, I personally wrote support for it in the
existing 8250 driver, other people wrote similar code in similar Linux
drivers.

But for some reason maintainers did not want to hear about this work. So I
must reinsert it over and over again with each new version of the kernel.
</sigh>

> "Code talks".
Indeed, please listen to drivers/serial/crisv10.c function rs_ioctl() (not
my code)
I can show you my own code also, if you care.

> > But
> > obviously neither of you used half duplex devices before.
>
> This is your "not true". I was using them, though they weren't
> modems.
>
> > There is no need for handshake, since half duplex is used
> > in master/slave situations.
>
> Not necesarily, there are CSMA/CD-style designs as well as token-ring
> style.

We talk about RTS use don't we ? What I talk about, is a way to toggle RTS
around transmit data with acceptable delays. This can only reside in the
serial driver, not in a line discipline.

A line discipline would have a hard time to switch on the OXFORD behaviour
without serial driver support wouldn't it ?

>
> > And I can insure you, that Windows handles this very well, using
> > only the above-mentioned RTS_TOGGLE flag.
>
> That means the DCE does all the buffering and handshaking. I'd say
> it's not common, most devices are simpler.

Of course !
That simply means that buffer management is a link-level function.
I do not want to remove the existing behaviour for RTS, I want to add a
optional "new" one to handle the original standard, and I do believe that I
am not alone to need this.

Best regards

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

"Tosoni" <jp.tosoni@acksys.fr> writes:

> The reality is: the need exists, it does not break the driver, other OSs
> support it, Linux does not, I personally wrote support for it in the
> existing 8250 driver, other people wrote similar code in similar Linux
> drivers.
>
> But for some reason maintainers did not want to hear about this work. So I
> must reinsert it over and over again with each new version of the kernel.
> </sigh>

Some link to archives maybe? I don't think I've seen your code.
Perhaps you should post the code again? Cc to the maintainer and
lkml wouldn't hurt.

> What I talk about, is a way to toggle RTS
> around transmit data with acceptable delays. This can only reside in the
> serial driver, not in a line discipline.

Of course.

> I do not want to remove the existing behaviour for RTS, I want to add a
> optional "new" one to handle the original standard, and I do believe that I
> am not alone to need this.

That is quite possible, though the normal way of getting things
included into the kernel is posting a patch, getting comments,
perhaps fixing problems, posting again, until it's accepted.
-- 
Krzysztof Halasa

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

2007/3/8, Russell King <rmk+lkml@arm.linux.org.uk>:
> On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> > On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> > > 2007/3/7, Robin Getz <rgetz@blackfin.uclinux.org>:
> > > > Right - so the question is where to manage the default state? I was
> > > > thinking in the resource might be a good idea, but there isn't really a
> > > > good place for it. (You could re-use some bits if flags, but I think that
> > > > would not be a good idea).
> > >
> > > /proc/tty/driver/uartN/settings?
> > >
> >
> > That would let you change things are run time, but the problem is at boot
> > time. A default setting needs to be set, so when things initialize, and proc
> > does not exist yet, it is still set properly...
>
> I disagree.  "proc does not exist yet" - the only time that applies is
> long before userspace as active.
>
> As I've said already, having a console on the same port as your application
> program is just asking for trouble.  All bets are off - the kernel _will_
> corrupt your data stream in random places.
>
> Don't do it - it will _NEVER_ be reliable.
>
> Never, ever, mix kernel consoles with application serial ports.

Ok. I understand now one of the sources of misunderstanding. I don't
want to mix console and application serial port. It was a question,
Myke Frisinger initially asked. I would switch on/off console
depending on some external control action if possible...

The other problem is how to open serial port with correct settings
_after_ booting. In this case /proc could be applicable, isn't it?

-Oleksiy

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
> 2007/3/8, Russell King <rmk+lkml@arm.linux.org.uk>:
> >On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> >> On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> >> > 2007/3/7, Robin Getz <rgetz@blackfin.uclinux.org>:
> >> > > Right - so the question is where to manage the default state? I was
> >> > > thinking in the resource might be a good idea, but there isn't 
> >really a
> >> > > good place for it. (You could re-use some bits if flags, but I think 
> >that
> >> > > would not be a good idea).
> >> >
> >> > /proc/tty/driver/uartN/settings?
> >> >
> >>
> >> That would let you change things are run time, but the problem is at boot
> >> time. A default setting needs to be set, so when things initialize, and 
> >proc
> >> does not exist yet, it is still set properly...
> >
> >I disagree.  "proc does not exist yet" - the only time that applies is
> >long before userspace as active.
> >
> >As I've said already, having a console on the same port as your application
> >program is just asking for trouble.  All bets are off - the kernel _will_
> >corrupt your data stream in random places.
> >
> >Don't do it - it will _NEVER_ be reliable.
> >
> >Never, ever, mix kernel consoles with application serial ports.
> 
> Ok. I understand now one of the sources of misunderstanding. I don't
> want to mix console and application serial port.

It's not a misunderstanding if you realise that email is threaded and
you _follow_ the individual threads.  Robin has a similar concern to
you but _additionally_ wants something that you don't.

So really to remove the "confusion" from this discussion you should
avoid trying to correct replies to Robin's emails.

> The other problem is how to open serial port with correct settings
> _after_ booting. In this case /proc could be applicable, isn't it?

Doubt it with todays opinions about /proc contents.  Probably more
appropriate in sysfs, if someone can be bothered to do the work
required to properly integrate tty and sysfs.

Don't look at me; I'm not doing very much with serial anymore.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

2007/3/8, Russell King <rmk+lkml@arm.linux.org.uk>:
> On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
> > Ok. I understand now one of the sources of misunderstanding. I don't
> > want to mix console and application serial port.
>
> It's not a misunderstanding if you realise that email is threaded and
> you _follow_ the individual threads.  Robin has a similar concern to
> you but _additionally_ wants something that you don't.
>
> So really to remove the "confusion" from this discussion you should
> avoid trying to correct replies to Robin's emails.

On some stages it was very close... Anyway, sorry...

> > The other problem is how to open serial port with correct settings
> > _after_ booting. In this case /proc could be applicable, isn't it?
>
> Doubt it with todays opinions about /proc contents.  Probably more
> appropriate in sysfs, if someone can be bothered to do the work
> required to properly integrate tty and sysfs.
>
> Don't look at me; I'm not doing very much with serial anymore.

I don't. :) Surely I'm not experienced kernel developer, but I would
like to do it. :)
The only purpose of my remarks and questions was to find the best
origin of force
to solve this problem. And all remarks in this thread are very valuable for me.

-Oleksiy

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

2007/3/8, Russell King <rmk+lkml@arm.linux.org.uk>:
> On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> > On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
> > > 2007/3/7, Robin Getz <rgetz@blackfin.uclinux.org>:
> > > > Right - so the question is where to manage the default state? I was
> > > > thinking in the resource might be a good idea, but there isn't really a
> > > > good place for it. (You could re-use some bits if flags, but I think that
> > > > would not be a good idea).
> > >
> > > /proc/tty/driver/uartN/settings?
> > >
> >
> > That would let you change things are run time, but the problem is at boot
> > time. A default setting needs to be set, so when things initialize, and proc
> > does not exist yet, it is still set properly...
>
> I disagree.  "proc does not exist yet" - the only time that applies is
> long before userspace as active.
>
> As I've said already, having a console on the same port as your application
> program is just asking for trouble.  All bets are off - the kernel _will_
> corrupt your data stream in random places.
>
> Don't do it - it will _NEVER_ be reliable.
>
> Never, ever, mix kernel consoles with application serial ports.
>
> --
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:
>


-- 
EvoLogics GmbH
Blumenstraße 49, 10243 Berlin

F&E Labor Bionik
Ackerstraße 76, 13355 Berlin

Tel.: + 49- (0) 30- 46 06 82 26
Fax:  + 49- (0) 30- 46 06 82 15

lesha@evologics.de
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: should RTS init in serial core be tied to CRTSCTS

[Robin Getz]

On Thu 8 Mar 2007 08:48, Russell King pondered:
> On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> > That would let you change things are run time, but the problem is at
> > boot time. A default setting needs to be set, so when things initialize,
> > and proc does not exist yet, it is still set properly...
>
> I disagree.  "proc does not exist yet" - the only time that applies is
> long before userspace as active.

Right - We both agree - And setting console=/dev/null in the bootargs still 
does not help.

When the kernel initializes the UART Port, it asserts RTS - which confuses the 
host it is attached to (in this case, the Linux system is the serial 
peripheral).

How about adding a module_param to serial core, which the default is to assert 
RTS (as is today), and someone (like me) can override with serial_core.RTS=0

-Robin

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
> On Thu 8 Mar 2007 08:48, Russell King pondered:
> > On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
> > > That would let you change things are run time, but the problem is at
> > > boot time. A default setting needs to be set, so when things initialize,
> > > and proc does not exist yet, it is still set properly...
> >
> > I disagree.  "proc does not exist yet" - the only time that applies is
> > long before userspace as active.
> 
> Right - We both agree - And setting console=/dev/null in the bootargs still 
> does not help.

Ok, good.

> When the kernel initializes the UART Port, it asserts RTS - which confuses
> the host it is attached to (in this case, the Linux system is the serial 
> peripheral).

... which occurs /after/ userspace is up and running, when sysfs is
available.  So putting it in sysfs is reasonable.

> How about adding a module_param to serial core, which the default is to
> assert RTS (as is today), and someone (like me) can override with
> serial_core.RTS=0

So all ports change behaviour with a single parameter?  That'll stop
NULL modem cables with hardware flow control enabled working on other
ports without compensatory tweaking.

No, doing a system-wide change like that is _not_ a solution - it just
moves the problem elsewhere.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: should RTS init in serial core be tied to CRTSCTS

[Robin Getz]

On Thu 8 Mar 2007 15:40, Russell King pondered:
> On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
> > Right - We both agree - And setting console=/dev/null in the bootargs
> > still does not help.
>
> Ok, good.
>
> > When the kernel initializes the UART Port, it asserts RTS - which
> > confuses the host it is attached to (in this case, the Linux system
> > is the serial peripheral).
>
> ... which occurs /after/ userspace is up and running, when sysfs is
> available.  So putting it in sysfs is reasonable.

Hmm - maybe I don't understand things then.

Today - RTS gets asserted when serial_core calls uart_startup(), which is 
pretty early in the boot process (unless it is loaded as a module - which I'm 
not doing).

-Robin

Re: should RTS init in serial core be tied to CRTSCTS

[Russell King]

On Thu, Mar 08, 2007 at 06:32:29PM -0500, Robin Getz wrote:
> On Thu 8 Mar 2007 15:40, Russell King pondered:
> > On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
> > > Right - We both agree - And setting console=/dev/null in the bootargs
> > > still does not help.
> >
> > Ok, good.
> >
> > > When the kernel initializes the UART Port, it asserts RTS - which
> > > confuses the host it is attached to (in this case, the Linux system
> > > is the serial peripheral).
> >
> > ... which occurs /after/ userspace is up and running, when sysfs is
> > available.  So putting it in sysfs is reasonable.
> 
> Hmm - maybe I don't understand things then.
> 
> Today - RTS gets asserted when serial_core calls uart_startup(), which is 
> pretty early in the boot process (unless it is loaded as a module - which I'm 
> not doing).

uart_startup() is called when something opens a serial port.  There's
two points which that happens:

1. when you have serial console enabled, and the kernel opens /dev/console
   before starting userspace.

2. when userspace opens a serial port.

If you're not using a serial console (and you don't have an utterly broken
/dev nodes - iow incorrect /dev/console entry), then (1) doesn't apply.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

2007/3/8, Russell King <rmk+lkml@arm.linux.org.uk>:
> ... which occurs /after/ userspace is up and running, when sysfs is
> available.  So putting it in sysfs is reasonable.

Is it right place for serial settings?
/sys/class/tty/ttySN/

How far is it reasonable to split termios settings to the attributes?
1)
/sys/class/tty/ttyS0/termios
2)
/sys/class/tty/ttyS0/c_iflag
/sys/class/tty/ttyS0/c_oflag
/sys/class/tty/ttyS0/c_cflag
/sys/class/tty/ttyS0/c_lflag
/sys/class/tty/ttyS0/c_cc
3)
/sys/class/tty/ttyS0/speed
/sys/class/tty/ttyS0/eof
/sys/class/tty/ttyS0/eon
/sys/class/tty/ttyS0/erase
.... and so on


-Oleksiy

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

> >  it's used for
> >  various purposes such as providing +12V to the device (and two pins
> >  can supply more power than one - sure, it isn't the best idea).
>
> I understand - the request wasn't to change the default operation - just add a
> method of controlling things, so those minority of people who want the
> control can have it.

There are two parts of at least my request.

The first part is, why should serial driver assert RTS when CRTSCTS is
not set and which problem may follow by changing this default behaviour.

The second part is that you are talking about. I don't see for a
moment some regular
way to preconfigure serial interface parameters before opening the
device, at the
same time current behaviour creates potentially dangerous RTS jerking
during device configuring.

May be it would be good idea to develop some tty control driver which
provides a
possibility to change default setting of the drivers?

-Oleksiy

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

"Oleksiy Kebkal" <kebkal@gmail.com> writes:

> May be it would be good idea to develop some tty control driver which
> provides a
> possibility to change default setting of the drivers?

If there is a real need for it (such as a real existing device)...
then sure (it wouldn't be a "default setting" anymore, of course).
-- 
Krzysztof Halasa

Re: should RTS init in serial core be tied to CRTSCTS

[Mike Frysinger]

On 3/7/07, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Oleksiy Kebkal" <kebkal@gmail.com> writes:
> > May be it would be good idea to develop some tty control driver which
> > provides a
> > possibility to change default setting of the drivers?
>
> If there is a real need for it (such as a real existing device)...
> then sure (it wouldn't be a "default setting" anymore, of course).

if there wasnt a real need to control this behavior (as in existing
devices), then i wouldnt have spawned this thread in the first place
:)

i dont muck around in serial core for fun
-mike

Re: should RTS init in serial core be tied to CRTSCTS

[Oleksiy Kebkal]

> > shouldnt TIOCM_RTS be passed down only when the 'r' is appended to the
> > boot cmdline ?
>
> How would it be useful?
>
> CRTSCTS is for CTS only (i.e., the transmission is paused when CTS is
> inactive), not for RTS. DTR and RTS should be active when the port is
> open even without CRTSCTS (= without handshaking), it's used for
> various purposes such as providing +12V to the device (and two pins
> can supply more power than one - sure, it isn't the best idea).

The name of the option is not CCTS, but CRTSCTS, isn't it? So, you may
not only want to pause own transmission when CTS is inactive, but to
control the transmission flow from the remote side. Why should RTS be
active when the port is open even without CRTSCTS? You may still
assert RTS manually if it is used to provide +12V to the device. But
as I understand it is not common use of this pin, isn't it?

And a question is not only about supporting legacy equipment but also
about embedded hardware where RTS/CTS handshaking is handshaking, not
something else...

-Oleksiy

Re: should RTS init in serial core be tied to CRTSCTS

[Krzysztof Halasa]

"Oleksiy Kebkal" <lesha@evologics.de> writes:

> The name of the option is not CCTS, but CRTSCTS, isn't it? So, you may
> not only want to pause own transmission when CTS is inactive, but to
> control the transmission flow from the remote side. Why should RTS be
> active when the port is open even without CRTSCTS?

Because you'd break many devices otherwise.
-- 
Krzysztof Halasa