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

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

[Oleksiy Kebkal]

On 4 Mar, 21:50, Robin Getz <r...@blackfin.uclinux.org> wrote:
> On Sun 4 Mar 2007 14:46, Russell King pondered:
> >  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.
> 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?

Yes, it is key issue. I think it is not silly to want to set up the
UART before RTS is enabled.
It is going not about some random RTS behaviour, but about the
question how to ask the
kernel just don't touch RTS signal. As I understand the current kernel
implementation
doesn't give a chance to do it.

I wrote about it also several days ago here:
http://groups.google.de/group/linux.kernel/browse_thread/thread/82e61dccd11c9e3f/b03971c074609c95?lnk=gst&q=Kebkal&rnum=1&hl=ru#b03971c074609c95
Maybe it would be more relevant to write it in this topic.

Thanks
-Oleksiy

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

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:

>> 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

[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

[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

[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 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 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

[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]

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

[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

[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 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

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: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

[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 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

[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

[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

[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

[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, 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

[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

[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" <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

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]

> > 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

[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

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

[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

[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/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

[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:

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

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 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

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