linux-kernel - Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

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, 14 Mar 2018 11:12:33 -0600
From:   Aaron Durbin <adurbin@...omium.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Daniel Kurtz <djkurtz@...omium.org>,
        Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>,
        Aaron Durbin <adurbin@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Marc Gonzalez <marc_gonzalez@...madesigns.com>,
        Doug Anderson <dianders@...omium.org>,
        Matt Redfearn <matt.redfearn@...s.com>,
        Jeffy <jeffy.chen@...k-chips.com>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD
 Carrizo / Stoneyridge

On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz <djkurtz@...omium.org> wrote:
>> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
>> ricardo.ribalda@...il.com> wrote:
>>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz <djkurtz@...omium.org>
>> wrote:
>
>> In fact, the recommended way is to have firmware specify an ACPI SPCR table
>> with OEMID="AMDCZ " (see https://patchwork.kernel.org/patch/10281307/) to
>> configure proper access and address.
>
> Hmm... I was thinking it's already there. And thus, this is just a
> quirk for *existing* firmware that doesn't correctly configured
> hardware.
> (Yes, I'm aware about one nuance in SPCR specification I'm trying to
> address via official ways)
>
>>  With an SPCR table in place,  the
>> kernel command line just becomes "earlycon", with no parameters.
>
> SPCR *provides* an address of UART (required by specification).

What is "it's" in your first sentence? The access method? Baud rate
can't be configured ever in the kernel w/o knowing the input clock to
the uart block. That's already been brought up, and it is inherently a
requirement to know that to recalculate the divisor. These patches are
doing early OOB binding to set the proper input clock because: 1. SPCR
doesn't have that information 2. you nak'd the generic way of
specifying the input clock on the command line. Sadly, this situation
is not unique to this hardware. There is hardware all over that does
not meet the current assumptions being made in the early uart drivers
within the kernel.