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

From: Allen Martin <amartin@nvidia.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Date: Thu, 25 Oct 2012 14:31:26 -0700	[thread overview]
Message-ID: <20121025213126.GC12183@badger> (raw)
In-Reply-To: <5089AEBC.7070103@ti.com>

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