Re: should RTS init in serial core be tied to CRTSCTS
"Tosoni" <[EMAIL PROTECTED]> 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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: should RTS init in serial core be tied to CRTSCTS
Krzysztof Halasa wrote: > "Tosoni" <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: should RTS init in serial core be tied to CRTSCTS
Krzysztof Halasa wrote: Tosoni [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Tosoni [EMAIL PROTECTED] 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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
"Tosoni" <[EMAIL PROTECTED]> 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 > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King <[EMAIL PROTECTED]>: ... 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King [EMAIL PROTECTED]: ... 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Tosoni [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: should RTS init in serial core be tied to CRTSCTS
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 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Carl-Daniel Hailfinger <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King <[EMAIL PROTECTED]>: 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote: > 2007/3/8, Russell King <[EMAIL PROTECTED]>: > >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 <[EMAIL PROTECTED]>: > >> > > 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King <[EMAIL PROTECTED]>: 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 <[EMAIL PROTECTED]>: > > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King <[EMAIL PROTECTED]>: 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 <[EMAIL PROTECTED]>: > > > 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- EvoLogics GmbH Blumenstraße 49, 10243 Berlin F Labor Bionik Ackerstraße 76, 13355 Berlin Tel.: + 49- (0) 30- 46 06 82 26 Fax: + 49- (0) 30- 46 06 82 15 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 <[EMAIL PROTECTED]>: > > > 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered: > 2007/3/7, Robin Getz <[EMAIL PROTECTED]>: > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered: 2007/3/7, Robin Getz [EMAIL PROTECTED]: 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 [EMAIL PROTECTED]: 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- EvoLogics GmbH Blumenstraße 49, 10243 Berlin FE Labor Bionik Ackerstraße 76, 13355 Berlin Tel.: + 49- (0) 30- 46 06 82 26 Fax: + 49- (0) 30- 46 06 82 15 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote: 2007/3/8, Russell King [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/8, Russell King [EMAIL PROTECTED]: 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Carl-Daniel Hailfinger [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: should RTS init in serial core be tied to CRTSCTS
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/7, Robin Getz <[EMAIL PROTECTED]>: 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 3/7/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: "Oleksiy Kebkal" <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Wed 7 Mar 2007 07:46, Krzysztof Halasa pondered: > Robin Getz <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/7, Krzysztof Halasa <[EMAIL PROTECTED]>: Robin Getz <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
"Oleksiy Kebkal" <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
"Oleksiy Kebkal" <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Robin Getz <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Robin Getz [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Oleksiy Kebkal [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Oleksiy Kebkal [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/7, Krzysztof Halasa [EMAIL PROTECTED]: Robin Getz [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Wed 7 Mar 2007 07:46, Krzysztof Halasa pondered: Robin Getz [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 3/7/07, Krzysztof Halasa [EMAIL PROTECTED] wrote: Oleksiy Kebkal [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
2007/3/7, Robin Getz [EMAIL PROTECTED]: 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Tue 6 Mar 2007 15:40, Krzysztof Halasa pondered: > "Mike Frysinger" <[EMAIL PROTECTED]> 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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
"Mike Frysinger" <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
Mike Frysinger [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Tue 6 Mar 2007 15:40, Krzysztof Halasa pondered: Mike Frysinger [EMAIL PROTECTED] 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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 3/5/07, Russell King <[EMAIL PROTECTED]> wrote: On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote: > On 3/4/07, Russell King <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote: > On 3/4/07, Russell King <[EMAIL PROTECTED]> 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 3/4/07, Russell King <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 4 Mar, 21:50, Robin Getz <[EMAIL PROTECTED]> 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=Kebkal=1=ru#b03971c074609c95 Maybe it would be more relevant to write it in this topic. Thanks -Oleksiy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 4 Mar, 21:50, Robin Getz [EMAIL PROTECTED] 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=gstq=Kebkalrnum=1hl=ru#b03971c074609c95 Maybe it would be more relevant to write it in this topic. Thanks -Oleksiy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 3/4/07, Russell King [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote: On 3/4/07, Russell King [EMAIL PROTECTED] 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
On 3/5/07, Russell King [EMAIL PROTECTED] wrote: On Mon, Mar 05, 2007 at 12:09:20PM -0500, Mike Frysinger wrote: On 3/4/07, Russell King [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: should RTS init in serial core be tied to CRTSCTS
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
should RTS init in serial core be tied to CRTSCTS
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
should RTS init in serial core be tied to CRTSCTS
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
