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

[Marek Vasut]

Dear Allen Martin,

> On Fri, Oct 26, 2012 at 11:39:48AM -0700, Joe Hershberger wrote:
> > Hi Marek,
> > 
> > On Fri, Oct 26, 2012 at 5:22 AM, Marek Vasut <marex at denx.de> 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's fine.  We should be able to make it work both ways.  In
> > other words, as long as there is only one serial device registered,
> > then "serial" will be accepted.  The actual name of the driver is also
> > always accepted.
> 
> Or, ever better we could just say "serial" always maps to
> default_serial_console() and that should map exactly to existing
> functionality regardless if there is one or more serial devices.  Then
> any board that wants more precise control can use the name of the
> serial driver instead.

So default_serial_console() will return a char * instead of driver pointer ... 
good.

Best regards,
Marek Vasut