From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Date: Thu, 25 Oct 2012 21:03:47 +0200 [thread overview]
Message-ID: <201210252103.47233.marex@denx.de> (raw)
In-Reply-To: <CAPnjgZ3nWGj8u8JcbCKbA_+sK1V_b+GvYUsRCu4-XcombPJVcQ@mail.gmail.com>
Dear Simon Glass,
> Hi,
>
> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin <amartin@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.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-10-25 19:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-07 0:07 [U-Boot] [PATCH 0/6] Serial cleanup series Marek Vasut
2012-10-07 0:07 ` [U-Boot] [PATCH 1/6] serial: Implement default_serial_puts() Marek Vasut
2012-10-17 14:59 ` [U-Boot] [U-Boot,1/6] " Tom Rini
2012-10-07 0:07 ` [U-Boot] [PATCH 2/6] serial: Use default_serial_puts() in drivers Marek Vasut
2012-10-07 0:07 ` [U-Boot] [PATCH 3/6] serial: Reorder serial_assign() Marek Vasut
2012-10-20 0:45 ` Allen Martin
2012-10-20 8:19 ` Marek Vasut
2012-10-22 17:23 ` Allen Martin
2012-10-25 18:09 ` Simon Glass
2012-10-25 19:03 ` Marek Vasut [this message]
2012-10-25 20:48 ` Allen Martin
2012-10-25 21:02 ` Simon Glass
2012-10-25 21:19 ` Allen Martin
2012-10-25 21:27 ` Tom Rini
2012-10-25 21:31 ` Allen Martin
2012-10-25 22:43 ` Joe Hershberger
2012-10-26 10:22 ` Marek Vasut
2012-10-26 17:34 ` Allen Martin
2012-10-26 18:39 ` Joe Hershberger
2012-10-26 21:55 ` Allen Martin
2012-10-27 12:39 ` Marek Vasut
2012-10-07 0:07 ` [U-Boot] [PATCH 4/6] serial: Reorder get_current() Marek Vasut
2012-10-07 0:07 ` [U-Boot] [PATCH 5/6] kerneldoc: Annotate drivers/serial/serial.c Marek Vasut
2012-10-08 19:37 ` Tom Rini
2012-10-08 22:56 ` Tom Rini
2012-10-08 23:26 ` Marek Vasut
2012-10-08 20:58 ` [U-Boot] [PATCH 5/6 V2] " Marek Vasut
2012-10-08 21:36 ` [U-Boot] [PATCH 5/6 V3] " Marek Vasut
2012-10-07 0:07 ` [U-Boot] [PATCH 6/6] kerneldoc: stdio: tmpl: Add stdio template Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201210252103.47233.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox