Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753065AbdLGSnf (ORCPT ); Thu, 7 Dec 2017 13:43:35 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:40556 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752997AbdLGSn3 (ORCPT ); Thu, 7 Dec 2017 13:43:29 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5F0D160581 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=timur@codeaurora.org X-Google-Smtp-Source: AGs4zMbQW6hzoswnnzaaZys8sJPxTuxkaOdslRcrxsq5TWMiBrQD7GN6AOoz35cVv8M/evKw3dxu5wavit5m+ENWHvM= MIME-Version: 1.0 In-Reply-To: <20171207172912.17868-2-prarit@redhat.com> References: <20171207172912.17868-1-prarit@redhat.com> <20171207172912.17868-2-prarit@redhat.com> From: Timur Tabi Date: Thu, 7 Dec 2017 12:43:26 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] acpi, spcr: Make SPCR avialable to other architectures To: Prarit Bhargava Cc: ACPI Devel Maling List , Jonathan Corbet , "the arch/x86 maintainers" , linux-pm@vger.kernel.org, Catalin Marinas , Bhupesh Sharma , linux-doc@vger.kernel.org, Will Deacon , lkml , Ingo Molnar , "Rafael J. Wysocki" , Lv Zheng , linux-serial@vger.kernel.org, "H. Peter Anvin" , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , Jeffrey Hugo Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3060 Lines: 81 On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote: > Other architectures can use SPCR to setup an early console or console but > the current code is ARM64 specific. > > Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak > function acpi_arch_setup_console() that can be used for arch-specific > setup. Move SPCR initialization flag into ACPI code. Update the > Documention on the use of the SPCR earlycon. > > This patch does not change arm64 behaviour. Let's hope so. Our E44 erratum work-around has caused lots of problems in the past, so the code is a bit fragile. > +static bool qdf2400_erratum_44_present(struct acpi_table_header *h) > +{ > + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE)) > + return false; > + > + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE)) > + return true; > + > + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) && > + h->oem_revision == 1) > + return true; > + > + return false; > +} Please give us a chance to test this patch before merging. We've had a lot of problems with our E44 work-around, and we need to make sure that qdf2400_erratum_44_present function is called before the pl011 driver is probed. > + > +/* > + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its > + * register aligned to 32-bit. In addition, the BIOS also encoded the > + * access width to be 8 bits. This function detects this errata condition. > + */ > +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb) > +{ > + bool xgene_8250 = false; > + > + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE) > + return false; > + > + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) && > + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE)) > + return false; > + > + if (!memcmp(tb->header.oem_table_id, "XGENESPC", > + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0) > + xgene_8250 = true; > + > + if (!memcmp(tb->header.oem_table_id, "ProLiant", > + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1) > + xgene_8250 = true; > + > + return xgene_8250; > +} I suspect that this function has the same issues as qdf2400_erratum_44_present(). > +config ACPI_SPCR_TABLE > + bool "ACPI Serial Port Console Redirection Support" > + default y if ARM64 > + help > + Enable support for Serial Port Console Redirection (SPCR) Table. > + This table provides information about the configuration of the > + earlycon console. > + So ACPI without SPCR has never been tested by us. Making it optional makes me a little nervous. We'll have to evaluate this change. -- 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.