[U-Boot] [PATCH 3/6] serial: Reorder serial_assign()

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/25/12 14:19, 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 <marex@denx.de> 
>> wrote:
>>> 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.
>> 
>> 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

Andrew's recent set of patches for am335x means I do.  If I follow
correctly, you're describing the case where >1 port for a driver is
known, we default to say 0 but want to use 1, via the env?

- -- 
Tom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQia68AAoJENk4IS6UOR1W4NYP/jlbMsXtRojPz7FOVdVSUV+K
OK3Pgzc0RD1LMREnHJGRrH42Y5k9s2op0eex/yRLGVjpdyQuM8MykvJ944pDihwX
+0Rw8z3oNDg1IeB3R2cgwVCH5vBRGARxr/WdvCQc51uaMDZLwwWM3smHfTvDEeeJ
bYIUH9JrAjkpq7DBYCSTq9FR91iJ7hMbLaJjULQaG4Fo64ZBG9A4Llf6+hotADEd
3rHrQN8mJNuYiUYmdbP3B94NNp9+hWXb6r10I8vj2Bb331tBqCHGPOWF4U2h9D2j
AHofm8hj22SDTiXNR4SRfGSjqWqc8ZrocaoKxjBTnvlqxgN9+o/w+JNogCJcJ07y
zNn73DdxiztgDvoRzWz7oYiI2jF5KGAXVjPRTkY6P5v8Ybh8QF+/CX3NaHjlO7GX
VvK3s9AOMqyVz69EZX0OVnaL47WEaz21cG3pA2u595/5kNKrrEbUDEc6tNzLg+vy
5ah1P/g1kqNmKIgN4UtYSKCjCRA4vC5gHs4ixqhPw31aI54YnkbMq/y0SVhvd7Fk
iBpsojMQnuHPwRNLtfffqKtkcSMuTxrk2U90KXMg9DSm3cOqPXZgFwfaZH8GXUAV
W0Oo7QKpzgoEY4Qm0TjME2/BA/xGh7fBqiu3SAQuE89+w9rGEpQamCkuFFEKYKRt
YjHt4C0QHEjwb4kqkINx
=D41e
-----END PGP SIGNATURE-----