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. Arnd -- 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
