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

[Allen Martin <amartin@nvidia.com>]

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