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

[Allen Martin]

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

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