All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: devicetree@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [RFC] Serial port aliases in DT
Date: Tue, 11 Mar 2014 12:46:22 +0000	[thread overview]
Message-ID: <20140311124622.GA30394@katana> (raw)
In-Reply-To: <1551855.ylN84WQiIN@avalon>

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

WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@the-dreams.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: devicetree@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [RFC] Serial port aliases in DT
Date: Tue, 11 Mar 2014 13:46:22 +0100	[thread overview]
Message-ID: <20140311124622.GA30394@katana> (raw)
In-Reply-To: <1551855.ylN84WQiIN@avalon>

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

  reply	other threads:[~2014-03-11 12:46 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 11:59 [RFC] Serial port aliases in DT Laurent Pinchart
2014-03-10 11:59 ` Laurent Pinchart
2014-03-10 12:38 ` Wolfram Sang
2014-03-10 12:38   ` Wolfram Sang
2014-03-11 11:56   ` Laurent Pinchart
2014-03-11 11:56     ` Laurent Pinchart
2014-03-11 12:46     ` Wolfram Sang [this message]
2014-03-11 12:46       ` Wolfram Sang
2014-03-12 10:40       ` Laurent Pinchart
2014-03-12 10:40         ` Laurent Pinchart
2014-03-12 10:45         ` Wolfram Sang
2014-03-12 10:45           ` Wolfram Sang
2014-03-10 12:57 ` Arnd Bergmann
2014-03-10 12:57   ` Arnd Bergmann
2014-03-11 11:57   ` Laurent Pinchart
2014-03-11 11:57     ` Laurent Pinchart
2014-03-27 12:50     ` Laurent Pinchart
2014-03-27 12:50       ` Laurent Pinchart
2014-03-27 13:54       ` Rob Herring
2014-03-27 13:54         ` Rob Herring
2014-03-27 14:43         ` Laurent Pinchart
2014-03-27 14:43           ` Laurent Pinchart
2014-03-27 15:18         ` Sascha Hauer
2014-03-27 15:18           ` Sascha Hauer
     [not found]           ` <20140327151829.GX17250-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-03-27 18:26             ` Arnd Bergmann
2014-03-27 18:26               ` Arnd Bergmann
2014-03-27 18:34               ` Pawel Moll
2014-03-27 18:34                 ` Pawel Moll
2014-03-27 20:07               ` Wolfram Sang
2014-03-27 20:07                 ` Wolfram Sang
2014-03-28  7:28               ` Sascha Hauer
2014-03-28  7:28                 ` Sascha Hauer
     [not found]                 ` <20140328072827.GY17250-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-03-28  8:09                   ` Geert Uytterhoeven
2014-03-28  8:09                     ` Geert Uytterhoeven
2014-03-28  8:30                     ` Arnd Bergmann
2014-03-28  8:30                       ` Arnd Bergmann
2014-03-28  8:39                       ` Geert Uytterhoeven
2014-03-28  8:39                         ` Geert Uytterhoeven
     [not found]                         ` <CAMuHMdVYhGGt7+fR4oHzf-hDvTOWbHfhM2g92eo3RqULd6yR2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-28 10:28                           ` Arnd Bergmann
2014-03-28 10:28                             ` Arnd Bergmann
2014-03-28 10:40                             ` Geert Uytterhoeven
2014-03-28 10:40                               ` Geert Uytterhoeven
     [not found]                               ` <CAMuHMdVJ8Jid=bdWLb7g5MP5dFOwDkvoHEbFH4nQD5bWp-2sxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-28 11:49                                 ` Arnd Bergmann
2014-03-28 11:49                                   ` Arnd Bergmann
2014-03-28 14:46                   ` Rob Herring
2014-03-28 14:46                     ` Rob Herring
2014-03-27 20:34             ` Rob Herring
2014-03-27 20:34               ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140311124622.GA30394@katana \
    --to=wsa@the-dreams.de \
    --cc=devicetree@vger.kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.