public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Glen Turner <glen.turner@aarnet.edu.au>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Krzysztof Halasa <khc@pm.waw.pl>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: 8250 serial console fixes -- issue
Date: Tue, 07 Feb 2006 13:57:56 +1030	[thread overview]
Message-ID: <43E813BC.8060003@aarnet.edu.au> (raw)
In-Reply-To: <20060206094740.GA9388@flint.arm.linux.org.uk>

Hi Russell,

> I think we're agreed (differently wired serial cables) as to why using
> the 'r' option to also monitor DSR would be a bad idea.

We are.  We need a caveat in the documentation reminding
users of 'r' the consequences of letting CTS float, but
that is all.

> A possible solution to this problem may be to have the additional
> option as you have suggested.  Whether it should be the same option
> as (1) above or not is debatable.

I think the same option will work -- let's define 'm' as
being "strictly observe modem status signals (ie, DSR and
DCD)".

'm' them implies:
  - all other modem signals (CTS and DCD) are undefined
    if DSR is not asserted.
  - transmission will only be allowed if DSR and DCD are
    both asserted at the instant when the character is
    ready for transmission.  There may be additional
    restrictions on transmission from flow control.
    Unlike flow control, the kernel never waits for
    the modem status signals to become asserted, but
    instantly discards the character.

'r' remains the same, namely
  - if CTS is asserted then the character is transmitted.
    Noting that 'm' additionally implies that CTS is only
    defined when DSR is asserted.
  - if 'r' is specificed and CTS is not asserted the
    transmitter will wait a limited period for CTS to
    become asserted.  If CTS is not asserted within this time
    then the character is discarded.

[As you can see I've changed the suggested option character. Perhaps
  's' as an option is just too easily confused with the 's' in 'ttyS'.]

> The advantage of the CRLF patch I posted previously is that we can now
> do a lot of the above in common code, which will fix a lot of serial
> drivers at the same time.

I had noticed that and it's a fine idea.

Depending on your timetable, if you agree with the above and
wait a few days I'll send a patch building atop your patch
and implementing the above.  I'm sorry I can't do that at
this moment, but I'm bandwidth-deprived.  Of course, being
much more experienced in this sort of thing you may have
already whipped something up :-)

Regards,
Glen

-- 
  Glen Turner         Tel: (08) 8303 3936 or +61 8 8303 3936
  Australia's Academic & Research Network  www.aarnet.edu.au

  reply	other threads:[~2006-02-07  3:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-02  1:21 8250 serial console fixes -- issue Kumar Gala
2006-02-02  1:47 ` Alan Cox
2006-02-02  5:54   ` Kumar Gala
2006-02-02  8:05     ` Kumar Gala
2006-02-02 17:10       ` Kumar Gala
2006-02-03  1:58   ` Glen Turner
2006-02-03  9:40     ` Russell King
2006-02-03 14:27       ` Glen Turner
2006-02-03 16:02         ` Russell King
2006-02-03 17:08           ` Glen Turner
2006-02-03 22:23             ` Russell King
2006-02-04 11:15               ` Russell King
2006-02-04 16:18               ` Krzysztof Halasa
2006-02-04 23:16                 ` Russell King
2006-02-04 23:54                   ` Krzysztof Halasa
2006-02-05  0:00                     ` Russell King
2006-02-05 12:57                       ` Krzysztof Halasa
2006-02-03 17:46           ` Krzysztof Halasa
2006-02-03 22:13             ` Russell King
2006-02-04 16:08               ` Krzysztof Halasa
2006-02-04 23:20                 ` Russell King
2006-02-05  3:12                   ` Glen Turner
2006-02-05 21:26                     ` Krzysztof Halasa
2006-02-06  9:47                     ` Russell King
2006-02-07  3:27                       ` Glen Turner [this message]
2006-02-03 15:05       ` Kumar Gala
2006-02-06 20:26       ` Pavel Machek
2006-02-06 20:55         ` Russell King
2006-02-07  4:00           ` Glen Turner
2006-02-07  9:18           ` Pavel Machek
2006-02-07 17:43             ` Russell King
2006-02-07 22:23               ` Krzysztof Halasa
2006-02-08  0:59               ` Junio C Hamano
2006-02-08  1:19                 ` Lee Revell
  -- strict thread matches above, loose matches on Subject: below --
2006-02-03 10:00 linux

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=43E813BC.8060003@aarnet.edu.au \
    --to=glen.turner@aarnet.edu.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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