On Friday 28 March 2014 11:40:03 Geert Uytterhoeven wrote: > On Fri, Mar 28, 2014 at 11:28 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Friday 28 March 2014 09:39:22 Geert Uytterhoeven wrote: > >> On Fri, Mar 28, 2014 at 9:30 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > On Friday 28 March 2014 09:09:23 Geert Uytterhoeven wrote: > >> >> On the Renesas SoCs, where this thread started, you also have different > >> >> types of IP blocks providing similar functionality on the same SoC. > >> >> E.g. 3 types of serial ports, 2 types of i2c, (at least) 2 types of spi... > >> >> Hence one more level of confusion (is SoC serial0 the first serial port of > >> >> type A, B, or C?). > >> > > >> > The 'serial' aliases are defined to refer to UARTs only, there is no debate > >> > about that. > >> > >> All 3 serial port types are UARTs. > >> > >> For the serial ports, they are sufficiently similar to use the same driver. > >> For i2c and spi, that's not the case, and they use different drivers. > > > > Ok, I see. I just misunderstood what you meant. > > > > The aliases are really meant to put all the uarts into a flat numbering space, > > regardless of the driver, and you can mix them them in any possible way. If > > a board uses one uart of each type, then serial0 through serial2 should > > point to the three that are used, but not the ones that aren't connected. > > So we should move all aliases from *.dtsi to <board>.dts. Yes. I was originally thinking that it might be good to have a default alias list for each SoC, but I'm leaning more towards making it per-board only. > > Using a separate name space for each driver keeps causing more problems than > > it solves, and we really should be addressing this. One way to do this > > that I think would handle it nicely is to make it optional for a uart_driver > > to provide a major/minor number range and device name for > > uart_register_driver, and move the ttyS%d namespace handling from the 8250 > > driver into serial_core.c. There are a couple of open questions regarding > > how to implement backwards compatibility with the existing behavior, but > > I think it can be done. > > Not serial_core.c. That's deprecated for new drivers, and we want a common > namespace across all serial drivers. Ah, right. I have a short memory and confused tty_port with uart_port. 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
