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  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:	Thu, 24 Mar 2016 03:09:37 +0100
From:	Matthias Schiffer <>
To:	Peter Hurley <>
Cc:	Ralf Baechle <>,,,,,
	"" <>
Subject: Re: Nonterministic hang during bootconsole/console handover on ath79

>> 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. 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)?


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists