From: Jiri Slaby <jslaby@suse.cz>
To: Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: serial ports now asserting DTR and RTS during boot; breaks connected hardware
Date: Tue, 03 Jan 2012 17:00:45 +0100 [thread overview]
Message-ID: <4F03262D.8090506@suse.cz> (raw)
In-Reply-To: <20120103153707.GA12771@redhat.com>
On 01/03/2012 04:37 PM, Dave Jones wrote:
> Jiri,
> We got this report from a user who notes a change in behaviour for
> his serial hardware over the last few kernel versions.
Hi!
I'm busy right now, however just after a quick look, it may be related to:
https://lkml.org/lkml/2011/12/6/573
I'll take a look later.
> https://bugzilla.redhat.com/show_bug.cgi?id=771010
>
> This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?
What changes do you mean? In serial-core.c? That one is not used by USB
serials. Hence this wouldn't occur with FTDI.
> > Description of problem:
> >
> > After upgrade from FC14 to FC16, it was discovered that during kernel boot, the
> > DTR and RTS signals of serial devices (both real UART and FTDI USB devices) are
> > being asserted from driver load to approx 20 seconds afterward. This causes
> > some types of hardware connected to these ports to fail as they expect a
> > different sequence or controlled activation of these signals. In particular,
> > ham radio equipment that uses these signals to key transmitters is now going
> > into uncontrolled transmit for nearly the duration of kernel boot.
> >
> >
> > Steps to Reproduce:
> > 1. connect RS232 breakout box to serial port
> > 2. boot system
> > 3. watch DTR and RTS LEDs light as kernel is booting
> >
> > Actual results:
> >
> > LEDs light and stay light for almost entire boot duration indicating that DTR
> > and RTS are asserting as the kernel boots.
> >
> > Expected results:
> >
> > DTR and RTS should not activate while kernel is booting. They should only
> > activate when the port is opened by an application and it has performed a
> > termios function to enable these signals.
> >
> >
> > Additional info:
> >
> > The following code in the ftdi_sio driver is one suspect but this behavior
> > happens on 8250 UARTs also so it is systemic now,
> >
> > ftdi_sio.c, line 2161,
> >
> > /* Ensure RTS and DTR are raised when baudrate changed from 0
> > */
> > if (!old_termios || (old_termios->c_cflag & CBAUD) == B0)
> > set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
> >
>
>
regards,
--
js
suse labs
next prev parent reply other threads:[~2012-01-03 16:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-03 15:37 serial ports now asserting DTR and RTS during boot; breaks connected hardware Dave Jones
2012-01-03 16:00 ` Jiri Slaby [this message]
2012-01-03 16:13 ` Dave Jones
2012-01-04 18:43 ` Jiri Slaby
2012-01-03 16:06 ` Alan Cox
2012-01-04 20:54 ` Jiri Slaby
2012-01-04 22:37 ` Chris Elmquist
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F03262D.8090506@suse.cz \
--to=jslaby@suse.cz \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.