From: "Oleksiy Kebkal" <kebkal@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: should RTS init in serial core be tied to CRTSCTS
Date: Mon, 5 Mar 2007 09:23:13 +0100 [thread overview]
Message-ID: <57354eff0703050023r419085f4y1f671feceed90f51@mail.gmail.com> (raw)
On 4 Mar, 21:50, Robin Getz <r...@blackfin.uclinux.org> wrote:
> On Sun 4 Mar 2007 14:46, Russell King pondered:
> > The console command *only* sets the state for the kernel's use of one
> > serial port. It does not affect any other serial port, so tying
> > random RTS behaviours into that command line option is absolutely
> > silly.
> The real issue is that there is some legacy equipment, which gets confused if
> it sees glitches on RTS (which happens today, when serial core init asserts
> RTS, and then the the main application turns it off)...
>
> How do I set the set up the UART, so RTS is avaliable, but not enabled?
Yes, it is key issue. I think it is not silly to want to set up the
UART before RTS is enabled.
It is going not about some random RTS behaviour, but about the
question how to ask the
kernel just don't touch RTS signal. As I understand the current kernel
implementation
doesn't give a chance to do it.
I wrote about it also several days ago here:
http://groups.google.de/group/linux.kernel/browse_thread/thread/82e61dccd11c9e3f/b03971c074609c95?lnk=gst&q=Kebkal&rnum=1&hl=ru#b03971c074609c95
Maybe it would be more relevant to write it in this topic.
Thanks
-Oleksiy
next reply other threads:[~2007-03-05 8:23 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-05 8:23 Oleksiy Kebkal [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-03-02 0:03 Mike Frysinger
2007-03-04 16:20 ` Robin Getz
2007-03-04 19:46 ` Russell King
2007-03-04 20:42 ` Robin Getz
2007-03-05 8:39 ` Russell King
2007-03-05 17:09 ` Mike Frysinger
2007-03-05 17:56 ` Russell King
2007-03-05 18:13 ` Mike Frysinger
2007-03-06 20:40 ` Krzysztof Halasa
2007-03-06 23:24 ` Robin Getz
2007-03-07 12:46 ` Krzysztof Halasa
2007-03-07 13:38 ` Oleksiy Kebkal
2007-03-07 15:19 ` Robin Getz
2007-03-07 21:30 ` Oleksiy Kebkal
2007-03-08 13:44 ` Robin Getz
2007-03-08 13:48 ` Russell King
2007-03-08 14:16 ` Carl-Daniel Hailfinger
2007-03-08 14:20 ` Russell King
2007-03-08 16:51 ` Krzysztof Halasa
2007-03-08 18:43 ` Tosoni
2007-03-09 20:39 ` Krzysztof Halasa
2007-03-12 9:22 ` Tosoni
2007-03-12 12:59 ` Krzysztof Halasa
2007-03-08 14:23 ` Oleksiy Kebkal
2007-03-08 14:28 ` Russell King
2007-03-08 14:40 ` Oleksiy Kebkal
2007-03-08 14:25 ` Oleksiy Kebkal
2007-03-08 20:23 ` Robin Getz
2007-03-08 20:40 ` Russell King
2007-03-08 23:32 ` Robin Getz
2007-03-09 8:57 ` Russell King
2007-03-09 14:18 ` Oleksiy Kebkal
2007-03-07 12:54 ` Oleksiy Kebkal
2007-03-07 13:03 ` Krzysztof Halasa
2007-03-07 20:04 ` Mike Frysinger
2007-03-07 5:13 ` Oleksiy Kebkal
2007-03-07 12:48 ` Krzysztof Halasa
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=57354eff0703050023r419085f4y1f671feceed90f51@mail.gmail.com \
--to=kebkal@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®