public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org, miles@gnu.org, dwmw2@redhat.com
Subject: Re: [SERIAL] change_speed -> settermios change
Date: Mon, 6 Jan 2003 11:36:49 +0000	[thread overview]
Message-ID: <20030106113649.A21952@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20030105.230218.84729944.davem@redhat.com>; from davem@redhat.com on Sun, Jan 05, 2003 at 11:02:18PM -0800

On Sun, Jan 05, 2003 at 11:02:18PM -0800, David S. Miller wrote:
> Hmmm, maybe it's a better idea to store the min/max in the UART port
> structure and have the upper layer do the limiting before we call
> down into the driver?

I like that idea.  However, I'd rather not put these in the uart port
structure because:

1. the max/min would be dependent on the uart clock rate for ports which
   use a clock divisor.

2. the max/min rate may require driver specific knowledge (eg, when the
   port supports *2 and *4 high speed modes)

3. the max/min might be constant for certain ports (eg, sunsab, nb85e)

I'm currently considering whether to pass the max / min into
uart_get_baud_rate(), along with the old termios:

a) move the loop out of uart_get_divisor() into uart_get_baud_rate()
b) uart_get_divisor() would be responsible for providing
   uart_get_baud_rate() with the appropriate min/max for case (1).
c) for case (2), the driver itself would pass these parameters itself.
   Whether or not the min/max depend on the uart clock rate is something
   which only the driver itself can know.

There is a fourth case which I didn't list above:

4. ports that use the raw baud rate may not support all baud rates that
   we are able to pass between a maximum and minimum.

This is outside our current scope at the moment (the usb serial drivers),
and from reading the usb code, it is unclear whether this is an issue for
any of these drivers.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2003-01-06 11:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-03 16:19 [SERIAL] change_speed -> settermios change Russell King
2003-01-06  7:02 ` David S. Miller
2003-01-06 11:36   ` Russell King [this message]
2003-01-06  7:49 ` Miles Bader

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=20030106113649.A21952@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=davem@redhat.com \
    --cc=dwmw2@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miles@gnu.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