Hi Arnd, 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. > Unfortunately, the Linux uart naming system doesn't work well with that, > because you'd end up with something like /dev/ttyA0, /dev/ttyC1, /dev/ttyB2 > for the case that you are using the A, C and B drivers in that order. > I would argue that we should try to fix it by changing the way that Linux > allocates the names (in a backwards compatible way of course), not by changing > the DT binding. Yes! > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html