linux-kernel - Re: [SPCR] mmio32 iotype access requirements for X-Gene 8250(

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: <c6a0c134-2fde-21c2-03fb-6e1961161a26@redhat.com>
Date:   Sat, 3 Dec 2016 15:33:15 -0500
From:   Jon Masters <jcm@...hat.com>
To:     Mark Salter <msalter@...hat.com>, Duc Dang <dhdang@....com>
Cc:     Rafael Wysocki <rafael@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        linux-arm <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        patches <patches@....com>,
        Aleksey Makarov <aleksey.makarov@...aro.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Grant Likely <grant.likely@....com>
Subject: Re: [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw)
 UART

Hi Mark,

On 12/03/2016 12:15 PM, Mark Salter wrote:
> On Sat, 2016-12-03 at 05:06 -0500, Jon Masters wrote:

>> There is a broader problem with X-Gene SPCR support. The problem is
>> that the 16550 UART in X-Gene requires the 32-bit access quirk (the
>> iotype is set to UPIO_MEM32 for the APMC0D08 device). This means
>> that when univ8250_console_match runs later, it will compare the
>> iotype (MEM32) with the type previously registered with the
>> kernel when the earlycon setup the preferred console.
> 
> Linaro has a kernel patch which looks at the bit_width field of the
> port address:
> 
> Author: Aleksey Makarov <aleksey.makarov@...aro.org>
> Date:   Thu Apr 28 19:52:38 2016 +0300
> 
>     serial: SPCR: check bit width for the 16550 UART
> 
> The SPCR in 3.06.25 firmware has a bit_width field set to 32 and with the
> above patch, I don't need to use console=. But HP firmware on m400 sets
> bit width to 8 so that needs a firmware fix to work with above.

Indeed, thanks. Graeme also mentioned that last night. I think this
a good solution for the moment, but still that it makes sense to
have a new 16650 UART type defined in the DBG2 spec for those
requiring 32-bit access (to mirror the type D for pl011). I
heard back from Microsoft this morning that they're looking.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop