linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tom Rini <trini@kernel.crashing.org>
To: Pantelis Antoniou <panto@intracom.gr>
Cc: Linuxppc-embedded@ozlabs.org
Subject: Re: CPM2 uart early console
Date: Wed, 27 Oct 2004 09:39:27 -0700	[thread overview]
Message-ID: <20041027163927.GD4979@smtp.west.cox.net> (raw)
In-Reply-To: <417F39EB.5010907@intracom.gr>

On Wed, Oct 27, 2004 at 09:02:19AM +0300, Pantelis Antoniou wrote:
> Tom Rini wrote:
> 
> >On Fri, Oct 22, 2004 at 05:01:54PM -0500, Rune Torgersen wrote:
> >
> >>>From: Tom Rini [mailto:trini@kernel.crashing.org] 
> >>>On Thu, Oct 21, 2004 at 04:57:56PM -0500, Rune Torgersen wrote:
> >>>
> >>>>BTW..
> >>>>What are the device node numbers for ttyCPM[0..5] ?
> >>>>
> >>>204 42...45 (devices.txt in linuxppc-2.5, Pantelis ever 
> >>>figure out what to do about the device # conflict with the 
> >>>i.MX driver so we can push that small bit upstream ?)
> >>>
> >>Aparently not that simple.... I looked in the source, and it depends if 
> >>an 8250 stype serial port is defined or not...
> >>
> >>#ifndef CONFIG_SERIAL_8250
> >>#define SERIAL_CPM_MAJOR	TTY_MAJOR
> >>#define SERIAL_CPM_MINOR	64
> >>#else
> >>#define SERIAL_CPM_MAJOR	204
> >>#define SERIAL_CPM_MINOR	42
> >>#endif
> >>
> >>Urgh...
> >>
> >
> >That doesn't make sense.  Pantelis?
> >
> >
> Well, it sure doesn't.
> 
> We should really try to find a generic solution to this
> problem, i.e. that SoC like processors almost always have a number of serial
> ports, and every single one ends up being of a different major/minor number.

I disagree, at least in the sense that this needs to involve the kernel.
What Rune found is a real bug, in that sometimes we steal the
major/minors of ttyS, and sometimes we don't.  What we need to do is to
always use our own major/minor.

> IMHO the best solution would be to allocate a single major number, and
> then map to the minors in order, the possible serial ports.

This isn't neccessary.  One could handle this rather trivially with udev
so that /dev/ttyC[0-N], to use your names are just symlinks to ttyCPM0,
ttyCPM1, ttyS0, ttyS1, and so on.

-- 
Tom Rini
http://gate.crashing.org/~trini/

  reply	other threads:[~2004-10-27 16:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-22 22:01 CPM2 uart early console Rune Torgersen
2004-10-26 14:35 ` Tom Rini
2004-10-27  6:02   ` Pantelis Antoniou
2004-10-27 16:39     ` Tom Rini [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-10-21 21:57 Rune Torgersen
2004-10-22 20:10 ` Tom Rini

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=20041027163927.GD4979@smtp.west.cox.net \
    --to=trini@kernel.crashing.org \
    --cc=Linuxppc-embedded@ozlabs.org \
    --cc=panto@intracom.gr \
    /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;
as well as URLs for NNTP newsgroup(s).