Re: Nonterministic hang during bootconsole/console handover on ath79

[Peter Hurley <peter@hurleysoftware.com>]

Hi Gabor,

On 03/25/2016 05:59 AM, Gabor Juhos wrote:
> 2016.03.24. 4:17 keltezéssel, Peter Hurley írta:
>> On 03/23/2016 07:09 PM, Matthias Schiffer wrote:
>>>>> autoconfig_16550a() is doing all kinds of weird checks to detect different
>>>>> hardware by writing a lot of register values which are documented as
>>>>> reserved in the AR7242 datasheet (there's a leaked version going around
>>>>> that can be easily googled...), no idea if any of those are problematic.
>>>>> Just setting UPF_FIXED_TYPE as suggested by Peter would avoid that code
>>>>> altogether.
>>>>
>>>> That's just a debugging patch and not appropriate for permanent use,
>>>> the reason being that this uart is _not_ 16550 compatible (or even 16450
>>>> compatible).
>>>>
>>>> The three options for 8250 driver support for this part are:
>>>> 1. Similar to the debugging patch, set UPF_FIXED_TYPE but set port type
>>>>    to PORT_8250 instead. This will lose FIFO support so 115K won't be
>>>>    possible and likely neither will 38400.
>>>>
>>>> 2. Set UPF_FIXED_TYPE but define a new PORT_* value and add support for
>>>>    this PORT_* value to uart_config array, uapi headers, and anywhere
>>>>    the scratch register is used.
>>>>
>>>> 3. As with 2. above but don't set UPF_FIXED_TYPE and add a probe function
>>>>    that detects ports of this type to autoconfig(). I don't recommend this
>>>>    method.
>>>>
>>>> This requirement is independent of fixing prom_putchar_ar71xx().
>>>>
>>>
>>> I can send patches for all of this, and I think that 2. would be the nicest
>>> solution. I've noticed though that include/uapi/linux/serial_core.h is
>>> experiencing a little "overflow": PORT_MAX_8250 has grown just below the
>>> first non-8250 entry.
>>
>> Ugh. Thanks for noting this.
>>
>>> Should I just add the new entry at the bottom (and
>>> thus grow the uart_config array by ~85 unused entries)? What about
>>> PORT_MAX_8250 (used at least in drivers/tty/serial/8250/8250_of.c)?
>>
>> None of the above, unfortunately. Ok, plan B.
>>
>> I need to clean off a dusty series that adds probe steering and
>> bugs pass-thru for 8250 sub-drivers and platform data. Then add a
>> UART_BUG_NOSCR to indicate a uart does not have a scratch register
>> (like this one). Then for this uart, set UPF_FIXED_TYPE and type to
>> PORT_16550A, with UART_BUG_NOSCR flag.
> 
> Introducing the UART_BUG_NOSCR flag for this UART is pointless in my opinion,
> because it does have a scratch register in fact. Even if it is not listed in the
> datasheet of the SoCs, it exists.

Ok, then the part(s) should be compatible enough with the 8250 driver as it is.
If boot hang problem persists on these parts, then the autoconfig() probes may
still be a problem, and my debugging patch from earlier can be used to skirt
autoconfig().


> I have tested that from the bootloader on the Netgear WNDR3700 board which uses
> the AR7161 SoC:

Thanks for testing.

Regards,
Peter Hurley