[U-Boot] [PATCH 2/2] serial: Make nulldev a serial device

[Marek Vasut <marex@denx.de>]

Dear Joe Hershberger,

> Hi Marek,
> 
> On Mon, Nov 5, 2012 at 6:47 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Joe Hershberger,
> > 
> >> Hi Marek.
> >> 
> >> On Mon, Nov 5, 2012 at 5:10 PM, Marek Vasut <marex@denx.de> wrote:
> >> > Dear Joe Hershberger,
> >> > 
> >> >> Hi Marek,
> >> >> 
> >> >> On Fri, Nov 2, 2012 at 8:37 PM, Marek Vasut <marex@denx.de> wrote:
> >> >> > Dear Joe Hershberger,
> >> >> > 
> >> >> >> This allows the default console to be specified as the nulldev. 
> >> >> >> This is specifically helpful when the real serial console's
> >> >> >> init() cannot run early in the boot process.  When the init can
> >> >> >> be run, then the console can be switched to the real device using
> >> >> >> the std* env vars.
> >> >> >> 
> >> >> >> Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
> >> >> > 
> >> >> > Isn't it actually better to have null stdio device? Some systems
> >> >> > might not even use serial port (and so null serial will be useless
> >> >> > on these systems)!
> >> >> 
> >> >> As I described in my commit log, this is for the case where the
> >> >> serial and console init must not touch the hardware, (since it
> >> >> doesn't exist yet if it's in an FPGA or on a PCI or USB connection).
> >> >>  Making the default serial port be the nulldev avoids this issue.
> >> > 
> >> > So add nulldev serial device for this stupid case. Even though fixing
> >> > iomux such that it'd not send anything to serial port at all if
> >> > nulldev is selected would be even better idea.
> >> 
> >> It's not a problem of something being sent to the serial port.  It's
> >> the call to serial_init() in arch/*/lib/board.c that kills it.  That
> >> call needs to be no-op-able.
> > 
> > Why?
> > 
> > What about fixing serial_init like this:
> > 
> > struct serial_device *dev = get_current();
> > int ret = 0;
> > if (dev)
> > 
> >   ret = dev->start();
> > 
> > return ret;
> 
> How does this help?  Are you suggesting that default_serial_console()
> return "NULL"?  It seems that you would then have to add a ton of
> checks for NULL coming back from default_serial_console() all the
> places that just use it assuming it's actually a device pointer.
> Sounds ugly.  If you aren't talking about having
> default_serial_console() return NULL, then I don't see how this helps.

Well what will default_serial_console() return in your case? You said the 
serial_init() is the problematic spot.

Best regards,
Marek Vasut