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

[Marek Vasut]

Dear Joe Hershberger,

> Hi Allen,
> 
> On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin <amartin at 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 at denx.de> wrote:
> >> > Dear Simon Glass,
> >> > 
> >> >> Hi,
> >> >> 
> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin at 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