From mboxrd@z Thu Jan 1 00:00:00 1970 From: Allen Martin Date: Thu, 25 Oct 2012 14:19:44 -0700 Subject: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign() In-Reply-To: References: <1349568426-27219-1-git-send-email-marex@denx.de> <20121022172326.GA13201@badger> <201210252103.47233.marex@denx.de> Message-ID: <20121025211944.GB12183@badger> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 -Allen -- nvpublic