linux-kernel - Re: Nonterministic hang during bootconsole/console handover on ath79

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56F53626.1040507@openwrt.org>
Date:	Fri, 25 Mar 2016 13:59:18 +0100
From:	Gabor Juhos <juhosg@...nwrt.org>
To:	Peter Hurley <peter@...leysoftware.com>,
	Matthias Schiffer <mschiffer@...verse-factory.net>
Cc:	Ralf Baechle <ralf@...ux-mips.org>, gregkh@...uxfoundation.org,
	jslaby@...e.com, linux-mips@...ux-mips.org,
	linux-serial@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Nonterministic hang during bootconsole/console handover on ath79

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.

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

ar7100> md.l 0xb802001c 1
b802001c: 00000000    ....
ar7100> mw.l 0xb802001c a5
ar7100> md.l 0xb802001c 1
b802001c: 000000a5    ....
ar7100> mw.l 0xb802001c 5a
ar7100> md.l 0xb802001c 1
b802001c: 0000005a    ...Z
ar7100>

The same test is on the TL-WR842ND v1 board (AR7241 SoC):

ar7240> md.l b802001c 1
b802001c: 00000000    ....
ar7240> mw.l b802001c a5
ar7240> md.l b802001c 1
b802001c: 000000a5    ....
ar7240> mw.l b802001c 5a
ar7240> md.l b802001c 1
b802001c: 0000005a    ...Z
ar7240>

And on the TL-WR841N v8 board (AR9341 Soc):

wasp> md.l b802001c 1
b802001c: 00000000    ....
wasp> mw.l b802001c a5
wasp> md.l b802001c 1
b802001c: 000000a5    ....
wasp> mw.l b802001c 5a
wasp> md.l b802001c 1
b802001c: 0000005a    ...Z
wasp>

Although i did not test it on other SoCs, but i assume that the behaviour is the
same on those.

-Gabor