From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 6 Nov 2012 01:47:33 +0100 Subject: [U-Boot] [PATCH 2/2] serial: Make nulldev a serial device In-Reply-To: References: <1351806388-27322-1-git-send-email-joe.hershberger@ni.com> <201211060010.22694.marex@denx.de> Message-ID: <201211060147.33342.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Joe Hershberger, > Hi Marek. > > On Mon, Nov 5, 2012 at 5:10 PM, Marek Vasut wrote: > > Dear Joe Hershberger, > > > >> Hi Marek, > >> > >> On Fri, Nov 2, 2012 at 8:37 PM, Marek Vasut 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 > >> > > >> > 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; Best regards, Marek Vasut