[RFC] Serial port aliases in DT

[RFC] Serial port aliases in DT

[Laurent Pinchart]

Hello,

I've recently reviewed a patch adding serial port aliases to the device tree 
and would like to pick your brains about a disagreement I had with the 
developer.

The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi, and 
enabled selectively by board DT files. As not all serial ports are available 
on all boards, the question was whether to add aliases for all ports (in the 
.dtsi in this case) like

         serial0 = &scif0;
         serial1 = &scif1;
         serial2 = &scif2;
         serial3 = &scif3;
         serial4 = &scif4;
         serial5 = &scif5;
         serial6 = &scif6;
         serial7 = &scif7;

or to just add aliases for the enabled ports (in the board DT file) like

         serial0 = &scif2;
         serial1 = &scif3;

Note the numbering in the latter case: as the board doesn't use serial ports 0 
and 1, hardware ports 2 and 3 become logical ports 0 and 1.

I considered that having Linux create ttySC0 and ttySC1 devices for the first 
two ports of the board, regardless of which hardware ports are used, is 
simpler from a user point of view (it allows sharing the same inittab settings 
for the console serial port across several boards for instance). I'd 
appreciate feedback on that.

-- 
Regards,

Laurent Pinchart

[RFC] Serial port aliases in DT

[Laurent Pinchart]

Hello,

I've recently reviewed a patch adding serial port aliases to the device tree 
and would like to pick your brains about a disagreement I had with the 
developer.

The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi, and 
enabled selectively by board DT files. As not all serial ports are available 
on all boards, the question was whether to add aliases for all ports (in the 
.dtsi in this case) like

         serial0 = &scif0;
         serial1 = &scif1;
         serial2 = &scif2;
         serial3 = &scif3;
         serial4 = &scif4;
         serial5 = &scif5;
         serial6 = &scif6;
         serial7 = &scif7;

or to just add aliases for the enabled ports (in the board DT file) like

         serial0 = &scif2;
         serial1 = &scif3;

Note the numbering in the latter case: as the board doesn't use serial ports 0 
and 1, hardware ports 2 and 3 become logical ports 0 and 1.

I considered that having Linux create ttySC0 and ttySC1 devices for the first 
two ports of the board, regardless of which hardware ports are used, is 
simpler from a user point of view (it allows sharing the same inittab settings 
for the console serial port across several boards for instance). I'd 
appreciate feedback on that.

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]


> I've recently reviewed a patch adding serial port aliases to the device tree 
> and would like to pick your brains about a disagreement I had with the 
> developer.

And here is the developer :)

> 
> The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi, and 
> enabled selectively by board DT files. As not all serial ports are available 
> on all boards, the question was whether to add aliases for all ports (in the 
> .dtsi in this case) like
> 
>          serial0 = &scif0;
>          serial1 = &scif1;
>          serial2 = &scif2;
>          serial3 = &scif3;
>          serial4 = &scif4;
>          serial5 = &scif5;
>          serial6 = &scif6;
>          serial7 = &scif7;
> 
> or to just add aliases for the enabled ports (in the board DT file) like
> 
>          serial0 = &scif2;
>          serial1 = &scif3;
> 
> Note the numbering in the latter case: as the board doesn't use serial ports 0 
> and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> 
> I considered that having Linux create ttySC0 and ttySC1 devices for the first 
> two ports of the board, regardless of which hardware ports are used, is 
> simpler from a user point of view (it allows sharing the same inittab settings 
> for the console serial port across several boards for instance). I'd 
> appreciate feedback on that.

First, I don't think this is restricted to serial ports but how to use
aliases in general. We may decide this or that way, yet we should do it
consistently. Using aliases this way for serial ports and that way for
I2C busses will create a mess.
And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
board, you'll need to open /dev/i2c-2, not /dev/i2c-0.

From my experience, things get complicated when stuff gets added and the
numbers go wild:

          serial0 = &scif2;
          serial1 = &scif3;
          serial2 = &scif6;
          serial3 = &scif0;
          serial4 = &scif7;

When debugging here, trying to remember which port to open for the
terminal, and which number to scan for in the schematics is error-prone
and a PITA.

Yeah, the drawback is that the console might be at different places
across boards. I suggest to update inittab at runtime anyhow, since not
only the number but also the naming often changes (ttyXYZ to ttyABC).

Regards,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]


> I've recently reviewed a patch adding serial port aliases to the device tree 
> and would like to pick your brains about a disagreement I had with the 
> developer.

And here is the developer :)

> 
> The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi, and 
> enabled selectively by board DT files. As not all serial ports are available 
> on all boards, the question was whether to add aliases for all ports (in the 
> .dtsi in this case) like
> 
>          serial0 = &scif0;
>          serial1 = &scif1;
>          serial2 = &scif2;
>          serial3 = &scif3;
>          serial4 = &scif4;
>          serial5 = &scif5;
>          serial6 = &scif6;
>          serial7 = &scif7;
> 
> or to just add aliases for the enabled ports (in the board DT file) like
> 
>          serial0 = &scif2;
>          serial1 = &scif3;
> 
> Note the numbering in the latter case: as the board doesn't use serial ports 0 
> and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> 
> I considered that having Linux create ttySC0 and ttySC1 devices for the first 
> two ports of the board, regardless of which hardware ports are used, is 
> simpler from a user point of view (it allows sharing the same inittab settings 
> for the console serial port across several boards for instance). I'd 
> appreciate feedback on that.

First, I don't think this is restricted to serial ports but how to use
aliases in general. We may decide this or that way, yet we should do it
consistently. Using aliases this way for serial ports and that way for
I2C busses will create a mess.
And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
board, you'll need to open /dev/i2c-2, not /dev/i2c-0.

From my experience, things get complicated when stuff gets added and the
numbers go wild:

          serial0 = &scif2;
          serial1 = &scif3;
          serial2 = &scif6;
          serial3 = &scif0;
          serial4 = &scif7;

When debugging here, trying to remember which port to open for the
terminal, and which number to scan for in the schematics is error-prone
and a PITA.

Yeah, the drawback is that the console might be at different places
across boards. I suggest to update inittab at runtime anyhow, since not
only the number but also the naming often changes (ttyXYZ to ttyABC).

Regards,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> 
> The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi, and 
> enabled selectively by board DT files. As not all serial ports are available 
> on all boards, the question was whether to add aliases for all ports (in the 
> .dtsi in this case) like
> 
>          serial0 = &scif0;
>          serial1 = &scif1;
>          serial2 = &scif2;
>          serial3 = &scif3;
>          serial4 = &scif4;
>          serial5 = &scif5;
>          serial6 = &scif6;
>          serial7 = &scif7;
> 
> or to just add aliases for the enabled ports (in the board DT file) like
> 
>          serial0 = &scif2;
>          serial1 = &scif3;
> 
> Note the numbering in the latter case: as the board doesn't use serial ports 0 
> and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> 
> I considered that having Linux create ttySC0 and ttySC1 devices for the first 
> two ports of the board, regardless of which hardware ports are used, is 
> simpler from a user point of view (it allows sharing the same inittab settings 
> for the console serial port across several boards for instance). I'd 
> appreciate feedback on that.

I think the traditional interpretation is that we want to use the aliases
to reflect the device names in the OS. 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.

	Arnd

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> 
> The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi, and 
> enabled selectively by board DT files. As not all serial ports are available 
> on all boards, the question was whether to add aliases for all ports (in the 
> .dtsi in this case) like
> 
>          serial0 = &scif0;
>          serial1 = &scif1;
>          serial2 = &scif2;
>          serial3 = &scif3;
>          serial4 = &scif4;
>          serial5 = &scif5;
>          serial6 = &scif6;
>          serial7 = &scif7;
> 
> or to just add aliases for the enabled ports (in the board DT file) like
> 
>          serial0 = &scif2;
>          serial1 = &scif3;
> 
> Note the numbering in the latter case: as the board doesn't use serial ports 0 
> and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> 
> I considered that having Linux create ttySC0 and ttySC1 devices for the first 
> two ports of the board, regardless of which hardware ports are used, is 
> simpler from a user point of view (it allows sharing the same inittab settings 
> for the console serial port across several boards for instance). I'd 
> appreciate feedback on that.

I think the traditional interpretation is that we want to use the aliases
to reflect the device names in the OS. 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.

	Arnd

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

Hi Wolfram,

On Monday 10 March 2014 13:38:37 Wolfram Sang wrote:
> > I've recently reviewed a patch adding serial port aliases to the device
> > tree and would like to pick your brains about a disagreement I had with
> > the developer.
> 
> And here is the developer :)
> 
> > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > and enabled selectively by board DT files. As not all serial ports are
> > available on all boards, the question was whether to add aliases for all
> > ports (in the .dtsi in this case) like
> > 
> >          serial0 = &scif0;
> >          serial1 = &scif1;
> >          serial2 = &scif2;
> >          serial3 = &scif3;
> >          serial4 = &scif4;
> >          serial5 = &scif5;
> >          serial6 = &scif6;
> >          serial7 = &scif7;
> > 
> > or to just add aliases for the enabled ports (in the board DT file) like
> > 
> >          serial0 = &scif2;
> >          serial1 = &scif3;
> > 
> > Note the numbering in the latter case: as the board doesn't use serial
> > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > 
> > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > first two ports of the board, regardless of which hardware ports are
> > used, is simpler from a user point of view (it allows sharing the same
> > inittab settings for the console serial port across several boards for
> > instance). I'd appreciate feedback on that.
> 
> First, I don't think this is restricted to serial ports but how to use
> aliases in general. We may decide this or that way, yet we should do it
> consistently. Using aliases this way for serial ports and that way for
> I2C busses will create a mess.
> And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
> board, you'll need to open /dev/i2c-2, not /dev/i2c-0.
> 
> From my experience, things get complicated when stuff gets added and the
> numbers go wild:
> 
>           serial0 = &scif2;
>           serial1 = &scif3;
>           serial2 = &scif6;
>           serial3 = &scif0;
>           serial4 = &scif7;
> 
> When debugging here, trying to remember which port to open for the
> terminal, and which number to scan for in the schematics is error-prone
> and a PITA.
> 
> Yeah, the drawback is that the console might be at different places
> across boards. I suggest to update inittab at runtime anyhow, since not
> only the number but also the naming often changes (ttyXYZ to ttyABC).

Just out of curiosity (as I could use it), do you have a sample implementation 
of dynamic inittab updates ?

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

Hi Wolfram,

On Monday 10 March 2014 13:38:37 Wolfram Sang wrote:
> > I've recently reviewed a patch adding serial port aliases to the device
> > tree and would like to pick your brains about a disagreement I had with
> > the developer.
> 
> And here is the developer :)
> 
> > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > and enabled selectively by board DT files. As not all serial ports are
> > available on all boards, the question was whether to add aliases for all
> > ports (in the .dtsi in this case) like
> > 
> >          serial0 = &scif0;
> >          serial1 = &scif1;
> >          serial2 = &scif2;
> >          serial3 = &scif3;
> >          serial4 = &scif4;
> >          serial5 = &scif5;
> >          serial6 = &scif6;
> >          serial7 = &scif7;
> > 
> > or to just add aliases for the enabled ports (in the board DT file) like
> > 
> >          serial0 = &scif2;
> >          serial1 = &scif3;
> > 
> > Note the numbering in the latter case: as the board doesn't use serial
> > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > 
> > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > first two ports of the board, regardless of which hardware ports are
> > used, is simpler from a user point of view (it allows sharing the same
> > inittab settings for the console serial port across several boards for
> > instance). I'd appreciate feedback on that.
> 
> First, I don't think this is restricted to serial ports but how to use
> aliases in general. We may decide this or that way, yet we should do it
> consistently. Using aliases this way for serial ports and that way for
> I2C busses will create a mess.
> And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
> board, you'll need to open /dev/i2c-2, not /dev/i2c-0.
> 
> From my experience, things get complicated when stuff gets added and the
> numbers go wild:
> 
>           serial0 = &scif2;
>           serial1 = &scif3;
>           serial2 = &scif6;
>           serial3 = &scif0;
>           serial4 = &scif7;
> 
> When debugging here, trying to remember which port to open for the
> terminal, and which number to scan for in the schematics is error-prone
> and a PITA.
> 
> Yeah, the drawback is that the console might be at different places
> across boards. I suggest to update inittab at runtime anyhow, since not
> only the number but also the naming often changes (ttyXYZ to ttyABC).

Just out of curiosity (as I could use it), do you have a sample implementation 
of dynamic inittab updates ?

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hi Arnd,

On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
> On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > and enabled selectively by board DT files. As not all serial ports are
> > available on all boards, the question was whether to add aliases for all
> > ports (in the .dtsi in this case) like
> > 
> >          serial0 = &scif0;
> >          serial1 = &scif1;
> >          serial2 = &scif2;
> >          serial3 = &scif3;
> >          serial4 = &scif4;
> >          serial5 = &scif5;
> >          serial6 = &scif6;
> >          serial7 = &scif7;
> > 
> > or to just add aliases for the enabled ports (in the board DT file) like
> > 
> >          serial0 = &scif2;
> >          serial1 = &scif3;
> > 
> > Note the numbering in the latter case: as the board doesn't use serial
> > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > 
> > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > first two ports of the board, regardless of which hardware ports are
> > used, is simpler from a user point of view (it allows sharing the same
> > inittab settings for the console serial port across several boards for
> > instance). I'd appreciate feedback on that.
> 
> I think the traditional interpretation is that we want to use the aliases
> to reflect the device names in the OS.

If I interpret this correctly it means that the question boils down to whether 
we want the system to expose ttySC0 and ttySC1 or ttySC2 and ttySC3, in case 
only ports 2 and 3 are enabled.

Let's note that, despite the above example showing 8 instances of identical 
serial IP cores, the reality is a bit more complex and Renesas SoCs usually 
include different serial IP cores with several instances of each of them. 
Ports of the same time are numbered in the datasheet, but there's no standard 
or natural ordering global to all serial ports.

This starts to remind me about the whole stable network device name changes we 
went through recently.

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

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hi Arnd,

On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
> On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > and enabled selectively by board DT files. As not all serial ports are
> > available on all boards, the question was whether to add aliases for all
> > ports (in the .dtsi in this case) like
> > 
> >          serial0 = &scif0;
> >          serial1 = &scif1;
> >          serial2 = &scif2;
> >          serial3 = &scif3;
> >          serial4 = &scif4;
> >          serial5 = &scif5;
> >          serial6 = &scif6;
> >          serial7 = &scif7;
> > 
> > or to just add aliases for the enabled ports (in the board DT file) like
> > 
> >          serial0 = &scif2;
> >          serial1 = &scif3;
> > 
> > Note the numbering in the latter case: as the board doesn't use serial
> > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > 
> > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > first two ports of the board, regardless of which hardware ports are
> > used, is simpler from a user point of view (it allows sharing the same
> > inittab settings for the console serial port across several boards for
> > instance). I'd appreciate feedback on that.
> 
> I think the traditional interpretation is that we want to use the aliases
> to reflect the device names in the OS.

If I interpret this correctly it means that the question boils down to whether 
we want the system to expose ttySC0 and ttySC1 or ttySC2 and ttySC3, in case 
only ports 2 and 3 are enabled.

Let's note that, despite the above example showing 8 instances of identical 
serial IP cores, the reality is a bit more complex and Renesas SoCs usually 
include different serial IP cores with several instances of each of them. 
Ports of the same time are numbered in the datasheet, but there's no standard 
or natural ordering global to all serial ports.

This starts to remind me about the whole stable network device name changes we 
went through recently.

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

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

On Tue, Mar 11, 2014 at 12:56:50PM +0100, Laurent Pinchart wrote:
> Hi Wolfram,
> 
> On Monday 10 March 2014 13:38:37 Wolfram Sang wrote:
> > > I've recently reviewed a patch adding serial port aliases to the device
> > > tree and would like to pick your brains about a disagreement I had with
> > > the developer.
> > 
> > And here is the developer :)
> > 
> > > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > > and enabled selectively by board DT files. As not all serial ports are
> > > available on all boards, the question was whether to add aliases for all
> > > ports (in the .dtsi in this case) like
> > > 
> > >          serial0 = &scif0;
> > >          serial1 = &scif1;
> > >          serial2 = &scif2;
> > >          serial3 = &scif3;
> > >          serial4 = &scif4;
> > >          serial5 = &scif5;
> > >          serial6 = &scif6;
> > >          serial7 = &scif7;
> > > 
> > > or to just add aliases for the enabled ports (in the board DT file) like
> > > 
> > >          serial0 = &scif2;
> > >          serial1 = &scif3;
> > > 
> > > Note the numbering in the latter case: as the board doesn't use serial
> > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > > 
> > > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > > first two ports of the board, regardless of which hardware ports are
> > > used, is simpler from a user point of view (it allows sharing the same
> > > inittab settings for the console serial port across several boards for
> > > instance). I'd appreciate feedback on that.
> > 
> > First, I don't think this is restricted to serial ports but how to use
> > aliases in general. We may decide this or that way, yet we should do it
> > consistently. Using aliases this way for serial ports and that way for
> > I2C busses will create a mess.
> > And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
> > board, you'll need to open /dev/i2c-2, not /dev/i2c-0.
> > 
> > From my experience, things get complicated when stuff gets added and the
> > numbers go wild:
> > 
> >           serial0 = &scif2;
> >           serial1 = &scif3;
> >           serial2 = &scif6;
> >           serial3 = &scif0;
> >           serial4 = &scif7;
> > 
> > When debugging here, trying to remember which port to open for the
> > terminal, and which number to scan for in the schematics is error-prone
> > and a PITA.

No comments on those? Are the experiences from the stable ethernet
naming which would speak for/against those arguments?

> > Yeah, the drawback is that the console might be at different places
> > across boards. I suggest to update inittab at runtime anyhow, since not
> > only the number but also the naming often changes (ttyXYZ to ttyABC).
> 
> Just out of curiosity (as I could use it), do you have a sample implementation 
> of dynamic inittab updates ?

Sure. Can be optimized and improved, but does its job (for an initramfs
at least, where the default 'ttyS0' keeps constant):

=== S02inittab

#!/bin/sh
#
# Update inittab at runtime - by Wolfram Sang, WTFPLv2

case "$1" in
  start)
	echo "Adapting inittab to kernel console"
	l=$(cat /proc/cmdline)
	l=${l##*console=}
	l=${l%%,*}
	sed -i s/ttyS0/$l/g /etc/inittab
	kill -s SIGHUP 1
	;;
  *)
	echo "Usage: $0 {start}"
	exit 1
esac

exit $?

===

Regards,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

On Tue, Mar 11, 2014 at 12:56:50PM +0100, Laurent Pinchart wrote:
> Hi Wolfram,
> 
> On Monday 10 March 2014 13:38:37 Wolfram Sang wrote:
> > > I've recently reviewed a patch adding serial port aliases to the device
> > > tree and would like to pick your brains about a disagreement I had with
> > > the developer.
> > 
> > And here is the developer :)
> > 
> > > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > > and enabled selectively by board DT files. As not all serial ports are
> > > available on all boards, the question was whether to add aliases for all
> > > ports (in the .dtsi in this case) like
> > > 
> > >          serial0 = &scif0;
> > >          serial1 = &scif1;
> > >          serial2 = &scif2;
> > >          serial3 = &scif3;
> > >          serial4 = &scif4;
> > >          serial5 = &scif5;
> > >          serial6 = &scif6;
> > >          serial7 = &scif7;
> > > 
> > > or to just add aliases for the enabled ports (in the board DT file) like
> > > 
> > >          serial0 = &scif2;
> > >          serial1 = &scif3;
> > > 
> > > Note the numbering in the latter case: as the board doesn't use serial
> > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > > 
> > > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > > first two ports of the board, regardless of which hardware ports are
> > > used, is simpler from a user point of view (it allows sharing the same
> > > inittab settings for the console serial port across several boards for
> > > instance). I'd appreciate feedback on that.
> > 
> > First, I don't think this is restricted to serial ports but how to use
> > aliases in general. We may decide this or that way, yet we should do it
> > consistently. Using aliases this way for serial ports and that way for
> > I2C busses will create a mess.
> > And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
> > board, you'll need to open /dev/i2c-2, not /dev/i2c-0.
> > 
> > From my experience, things get complicated when stuff gets added and the
> > numbers go wild:
> > 
> >           serial0 = &scif2;
> >           serial1 = &scif3;
> >           serial2 = &scif6;
> >           serial3 = &scif0;
> >           serial4 = &scif7;
> > 
> > When debugging here, trying to remember which port to open for the
> > terminal, and which number to scan for in the schematics is error-prone
> > and a PITA.

No comments on those? Are the experiences from the stable ethernet
naming which would speak for/against those arguments?

> > Yeah, the drawback is that the console might be at different places
> > across boards. I suggest to update inittab at runtime anyhow, since not
> > only the number but also the naming often changes (ttyXYZ to ttyABC).
> 
> Just out of curiosity (as I could use it), do you have a sample implementation 
> of dynamic inittab updates ?

Sure. Can be optimized and improved, but does its job (for an initramfs
at least, where the default 'ttyS0' keeps constant):

=== S02inittab

#!/bin/sh
#
# Update inittab at runtime - by Wolfram Sang, WTFPLv2

case "$1" in
  start)
	echo "Adapting inittab to kernel console"
	l=$(cat /proc/cmdline)
	l=${l##*console=}
	l=${l%%,*}
	sed -i s/ttyS0/$l/g /etc/inittab
	kill -s SIGHUP 1
	;;
  *)
	echo "Usage: $0 {start}"
	exit 1
esac

exit $?

===

Regards,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hi Wolfram,

On Tuesday 11 March 2014 13:46:22 Wolfram Sang wrote:
> On Tue, Mar 11, 2014 at 12:56:50PM +0100, Laurent Pinchart wrote:
> > On Monday 10 March 2014 13:38:37 Wolfram Sang wrote:
> > > > I've recently reviewed a patch adding serial port aliases to the
> > > > device tree and would like to pick your brains about a disagreement I
> > > > had with the developer.
> > > 
> > > And here is the developer :)
> > > 
> > > > The SoC includes 8 serial ports. They are all disabled in the SoC
> > > > .dtsi, and enabled selectively by board DT files. As not all serial
> > > > ports are available on all boards, the question was whether to add
> > > > aliases for all ports (in the .dtsi in this case) like
> > > > 
> > > >          serial0 = &scif0;
> > > >          serial1 = &scif1;
> > > >          serial2 = &scif2;
> > > >          serial3 = &scif3;
> > > >          serial4 = &scif4;
> > > >          serial5 = &scif5;
> > > >          serial6 = &scif6;
> > > >          serial7 = &scif7;
> > > > 
> > > > or to just add aliases for the enabled ports (in the board DT file)
> > > > like
> > > > 
> > > >          serial0 = &scif2;
> > > >          serial1 = &scif3;
> > > > 
> > > > Note the numbering in the latter case: as the board doesn't use serial
> > > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > > > 
> > > > I considered that having Linux create ttySC0 and ttySC1 devices for
> > > > the first two ports of the board, regardless of which hardware ports
> > > > are used, is simpler from a user point of view (it allows sharing the
> > > > same inittab settings for the console serial port across several
> > > > boards for instance). I'd appreciate feedback on that.
> > > 
> > > First, I don't think this is restricted to serial ports but how to use
> > > aliases in general. We may decide this or that way, yet we should do it
> > > consistently. Using aliases this way for serial ports and that way for
> > > I2C busses will create a mess.
> > > And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
> > > board, you'll need to open /dev/i2c-2, not /dev/i2c-0.
> > > 
> > > From my experience, things get complicated when stuff gets added and the
> > > 
> > > numbers go wild:
> > >           serial0 = &scif2;
> > >           serial1 = &scif3;
> > >           serial2 = &scif6;
> > >           serial3 = &scif0;
> > >           serial4 = &scif7;
> > > 
> > > When debugging here, trying to remember which port to open for the
> > > terminal, and which number to scan for in the schematics is error-prone
> > > and a PITA.
> 
> No comments on those? Are the experiences from the stable ethernet
> naming which would speak for/against those arguments?

I'm waiting for others to comment :-) I agree that you have a point though.

> > > Yeah, the drawback is that the console might be at different places
> > > across boards. I suggest to update inittab at runtime anyhow, since not
> > > only the number but also the naming often changes (ttyXYZ to ttyABC).
> > 
> > Just out of curiosity (as I could use it), do you have a sample
> > implementation of dynamic inittab updates ?
> 
> Sure. Can be optimized and improved, but does its job (for an initramfs
> at least, where the default 'ttyS0' keeps constant):
> 
> == S02inittab
> 
> #!/bin/sh
> #
> # Update inittab at runtime - by Wolfram Sang, WTFPLv2
> 
> case "$1" in
>   start)
> 	echo "Adapting inittab to kernel console"
> 	l=$(cat /proc/cmdline)
> 	l=${l##*console=}
> 	l=${l%%,*}
> 	sed -i s/ttyS0/$l/g /etc/inittab
> 	kill -s SIGHUP 1
> 	;;
>   *)
> 	echo "Usage: $0 {start}"
> 	exit 1
> esac
> 
> exit $?
> 
> =
Thank you.

Maybe we could also let udev create a link to the console serial port.

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hi Wolfram,

On Tuesday 11 March 2014 13:46:22 Wolfram Sang wrote:
> On Tue, Mar 11, 2014 at 12:56:50PM +0100, Laurent Pinchart wrote:
> > On Monday 10 March 2014 13:38:37 Wolfram Sang wrote:
> > > > I've recently reviewed a patch adding serial port aliases to the
> > > > device tree and would like to pick your brains about a disagreement I
> > > > had with the developer.
> > > 
> > > And here is the developer :)
> > > 
> > > > The SoC includes 8 serial ports. They are all disabled in the SoC
> > > > .dtsi, and enabled selectively by board DT files. As not all serial
> > > > ports are available on all boards, the question was whether to add
> > > > aliases for all ports (in the .dtsi in this case) like
> > > > 
> > > >          serial0 = &scif0;
> > > >          serial1 = &scif1;
> > > >          serial2 = &scif2;
> > > >          serial3 = &scif3;
> > > >          serial4 = &scif4;
> > > >          serial5 = &scif5;
> > > >          serial6 = &scif6;
> > > >          serial7 = &scif7;
> > > > 
> > > > or to just add aliases for the enabled ports (in the board DT file)
> > > > like
> > > > 
> > > >          serial0 = &scif2;
> > > >          serial1 = &scif3;
> > > > 
> > > > Note the numbering in the latter case: as the board doesn't use serial
> > > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > > > 
> > > > I considered that having Linux create ttySC0 and ttySC1 devices for
> > > > the first two ports of the board, regardless of which hardware ports
> > > > are used, is simpler from a user point of view (it allows sharing the
> > > > same inittab settings for the console serial port across several
> > > > boards for instance). I'd appreciate feedback on that.
> > > 
> > > First, I don't think this is restricted to serial ports but how to use
> > > aliases in general. We may decide this or that way, yet we should do it
> > > consistently. Using aliases this way for serial ports and that way for
> > > I2C busses will create a mess.
> > > And currently, I only know of 1:1 mappings for I2C/SPI. So, on the same
> > > board, you'll need to open /dev/i2c-2, not /dev/i2c-0.
> > > 
> > > From my experience, things get complicated when stuff gets added and the
> > > 
> > > numbers go wild:
> > >           serial0 = &scif2;
> > >           serial1 = &scif3;
> > >           serial2 = &scif6;
> > >           serial3 = &scif0;
> > >           serial4 = &scif7;
> > > 
> > > When debugging here, trying to remember which port to open for the
> > > terminal, and which number to scan for in the schematics is error-prone
> > > and a PITA.
> 
> No comments on those? Are the experiences from the stable ethernet
> naming which would speak for/against those arguments?

I'm waiting for others to comment :-) I agree that you have a point though.

> > > Yeah, the drawback is that the console might be at different places
> > > across boards. I suggest to update inittab at runtime anyhow, since not
> > > only the number but also the naming often changes (ttyXYZ to ttyABC).
> > 
> > Just out of curiosity (as I could use it), do you have a sample
> > implementation of dynamic inittab updates ?
> 
> Sure. Can be optimized and improved, but does its job (for an initramfs
> at least, where the default 'ttyS0' keeps constant):
> 
> === S02inittab
> 
> #!/bin/sh
> #
> # Update inittab at runtime - by Wolfram Sang, WTFPLv2
> 
> case "$1" in
>   start)
> 	echo "Adapting inittab to kernel console"
> 	l=$(cat /proc/cmdline)
> 	l=${l##*console=}
> 	l=${l%%,*}
> 	sed -i s/ttyS0/$l/g /etc/inittab
> 	kill -s SIGHUP 1
> 	;;
>   *)
> 	echo "Usage: $0 {start}"
> 	exit 1
> esac
> 
> exit $?
> 
> ===

Thank you.

Maybe we could also let udev create a link to the console serial port.

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]


> Maybe we could also let udev create a link to the console serial port.

Mabye, yet my minimal initramfs should not have udev/mdev by default.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]


> Maybe we could also let udev create a link to the console serial port.

Mabye, yet my minimal initramfs should not have udev/mdev by default.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hello DT maintainers,

Ping ? This issue is blocking the merge of serial port DT support on Renesas 
platforms, as we need to decide on how to name the ports.

On Tuesday 11 March 2014 12:57:59 Laurent Pinchart wrote:
> On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
> > On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> > > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > > and enabled selectively by board DT files. As not all serial ports are
> > > available on all boards, the question was whether to add aliases for all
> > > ports (in the .dtsi in this case) like
> > > 
> > >          serial0 = &scif0;
> > >          serial1 = &scif1;
> > >          serial2 = &scif2;
> > >          serial3 = &scif3;
> > >          serial4 = &scif4;
> > >          serial5 = &scif5;
> > >          serial6 = &scif6;
> > >          serial7 = &scif7;
> > > 
> > > or to just add aliases for the enabled ports (in the board DT file) like
> > > 
> > >          serial0 = &scif2;
> > >          serial1 = &scif3;
> > > 
> > > Note the numbering in the latter case: as the board doesn't use serial
> > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > > 
> > > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > > first two ports of the board, regardless of which hardware ports are
> > > used, is simpler from a user point of view (it allows sharing the same
> > > inittab settings for the console serial port across several boards for
> > > instance). I'd appreciate feedback on that.
> > 
> > I think the traditional interpretation is that we want to use the aliases
> > to reflect the device names in the OS.
> 
> If I interpret this correctly it means that the question boils down to
> whether we want the system to expose ttySC0 and ttySC1 or ttySC2 and
> ttySC3, in case only ports 2 and 3 are enabled.
> 
> Let's note that, despite the above example showing 8 instances of identical
> serial IP cores, the reality is a bit more complex and Renesas SoCs usually
> include different serial IP cores with several instances of each of them.
> Ports of the same time are numbered in the datasheet, but there's no
> standard or natural ordering global to all serial ports.
> 
> This starts to remind me about the whole stable network device name changes
> we went through recently.
> 
> > 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.

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hello DT maintainers,

Ping ? This issue is blocking the merge of serial port DT support on Renesas 
platforms, as we need to decide on how to name the ports.

On Tuesday 11 March 2014 12:57:59 Laurent Pinchart wrote:
> On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
> > On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> > > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
> > > and enabled selectively by board DT files. As not all serial ports are
> > > available on all boards, the question was whether to add aliases for all
> > > ports (in the .dtsi in this case) like
> > > 
> > >          serial0 = &scif0;
> > >          serial1 = &scif1;
> > >          serial2 = &scif2;
> > >          serial3 = &scif3;
> > >          serial4 = &scif4;
> > >          serial5 = &scif5;
> > >          serial6 = &scif6;
> > >          serial7 = &scif7;
> > > 
> > > or to just add aliases for the enabled ports (in the board DT file) like
> > > 
> > >          serial0 = &scif2;
> > >          serial1 = &scif3;
> > > 
> > > Note the numbering in the latter case: as the board doesn't use serial
> > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
> > > 
> > > I considered that having Linux create ttySC0 and ttySC1 devices for the
> > > first two ports of the board, regardless of which hardware ports are
> > > used, is simpler from a user point of view (it allows sharing the same
> > > inittab settings for the console serial port across several boards for
> > > instance). I'd appreciate feedback on that.
> > 
> > I think the traditional interpretation is that we want to use the aliases
> > to reflect the device names in the OS.
> 
> If I interpret this correctly it means that the question boils down to
> whether we want the system to expose ttySC0 and ttySC1 or ttySC2 and
> ttySC3, in case only ports 2 and 3 are enabled.
> 
> Let's note that, despite the above example showing 8 instances of identical
> serial IP cores, the reality is a bit more complex and Renesas SoCs usually
> include different serial IP cores with several instances of each of them.
> Ports of the same time are numbered in the datasheet, but there's no
> standard or natural ordering global to all serial ports.
> 
> This starts to remind me about the whole stable network device name changes
> we went through recently.
> 
> > 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.

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Rob Herring]

On Thu, Mar 27, 2014 at 7:50 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hello DT maintainers,
>
> Ping ? This issue is blocking the merge of serial port DT support on Renesas
> platforms, as we need to decide on how to name the ports.

This seems like a topic for devicetree-spec.

> On Tuesday 11 March 2014 12:57:59 Laurent Pinchart wrote:
>> On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
>> > On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
>> > > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
>> > > and enabled selectively by board DT files. As not all serial ports are
>> > > available on all boards, the question was whether to add aliases for all
>> > > ports (in the .dtsi in this case) like
>> > >
>> > >          serial0 = &scif0;
>> > >          serial1 = &scif1;
>> > >          serial2 = &scif2;
>> > >          serial3 = &scif3;
>> > >          serial4 = &scif4;
>> > >          serial5 = &scif5;
>> > >          serial6 = &scif6;
>> > >          serial7 = &scif7;
>> > >
>> > > or to just add aliases for the enabled ports (in the board DT file) like
>> > >
>> > >          serial0 = &scif2;
>> > >          serial1 = &scif3;
>> > >
>> > > Note the numbering in the latter case: as the board doesn't use serial
>> > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
>> > >
>> > > I considered that having Linux create ttySC0 and ttySC1 devices for the
>> > > first two ports of the board, regardless of which hardware ports are
>> > > used, is simpler from a user point of view (it allows sharing the same
>> > > inittab settings for the console serial port across several boards for
>> > > instance). I'd appreciate feedback on that.
>> >
>> > I think the traditional interpretation is that we want to use the aliases
>> > to reflect the device names in the OS.
>>
>> If I interpret this correctly it means that the question boils down to
>> whether we want the system to expose ttySC0 and ttySC1 or ttySC2 and
>> ttySC3, in case only ports 2 and 3 are enabled.
>>
>> Let's note that, despite the above example showing 8 instances of identical
>> serial IP cores, the reality is a bit more complex and Renesas SoCs usually
>> include different serial IP cores with several instances of each of them.
>> Ports of the same time are numbered in the datasheet, but there's no
>> standard or natural ordering global to all serial ports.
>>
>> This starts to remind me about the whole stable network device name changes
>> we went through recently.
>>
>> > 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. My main reasoning is giving consistent
naming across boards and it is more inline with how other devices are
named. The aliases are just to give you consistency in the numbering
within the 0 to N. Hopefully this is inline with what other platforms
have done as above all I think we should be consistent.

Rob

Re: [RFC] Serial port aliases in DT

[Rob Herring]

On Thu, Mar 27, 2014 at 7:50 AM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> Hello DT maintainers,
>
> Ping ? This issue is blocking the merge of serial port DT support on Renesas
> platforms, as we need to decide on how to name the ports.

This seems like a topic for devicetree-spec.

> On Tuesday 11 March 2014 12:57:59 Laurent Pinchart wrote:
>> On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
>> > On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
>> > > The SoC includes 8 serial ports. They are all disabled in the SoC .dtsi,
>> > > and enabled selectively by board DT files. As not all serial ports are
>> > > available on all boards, the question was whether to add aliases for all
>> > > ports (in the .dtsi in this case) like
>> > >
>> > >          serial0 = &scif0;
>> > >          serial1 = &scif1;
>> > >          serial2 = &scif2;
>> > >          serial3 = &scif3;
>> > >          serial4 = &scif4;
>> > >          serial5 = &scif5;
>> > >          serial6 = &scif6;
>> > >          serial7 = &scif7;
>> > >
>> > > or to just add aliases for the enabled ports (in the board DT file) like
>> > >
>> > >          serial0 = &scif2;
>> > >          serial1 = &scif3;
>> > >
>> > > Note the numbering in the latter case: as the board doesn't use serial
>> > > ports 0 and 1, hardware ports 2 and 3 become logical ports 0 and 1.
>> > >
>> > > I considered that having Linux create ttySC0 and ttySC1 devices for the
>> > > first two ports of the board, regardless of which hardware ports are
>> > > used, is simpler from a user point of view (it allows sharing the same
>> > > inittab settings for the console serial port across several boards for
>> > > instance). I'd appreciate feedback on that.
>> >
>> > I think the traditional interpretation is that we want to use the aliases
>> > to reflect the device names in the OS.
>>
>> If I interpret this correctly it means that the question boils down to
>> whether we want the system to expose ttySC0 and ttySC1 or ttySC2 and
>> ttySC3, in case only ports 2 and 3 are enabled.
>>
>> Let's note that, despite the above example showing 8 instances of identical
>> serial IP cores, the reality is a bit more complex and Renesas SoCs usually
>> include different serial IP cores with several instances of each of them.
>> Ports of the same time are numbered in the datasheet, but there's no
>> standard or natural ordering global to all serial ports.
>>
>> This starts to remind me about the whole stable network device name changes
>> we went through recently.
>>
>> > 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. My main reasoning is giving consistent
naming across boards and it is more inline with how other devices are
named. The aliases are just to give you consistency in the numbering
within the 0 to N. Hopefully this is inline with what other platforms
have done as above all I think we should be consistent.

Rob
--
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

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hi Rob,

On Thursday 27 March 2014 08:54:09 Rob Herring wrote:
> On Thu, Mar 27, 2014 at 7:50 AM, Laurent Pinchart wrote:
> > Hello DT maintainers,
> > 
> > Ping ? This issue is blocking the merge of serial port DT support on
> > Renesas platforms, as we need to decide on how to name the ports.
> 
> This seems like a topic for devicetree-spec.

Indeed.

> > On Tuesday 11 March 2014 12:57:59 Laurent Pinchart wrote:
> >> On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
> >> > On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> >> > > The SoC includes 8 serial ports. They are all disabled in the SoC
> >> > > .dtsi, and enabled selectively by board DT files. As not all serial
> >> > > ports are available on all boards, the question was whether to add
> >> > > aliases for all ports (in the .dtsi in this case) like
> >> > > 
> >> > >          serial0 = &scif0;
> >> > >          serial1 = &scif1;
> >> > >          serial2 = &scif2;
> >> > >          serial3 = &scif3;
> >> > >          serial4 = &scif4;
> >> > >          serial5 = &scif5;
> >> > >          serial6 = &scif6;
> >> > >          serial7 = &scif7;
> >> > > 
> >> > > or to just add aliases for the enabled ports (in the board DT file)
> >> > > like
> >> > > 
> >> > >          serial0 = &scif2;
> >> > >          serial1 = &scif3;
> >> > > 
> >> > > Note the numbering in the latter case: as the board doesn't use
> >> > > serial ports 0 and 1, hardware ports 2 and 3 become logical ports 0
> >> > > and 1.
> >> > > 
> >> > > I considered that having Linux create ttySC0 and ttySC1 devices for
> >> > > the first two ports of the board, regardless of which hardware ports
> >> > > are used, is simpler from a user point of view (it allows sharing the
> >> > > same inittab settings for the console serial port across several
> >> > > boards for instance). I'd appreciate feedback on that.
> >> > 
> >> > I think the traditional interpretation is that we want to use the
> >> > aliases to reflect the device names in the OS.
> >> 
> >> If I interpret this correctly it means that the question boils down to
> >> whether we want the system to expose ttySC0 and ttySC1 or ttySC2 and
> >> ttySC3, in case only ports 2 and 3 are enabled.
> >> 
> >> Let's note that, despite the above example showing 8 instances of
> >> identical serial IP cores, the reality is a bit more complex and Renesas
> >> SoCs usually include different serial IP cores with several instances of
> >> each of them. Ports of the same time are numbered in the datasheet, but
> >> there's no standard or natural ordering global to all serial ports.
> >> 
> >> This starts to remind me about the whole stable network device name
> >> changes we went through recently.
> >> 
> >> > 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. My main reasoning is giving consistent naming
> across boards and it is more inline with how other devices are named. The
> aliases are just to give you consistency in the numbering within the 0 to N.
> Hopefully this is inline with what other platforms have done as above all I
> think we should be consistent.

That's my preference as well, but not everybody agreed, hence the RFC.

-- 
Regards,

Laurent Pinchart

Re: [RFC] Serial port aliases in DT

[Laurent Pinchart]

Hi Rob,

On Thursday 27 March 2014 08:54:09 Rob Herring wrote:
> On Thu, Mar 27, 2014 at 7:50 AM, Laurent Pinchart wrote:
> > Hello DT maintainers,
> > 
> > Ping ? This issue is blocking the merge of serial port DT support on
> > Renesas platforms, as we need to decide on how to name the ports.
> 
> This seems like a topic for devicetree-spec.

Indeed.

> > On Tuesday 11 March 2014 12:57:59 Laurent Pinchart wrote:
> >> On Monday 10 March 2014 13:57:23 Arnd Bergmann wrote:
> >> > On Monday 10 March 2014 12:59:03 Laurent Pinchart wrote:
> >> > > The SoC includes 8 serial ports. They are all disabled in the SoC
> >> > > .dtsi, and enabled selectively by board DT files. As not all serial
> >> > > ports are available on all boards, the question was whether to add
> >> > > aliases for all ports (in the .dtsi in this case) like
> >> > > 
> >> > >          serial0 = &scif0;
> >> > >          serial1 = &scif1;
> >> > >          serial2 = &scif2;
> >> > >          serial3 = &scif3;
> >> > >          serial4 = &scif4;
> >> > >          serial5 = &scif5;
> >> > >          serial6 = &scif6;
> >> > >          serial7 = &scif7;
> >> > > 
> >> > > or to just add aliases for the enabled ports (in the board DT file)
> >> > > like
> >> > > 
> >> > >          serial0 = &scif2;
> >> > >          serial1 = &scif3;
> >> > > 
> >> > > Note the numbering in the latter case: as the board doesn't use
> >> > > serial ports 0 and 1, hardware ports 2 and 3 become logical ports 0
> >> > > and 1.
> >> > > 
> >> > > I considered that having Linux create ttySC0 and ttySC1 devices for
> >> > > the first two ports of the board, regardless of which hardware ports
> >> > > are used, is simpler from a user point of view (it allows sharing the
> >> > > same inittab settings for the console serial port across several
> >> > > boards for instance). I'd appreciate feedback on that.
> >> > 
> >> > I think the traditional interpretation is that we want to use the
> >> > aliases to reflect the device names in the OS.
> >> 
> >> If I interpret this correctly it means that the question boils down to
> >> whether we want the system to expose ttySC0 and ttySC1 or ttySC2 and
> >> ttySC3, in case only ports 2 and 3 are enabled.
> >> 
> >> Let's note that, despite the above example showing 8 instances of
> >> identical serial IP cores, the reality is a bit more complex and Renesas
> >> SoCs usually include different serial IP cores with several instances of
> >> each of them. Ports of the same time are numbered in the datasheet, but
> >> there's no standard or natural ordering global to all serial ports.
> >> 
> >> This starts to remind me about the whole stable network device name
> >> changes we went through recently.
> >> 
> >> > 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. My main reasoning is giving consistent naming
> across boards and it is more inline with how other devices are named. The
> aliases are just to give you consistency in the numbering within the 0 to N.
> Hopefully this is inline with what other platforms have done as above all I
> think we should be consistent.

That's my preference as well, but not everybody agreed, hence the RFC.

-- 
Regards,

Laurent Pinchart

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

Re: [RFC] Serial port aliases in DT

[Sascha Hauer]

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

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] Serial port aliases in DT

[Sascha Hauer]

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

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

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

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Serial port aliases in DT

[Pawel Moll]

On Thu, 2014-03-27 at 18:26 +0000, Arnd Bergmann wrote:
> >  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.

I'm with you on this one, for what it's worth.

Pawel

Re: [RFC] Serial port aliases in DT

[Pawel Moll]

On Thu, 2014-03-27 at 18:26 +0000, Arnd Bergmann wrote:
> >  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.

I'm with you on this one, for what it's worth.

Pawel

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

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]


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

I agree with this one, makes sense. It calls for quite some cleanup,
though:

$ grep aliases arch/arm/boot/dts/*.dtsi | wc -l
79


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]


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

I agree with this one, makes sense. It calls for quite some cleanup,
though:

$ grep aliases arch/arm/boot/dts/*.dtsi | wc -l
79


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] Serial port aliases in DT

[Rob Herring]

On Thu, Mar 27, 2014 at 10:18 AM, Sascha Hauer <s.hauer@pengutronix.de> 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.  Many
> devicetrees specify aliases for i2c/spi/mmc controllers aswell.  Should
> they order their i2c controllers in the order of preference now?

I was only referring to serial consoles for this discussion.

I don't think expanding aliases usage beyond serial ports is a good
thing. It may work for fixed h/w, but it won't for hotplug cases. This
naming issue has been solved in other ways for other devices: udev
persistent net rules, uuid for disks, etc. It needs to be solved for
serial devices.

> Most dtsi files in the kernel specify a SoC specific order of aliases
> and I think this makes the most sense.

I agree with Arnd here. If we are going to care about the name, it
should be something that makes sense to the user of a board, not the
SOC. Of course, if a board has a serial port labeled "Debug port" or
something, that doesn't tell you the name or index either.

Rob

Re: [RFC] Serial port aliases in DT

[Rob Herring]

On Thu, Mar 27, 2014 at 10:18 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 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.  Many
> devicetrees specify aliases for i2c/spi/mmc controllers aswell.  Should
> they order their i2c controllers in the order of preference now?

I was only referring to serial consoles for this discussion.

I don't think expanding aliases usage beyond serial ports is a good
thing. It may work for fixed h/w, but it won't for hotplug cases. This
naming issue has been solved in other ways for other devices: udev
persistent net rules, uuid for disks, etc. It needs to be solved for
serial devices.

> Most dtsi files in the kernel specify a SoC specific order of aliases
> and I think this makes the most sense.

I agree with Arnd here. If we are going to care about the name, it
should be something that makes sense to the user of a board, not the
SOC. Of course, if a board has a serial port labeled "Debug port" or
something, that doesn't tell you the name or index either.

Rob
--
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

Re: [RFC] Serial port aliases in DT

[Sascha Hauer]

On Thu, Mar 27, 2014 at 07:26:27PM +0100, Arnd Bergmann wrote:
> 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.

Freescale starts numbering the devices at 1, Linux normally starts at 0.
This leads to enough confusion already. I really don't want to have an
additional board vendor specific translation. This would mean when
talking about an UART we would not only have to make clear whether we
mean freescale numbering or Linux numbering, but also whether we me mean
board vendor numbering. Things like earlyprintk would still have the SoC
numbering. Bootloaders which still use the SoC numbering would add to
the confusion.
I really don't think making the numbering board specific is going to
improve the situation.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC] Serial port aliases in DT

[Sascha Hauer]

On Thu, Mar 27, 2014 at 07:26:27PM +0100, Arnd Bergmann wrote:
> 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.

Freescale starts numbering the devices at 1, Linux normally starts at 0.
This leads to enough confusion already. I really don't want to have an
additional board vendor specific translation. This would mean when
talking about an UART we would not only have to make clear whether we
mean freescale numbering or Linux numbering, but also whether we me mean
board vendor numbering. Things like earlyprintk would still have the SoC
numbering. Bootloaders which still use the SoC numbering would add to
the confusion.
I really don't think making the numbering board specific is going to
improve the situation.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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

Re: [RFC] Serial port aliases in DT

[Geert Uytterhoeven]

On Fri, Mar 28, 2014 at 8:28 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Thu, Mar 27, 2014 at 07:26:27PM +0100, Arnd Bergmann wrote:
>> 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.
>
> Freescale starts numbering the devices at 1, Linux normally starts at 0.
> This leads to enough confusion already. I really don't want to have an
> additional board vendor specific translation. This would mean when
> talking about an UART we would not only have to make clear whether we
> mean freescale numbering or Linux numbering, but also whether we me mean
> board vendor numbering. Things like earlyprintk would still have the SoC
> numbering. Bootloaders which still use the SoC numbering would add to
> the confusion.
> I really don't think making the numbering board specific is going to
> improve the situation.

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?).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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

Re: [RFC] Serial port aliases in DT

[Geert Uytterhoeven]

On Fri, Mar 28, 2014 at 8:28 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> On Thu, Mar 27, 2014 at 07:26:27PM +0100, Arnd Bergmann wrote:
>> 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.
>
> Freescale starts numbering the devices at 1, Linux normally starts at 0.
> This leads to enough confusion already. I really don't want to have an
> additional board vendor specific translation. This would mean when
> talking about an UART we would not only have to make clear whether we
> mean freescale numbering or Linux numbering, but also whether we me mean
> board vendor numbering. Things like earlyprintk would still have the SoC
> numbering. Bootloaders which still use the SoC numbering would add to
> the confusion.
> I really don't think making the numbering board specific is going to
> improve the situation.

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?).

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

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

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.

	Arnd

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

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.

	Arnd

Re: [RFC] Serial port aliases in DT

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Mar 28, 2014 at 9:30 AM, Arnd Bergmann <arnd@arndb.de> 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.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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

Re: [RFC] Serial port aliases in DT

[Geert Uytterhoeven]

Hi Arnd,

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.

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

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

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

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

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.

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

Re: [RFC] Serial port aliases in DT

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Mar 28, 2014 at 11:28 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 28 March 2014 09:39:22 Geert Uytterhoeven wrote:
>> On Fri, Mar 28, 2014 at 9:30 AM, Arnd Bergmann <arnd@arndb.de> 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@linux-m68k.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

Re: [RFC] Serial port aliases in DT

[Geert Uytterhoeven]

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

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

On Friday 28 March 2014 11:40:03 Geert Uytterhoeven wrote:
> On Fri, Mar 28, 2014 at 11:28 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 28 March 2014 09:39:22 Geert Uytterhoeven wrote:
> >> On Fri, Mar 28, 2014 at 9:30 AM, Arnd Bergmann <arnd@arndb.de> 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

Re: [RFC] Serial port aliases in DT

[Arnd Bergmann]

On Friday 28 March 2014 11:40:03 Geert Uytterhoeven wrote:
> 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.

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Serial port aliases in DT

[Rob Herring]

On Fri, Mar 28, 2014 at 2:28 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Thu, Mar 27, 2014 at 07:26:27PM +0100, Arnd Bergmann wrote:
>> 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.
>
> Freescale starts numbering the devices at 1, Linux normally starts at 0.
> This leads to enough confusion already. I really don't want to have an
> additional board vendor specific translation. This would mean when
> talking about an UART we would not only have to make clear whether we
> mean freescale numbering or Linux numbering, but also whether we me mean
> board vendor numbering. Things like earlyprintk would still have the SoC
> numbering. Bootloaders which still use the SoC numbering would add to
> the confusion.

I'm working on a series to support early console from command line or
DT (linux,stdout-path). This should mostly replace using DEBUG_LL for
earlyprintk (although they can coexist).

> I really don't think making the numbering board specific is going to
> improve the situation.

The way I look at is if I pick-up any board with UARTs labeled in some
way with ordering whether it is 0,1,2; 1,2,3; or A,B,C that I can
count on connecting to the 1st port and get a console on /dev/ttyS0. I
really don't care what physical UART that corresponds to and I don't
want to have to go look it up on every different board. That works on
any PC ever made no matter what chipset. It should be for ARM as well.
We should be designing things to just work for an experienced Linux
user, not someone familiar with particular h/w knowledge. Of course we
are not there yet with separate namespaces for each UART, but that is
a kernel problem which we need to fix.

Rob

Re: [RFC] Serial port aliases in DT

[Rob Herring]

On Fri, Mar 28, 2014 at 2:28 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> On Thu, Mar 27, 2014 at 07:26:27PM +0100, Arnd Bergmann wrote:
>> 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.
>
> Freescale starts numbering the devices at 1, Linux normally starts at 0.
> This leads to enough confusion already. I really don't want to have an
> additional board vendor specific translation. This would mean when
> talking about an UART we would not only have to make clear whether we
> mean freescale numbering or Linux numbering, but also whether we me mean
> board vendor numbering. Things like earlyprintk would still have the SoC
> numbering. Bootloaders which still use the SoC numbering would add to
> the confusion.

I'm working on a series to support early console from command line or
DT (linux,stdout-path). This should mostly replace using DEBUG_LL for
earlyprintk (although they can coexist).

> I really don't think making the numbering board specific is going to
> improve the situation.

The way I look at is if I pick-up any board with UARTs labeled in some
way with ordering whether it is 0,1,2; 1,2,3; or A,B,C that I can
count on connecting to the 1st port and get a console on /dev/ttyS0. I
really don't care what physical UART that corresponds to and I don't
want to have to go look it up on every different board. That works on
any PC ever made no matter what chipset. It should be for ARM as well.
We should be designing things to just work for an experienced Linux
user, not someone familiar with particular h/w knowledge. Of course we
are not there yet with separate namespaces for each UART, but that is
a kernel problem which we need to fix.

Rob
--
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