linux-kernel - Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

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: <bd59cc0d-fcd6-aa7e-409f-1e363599b1a1@codeaurora.org>
Date:   Wed, 8 Feb 2017 16:57:35 -0500
From:   Christopher Covington <cov@...eaurora.org>
To:     Robin Murphy <robin.murphy@....com>,
        Marc Zyngier <marc.zyngier@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Mark Rutland <mark.rutland@....com>
Cc:     Timur Tabi <timur@...eaurora.org>,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Shanker Donthineni <shankerd@...eaurora.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Russell King <linux@...linux.org.uk>,
        linux-serial@...r.kernel.org, Jon Masters <jcm@...hat.com>,
        Neil Leeder <nleeder@...eaurora.org>,
        Mark Langsdorf <mlangsdo@...hat.com>,
        Mark Salter <msalter@...hat.com>,
        Sameer Goel <sgoel@...eaurora.org>,
        Philip Elcan <pelcan@...eaurora.org>,
        Steve Ulrich <sulrich@...eaurora.org>,
        Richard Ruigrok <rruigrok@...eaurora.org>,
        Peter Hurley <peter@...leysoftware.com>
Subject: Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

Hi,

On 02/08/2017 08:27 AM, Timur Tabi wrote:
> Robin Murphy wrote:
>> Is there a reason anyone would ever want to turn this off? AFAICS you
>> save a few dozen bytes in return for a kernel image which you know won't
>> work properly on some hardware. That doesn't seem particularly
>> worthwhile, and it's not like the PL011 driver isn't already ripe with
>> unconditional vendor-specific data.

I'll make it unconditional in the next version.

>>> > +static bool qdf2400_e44(void) {
>>> > +    u32 cpu_var_model = read_cpuid_id() & ~MIDR_REVISION_MASK;
>>> > +
>>> > +    return (cpu_var_model == MIDR_QCOM_KRYO_V1 ||
>>> > +        cpu_var_model == MIDR_QCOM_FALKOR_V1);
> 
>> Are we to take it that every SoC now and always with any Kryo or Falkor
>> core which also has an SBSA UART will require this workaround?

I should have matched full 32 bit MIDR values, but I masked off the revision
number after careful investigation of current and future known MIDR values
and system pairings because MIDR_FOO isn't actually a 32 bit MIDR value as
the name would suggest but has variant and revision zeroed. The CPU in the
QDF2432 has a non-zero revision number and I didn't want to try to add an
unprecedented revision number to cputype.h after Will told me I wasn't
allowed to play with CPU toys for SoC games.

I'm going to stop using MIDR, but as an aside, there are two very different
CPUs, which may require different CPU errata workarounds, that (by accident)
only differ by the variant field. Robert Richter's recent MIDR_CPU_VAR_REV
is a welcome clarification.

> No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
> will have this fixed.

A year ago, we were operating under the incorrect-in-hindsight assumption
that the QDF2400 v1 SoC with Falkor v1 CPU would have this fixed.

As for alternative means of identifying the errant hardware, I think that I
or a colleague will experiment with the approach used for ACPI PCI quirks:
checking the OEM ID, OEM Table ID, and OEM Revision. In this case, those
header fields would come from the Serial Port Console Redirection (SPCR)
table, rather than the PCI-specific MCFG table.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b69b85ba1ddd36be01f5c57830b37a3c8256009

Regarding ongoing support, I don't see any disagreement that the code must
be supported and maintained for the life of the hardware, however many years
that ends up being.

Thanks,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.