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 19:31:19 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Aaron Durbin <adurbin@...omium.org>
Cc:     Daniel Kurtz <djkurtz@...omium.org>,
        Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>,
        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 7:12 PM, Aaron Durbin <adurbin@...omium.org> wrote:
> 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?

*SPCR table* itself on the platforms in question.

>  There is hardware all over that does
> not meet the current assumptions being made in the early uart drivers
> within the kernel.

I know, that's why I'm working now on a proposal to SPCR specification
to make our life slightly easier in that sense.

P.S. In case you are interested, I have crafted SPCR in U-Boot for
Intel Edison (ACPI case) where UART clock is also non-standard and did
some tests. It works quite nicely when firmware, **iff written
properly**, configures UART beforehand. In this case no clock
information is needed, no code needs to be added into the kernel.

-- 
With Best Regards,
Andy Shevchenko