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

[Allen Martin]

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

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