From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 26 Oct 2012 12:22:32 +0200 Subject: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign() In-Reply-To: References: <1349568426-27219-1-git-send-email-marex@denx.de> <20121025211944.GB12183@badger> Message-ID: <201210261222.32886.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 Allen, > > On Thu, Oct 25, 2012 at 4:19 PM, 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 wrote: > >> > Dear Simon Glass, > >> > > >> >> Hi, > >> >> > >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin 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 ". I think that's the approach to take. But it'd break many boards. Best regards, Marek Vasut