[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Allen Martin]

Add a new special environment variable "serial" that allows selection
of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
that were not doing anything.

Signed-off-by: Allen Martin <amartin@nvidia.com>
---
 common/cmd_nvedit.c             |    7 ++++++-
 common/iomux.c                  |   10 ----------
 doc/driver-model/UDM-serial.txt |    5 +++--
 3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 1f9c674..d1ee07d 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char *oldval,
 		/* Try assigning specified device */
 		if (console_assign(console, newval) < 0)
 			return 1;
+#endif /* CONFIG_CONSOLE_MUX */
+	}
 
+#ifdef CONFIG_SERIAL_MULTI
+	/* Check for serial redirection */
+	if (strcmp(name, "serial") == 0) {
 		if (serial_assign(newval) < 0)
 			return 1;
-#endif /* CONFIG_CONSOLE_MUX */
 	}
+#endif /* CONFIG_SERIAL_MULTI */
 
 	/*
 	 * Some variables like "ethaddr" and "serial#" can be set only once and
diff --git a/common/iomux.c b/common/iomux.c
index dbc2312..6a75704 100644
--- a/common/iomux.c
+++ b/common/iomux.c
@@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
 		 */
 		if (console_assign(console, start[j]) < 0)
 			continue;
-		/*
-		 * This was taken from common/cmd_nvedit.c.
-		 * This will never work because serial_assign() returns
-		 * 1 upon error, not -1.
-		 * This would almost always return an error anyway because
-		 * serial_assign() expects the name of a serial device, like
-		 * serial_smc, but the user generally only wants to set serial.
-		 */
-		if (serial_assign(start[j]) < 0)
-			continue;
 		cons_set[cs_idx++] = dev;
 	}
 	free(console_args);
diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
index 9feb2e5..66f3e6b 100644
--- a/doc/driver-model/UDM-serial.txt
+++ b/doc/driver-model/UDM-serial.txt
@@ -26,8 +26,9 @@ and serial_setbrg() are often called from platform-dependent places.
 It's important to consider current implementation of CONFIG_SERIAL_MULTI though.
 This resides in common/serial.c and behaves as a multiplexer for serial ports.
 This, by calling serial_assign(), allows user to switch I/O from one serial port
-to another. Though the environmental variables "stdin", "stdout", "stderr"
-remain set to "serial".
+to another. The environment variable "serial" is used to select which of the
+serial ports is the currently active port.  The environmental variables
+"stdin", "stdout", "stderr" remain set to "serial".
 
 These variables are managed by the IOMUX. This resides in common/iomux.c and
 manages all console input/output from U-Boot. For serial port, only one IOMUX is
-- 
1.7.10.4

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Marek Vasut]

Dear Allen Martin,

> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
> 
> Signed-off-by: Allen Martin <amartin@nvidia.com>
> ---
>  common/cmd_nvedit.c             |    7 ++++++-
>  common/iomux.c                  |   10 ----------
>  doc/driver-model/UDM-serial.txt |    5 +++--
>  3 files changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char
> *oldval, /* Try assigning specified device */
>  		if (console_assign(console, newval) < 0)
>  			return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> +	}
> 
> +#ifdef CONFIG_SERIAL_MULTI

Drop this, it's default. There's no CONFIG_SERIAL_MULTI in the tree at all 
anymore.

> +	/* Check for serial redirection */
> +	if (strcmp(name, "serial") == 0) {
>  		if (serial_assign(newval) < 0)
>  			return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
>  	}
> +#endif /* CONFIG_SERIAL_MULTI */
> 
>  	/*
>  	 * Some variables like "ethaddr" and "serial#" can be set only once and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
>  		 */
>  		if (console_assign(console, start[j]) < 0)
>  			continue;
> -		/*
> -		 * This was taken from common/cmd_nvedit.c.
> -		 * This will never work because serial_assign() returns
> -		 * 1 upon error, not -1.
> -		 * This would almost always return an error anyway because
> -		 * serial_assign() expects the name of a serial device, like
> -		 * serial_smc, but the user generally only wants to set serial.
> -		 */
> -		if (serial_assign(start[j]) < 0)
> -			continue;
>  		cons_set[cs_idx++] = dev;
>  	}
>  	free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt
> b/doc/driver-model/UDM-serial.txt index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from
> platform-dependent places. It's important to consider current
> implementation of CONFIG_SERIAL_MULTI though. This resides in
> common/serial.c and behaves as a multiplexer for serial ports. This, by
> calling serial_assign(), allows user to switch I/O from one serial port
> -to another. Though the environmental variables "stdin", "stdout",
> "stderr" -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of
> the +serial ports is the currently active port.  The environmental
> variables +"stdin", "stdout", "stderr" remain set to "serial".
> 
>  These variables are managed by the IOMUX. This resides in common/iomux.c
> and manages all console input/output from U-Boot. For serial port, only
> one IOMUX is

Best regards,
Marek Vasut

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Tom Rini]

On Thu, Oct 25, 2012 at 02:59:50PM -0700, Allen Martin wrote:

> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
> 
> Signed-off-by: Allen Martin <amartin@nvidia.com>

Two things.  First, should I or should I not need to have
CONFIG_CONSOLE_MUX set?  If I set it, adding serial=eserial3 to my
default environment switches from eserial0 to eserial3 when we get to
that point in the boot, otherwise I do have to manually setenv serial
eserial3 for anything to happen.  And the second thing, I can't get any
output on the other UART, either way.  It goes away from eserial0 but
nothing ever shows up to eserial3 (the easiest one here to test).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121025/d17afa93/attachment.pgp>

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Joe Hershberger]

Hi Allen,

On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin <amartin@nvidia.com>
> ---
>  common/cmd_nvedit.c             |    7 ++++++-
>  common/iomux.c                  |   10 ----------
>  doc/driver-model/UDM-serial.txt |    5 +++--
>  3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char *oldval,
>                 /* Try assigning specified device */
>                 if (console_assign(console, newval) < 0)
>                         return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> +       }
>
> +#ifdef CONFIG_SERIAL_MULTI
> +       /* Check for serial redirection */
> +       if (strcmp(name, "serial") == 0) {
>                 if (serial_assign(newval) < 0)
>                         return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
>         }
> +#endif /* CONFIG_SERIAL_MULTI */

Changes to this directly conflict with the environment callback series
I sent out RFC (soon be be a real series).  Can we hold off on this
until that happens?

>         /*
>          * Some variables like "ethaddr" and "serial#" can be set only once and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
>                  */
>                 if (console_assign(console, start[j]) < 0)
>                         continue;
> -               /*
> -                * This was taken from common/cmd_nvedit.c.
> -                * This will never work because serial_assign() returns
> -                * 1 upon error, not -1.
> -                * This would almost always return an error anyway because
> -                * serial_assign() expects the name of a serial device, like
> -                * serial_smc, but the user generally only wants to set serial.
> -                */
> -               if (serial_assign(start[j]) < 0)
> -                       continue;
>                 cons_set[cs_idx++] = dev;
>         }
>         free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
> index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from platform-dependent places.
>  It's important to consider current implementation of CONFIG_SERIAL_MULTI though.
>  This resides in common/serial.c and behaves as a multiplexer for serial ports.
>  This, by calling serial_assign(), allows user to switch I/O from one serial port
> -to another. Though the environmental variables "stdin", "stdout", "stderr"
> -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of the
> +serial ports is the currently active port.  The environmental variables
> +"stdin", "stdout", "stderr" remain set to "serial".
>
>  These variables are managed by the IOMUX. This resides in common/iomux.c and
>  manages all console input/output from U-Boot. For serial port, only one IOMUX is
> --
> 1.7.10.4
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Stephen Warren]

On 10/25/2012 03:59 PM, Allen Martin wrote:
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.

So I think this requires (for example) the following environment variables:

stdout=serial
serial=eserial0

Is it possible to allow the following instead:

stdout=eserial0

That way, one could presumably set:

stdout=eserial0,eserial3

and hence allow the use of multiple serial consoles?

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Stephen Warren]

On 10/25/2012 04:36 PM, Joe Hershberger wrote:
> Hi Allen,
> 
> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
>> Add a new special environment variable "serial" that allows selection
>> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> that were not doing anything.
...
> Changes to this directly conflict with the environment callback series
> I sent out RFC (soon be be a real series).  Can we hold off on this
> until that happens?

The problem here is that serial output on Tegra simply doesn't work
(after some point in boot?) without this patch. It seems better to get
everything working before adding new features doesn't it? Otherwise, if
the environment callback stuff (or any other change right now) breaks
something Tegra-specific, there would be no way to identify which change
broke it.

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Joe Hershberger]

Hi Stephen,

On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/25/2012 03:59 PM, Allen Martin wrote:
>> Add a new special environment variable "serial" that allows selection
>> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> that were not doing anything.
>
> So I think this requires (for example) the following environment variables:
>
> stdout=serial
> serial=eserial0
>
> Is it possible to allow the following instead:
>
> stdout=eserial0

This is precisely what the patch I had pre-Marek serial did.

> That way, one could presumably set:
>
> stdout=eserial0,eserial3

Though it didn't allow this.

-Joe

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Joe Hershberger]

Hi Stephen,

On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/25/2012 04:36 PM, Joe Hershberger wrote:
>> Hi Allen,
>>
>> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
>>> Add a new special environment variable "serial" that allows selection
>>> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
>>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>>> that were not doing anything.
> ...
>> Changes to this directly conflict with the environment callback series
>> I sent out RFC (soon be be a real series).  Can we hold off on this
>> until that happens?
>
> The problem here is that serial output on Tegra simply doesn't work
> (after some point in boot?) without this patch. It seems better to get
> everything working before adding new features doesn't it? Otherwise, if
> the environment callback stuff (or any other change right now) breaks
> something Tegra-specific, there would be no way to identify which change
> broke it.

Fair enough.  However I don't think this patch is the right way to fix it.

-Joe

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Allen Martin]

On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote:
> Hi Stephen,
> 
> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 10/25/2012 03:59 PM, Allen Martin wrote:
> >> Add a new special environment variable "serial" that allows selection
> >> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >> that were not doing anything.
> >
> > So I think this requires (for example) the following environment variables:
> >
> > stdout=serial
> > serial=eserial0
> >
> > Is it possible to allow the following instead:
> >
> > stdout=eserial0
> 
> This is precisely what the patch I had pre-Marek serial did.

In your patch would "stdout=serial" still work for case where there is
only one serial port?  I think it's important to try to preserve that
to no be too disruptive.

> 
> > That way, one could presumably set:
> >
> > stdout=eserial0,eserial3
> 
> Though it didn't allow this.
> 

Shouldn't that be (nearly) transparent through iomux?

-Allen
-- 
nvpublic

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Allen Martin]

On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote:
> Hi Stephen,
> 
> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 10/25/2012 04:36 PM, Joe Hershberger wrote:
> >> Hi Allen,
> >>
> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
> >>> Add a new special environment variable "serial" that allows selection
> >>> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >>> that were not doing anything.
> > ...
> >> Changes to this directly conflict with the environment callback series
> >> I sent out RFC (soon be be a real series).  Can we hold off on this
> >> until that happens?
> >
> > The problem here is that serial output on Tegra simply doesn't work
> > (after some point in boot?) without this patch. It seems better to get
> > everything working before adding new features doesn't it? Otherwise, if
> > the environment callback stuff (or any other change right now) breaks
> > something Tegra-specific, there would be no way to identify which change
> > broke it.
> 
> Fair enough.  However I don't think this patch is the right way to fix it.
> 

Ok, would removing the existing calls to serial_assign() from iomux.c
and cmd_nvedit.c be an ok first step?  They don't appear to do
anything useful right now and that would fix tegra and raspberry pi.

-Allen
-- 
nvpublic

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Joe Hershberger]

Hi Allen,

On Thu, Oct 25, 2012 at 5:50 PM, Allen Martin <amartin@nvidia.com> wrote:
> On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote:
>> Hi Stephen,
>>
>> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> > On 10/25/2012 03:59 PM, Allen Martin wrote:
>> >> Add a new special environment variable "serial" that allows selection
>> >> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
>> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> >> that were not doing anything.
>> >
>> > So I think this requires (for example) the following environment variables:
>> >
>> > stdout=serial
>> > serial=eserial0
>> >
>> > Is it possible to allow the following instead:
>> >
>> > stdout=eserial0
>>
>> This is precisely what the patch I had pre-Marek serial did.
>
> In your patch would "stdout=serial" still work for case where there is
> only one serial port?  I think it's important to try to preserve that
> to no be too disruptive.

It used to support stdout=serial based on not being
CONFIG_SERIAL_MULTI.  Now that that's gone, I'm guessing it would
simply be based on only having one registered serial device.

>>
>> > That way, one could presumably set:
>> >
>> > stdout=eserial0,eserial3
>>
>> Though it didn't allow this.
>>
>
> Shouldn't that be (nearly) transparent through iomux?

If that's what iomux does, then sure!  I haven't used I/O mux on a
device before.

-Joe

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Joe Hershberger]

Hi Allen,

On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin <amartin@nvidia.com> wrote:
> On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote:
>> Hi Stephen,
>>
>> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> > On 10/25/2012 04:36 PM, Joe Hershberger wrote:
>> >> Hi Allen,
>> >>
>> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
>> >>> Add a new special environment variable "serial" that allows selection
>> >>> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
>> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
>> >>> that were not doing anything.
>> > ...
>> >> Changes to this directly conflict with the environment callback series
>> >> I sent out RFC (soon be be a real series).  Can we hold off on this
>> >> until that happens?
>> >
>> > The problem here is that serial output on Tegra simply doesn't work
>> > (after some point in boot?) without this patch. It seems better to get
>> > everything working before adding new features doesn't it? Otherwise, if
>> > the environment callback stuff (or any other change right now) breaks
>> > something Tegra-specific, there would be no way to identify which change
>> > broke it.
>>
>> Fair enough.  However I don't think this patch is the right way to fix it.
>>
>
> Ok, would removing the existing calls to serial_assign() from iomux.c
> and cmd_nvedit.c be an ok first step?  They don't appear to do
> anything useful right now and that would fix tegra and raspberry pi.

I think that's fine to just remove those 2 calls.  Seem like a good
short-term solution.

-Joe

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Allen Martin]

On Thu, Oct 25, 2012 at 04:18:11PM -0700, Joe Hershberger wrote:
> Hi Allen,
> 
> On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin <amartin@nvidia.com> wrote:
> > On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote:
> >> Hi Stephen,
> >>
> >> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >> > On 10/25/2012 04:36 PM, Joe Hershberger wrote:
> >> >> Hi Allen,
> >> >>
> >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin <amartin@nvidia.com> wrote:
> >> >>> Add a new special environment variable "serial" that allows selection
> >> >>> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> >> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >> >>> that were not doing anything.
> >> > ...
> >> >> Changes to this directly conflict with the environment callback series
> >> >> I sent out RFC (soon be be a real series).  Can we hold off on this
> >> >> until that happens?
> >> >
> >> > The problem here is that serial output on Tegra simply doesn't work
> >> > (after some point in boot?) without this patch. It seems better to get
> >> > everything working before adding new features doesn't it? Otherwise, if
> >> > the environment callback stuff (or any other change right now) breaks
> >> > something Tegra-specific, there would be no way to identify which change
> >> > broke it.
> >>
> >> Fair enough.  However I don't think this patch is the right way to fix it.
> >>
> >
> > Ok, would removing the existing calls to serial_assign() from iomux.c
> > and cmd_nvedit.c be an ok first step?  They don't appear to do
> > anything useful right now and that would fix tegra and raspberry pi.
> 
> I think that's fine to just remove those 2 calls.  Seem like a good
> short-term solution.
> 

Ok, I'll send out a patch for that now, thanks.

-Allen
-- 
nvpublic

[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI

[Marek Vasut]

Dear Joe Hershberger,

> Hi Allen,
> 
> On Thu, Oct 25, 2012 at 5:50 PM, Allen Martin <amartin@nvidia.com> wrote:
> > On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote:
> >> Hi Stephen,
> >> 
> >> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren <swarren@wwwdotorg.org> 
wrote:
> >> > On 10/25/2012 03:59 PM, Allen Martin wrote:
> >> >> Add a new special environment variable "serial" that allows selection
> >> >> of serial device when CONFIG_SERIAL_MULTI is defined.  This replaces
> >> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> >> >> that were not doing anything.
> >> > 
> >> > So I think this requires (for example) the following environment
> >> > variables:
> >> > 
> >> > stdout=serial
> >> > serial=eserial0
> >> > 
> >> > Is it possible to allow the following instead:
> >> > 
> >> > stdout=eserial0
> >> 
> >> This is precisely what the patch I had pre-Marek serial did.
> > 
> > In your patch would "stdout=serial" still work for case where there is
> > only one serial port?  I think it's important to try to preserve that
> > to no be too disruptive.
> 
> It used to support stdout=serial based on not being
> CONFIG_SERIAL_MULTI.  Now that that's gone, I'm guessing it would
> simply be based on only having one registered serial device.
> 
> >> > That way, one could presumably set:
> >> > 
> >> > stdout=eserial0,eserial3
> >> 
> >> Though it didn't allow this.
> > 
> > Shouldn't that be (nearly) transparent through iomux?
> 
> If that's what iomux does, then sure!  I haven't used I/O mux on a
> device before.

This is what we should do, indeed.

Best regards,
Marek Vasut