From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: Mike Frysinger <vapier.adi@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-serial@vger.kernel.org
Subject: Re: should RTS init in serial core be tied to CRTSCTS
Date: Mon, 5 Mar 2007 08:39:18 +0000 [thread overview]
Message-ID: <20070305083918.GA26436@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200703041542.25633.rgetz@blackfin.uclinux.org>
On Sun, Mar 04, 2007 at 03:42:25PM -0500, Robin Getz wrote:
> On Sun 4 Mar 2007 14:46, Russell King pondered:
> > On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> > > the console= bootcmd allows for controlling of the initial state of
> > > flow control by adding/omitting the 'r' suffix ...
> >
> > The console command *only* sets the state for the kernel's use of one
> > serial port. It does not affect any other serial port, so tying
> > random RTS behaviours into that command line option is absolutely
> > silly.
>
> I have one serial port in the system, it shares console, and the
> communications port for the application. (But I guess that is besides the
> point).
In which case communications over that port could be unreliable.
What if the kernel decides to spit out a message in the middle of
your applications data transfer?
If you're using a serial port for a data application, don't make it
the kernel console.
> When the common serial core initialises the UART, and sees that it has the
> capability to do HW flow control - it enables it, asserting the pin, even if
> I don't want it at that moment in time.
>
> The real issue is that there is some legacy equipment, which gets confused if
> it sees glitches on RTS (which happens today, when serial core init asserts
> RTS, and then the the main application turns it off)...
>
> How do I set the set up the UART, so RTS is avaliable, but not enabled?
No idea, sorry. It's not something any Linux kernel version has ever
supported, and since I no longer do serial support it's not something
I'd be involved with anymore.
All I will say is that thinking about keying such a decision off the
kernel console= parameter is absolutely silly - the console= parameter
has nothing to do with the serial port's userspace settings.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: Mike Frysinger <vapier.adi@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-serial@vger.kernel.org
Subject: Re: should RTS init in serial core be tied to CRTSCTS
Date: Mon, 5 Mar 2007 08:39:18 +0000 [thread overview]
Message-ID: <20070305083918.GA26436@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200703041542.25633.rgetz@blackfin.uclinux.org>
On Sun, Mar 04, 2007 at 03:42:25PM -0500, Robin Getz wrote:
> On Sun 4 Mar 2007 14:46, Russell King pondered:
> > On Thu, Mar 01, 2007 at 07:03:02PM -0500, Mike Frysinger wrote:
> > > the console= bootcmd allows for controlling of the initial state of
> > > flow control by adding/omitting the 'r' suffix ...
> >
> > The console command *only* sets the state for the kernel's use of one
> > serial port. It does not affect any other serial port, so tying
> > random RTS behaviours into that command line option is absolutely
> > silly.
>
> I have one serial port in the system, it shares console, and the
> communications port for the application. (But I guess that is besides the
> point).
In which case communications over that port could be unreliable.
What if the kernel decides to spit out a message in the middle of
your applications data transfer?
If you're using a serial port for a data application, don't make it
the kernel console.
> When the common serial core initialises the UART, and sees that it has the
> capability to do HW flow control - it enables it, asserting the pin, even if
> I don't want it at that moment in time.
>
> The real issue is that there is some legacy equipment, which gets confused if
> it sees glitches on RTS (which happens today, when serial core init asserts
> RTS, and then the the main application turns it off)...
>
> How do I set the set up the UART, so RTS is avaliable, but not enabled?
No idea, sorry. It's not something any Linux kernel version has ever
supported, and since I no longer do serial support it's not something
I'd be involved with anymore.
All I will say is that thinking about keying such a decision off the
kernel console= parameter is absolutely silly - the console= parameter
has nothing to do with the serial port's userspace settings.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next prev parent reply other threads:[~2007-03-05 8:39 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-02 0:03 should RTS init in serial core be tied to CRTSCTS 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-04 20:42 ` Robin Getz
2007-03-05 8:39 ` Russell King [this message]
2007-03-05 8:39 ` Russell King
2007-03-05 17:09 ` Mike Frysinger
2007-03-05 17:39 ` Tosoni
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-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-08 18:43 ` Tosoni
2007-03-09 20:39 ` Krzysztof Halasa
2007-03-09 20:39 ` Krzysztof Halasa
2007-03-12 9:22 ` Tosoni
2007-03-12 9:22 ` Tosoni
2007-03-12 12:59 ` Krzysztof Halasa
2007-03-12 12:59 ` Krzysztof Halasa
2007-03-14 11:07 ` Tosoni
2007-03-14 12:44 ` Krzysztof Halasa
2007-03-14 13:45 ` Tosoni
2007-03-14 23: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 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
-- strict thread matches above, loose matches on Subject: below --
2007-03-05 8:23 Oleksiy Kebkal
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=20070305083918.GA26436@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=rgetz@blackfin.uclinux.org \
--cc=vapier.adi@gmail.com \
/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.