CPM2 uart early console

[Tom Rini]

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 at 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/