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