Re: [RFC] Serial port aliases in DT

[Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>]

Hi Arnd,

On Fri, Mar 28, 2014 at 11:28 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Friday 28 March 2014 09:39:22 Geert Uytterhoeven wrote:
>> On Fri, Mar 28, 2014 at 9:30 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> 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-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

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-spec" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html