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/
next prev parent 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 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.