Patchwork [U-Boot,3/6] serial: Reorder serial_assign()

login
register
mail settings
Submitter Marek Vasut
Date Oct. 7, 2012, 12:07 a.m.
Message ID <1349568426-27219-4-git-send-email-marex@denx.de>
Download mbox | patch
Permalink /patch/189773/
State Accepted
Delegated to: Tom Rini
Headers show

Comments

Marek Vasut - Oct. 7, 2012, 12:07 a.m.
Reorder serial_assign() function to get rid of the extra level of
indentation. Also, adjust the return value to be -EINVAL instead of
positive one to be more consistent.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Tom Rini <trini@ti.com>
---
 drivers/serial/serial.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
Allen Martin - Oct. 20, 2012, 12:45 a.m.
On Sat, Oct 06, 2012 at 05:07:03PM -0700, Marek Vasut wrote:
> Reorder serial_assign() function to get rid of the extra level of
> indentation. Also, adjust the return value to be -EINVAL instead of
> positive one to be more consistent.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Marek Vasut <marek.vasut@gmail.com>
> Cc: Tom Rini <trini@ti.com>
> ---
>  drivers/serial/serial.c |   11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> index da41cd5..1054494 100644
> --- a/drivers/serial/serial.c
> +++ b/drivers/serial/serial.c
> @@ -26,6 +26,7 @@
>  #include <stdio_dev.h>
>  #include <post.h>
>  #include <linux/compiler.h>
> +#include <errno.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -203,13 +204,13 @@ int serial_assign(const char *name)
>  	struct serial_device *s;
>  
>  	for (s = serial_devices; s; s = s->next) {
> -		if (strcmp(s->name, name) == 0) {
> -			serial_current = s;
> -			return 0;
> -		}
> +		if (strcmp(s->name, name))
> +			continue;
> +		serial_current = s;
> +		return 0;
>  	}
>  
> -	return 1;
> +	return -EINVAL;

Hi Marek, the change to return value here broke serial output on
tegra.  What I see is that the serial device name (s->name) is
"eserial0" as set by serial_ns16550.c, and the name passed in from the
stdout environment is "serial" so they don't match and it fails.  This
always used to be ok because the return code didn't indicate failure
and iomux_doenv() would continue on happily, but now it causes
iomux_doenv() to fail and no printfs() work after that.

Not sure what the right fix is, should stdout really be set to
"eserial0"?  It seems "serial" should mean "the default serial device"
which for the normal case is the one and only device.

-Allen
Marek Vasut - Oct. 20, 2012, 8:19 a.m.
Dear Allen Martin,

[...]
> 
> Hi Marek, the change to return value here broke serial output on
> tegra.  What I see is that the serial device name (s->name) is
> "eserial0" as set by serial_ns16550.c, and the name passed in from the
> stdout environment is "serial" so they don't match and it fails.  This
> always used to be ok because the return code didn't indicate failure
> and iomux_doenv() would continue on happily, but now it causes
> iomux_doenv() to fail and no printfs() work after that.
> 
> Not sure what the right fix is, should stdout really be set to
> "eserial0"?  It seems "serial" should mean "the default serial device"
> which for the normal case is the one and only device.

Looking at the source, the obvious course of action is to fix iomux.c .

> -Allen

Best regards,
Marek Vasut
Allen Martin - Oct. 22, 2012, 5:23 p.m.
On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> Dear Allen Martin,
> 
> [...]
> > 
> > Hi Marek, the change to return value here broke serial output on
> > tegra.  What I see is that the serial device name (s->name) is
> > "eserial0" as set by serial_ns16550.c, and the name passed in from the
> > stdout environment is "serial" so they don't match and it fails.  This
> > always used to be ok because the return code didn't indicate failure
> > and iomux_doenv() would continue on happily, but now it causes
> > iomux_doenv() to fail and no printfs() work after that.
> > 
> > Not sure what the right fix is, should stdout really be set to
> > "eserial0"?  It seems "serial" should mean "the default serial device"
> > which for the normal case is the one and only device.
> 
> Looking at the source, the obvious course of action is to fix iomux.c .
> 

I've been looking at this call to serial_assign() from iomux.c and I'm
not convinced this code does anything meaningful at all.  It passes
the name of a struct stdio_dev device which serial_assign() then tries
to match against the registered struct serial_devices, which will
never match.

What I don't understand is the case where you have a board that
actually has more than one physical serial port and how the mapping
from stdio_dev to serial_device happens.

Also, looking at the code to cmd_nvedit, I think your change also broke
"setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX.  We
always have this on for tegra, so we don't go down this code path, but
it looks identical to the code in iomux.c

-Allen
Simon Glass - Oct. 25, 2012, 6:09 p.m.
Hi,

On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> wrote:
> On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
>> Dear Allen Martin,
>>
>> [...]
>> >
>> > Hi Marek, the change to return value here broke serial output on
>> > tegra.  What I see is that the serial device name (s->name) is
>> > "eserial0" as set by serial_ns16550.c, and the name passed in from the
>> > stdout environment is "serial" so they don't match and it fails.  This
>> > always used to be ok because the return code didn't indicate failure
>> > and iomux_doenv() would continue on happily, but now it causes
>> > iomux_doenv() to fail and no printfs() work after that.
>> >
>> > Not sure what the right fix is, should stdout really be set to
>> > "eserial0"?  It seems "serial" should mean "the default serial device"
>> > which for the normal case is the one and only device.
>>
>> Looking at the source, the obvious course of action is to fix iomux.c .
>>
>
> I've been looking at this call to serial_assign() from iomux.c and I'm
> not convinced this code does anything meaningful at all.  It passes
> the name of a struct stdio_dev device which serial_assign() then tries
> to match against the registered struct serial_devices, which will
> never match.
>
> What I don't understand is the case where you have a board that
> actually has more than one physical serial port and how the mapping
> from stdio_dev to serial_device happens.
>
> Also, looking at the code to cmd_nvedit, I think your change also broke
> "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX.  We
> always have this on for tegra, so we don't go down this code path, but
> it looks identical to the code in iomux.c

Sorry if I missed it - what was the resolution here? Should we revert
that change?

Regards,
Simon

>
> -Allen
> --
> nvpublic
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Marek Vasut - Oct. 25, 2012, 7:03 p.m.
Dear Simon Glass,

> Hi,
> 
> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> wrote:
> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> >> Dear Allen Martin,
> >> 
> >> [...]
> >> 
> >> > Hi Marek, the change to return value here broke serial output on
> >> > tegra.  What I see is that the serial device name (s->name) is
> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the
> >> > stdout environment is "serial" so they don't match and it fails.  This
> >> > always used to be ok because the return code didn't indicate failure
> >> > and iomux_doenv() would continue on happily, but now it causes
> >> > iomux_doenv() to fail and no printfs() work after that.
> >> > 
> >> > Not sure what the right fix is, should stdout really be set to
> >> > "eserial0"?  It seems "serial" should mean "the default serial device"
> >> > which for the normal case is the one and only device.
> >> 
> >> Looking at the source, the obvious course of action is to fix iomux.c .
> > 
> > I've been looking at this call to serial_assign() from iomux.c and I'm
> > not convinced this code does anything meaningful at all.  It passes
> > the name of a struct stdio_dev device which serial_assign() then tries
> > to match against the registered struct serial_devices, which will
> > never match.
> > 
> > What I don't understand is the case where you have a board that
> > actually has more than one physical serial port and how the mapping
> > from stdio_dev to serial_device happens.
> > 
> > Also, looking at the code to cmd_nvedit, I think your change also broke
> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX.  We
> > always have this on for tegra, so we don't go down this code path, but
> > it looks identical to the code in iomux.c
> 
> Sorry if I missed it - what was the resolution here? Should we revert
> that change?

Definitelly not. We should fix the iomux.c , possibly by flipping the inequation 
mark as a short term solution.

Best regards,
Marek Vasut
Allen Martin - Oct. 25, 2012, 8:48 p.m.
On Thu, Oct 25, 2012 at 12:03:47PM -0700, Marek Vasut wrote:
> Dear Simon Glass,
> 
> > Hi,
> > 
> > On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> wrote:
> > > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> > >> Dear Allen Martin,
> > >> 
> > >> [...]
> > >> 
> > >> > Hi Marek, the change to return value here broke serial output on
> > >> > tegra.  What I see is that the serial device name (s->name) is
> > >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the
> > >> > stdout environment is "serial" so they don't match and it fails.  This
> > >> > always used to be ok because the return code didn't indicate failure
> > >> > and iomux_doenv() would continue on happily, but now it causes
> > >> > iomux_doenv() to fail and no printfs() work after that.
> > >> > 
> > >> > Not sure what the right fix is, should stdout really be set to
> > >> > "eserial0"?  It seems "serial" should mean "the default serial device"
> > >> > which for the normal case is the one and only device.
> > >> 
> > >> Looking at the source, the obvious course of action is to fix iomux.c .
> > > 
> > > I've been looking at this call to serial_assign() from iomux.c and I'm
> > > not convinced this code does anything meaningful at all.  It passes
> > > the name of a struct stdio_dev device which serial_assign() then tries
> > > to match against the registered struct serial_devices, which will
> > > never match.
> > > 
> > > What I don't understand is the case where you have a board that
> > > actually has more than one physical serial port and how the mapping
> > > from stdio_dev to serial_device happens.
> > > 
> > > Also, looking at the code to cmd_nvedit, I think your change also broke
> > > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX.  We
> > > always have this on for tegra, so we don't go down this code path, but
> > > it looks identical to the code in iomux.c
> > 
> > Sorry if I missed it - what was the resolution here? Should we revert
> > that change?
> 
> Definitelly not. We should fix the iomux.c , possibly by flipping the inequation 
> mark as a short term solution.

Adding Joe Hershberger to cc

I think its safe to remove the call to serial_assign() altogether, as
it's written now it will always fail.  Reading through
doc/driver-model/UDM-serial.txt the CONFIG_SERIAL_MULTI case should be
handled transparently underneath iomux.  The part that still not clear
to me is what mechanism is supposed to be used to select the current
serial port in a CONFIG_SERIAL_MULTI configuration?  AFAICT the only
caller of serial_assign() that actually passes the name of a serial device
is in serial_initialize():

        serial_assign(default_serial_console()->name);

Should there be another environemnt variable that maps the stdio_dev
"serial" to the current serial_device so you could do something like:

; get input from first serial port and USB keyboard
# setenv serial eserial0
# setenv stdin serial,usbkbd

; get input from second serial port and USB keyboard
# setenv serial eserial1
# setenv stdin seriak,usbkbd


-Allen
Simon Glass - Oct. 25, 2012, 9:02 p.m.
Hi,

On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Simon Glass,
>
>> Hi,
>>
>> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> wrote:
>> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
>> >> Dear Allen Martin,
>> >>
>> >> [...]
>> >>
>> >> > Hi Marek, the change to return value here broke serial output on
>> >> > tegra.  What I see is that the serial device name (s->name) is
>> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the
>> >> > stdout environment is "serial" so they don't match and it fails.  This
>> >> > always used to be ok because the return code didn't indicate failure
>> >> > and iomux_doenv() would continue on happily, but now it causes
>> >> > iomux_doenv() to fail and no printfs() work after that.
>> >> >
>> >> > Not sure what the right fix is, should stdout really be set to
>> >> > "eserial0"?  It seems "serial" should mean "the default serial device"
>> >> > which for the normal case is the one and only device.
>> >>
>> >> Looking at the source, the obvious course of action is to fix iomux.c .
>> >
>> > I've been looking at this call to serial_assign() from iomux.c and I'm
>> > not convinced this code does anything meaningful at all.  It passes
>> > the name of a struct stdio_dev device which serial_assign() then tries
>> > to match against the registered struct serial_devices, which will
>> > never match.
>> >
>> > What I don't understand is the case where you have a board that
>> > actually has more than one physical serial port and how the mapping
>> > from stdio_dev to serial_device happens.
>> >
>> > Also, looking at the code to cmd_nvedit, I think your change also broke
>> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX.  We
>> > always have this on for tegra, so we don't go down this code path, but
>> > it looks identical to the code in iomux.c
>>
>> Sorry if I missed it - what was the resolution here? Should we revert
>> that change?
>
> Definitelly not. We should fix the iomux.c , possibly by flipping the inequation
> mark as a short term solution.

OK that's fine. Is someone working on a patch?

Regards,
Simon

>
> Best regards,
> Marek Vasut
Allen Martin - Oct. 25, 2012, 9:19 p.m.
On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
> Hi,
> 
> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Simon Glass,
> >
> >> Hi,
> >>
> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> wrote:
> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> >> >> Dear Allen Martin,
> >> >>
> >> >> [...]
> >> >>
> >> >> > Hi Marek, the change to return value here broke serial output on
> >> >> > tegra.  What I see is that the serial device name (s->name) is
> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the
> >> >> > stdout environment is "serial" so they don't match and it fails.  This
> >> >> > always used to be ok because the return code didn't indicate failure
> >> >> > and iomux_doenv() would continue on happily, but now it causes
> >> >> > iomux_doenv() to fail and no printfs() work after that.
> >> >> >
> >> >> > Not sure what the right fix is, should stdout really be set to
> >> >> > "eserial0"?  It seems "serial" should mean "the default serial device"
> >> >> > which for the normal case is the one and only device.
> >> >>
> >> >> Looking at the source, the obvious course of action is to fix iomux.c .
> >> >
> >> > I've been looking at this call to serial_assign() from iomux.c and I'm
> >> > not convinced this code does anything meaningful at all.  It passes
> >> > the name of a struct stdio_dev device which serial_assign() then tries
> >> > to match against the registered struct serial_devices, which will
> >> > never match.
> >> >
> >> > What I don't understand is the case where you have a board that
> >> > actually has more than one physical serial port and how the mapping
> >> > from stdio_dev to serial_device happens.
> >> >
> >> > Also, looking at the code to cmd_nvedit, I think your change also broke
> >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX.  We
> >> > always have this on for tegra, so we don't go down this code path, but
> >> > it looks identical to the code in iomux.c
> >>
> >> Sorry if I missed it - what was the resolution here? Should we revert
> >> that change?
> >
> > Definitelly not. We should fix the iomux.c , possibly by flipping the inequation
> > mark as a short term solution.
> 
> OK that's fine. Is someone working on a patch?
> 

I'll send out my proposal for a patch.  Unfortunately I don't have a
board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI

-Allen
Tom Rini - Oct. 25, 2012, 9:27 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/25/12 14:19, Allen Martin wrote:
> On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
>> Hi,
>> 
>> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> 
>> wrote:
>>> Dear Simon Glass,
>>> 
>>>> Hi,
>>>> 
>>>> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin 
>>>> <amartin@nvidia.com> wrote:
>>>>> On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut 
>>>>> wrote:
>>>>>> Dear Allen Martin,
>>>>>> 
>>>>>> [...]
>>>>>> 
>>>>>>> Hi Marek, the change to return value here broke serial
>>>>>>>  output on tegra.  What I see is that the serial device
>>>>>>>  name (s->name) is "eserial0" as set by 
>>>>>>> serial_ns16550.c, and the name passed in from the 
>>>>>>> stdout environment is "serial" so they don't match and
>>>>>>>  it fails.  This always used to be ok because the 
>>>>>>> return code didn't indicate failure and iomux_doenv() 
>>>>>>> would continue on happily, but now it causes 
>>>>>>> iomux_doenv() to fail and no printfs() work after 
>>>>>>> that.
>>>>>>> 
>>>>>>> Not sure what the right fix is, should stdout really be
>>>>>>> set to "eserial0"?  It seems "serial" should mean "the
>>>>>>> default serial device" which for the normal case is the
>>>>>>> one and only device.
>>>>>> 
>>>>>> Looking at the source, the obvious course of action is to
>>>>>> fix iomux.c .
>>>>> 
>>>>> I've been looking at this call to serial_assign() from 
>>>>> iomux.c and I'm not convinced this code does anything 
>>>>> meaningful at all.  It passes the name of a struct 
>>>>> stdio_dev device which serial_assign() then tries to match
>>>>>  against the registered struct serial_devices, which will 
>>>>> never match.
>>>>> 
>>>>> What I don't understand is the case where you have a board
>>>>>  that actually has more than one physical serial port and 
>>>>> how the mapping from stdio_dev to serial_device happens.
>>>>> 
>>>>> Also, looking at the code to cmd_nvedit, I think your 
>>>>> change also broke "setenv stdout" for boards that don't 
>>>>> define CONFIG_CONSOLE_MUX.  We always have this on for 
>>>>> tegra, so we don't go down this code path, but it looks 
>>>>> identical to the code in iomux.c
>>>> 
>>>> Sorry if I missed it - what was the resolution here? Should 
>>>> we revert that change?
>>> 
>>> Definitelly not. We should fix the iomux.c , possibly by 
>>> flipping the inequation mark as a short term solution.
>> 
>> OK that's fine. Is someone working on a patch?
>> 
> 
> I'll send out my proposal for a patch.  Unfortunately I don't have
>  a board with multiple serial ports to correctly test 
> CONFIG_SERIAL_MULTI

Andrew's recent set of patches for am335x means I do.  If I follow
correctly, you're describing the case where >1 port for a driver is
known, we default to say 0 but want to use 1, via the env?

- -- 
Tom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQia68AAoJENk4IS6UOR1W4NYP/jlbMsXtRojPz7FOVdVSUV+K
OK3Pgzc0RD1LMREnHJGRrH42Y5k9s2op0eex/yRLGVjpdyQuM8MykvJ944pDihwX
+0Rw8z3oNDg1IeB3R2cgwVCH5vBRGARxr/WdvCQc51uaMDZLwwWM3smHfTvDEeeJ
bYIUH9JrAjkpq7DBYCSTq9FR91iJ7hMbLaJjULQaG4Fo64ZBG9A4Llf6+hotADEd
3rHrQN8mJNuYiUYmdbP3B94NNp9+hWXb6r10I8vj2Bb331tBqCHGPOWF4U2h9D2j
AHofm8hj22SDTiXNR4SRfGSjqWqc8ZrocaoKxjBTnvlqxgN9+o/w+JNogCJcJ07y
zNn73DdxiztgDvoRzWz7oYiI2jF5KGAXVjPRTkY6P5v8Ybh8QF+/CX3NaHjlO7GX
VvK3s9AOMqyVz69EZX0OVnaL47WEaz21cG3pA2u595/5kNKrrEbUDEc6tNzLg+vy
5ah1P/g1kqNmKIgN4UtYSKCjCRA4vC5gHs4ixqhPw31aI54YnkbMq/y0SVhvd7Fk
iBpsojMQnuHPwRNLtfffqKtkcSMuTxrk2U90KXMg9DSm3cOqPXZgFwfaZH8GXUAV
W0Oo7QKpzgoEY4Qm0TjME2/BA/xGh7fBqiu3SAQuE89+w9rGEpQamCkuFFEKYKRt
YjHt4C0QHEjwb4kqkINx
=D41e
-----END PGP SIGNATURE-----
Allen Martin - Oct. 25, 2012, 9:31 p.m.
On Thu, Oct 25, 2012 at 02:27:24PM -0700, Tom Rini wrote:
> * PGP Signed by an unknown key
> 
> On 10/25/12 14:19, Allen Martin wrote:
> > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
> >> Hi,
> >> 
> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> 
> >> wrote:
> >>> Dear Simon Glass,
> >>> 
> >>>> Hi,
> >>>> 
> >>>> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin 
> >>>> <amartin@nvidia.com> wrote:
> >>>>> On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut 
> >>>>> wrote:
> >>>>>> Dear Allen Martin,
> >>>>>> 
> >>>>>> [...]
> >>>>>> 
> >>>>>>> Hi Marek, the change to return value here broke serial
> >>>>>>>  output on tegra.  What I see is that the serial device
> >>>>>>>  name (s->name) is "eserial0" as set by 
> >>>>>>> serial_ns16550.c, and the name passed in from the 
> >>>>>>> stdout environment is "serial" so they don't match and
> >>>>>>>  it fails.  This always used to be ok because the 
> >>>>>>> return code didn't indicate failure and iomux_doenv() 
> >>>>>>> would continue on happily, but now it causes 
> >>>>>>> iomux_doenv() to fail and no printfs() work after 
> >>>>>>> that.
> >>>>>>> 
> >>>>>>> Not sure what the right fix is, should stdout really be
> >>>>>>> set to "eserial0"?  It seems "serial" should mean "the
> >>>>>>> default serial device" which for the normal case is the
> >>>>>>> one and only device.
> >>>>>> 
> >>>>>> Looking at the source, the obvious course of action is to
> >>>>>> fix iomux.c .
> >>>>> 
> >>>>> I've been looking at this call to serial_assign() from 
> >>>>> iomux.c and I'm not convinced this code does anything 
> >>>>> meaningful at all.  It passes the name of a struct 
> >>>>> stdio_dev device which serial_assign() then tries to match
> >>>>>  against the registered struct serial_devices, which will 
> >>>>> never match.
> >>>>> 
> >>>>> What I don't understand is the case where you have a board
> >>>>>  that actually has more than one physical serial port and 
> >>>>> how the mapping from stdio_dev to serial_device happens.
> >>>>> 
> >>>>> Also, looking at the code to cmd_nvedit, I think your 
> >>>>> change also broke "setenv stdout" for boards that don't 
> >>>>> define CONFIG_CONSOLE_MUX.  We always have this on for 
> >>>>> tegra, so we don't go down this code path, but it looks 
> >>>>> identical to the code in iomux.c
> >>>> 
> >>>> Sorry if I missed it - what was the resolution here? Should 
> >>>> we revert that change?
> >>> 
> >>> Definitelly not. We should fix the iomux.c , possibly by 
> >>> flipping the inequation mark as a short term solution.
> >> 
> >> OK that's fine. Is someone working on a patch?
> >> 
> > 
> > I'll send out my proposal for a patch.  Unfortunately I don't have
> >  a board with multiple serial ports to correctly test 
> > CONFIG_SERIAL_MULTI
> 
> Andrew's recent set of patches for am335x means I do.  If I follow
> correctly, you're describing the case where >1 port for a driver is
> known, we default to say 0 but want to use 1, via the env?

Yes, exactly.  I assume that's what the current calls to
serial_assign() were supposed to be doing, but weren't.

-Allen
Joe Hershberger - Oct. 25, 2012, 10:43 p.m.
Hi Allen,

On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amartin@nvidia.com> wrote:
> On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
>> Hi,
>>
>> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
>> > Dear Simon Glass,
>> >
>> >> Hi,
>> >>
>> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> wrote:
>> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
>> >> >> Dear Allen Martin,
>> >> >>
>> >> >> [...]
>> >> >>
>> >> >> > Hi Marek, the change to return value here broke serial output on
>> >> >> > tegra.  What I see is that the serial device name (s->name) is
>> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the
>> >> >> > stdout environment is "serial" so they don't match and it fails.  This
>> >> >> > always used to be ok because the return code didn't indicate failure
>> >> >> > and iomux_doenv() would continue on happily, but now it causes
>> >> >> > iomux_doenv() to fail and no printfs() work after that.
>> >> >> >
>> >> >> > Not sure what the right fix is, should stdout really be set to
>> >> >> > "eserial0"?  It seems "serial" should mean "the default serial device"
>> >> >> > which for the normal case is the one and only device.
>> >> >>
>> >> >> Looking at the source, the obvious course of action is to fix iomux.c .
>> >> >
>> >> > I've been looking at this call to serial_assign() from iomux.c and I'm
>> >> > not convinced this code does anything meaningful at all.  It passes
>> >> > the name of a struct stdio_dev device which serial_assign() then tries
>> >> > to match against the registered struct serial_devices, which will
>> >> > never match.
>> >> >
>> >> > What I don't understand is the case where you have a board that
>> >> > actually has more than one physical serial port and how the mapping
>> >> > from stdio_dev to serial_device happens.
>> >> >
>> >> > Also, looking at the code to cmd_nvedit, I think your change also broke
>> >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX.  We
>> >> > always have this on for tegra, so we don't go down this code path, but
>> >> > it looks identical to the code in iomux.c
>> >>
>> >> Sorry if I missed it - what was the resolution here? Should we revert
>> >> that change?
>> >
>> > Definitelly not. We should fix the iomux.c , possibly by flipping the inequation
>> > mark as a short term solution.
>>
>> OK that's fine. Is someone working on a patch?
>>
>
> I'll send out my proposal for a patch.  Unfortunately I don't have a
> board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI

One of the boards I'm working on does this (has more than one).  At
least before the serial rework from Marek, the stdout was either the
serial device directly (each serial device was added as a console
device as well) so the serial setting was redundant.  You could just
set them directly to the serial port (which is more flexible).

I had two patches (not sent to ML before Marek made them highly
conflicting) that take the opposite approach you were, since it
preserves the flexibility.  It removed the "serial" setting to each of
the std* variables and instead sets it to the default serial device.
I'll remake that patch on top of the new serial landscape sometime
soon.

-Joe
Marek Vasut - Oct. 26, 2012, 10:22 a.m.
Dear Joe Hershberger,

> Hi Allen,
> 
> On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amartin@nvidia.com> wrote:
> > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
> >> Hi,
> >> 
> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
> >> > Dear Simon Glass,
> >> > 
> >> >> Hi,
> >> >> 
> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> 
wrote:
> >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> >> >> >> Dear Allen Martin,
> >> >> >> 
> >> >> >> [...]
> >> >> >> 
> >> >> >> > Hi Marek, the change to return value here broke serial output on
> >> >> >> > tegra.  What I see is that the serial device name (s->name) is
> >> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in
> >> >> >> > from the stdout environment is "serial" so they don't match and
> >> >> >> > it fails.  This always used to be ok because the return code
> >> >> >> > didn't indicate failure and iomux_doenv() would continue on
> >> >> >> > happily, but now it causes iomux_doenv() to fail and no
> >> >> >> > printfs() work after that.
> >> >> >> > 
> >> >> >> > Not sure what the right fix is, should stdout really be set to
> >> >> >> > "eserial0"?  It seems "serial" should mean "the default serial
> >> >> >> > device" which for the normal case is the one and only device.
> >> >> >> 
> >> >> >> Looking at the source, the obvious course of action is to fix
> >> >> >> iomux.c .
> >> >> > 
> >> >> > I've been looking at this call to serial_assign() from iomux.c and
> >> >> > I'm not convinced this code does anything meaningful at all.  It
> >> >> > passes the name of a struct stdio_dev device which serial_assign()
> >> >> > then tries to match against the registered struct serial_devices,
> >> >> > which will never match.
> >> >> > 
> >> >> > What I don't understand is the case where you have a board that
> >> >> > actually has more than one physical serial port and how the mapping
> >> >> > from stdio_dev to serial_device happens.
> >> >> > 
> >> >> > Also, looking at the code to cmd_nvedit, I think your change also
> >> >> > broke "setenv stdout" for boards that don't define
> >> >> > CONFIG_CONSOLE_MUX.  We always have this on for tegra, so we don't
> >> >> > go down this code path, but it looks identical to the code in
> >> >> > iomux.c
> >> >> 
> >> >> Sorry if I missed it - what was the resolution here? Should we revert
> >> >> that change?
> >> > 
> >> > Definitelly not. We should fix the iomux.c , possibly by flipping the
> >> > inequation mark as a short term solution.
> >> 
> >> OK that's fine. Is someone working on a patch?
> > 
> > I'll send out my proposal for a patch.  Unfortunately I don't have a
> > board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI
> 
> One of the boards I'm working on does this (has more than one).  At
> least before the serial rework from Marek, the stdout was either the
> serial device directly (each serial device was added as a console
> device as well) so the serial setting was redundant.  You could just
> set them directly to the serial port (which is more flexible).
> 
> I had two patches (not sent to ML before Marek made them highly
> conflicting)

I know, he's such a bastard, always breaking stuff and interfering with other 
people's work !

> that take the opposite approach you were, since it
> preserves the flexibility.  It removed the "serial" setting to each of
> the std* variables and instead sets it to the default serial device.
> I'll remake that patch on top of the new serial landscape sometime
> soon.

Actually, I'd like to merge the serial stuff and stdio stuff into one. So 
"setenv stdX serial" would be replaced with "setenv stdX <serial_driver_name>". 
I think that's the approach to take. But it'd break many boards.

Best regards,
Marek Vasut
Allen Martin - Oct. 26, 2012, 5:34 p.m.
On Fri, Oct 26, 2012 at 03:22:32AM -0700, Marek Vasut wrote:
> Dear Joe Hershberger,
> 
> > Hi Allen,
> > 
> > On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amartin@nvidia.com> wrote:
> > > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
> > >> Hi,
> > >> 
> > >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
> > >> > Dear Simon Glass,
> > >> > 
> > >> >> Hi,
> > >> >> 
> > >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com> 
> wrote:
> > >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> > >> >> >> Dear Allen Martin,
> > >> >> >> 
> > >> >> >> [...]
> > >> >> >> 
> > >> >> >> > Hi Marek, the change to return value here broke serial output on
> > >> >> >> > tegra.  What I see is that the serial device name (s->name) is
> > >> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in
> > >> >> >> > from the stdout environment is "serial" so they don't match and
> > >> >> >> > it fails.  This always used to be ok because the return code
> > >> >> >> > didn't indicate failure and iomux_doenv() would continue on
> > >> >> >> > happily, but now it causes iomux_doenv() to fail and no
> > >> >> >> > printfs() work after that.
> > >> >> >> > 
> > >> >> >> > Not sure what the right fix is, should stdout really be set to
> > >> >> >> > "eserial0"?  It seems "serial" should mean "the default serial
> > >> >> >> > device" which for the normal case is the one and only device.
> > >> >> >> 
> > >> >> >> Looking at the source, the obvious course of action is to fix
> > >> >> >> iomux.c .
> > >> >> > 
> > >> >> > I've been looking at this call to serial_assign() from iomux.c and
> > >> >> > I'm not convinced this code does anything meaningful at all.  It
> > >> >> > passes the name of a struct stdio_dev device which serial_assign()
> > >> >> > then tries to match against the registered struct serial_devices,
> > >> >> > which will never match.
> > >> >> > 
> > >> >> > What I don't understand is the case where you have a board that
> > >> >> > actually has more than one physical serial port and how the mapping
> > >> >> > from stdio_dev to serial_device happens.
> > >> >> > 
> > >> >> > Also, looking at the code to cmd_nvedit, I think your change also
> > >> >> > broke "setenv stdout" for boards that don't define
> > >> >> > CONFIG_CONSOLE_MUX.  We always have this on for tegra, so we don't
> > >> >> > go down this code path, but it looks identical to the code in
> > >> >> > iomux.c
> > >> >> 
> > >> >> Sorry if I missed it - what was the resolution here? Should we revert
> > >> >> that change?
> > >> > 
> > >> > Definitelly not. We should fix the iomux.c , possibly by flipping the
> > >> > inequation mark as a short term solution.
> > >> 
> > >> OK that's fine. Is someone working on a patch?
> > > 
> > > I'll send out my proposal for a patch.  Unfortunately I don't have a
> > > board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI
> > 
> > One of the boards I'm working on does this (has more than one).  At
> > least before the serial rework from Marek, the stdout was either the
> > serial device directly (each serial device was added as a console
> > device as well) so the serial setting was redundant.  You could just
> > set them directly to the serial port (which is more flexible).
> > 
> > I had two patches (not sent to ML before Marek made them highly
> > conflicting)
> 
> I know, he's such a bastard, always breaking stuff and interfering with other 
> people's work !
> 
> > that take the opposite approach you were, since it
> > preserves the flexibility.  It removed the "serial" setting to each of
> > the std* variables and instead sets it to the default serial device.
> > I'll remake that patch on top of the new serial landscape sometime
> > soon.
> 
> Actually, I'd like to merge the serial stuff and stdio stuff into one. So 
> "setenv stdX serial" would be replaced with "setenv stdX <serial_driver_name>". 
> I think that's the approach to take. But it'd break many boards.

I think that would be fine if we can also preserve "setenv stdin
serial" to use the default serial device.  That will mean no changes
for boards that have only one serial port, which is the vast majority.

-Allen
Joe Hershberger - Oct. 26, 2012, 6:39 p.m.
Hi Marek,

On Fri, Oct 26, 2012 at 5:22 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Joe Hershberger,
>
>> Hi Allen,
>>
>> On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amartin@nvidia.com> wrote:
>> > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
>> >> Hi,
>> >>
>> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
>> >> > Dear Simon Glass,
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com>
> wrote:
>> >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
>> >> >> >> Dear Allen Martin,
>> >> >> >>
>> >> >> >> [...]
>> >> >> >>
>> >> >> >> > Hi Marek, the change to return value here broke serial output on
>> >> >> >> > tegra.  What I see is that the serial device name (s->name) is
>> >> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in
>> >> >> >> > from the stdout environment is "serial" so they don't match and
>> >> >> >> > it fails.  This always used to be ok because the return code
>> >> >> >> > didn't indicate failure and iomux_doenv() would continue on
>> >> >> >> > happily, but now it causes iomux_doenv() to fail and no
>> >> >> >> > printfs() work after that.
>> >> >> >> >
>> >> >> >> > Not sure what the right fix is, should stdout really be set to
>> >> >> >> > "eserial0"?  It seems "serial" should mean "the default serial
>> >> >> >> > device" which for the normal case is the one and only device.
>> >> >> >>
>> >> >> >> Looking at the source, the obvious course of action is to fix
>> >> >> >> iomux.c .
>> >> >> >
>> >> >> > I've been looking at this call to serial_assign() from iomux.c and
>> >> >> > I'm not convinced this code does anything meaningful at all.  It
>> >> >> > passes the name of a struct stdio_dev device which serial_assign()
>> >> >> > then tries to match against the registered struct serial_devices,
>> >> >> > which will never match.
>> >> >> >
>> >> >> > What I don't understand is the case where you have a board that
>> >> >> > actually has more than one physical serial port and how the mapping
>> >> >> > from stdio_dev to serial_device happens.
>> >> >> >
>> >> >> > Also, looking at the code to cmd_nvedit, I think your change also
>> >> >> > broke "setenv stdout" for boards that don't define
>> >> >> > CONFIG_CONSOLE_MUX.  We always have this on for tegra, so we don't
>> >> >> > go down this code path, but it looks identical to the code in
>> >> >> > iomux.c
>> >> >>
>> >> >> Sorry if I missed it - what was the resolution here? Should we revert
>> >> >> that change?
>> >> >
>> >> > Definitelly not. We should fix the iomux.c , possibly by flipping the
>> >> > inequation mark as a short term solution.
>> >>
>> >> OK that's fine. Is someone working on a patch?
>> >
>> > I'll send out my proposal for a patch.  Unfortunately I don't have a
>> > board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI
>>
>> One of the boards I'm working on does this (has more than one).  At
>> least before the serial rework from Marek, the stdout was either the
>> serial device directly (each serial device was added as a console
>> device as well) so the serial setting was redundant.  You could just
>> set them directly to the serial port (which is more flexible).
>>
>> I had two patches (not sent to ML before Marek made them highly
>> conflicting)
>
> I know, he's such a bastard, always breaking stuff and interfering with other
> people's work !

:)

>> that take the opposite approach you were, since it
>> preserves the flexibility.  It removed the "serial" setting to each of
>> the std* variables and instead sets it to the default serial device.
>> I'll remake that patch on top of the new serial landscape sometime
>> soon.
>
> Actually, I'd like to merge the serial stuff and stdio stuff into one. So
> "setenv stdX serial" would be replaced with "setenv stdX <serial_driver_name>".
> I think that's the approach to take. But it'd break many boards.

I think that's fine.  We should be able to make it work both ways.  In
other words, as long as there is only one serial device registered,
then "serial" will be accepted.  The actual name of the driver is also
always accepted.

-Joe
Allen Martin - Oct. 26, 2012, 9:55 p.m.
On Fri, Oct 26, 2012 at 11:39:48AM -0700, Joe Hershberger wrote:
> Hi Marek,
> 
> On Fri, Oct 26, 2012 at 5:22 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Joe Hershberger,
> >
> >> Hi Allen,
> >>
> >> On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amartin@nvidia.com> wrote:
> >> > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
> >> >> Hi,
> >> >>
> >> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
> >> >> > Dear Simon Glass,
> >> >> >
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@nvidia.com>
> > wrote:
> >> >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> >> >> >> >> Dear Allen Martin,
> >> >> >> >>
> >> >> >> >> [...]
> >> >> >> >>
> >> >> >> >> > Hi Marek, the change to return value here broke serial output on
> >> >> >> >> > tegra.  What I see is that the serial device name (s->name) is
> >> >> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in
> >> >> >> >> > from the stdout environment is "serial" so they don't match and
> >> >> >> >> > it fails.  This always used to be ok because the return code
> >> >> >> >> > didn't indicate failure and iomux_doenv() would continue on
> >> >> >> >> > happily, but now it causes iomux_doenv() to fail and no
> >> >> >> >> > printfs() work after that.
> >> >> >> >> >
> >> >> >> >> > Not sure what the right fix is, should stdout really be set to
> >> >> >> >> > "eserial0"?  It seems "serial" should mean "the default serial
> >> >> >> >> > device" which for the normal case is the one and only device.
> >> >> >> >>
> >> >> >> >> Looking at the source, the obvious course of action is to fix
> >> >> >> >> iomux.c .
> >> >> >> >
> >> >> >> > I've been looking at this call to serial_assign() from iomux.c and
> >> >> >> > I'm not convinced this code does anything meaningful at all.  It
> >> >> >> > passes the name of a struct stdio_dev device which serial_assign()
> >> >> >> > then tries to match against the registered struct serial_devices,
> >> >> >> > which will never match.
> >> >> >> >
> >> >> >> > What I don't understand is the case where you have a board that
> >> >> >> > actually has more than one physical serial port and how the mapping
> >> >> >> > from stdio_dev to serial_device happens.
> >> >> >> >
> >> >> >> > Also, looking at the code to cmd_nvedit, I think your change also
> >> >> >> > broke "setenv stdout" for boards that don't define
> >> >> >> > CONFIG_CONSOLE_MUX.  We always have this on for tegra, so we don't
> >> >> >> > go down this code path, but it looks identical to the code in
> >> >> >> > iomux.c
> >> >> >>
> >> >> >> Sorry if I missed it - what was the resolution here? Should we revert
> >> >> >> that change?
> >> >> >
> >> >> > Definitelly not. We should fix the iomux.c , possibly by flipping the
> >> >> > inequation mark as a short term solution.
> >> >>
> >> >> OK that's fine. Is someone working on a patch?
> >> >
> >> > I'll send out my proposal for a patch.  Unfortunately I don't have a
> >> > board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI
> >>
> >> One of the boards I'm working on does this (has more than one).  At
> >> least before the serial rework from Marek, the stdout was either the
> >> serial device directly (each serial device was added as a console
> >> device as well) so the serial setting was redundant.  You could just
> >> set them directly to the serial port (which is more flexible).
> >>
> >> I had two patches (not sent to ML before Marek made them highly
> >> conflicting)
> >
> > I know, he's such a bastard, always breaking stuff and interfering with other
> > people's work !
> 
> :)
> 
> >> that take the opposite approach you were, since it
> >> preserves the flexibility.  It removed the "serial" setting to each of
> >> the std* variables and instead sets it to the default serial device.
> >> I'll remake that patch on top of the new serial landscape sometime
> >> soon.
> >
> > Actually, I'd like to merge the serial stuff and stdio stuff into one. So
> > "setenv stdX serial" would be replaced with "setenv stdX <serial_driver_name>".
> > I think that's the approach to take. But it'd break many boards.
> 
> I think that's fine.  We should be able to make it work both ways.  In
> other words, as long as there is only one serial device registered,
> then "serial" will be accepted.  The actual name of the driver is also
> always accepted.

Or, ever better we could just say "serial" always maps to
default_serial_console() and that should map exactly to existing
functionality regardless if there is one or more serial devices.  Then
any board that wants more precise control can use the name of the
serial driver instead.

-Allen
Marek Vasut - Oct. 27, 2012, 12:39 p.m.
Dear Allen Martin,

> On Fri, Oct 26, 2012 at 11:39:48AM -0700, Joe Hershberger wrote:
> > Hi Marek,
> > 
> > On Fri, Oct 26, 2012 at 5:22 AM, Marek Vasut <marex@denx.de> wrote:
> > > Dear Joe Hershberger,
> > > 
> > >> Hi Allen,
> > >> 
> > >> On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amartin@nvidia.com> wrote:
> > >> > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote:
> > >> >> Hi,
> > >> >> 
> > >> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut <marex@denx.de> wrote:
> > >> >> > Dear Simon Glass,
> > >> >> > 
> > >> >> >> Hi,
> > >> >> >> 
> > >> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin
> > >> >> >> <amartin@nvidia.com>
> > > 
> > > wrote:
> > >> >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote:
> > >> >> >> >> Dear Allen Martin,
> > >> >> >> >> 
> > >> >> >> >> [...]
> > >> >> >> >> 
> > >> >> >> >> > Hi Marek, the change to return value here broke serial
> > >> >> >> >> > output on tegra.  What I see is that the serial device
> > >> >> >> >> > name (s->name) is "eserial0" as set by serial_ns16550.c,
> > >> >> >> >> > and the name passed in from the stdout environment is
> > >> >> >> >> > "serial" so they don't match and it fails.  This always
> > >> >> >> >> > used to be ok because the return code didn't indicate
> > >> >> >> >> > failure and iomux_doenv() would continue on happily, but
> > >> >> >> >> > now it causes iomux_doenv() to fail and no printfs() work
> > >> >> >> >> > after that.
> > >> >> >> >> > 
> > >> >> >> >> > Not sure what the right fix is, should stdout really be set
> > >> >> >> >> > to "eserial0"?  It seems "serial" should mean "the default
> > >> >> >> >> > serial device" which for the normal case is the one and
> > >> >> >> >> > only device.
> > >> >> >> >> 
> > >> >> >> >> Looking at the source, the obvious course of action is to fix
> > >> >> >> >> iomux.c .
> > >> >> >> > 
> > >> >> >> > I've been looking at this call to serial_assign() from iomux.c
> > >> >> >> > and I'm not convinced this code does anything meaningful at
> > >> >> >> > all.  It passes the name of a struct stdio_dev device which
> > >> >> >> > serial_assign() then tries to match against the registered
> > >> >> >> > struct serial_devices, which will never match.
> > >> >> >> > 
> > >> >> >> > What I don't understand is the case where you have a board
> > >> >> >> > that actually has more than one physical serial port and how
> > >> >> >> > the mapping from stdio_dev to serial_device happens.
> > >> >> >> > 
> > >> >> >> > Also, looking at the code to cmd_nvedit, I think your change
> > >> >> >> > also broke "setenv stdout" for boards that don't define
> > >> >> >> > CONFIG_CONSOLE_MUX.  We always have this on for tegra, so we
> > >> >> >> > don't go down this code path, but it looks identical to the
> > >> >> >> > code in iomux.c
> > >> >> >> 
> > >> >> >> Sorry if I missed it - what was the resolution here? Should we
> > >> >> >> revert that change?
> > >> >> > 
> > >> >> > Definitelly not. We should fix the iomux.c , possibly by flipping
> > >> >> > the inequation mark as a short term solution.
> > >> >> 
> > >> >> OK that's fine. Is someone working on a patch?
> > >> > 
> > >> > I'll send out my proposal for a patch.  Unfortunately I don't have a
> > >> > board with multiple serial ports to correctly test
> > >> > CONFIG_SERIAL_MULTI
> > >> 
> > >> One of the boards I'm working on does this (has more than one).  At
> > >> least before the serial rework from Marek, the stdout was either the
> > >> serial device directly (each serial device was added as a console
> > >> device as well) so the serial setting was redundant.  You could just
> > >> set them directly to the serial port (which is more flexible).
> > >> 
> > >> I had two patches (not sent to ML before Marek made them highly
> > >> conflicting)
> > > 
> > > I know, he's such a bastard, always breaking stuff and interfering with
> > > other people's work !
> > :
> > :)
> > :
> > >> that take the opposite approach you were, since it
> > >> preserves the flexibility.  It removed the "serial" setting to each of
> > >> the std* variables and instead sets it to the default serial device.
> > >> I'll remake that patch on top of the new serial landscape sometime
> > >> soon.
> > > 
> > > Actually, I'd like to merge the serial stuff and stdio stuff into one.
> > > So "setenv stdX serial" would be replaced with "setenv stdX
> > > <serial_driver_name>". I think that's the approach to take. But it'd
> > > break many boards.
> > 
> > I think that's fine.  We should be able to make it work both ways.  In
> > other words, as long as there is only one serial device registered,
> > then "serial" will be accepted.  The actual name of the driver is also
> > always accepted.
> 
> Or, ever better we could just say "serial" always maps to
> default_serial_console() and that should map exactly to existing
> functionality regardless if there is one or more serial devices.  Then
> any board that wants more precise control can use the name of the
> serial driver instead.

So default_serial_console() will return a char * instead of driver pointer ... 
good.

Best regards,
Marek Vasut

Patch

diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index da41cd5..1054494 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -26,6 +26,7 @@ 
 #include <stdio_dev.h>
 #include <post.h>
 #include <linux/compiler.h>
+#include <errno.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -203,13 +204,13 @@  int serial_assign(const char *name)
 	struct serial_device *s;
 
 	for (s = serial_devices; s; s = s->next) {
-		if (strcmp(s->name, name) == 0) {
-			serial_current = s;
-			return 0;
-		}
+		if (strcmp(s->name, name))
+			continue;
+		serial_current = s;
+		return 0;
 	}
 
-	return 1;
+	return -EINVAL;
 }
 
 void serial_reinit_all(void)