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]

Date:	Wed, 23 Mar 2016 20:17:07 -0700
From:	Peter Hurley <peter@...leysoftware.com>
To:	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

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.

Couple of days because I'm in the middle of something else, ok?

Regards,
Peter Hurley