Re: [RFC] Serial port aliases in DT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, Mar 27, 2014 at 07:26:27PM +0100, Arnd Bergmann wrote:
> On Thursday 27 March 2014 16:18:29 Sascha Hauer wrote:
> > On Thu, Mar 27, 2014 at 08:54:09AM -0500, Rob Herring wrote:
> > > >>
> > > >> > This however comes back to the more general issue of serial port device
> > > >> > naming: Linux traditionally uses separate names per driver (e.g. ttySC0
> > > >> > instead of ttyS0).
> > > >> >
> > > >> > There has been discussion in the past about changing this to let all
> > > >> > drivers use the same namespace, but it's not yet clear to me how we'd do
> > > >> > this in a 100% backwards compatible way. Maybe it's best left to udev to
> > > >> > figure out the driver independent name, but then we definitely should use
> > > >> > the alias for that name.
> > > 
> > > This discussion has come up in just the last month or so.
> > > 
> > > My opinion is device name numbering should start at 0 with 0 being the
> > > preferred console device.
> > 
> > That's completely different to everything I've heard and seen so far 
> > 
> > For specifying the console we have the linux,stdout-path property in the
> > chosen node. My preferred console may not be a serial port at all in
> > which case I would end up with a serial0 = &lcd0 alias.
> 
> Agreed. Also, don't we already have /dev/console for the preferred console
> device?
> 
> >  Many
> > devicetrees specify aliases for i2c/spi/mmc controllers aswell.  Should
> > they order their i2c controllers in the order of preference now?
> > 
> > Most dtsi files in the kernel specify a SoC specific order of aliases
> > and I think this makes the most sense.
> 
> I disagree with this one: the aliases should be a board specific
> property, if not settable in the boot loader. This is how it traditionally
> work on OF, and I think it's the most sensible approach for end users:
> If the machine has multiple serial ports coming out the back, they are
> normally numbered in some way, and the numbers should match what you
> see in the OS, regardless of what the SoC calls them.

Freescale starts numbering the devices at 1, Linux normally starts at 0.
This leads to enough confusion already. I really don't want to have an
additional board vendor specific translation. This would mean when
talking about an UART we would not only have to make clear whether we
mean freescale numbering or Linux numbering, but also whether we me mean
board vendor numbering. Things like earlyprintk would still have the SoC
numbering. Bootloaders which still use the SoC numbering would add to
the confusion.
I really don't think making the numbering board specific is going to
improve the situation.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux