[{"id":1775966,"web_url":"http://patchwork.ozlabs.org/comment/1775966/","msgid":"","list_archive_url":null,"date":"2017-09-27T00:40:20","subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/26/2017 03:23 PM, Al Stone wrote:\n> While it is very useful to know what CPU is being used, it is also\n> useful to know who made the platform being used. On servers, this\n> can point to the right person to contact when a server is having\n> trouble.\n> \n> Go get the product info -- manufacturer, product name and version --\n> from DMI (aka SMBIOS) and display it in /proc/cpuinfo. To look more\n> like other server platforms, include the CPU type and frequency when\n> displaying the product info, too.\n> \n> Signed-off-by: Al Stone \n> Cc: Catalin Marinas \n> Cc: Will Deacon \n> Cc: Suzuki K Poulose \n> Cc: Mark Rutland \n> ---\n\n[snip]\n\n> +/* Look up the baseboard info in DMI */\n> +static void get_dmi_product_info(void)\n> +{\n> +\tif (!dmi_product_info) {\n> +\t\tdmi_product_info = kcalloc(DMI_MAX_STRLEN,\n> +\t\t\t\t\t sizeof(char), GFP_KERNEL);\n> +\t\tif (!dmi_product_info)\n> +\t\t\treturn;\n> +\t}\n> +\n> +\tdmi_walk(find_dmi_product_info, dmi_product_info);\n> +}\n\nDon't you need all of these DMI-related functions you defined to be also\nenclosed within an #if IS_ENABLED(CONFIG_DMI) otherwise chances are that\nwe are going to get defined but unused warnings?\n\n\n> \t\timpl = (u8) MIDR_IMPLEMENTOR(midr);\n> \t\tfor (j = 0; hw_implementer[j].id != 0; j++) {\n> \t\t\tif (hw_implementer[j].id == impl) {\n> @@ -208,7 +341,7 @@ static int c_show(struct seq_file *m, void *v)\n> \t\tpart = (u16) MIDR_PARTNUM(midr);\n> \t\tfor (j = 0; parts[j].id != (-1); j++) {\n> \t\t\tif (parts[j].id == part) {\n> -\t\t\t\tseq_printf(m, \"%s\\n\", parts[j].name);\n> +\t\t\t\tseq_printf(m, \"%s \", parts[j].name);\n> \t\t\t\tbreak;\n> \t\t\t}\n\nShould this hunk be part of patch 3?","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"Njh0FzmR\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"PlDCjjKy\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1zWq5nT6z9t3F\n\tfor ;\n\tWed, 27 Sep 2017 10:40:55 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx0PD-0005dl-BP; Wed, 27 Sep 2017 00:40:51 +0000","from mail-qk0-x243.google.com ([2607:f8b0:400d:c09::243])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx0P9-0005UR-9U for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 00:40:49 +0000","by mail-qk0-x243.google.com with SMTP id q8so514957qkl.5\n\tfor ;\n\tTue, 26 Sep 2017 17:40:26 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tt3sm6871041qtd.8.2017.09.26.17.40.21\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 26 Sep 2017 17:40:24 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=bkL73zcIO02LGt6NdIkZVBdndAnlSAQgHmVAFtM0XR8=;\n\tb=Njh0FzmRE2rb/n\n\tInH6ysyfUHkjy4XOIoB0U49oGT4V1dyobJOLco3ST8rmO9Xl656yGCDO8UbvvApTQWwj6tq+XUAK6\n\t9W0y2UIZ3hBfJuML6f9wpBQKM8nyRuz/LCtRhsO/VQBkSkJSU2EBVS1LRY5qsc+D5Qmia2ol/ygPj\n\tt6auqShinbYgA+3ea1S6FOJ4UqK8dSbx2HYfeQ3UbVbWgWENAUkhTlCPaqiLfRw64RFYN2fiEUA/x\n\t6c2iLJE/pp9tlLIxPIUeBVNEhH4xayC8LMaQo8xFlZDxHG+SKwrBmHTFuw6N2M9oHKblxodewRAhE\n\tEs4QeBUH6vVWOal/dEGw==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=5u7wNgU37zDR67QjQ6mmtNfg+DOMTxXq6EUHM05W+B0=;\n\tb=PlDCjjKyHrTiStRky0PR32JIiH5yXuRNCmwxSJ0HjH20moUEl71EUP/R0AO1WlS9PK\n\tS4jGqZBk/OsNGbufBohsLy65VwOHYCfF3BkR58Sp9e9rc3HVf/6cuuyTc++n6BcTGqiK\n\tJGSXioQ9oYNiKzBQ4KY+lkar4XSfOVtgBmA96yaJdwZFNbu6KOwzd5jrxR4KNcz4YuOA\n\tofiSJ8CEYv1yPWew1kN95qFjCB4FtqhTB6uKSj7itHcwn1qgEkDeWyoxmBYV/5gw++pG\n\t4hW+6R4PqYB/qczzTRfwYMrAvhalMLow4PL0ci6fSzwipLy5miA6uIXmC8aX6P8+qtSW\n\t/LUA=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=5u7wNgU37zDR67QjQ6mmtNfg+DOMTxXq6EUHM05W+B0=;\n\tb=AQub8xQopDi4C4N/jOCORKSLSdttHTXTN7ltQYn0tF2oXESsxetJ5LgjtctCyoBiuF\n\t9U9XwhD7OobyJF6naS0indlpSXijSkLvtzpWJ056aWbYsNklmJ2v/siHG9vqfvdXiVZf\n\t41S30sVCzelffjeKmTWh1OqWYQlpAaR6+B34yLVLw6X48nW11aFlsacO/CXKPoiswz19\n\tgtRnP0tXi4DV7FH81RFfOzOlzdjG+uXqBZQhFQGXFlLdQpzQn8E+yLDEe+IBQrU1EjZ9\n\toiWvHqzh4j8edFbT3i+VIfHSZSxgjke7iambkLnoPtbvwdZwK1zTePgiIlkNfeXo8/v5\n\t7a0A==","X-Gm-Message-State":"AMCzsaVyOmHoAG76OzO1d+bV2U2mJ3MWbkaXZ5t1QKIua6CyzDdVmaY4\n\t8iwrrdzdlMwX0bw+HZPVmm2JQ9Ty","X-Google-Smtp-Source":"AOwi7QC0r1U4eR0yF7agqRNzuGmclisMU8NN5y9hB2j1fOLKrbaaOYdVVBwpqdmsGOuAZGNMIXKXzg==","X-Received":"by 10.55.22.218 with SMTP id 87mr207386qkw.248.1506472825517;\n\tTue, 26 Sep 2017 17:40:25 -0700 (PDT)","Subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","To":"Al Stone , linux-arm-kernel@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-4-ahs3@redhat.com>","From":"Florian Fainelli ","Message-ID":"","Date":"Tue, 26 Sep 2017 17:40:20 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170926222324.17409-4-ahs3@redhat.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170926_174047_440187_8F22AF95 ","X-CRM114-Status":"GOOD ( 16.21 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400d:c09:0:0:0:243 listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n\tprovider (f.fainelli[at]gmail.com)\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Mark Rutland ,\n\tCatalin Marinas ,\n\tWill Deacon , \n\tSuzuki K Poulose ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776235,"web_url":"http://patchwork.ozlabs.org/comment/1776235/","msgid":"","list_archive_url":null,"date":"2017-09-27T10:35:01","subject":"Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to\n\t/proc/cpuinfo","submitter":{"id":65641,"url":"http://patchwork.ozlabs.org/api/people/65641/","name":"Robin Murphy","email":"robin.murphy@arm.com"},"content":"On 26/09/17 23:23, Al Stone wrote:\n> In the interest of making things easier for humans to use, add a\n> \"CPU name\" line to /proc/cpuinfo for each CPU that uses plain old\n> words instead of hex values. For example, instead of printing only\n> CPU implementer 0x43 and CPU part 0x0A1, print also \"CPU name :\n> Cavium ThunderX\".\n> \n> Note that this is not meant to be an exhaustive list of all possible\n> implementers or CPUs (I'm not even sure that is knowable); this patch\n> is intentionally limited to only those willing to provide info in\n> arch/arm64/include/asm/cputype.h\n\nHow valuable is an incomplete interface really? If users who want to\ndecode MIDRs are going to have to rely on (pretty trivial ) userspace\ntools anyway when their stable distro kernel doesn't know their spangly\nnew hardware, why does the kernel need to bother at all.\n\nThe fact is that we already do the exact same thing as x86 - we print\nexactly what the ID registers say. The fact that on x86 some of those\nvalues happen to form a readable ASCII string is a different matter.\n\n> Signed-off-by: Al Stone \n> Cc: Catalin Marinas \n> Cc: Will Deacon \n> Cc: Suzuki K Poulose \n> Cc: Mark Rutland \n> ---\n> arch/arm64/kernel/cpuinfo.c | 84 +++++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 84 insertions(+)\n> \n> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c\n> index e505007138eb..0b4261884862 100644\n> --- a/arch/arm64/kernel/cpuinfo.c\n> +++ b/arch/arm64/kernel/cpuinfo.c\n> @@ -75,6 +75,61 @@ static const char *const hwcap_str[] = {\n> \tNULL\n> };\n> \n> +struct hw_part {\n> +\tu16\tid;\n> +\tchar\t*name;\n> +};\n> +\n> +static const struct hw_part arm_hw_part[] = {\n> +\t{ ARM_CPU_PART_AEM_V8,\t\t\"AEMv8 Model\" },\n> +\t{ ARM_CPU_PART_FOUNDATION,\t\"Foundation Model\" },\n> +\t{ ARM_CPU_PART_CORTEX_A57,\t\"Cortex A57\" },\n> +\t{ ARM_CPU_PART_CORTEX_A53,\t\"Cortex A53\" },\n> +\t{ ARM_CPU_PART_CORTEX_A73,\t\"Cortex A73\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n\nSo for a fair chunk of *current* server-class hardware, we'll be\nprinting \"unknown\" already. Great.\n\nRobin.\n\n> +};\n> +\n> +static const struct hw_part apm_hw_part[] = {\n> +\t{ APM_CPU_PART_POTENZA,\t\t\"Potenza\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part brcm_hw_part[] = {\n> +\t{ BRCM_CPU_PART_VULCAN,\t\t\"Vulcan\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part cavium_hw_part[] = {\n> +\t{ CAVIUM_CPU_PART_THUNDERX,\t \"ThunderX\" },\n> +\t{ CAVIUM_CPU_PART_THUNDERX_81XX, \"ThunderX 81XX\" },\n> +\t{ CAVIUM_CPU_PART_THUNDERX_83XX, \"ThunderX 83XX\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part qcom_hw_part[] = {\n> +\t{ QCOM_CPU_PART_FALKOR_V1,\t\"Falkor v1\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part unknown_hw_part[] = {\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +struct hw_impl {\n> +\tu8\t\t\tid;\n> +\tconst struct hw_part\t*parts;\n> +\tchar\t\t\t*name;\n> +};\n> +\n> +static const struct hw_impl hw_implementer[] = {\n> +\t{ ARM_CPU_IMP_ARM,\tarm_hw_part,\t\"ARM Ltd.\" },\n> +\t{ ARM_CPU_IMP_APM,\tapm_hw_part,\t\"Applied Micro\" },\n> +\t{ ARM_CPU_IMP_CAVIUM,\tcavium_hw_part,\t\"Cavium\" },\n> +\t{ ARM_CPU_IMP_BRCM,\tbrcm_hw_part,\t\"Broadcom\" },\n> +\t{ ARM_CPU_IMP_QCOM,\tqcom_hw_part,\t\"Qualcomm\" },\n> +\t{ 0, unknown_hw_part, \"unknown\" }\n> +};\n> +\n> #ifdef CONFIG_COMPAT\n> static const char *const compat_hwcap_str[] = {\n> \t\"swp\",\n> @@ -116,6 +171,9 @@ static int c_show(struct seq_file *m, void *v)\n> {\n> \tint i, j;\n> \tbool compat = personality(current->personality) == PER_LINUX32;\n> +\tu8 impl;\n> +\tu16 part;\n> +\tconst struct hw_part *parts;\n> \n> \tfor_each_online_cpu(i) {\n> \t\tstruct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);\n> @@ -132,6 +190,32 @@ static int c_show(struct seq_file *m, void *v)\n> \t\t\tseq_printf(m, \"model name\\t: ARMv8 Processor rev %d (%s)\\n\",\n> \t\t\t\t MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);\n> \n> +\t\timpl = (u8) MIDR_IMPLEMENTOR(midr);\n> +\t\tfor (j = 0; hw_implementer[j].id != 0; j++) {\n> +\t\t\tif (hw_implementer[j].id == impl) {\n> +\t\t\t\tseq_printf(m, \"CPU name\\t: %s \",\n> +\t\t\t\t\t hw_implementer[j].name);\n> +\t\t\t\tparts = hw_implementer[j].parts;\n> +\t\t\t\tbreak;\n> +\t\t\t}\n> +\t\t}\n> +\t\tif (hw_implementer[j].id == 0) {\n> +\t\t\tseq_printf(m, \"CPU name\\t: %s \",\n> +\t\t\t\t hw_implementer[j].name);\n> +\t\t\tparts = hw_implementer[j].parts;\n> +\t\t}\n> +\n> +\t\tpart = (u16) MIDR_PARTNUM(midr);\n> +\t\tfor (j = 0; parts[j].id != (-1); j++) {\n> +\t\t\tif (parts[j].id == part) {\n> +\t\t\t\tseq_printf(m, \"%s\\n\", parts[j].name);\n> +\t\t\t\tbreak;\n> +\t\t\t}\n> +\t\t}\n> +\t\tif (parts[j].id == (-1))\n> +\t\t\tseq_printf(m, \"%s\", parts[j].name);\n> +\t\tseq_puts(m, \"\\n\");\n> +\n> \t\tseq_printf(m, \"BogoMIPS\\t: %lu.%02lu\\n\",\n> \t\t\t loops_per_jiffy / (500000UL/HZ),\n> \t\t\t loops_per_jiffy / (5000UL/HZ) % 100);\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"deJnwL/f\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2Djz5bNzz9tXf\n\tfor ;\n\tWed, 27 Sep 2017 20:35:35 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx9gi-0000bT-BJ; Wed, 27 Sep 2017 10:35:32 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx9ga-0007c8-QB for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 10:35:31 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7ED9715A2;\n\tWed, 27 Sep 2017 03:35:04 -0700 (PDT)","from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t4676D3F53D; Wed, 27 Sep 2017 03:35:03 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=wLUCNR8WJnvBaw6nc2y3FdxHZQd1ar2z1bKtkmYQiHg=;\n\tb=deJnwL/fvk7tje\n\tiAXj7Z2fwHtWlQsTaB74s+npP0lpgV1DbbUCY1aPQDlzpBjkCY7+QeuAWSeks5Bw6qjIF12VbTuaq\n\t5eVTXAhJuvfTVcbV6zTcJS1ghn/pw+WlQ69QdFFH8dAYa9iAvFBDBfMXCBNhlfmel+MV3kkI3Apjn\n\tBCEIWwvjSb2+JVHtFGtPupTJKFrRQbI/GMHjvYGUUTXO9MunRuS1odgQEHJXUK2t6xSVP2BLzfi1o\n\teROz31yVNz3K8JTXmZ3wK5Ed0Ocom8lujUbKNXIWPaqPA0kh7asyZToYMOBafYOB7vXw7Be1pi+EK\n\tagiU/EWAHLk6ix4ibbSw==;","Subject":"Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to\n\t/proc/cpuinfo","To":"Al Stone , linux-arm-kernel@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-3-ahs3@redhat.com>","From":"Robin Murphy ","Message-ID":"","Date":"Wed, 27 Sep 2017 11:35:01 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170926222324.17409-3-ahs3@redhat.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_033524_884411_48E90D87 ","X-CRM114-Status":"GOOD ( 17.69 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Mark Rutland ,\n\tCatalin Marinas ,\n\tWill Deacon , \n\tSuzuki K Poulose ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776236,"web_url":"http://patchwork.ozlabs.org/comment/1776236/","msgid":"<20170927103406.GC32150@leverpostej>","list_archive_url":null,"date":"2017-09-27T10:34:07","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi Al,\n\nOn Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:\n> As ARMv8 servers get deployed, I keep getting the same set of questions\n> from end-users of those systems: what do all the hex numbers mean in \n> /proc/cpuinfo and could you make them so I don't have to carry a cheat\n> sheet with me all the time?\n\nI appreciate that /proc/cpuinfo can be opaque to end users, but I do not\nbelieve that this is the right solution to that problem.\n\nThere are a number of issues stemming from the face that /proc/cpuinfo\nis ill-defined and overused for a number of cases. Changes to it almost\ncertainly violate brittle de-facto ABI details people are relying on,\nand there's a very long tail on fallout resulting from this. In\naddition, many niceties come at an excessive maintenance cost, and are\nsimply unreliable as an ABI.\n\nSo, as with all other patches modifying /proc/cpuinfo, I must NAK this\nseries.\n\nFor the MPIDR and product info, I think we can expose this in a more\nstructured way (e.g. under sysfs). IIUC the product info is all derived\nfrom DMI -- do we not expose that already?\n\nFor the human-readable names I must NAK such patches. This is an\nextremely brittle ABI that cannot be forwards compatible, and comes with\nhilarious political problems. This should be managed in userspace alone.\n\nI thought tools like lscpu and lshw were intended to gather such\ninformation for users. What are these missing today?\n\nThanks,\nMark.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"nuWzN6qu\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2DkX2SfNz9tXn\n\tfor ;\n\tWed, 27 Sep 2017 20:36:04 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx9h8-00013u-9w; Wed, 27 Sep 2017 10:35:58 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx9h4-0000eA-CK for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 10:35:56 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 231721435;\n\tWed, 27 Sep 2017 03:35:34 -0700 (PDT)","from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t5B9643F53D; Wed, 27 Sep 2017 03:35:33 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=sBNhWGUX9KWgCtiS/htj7eF1Z51QhdyptA0iv6lBBFo=;\n\tb=nuWzN6quQHrcoU\n\tDlbCiMD6JM4s4r/C5coExYhXbmTzrYtUJcb9OzgxC8x7FrjXuTzT9Y6ome+Utj4+qMwe0TrxAcHRh\n\tJBygWNpJ1JKk0MSEOArM31BebILblguyy+7qszyBBEZY0TEP7MSiNXWaE391eevAmqQvliTAbwqjZ\n\tOO7wyoDYXgvGYQuEuBhsSxeAGS8E376AHDB21Lw5qGKUArFDHvkIk/wpYQ/KU2T+dUJCtcAZ0gxdF\n\tN0YSVkBXJuUYEzSdyxbkkzhiM0xwyfve2ALrwQZKWoTbV+vZm5zZyrTfxszqlkaIxKVUIc2eeAjK+\n\t17/X1nvUbreBxzalO8AA==;","Date":"Wed, 27 Sep 2017 11:34:07 +0100","From":"Mark Rutland ","To":"Al Stone ","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","Message-ID":"<20170927103406.GC32150@leverpostej>","References":"<20170926222324.17409-1-ahs3@redhat.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170926222324.17409-1-ahs3@redhat.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_033554_619640_D318252C ","X-CRM114-Status":"GOOD ( 11.69 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776238,"web_url":"http://patchwork.ozlabs.org/comment/1776238/","msgid":"","list_archive_url":null,"date":"2017-09-27T10:42:07","subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","submitter":{"id":65641,"url":"http://patchwork.ozlabs.org/api/people/65641/","name":"Robin Murphy","email":"robin.murphy@arm.com"},"content":"On 26/09/17 23:23, Al Stone wrote:\n> While it is very useful to know what CPU is being used, it is also\n> useful to know who made the platform being used. On servers, this\n> can point to the right person to contact when a server is having\n> trouble.\n> \n> Go get the product info -- manufacturer, product name and version --\n> from DMI (aka SMBIOS) and display it in /proc/cpuinfo. To look more\n> like other server platforms, include the CPU type and frequency when\n> displaying the product info, too.\n> \n> Signed-off-by: Al Stone \n> Cc: Catalin Marinas \n> Cc: Will Deacon \n> Cc: Suzuki K Poulose \n> Cc: Mark Rutland \n> ---\n[...]\n> @@ -190,6 +298,31 @@ static int c_show(struct seq_file *m, void *v)\n> \t\t\tseq_printf(m, \"model name\\t: ARMv8 Processor rev %d (%s)\\n\",\n> \t\t\t\t MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);\n> \n> +\t\tif (IS_ENABLED(CONFIG_DMI)) {\n> +\t\t\tseq_puts(m, \"product name\\t: \");\n> +\n> +\t\t\tif (!dmi_product_info)\n> +\t\t\t\tget_dmi_product_info();\n> +\t\t\tif (dmi_product_info)\n> +\t\t\t\tseq_printf(m, \"%s\", dmi_product_info);\n> +\t\t\telse\n> +\t\t\t\tseq_puts(m, \"\");\n> +\n> +\t\t\tseq_printf(m, \", ARM 8.%d (r%dp%d) CPU\",\n> +\t\t\t\t MIDR_VARIANT(midr),\n> +\t\t\t\t MIDR_VARIANT(midr),\n> +\t\t\t\t MIDR_REVISION(midr));\n\nWhat is \"ARM 8.1\" meant to infer for, say, a typical Cortex-A57?\n\nRobin.\n\n> +\n> +\t\t\tif (!dmi_max_mhz)\n> +\t\t\t\tdmi_max_mhz = get_dmi_max_mhz();\n> +\t\t\tif (dmi_max_mhz)\n> +\t\t\t\tseq_printf(m, \" @ %d.%02dGHz\\n\",\n> +\t\t\t\t\t (int)(dmi_max_mhz / 1000),\n> +\t\t\t\t\t (int)(dmi_max_mhz % 1000));\n> +\t\t\telse\n> +\t\t\t\tseq_puts(m, \" @ GHz\\n\");\n> +\t\t}\n> +\n> \t\timpl = (u8) MIDR_IMPLEMENTOR(midr);\n> \t\tfor (j = 0; hw_implementer[j].id != 0; j++) {\n> \t\t\tif (hw_implementer[j].id == impl) {","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"pzh6PbWN\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2Dt61T5fz9tXf\n\tfor ;\n\tWed, 27 Sep 2017 20:42:38 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx9nW-0006hf-Rz; Wed, 27 Sep 2017 10:42:34 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx9nS-0006VT-1Q for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 10:42:32 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E34521435;\n\tWed, 27 Sep 2017 03:42:09 -0700 (PDT)","from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t8C5013F53D; Wed, 27 Sep 2017 03:42:08 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=eJnV1wV1CITy2mLOqpLekiarvwCpmxFDA5nThS/r4Y8=;\n\tb=pzh6PbWNVgy6ZD\n\tVR8jRGbbVsi51kGrR4nfMd5NYgZEFy5/wUMRiByWyGc1P2U42SbmJVkX5Tu9TwTcrx7AX31TxOdjo\n\tnErRj0bj5/3iraX3tmKIScEeBA5mOR/Vp9RnBfmMp4cY50j5jumEI94m3cCk6SKuJrOZgMbFGTwqa\n\tWJlMaNzuolsYnaTkTBQjjqRGq9UMQ0nq0zr0cqOIxTJusz9izGJpAkWyKGnf0M7N4dS9Ca5PrgItK\n\tO/Wyhh90wkGq+2xsGmoPHcPtH66THDeb9Qa8PiJczSoo7rZbckj5j6x/UzkaDTHWZ2ktMEoHlAr86\n\tDW4dXC5Toffva2AyjUow==;","Subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","To":"Al Stone , linux-arm-kernel@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-4-ahs3@redhat.com>","From":"Robin Murphy ","Message-ID":"","Date":"Wed, 27 Sep 2017 11:42:07 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170926222324.17409-4-ahs3@redhat.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_034230_241483_A940E33A ","X-CRM114-Status":"GOOD ( 13.44 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Mark Rutland ,\n\tCatalin Marinas ,\n\tWill Deacon , \n\tSuzuki K Poulose ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776258,"web_url":"http://patchwork.ozlabs.org/comment/1776258/","msgid":"<20170927112600.GD32150@leverpostej>","list_archive_url":null,"date":"2017-09-27T11:26:01","subject":"Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to\n\t/proc/cpuinfo","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi Al,\n\nOn Tue, Sep 26, 2017 at 04:23:23PM -0600, Al Stone wrote:\n> In the interest of making things easier for humans to use, add a\n> \"CPU name\" line to /proc/cpuinfo for each CPU that uses plain old\n> words instead of hex values. For example, instead of printing only\n> CPU implementer 0x43 and CPU part 0x0A1, print also \"CPU name :\n> Cavium ThunderX\".\n> \n> Note that this is not meant to be an exhaustive list of all possible\n> implementers or CPUs (I'm not even sure that is knowable); this patch\n> is intentionally limited to only those willing to provide info in\n> arch/arm64/include/asm/cputype.h\n\nAs mentioned in the cover letter, and as with previous patches\nattempting to do the same thing:\n\nNAK to this patch.\n\nIn general, modifying /proc/cpuinfo comes with the risk of breaking\napplications that (for better or worse) try to parse it mechanically.\nFurther, such modifications add to the problem by introducing yet more\nABI state applications may or may not end up depending on to function\n(even if they don't require or use the information at all).\n\nSpecifically regarding mapping MIDRs to strings in the kernel, there are\na number of problems that make this undesirable, including (but not\nlimited to):\n\n* As mentioned in the commit message, this cannot be complete, and is\n thus unreliable. We cannot know the set of CPUs that will exist in the\n future, and thus this practically mandates a kernel upgrade to use new\n CPUs, solely for a nicety.\n\n* The names of CPUs can change, so there's not necessarily a single\n correct name to expose. As seen with Cortex-A12 and Cortex-A17 [1],\n where some users were upset if their CPU was considered to be a\n Cortex-A12 rather than a Cortex-A17.\n\n This embeds a political problem into kernel ABI.\n\n* No matter how many times we tell them not to, applications *will* try\n to parse this. Any change (e.g. typo fixing or naming updates) will\n break some applications. An unexpectedly long CPU name may break\n parses using a small buffer.\n\n Worse, this could change over a kernel update, as a cpu goes from\n being:\n \n CPU name: unknown\n \n ... to being:\n\n CPU name: awesome super CPU 2000xx-super-mega-long-name-edition\n\n ... which could break applications, and some could argue that this is\n a kernel-side regression breaking userspace.\n\n* This information can be derived from the MIDR and REVIDR. The decoded\n MIDR has always been exposed under /proc/cpuinfo, and both are exposed\n in a structured way under:\n\n /sys/devices/system/cpu/cpu${N}/regs/identification\n\n This duplicates information that way already expose, but in an\n unreliable fashion.\n\n* This requires us to maintain an ever growing mapping of CPU IDs to\n strings.\n\n* For similar reasons, this information is not exposed by 32-bit ARM,\n and further bifurcates our /proc/cpuinfo formats.\n\nThese problems cannot be solved kernel-side, and given this, I will\ncontinue to NAK patches which attempt to decode the MIDR to human\nreadable strings.\n\nThanks,\nMark.\n\n[1] https://community.arm.com/processors/b/blog/posts/arm-cortex-a17-cortex-a12-processor-update?CommentId=85c9dea4-1c9a-460c-a7b6-dcf59caab43d&pi10955=99\n\n> \n> Signed-off-by: Al Stone \n> Cc: Catalin Marinas \n> Cc: Will Deacon \n> Cc: Suzuki K Poulose \n> Cc: Mark Rutland \n> ---\n> arch/arm64/kernel/cpuinfo.c | 84 +++++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 84 insertions(+)\n> \n> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c\n> index e505007138eb..0b4261884862 100644\n> --- a/arch/arm64/kernel/cpuinfo.c\n> +++ b/arch/arm64/kernel/cpuinfo.c\n> @@ -75,6 +75,61 @@ static const char *const hwcap_str[] = {\n> \tNULL\n> };\n> \n> +struct hw_part {\n> +\tu16\tid;\n> +\tchar\t*name;\n> +};\n> +\n> +static const struct hw_part arm_hw_part[] = {\n> +\t{ ARM_CPU_PART_AEM_V8,\t\t\"AEMv8 Model\" },\n> +\t{ ARM_CPU_PART_FOUNDATION,\t\"Foundation Model\" },\n> +\t{ ARM_CPU_PART_CORTEX_A57,\t\"Cortex A57\" },\n> +\t{ ARM_CPU_PART_CORTEX_A53,\t\"Cortex A53\" },\n> +\t{ ARM_CPU_PART_CORTEX_A73,\t\"Cortex A73\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part apm_hw_part[] = {\n> +\t{ APM_CPU_PART_POTENZA,\t\t\"Potenza\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part brcm_hw_part[] = {\n> +\t{ BRCM_CPU_PART_VULCAN,\t\t\"Vulcan\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part cavium_hw_part[] = {\n> +\t{ CAVIUM_CPU_PART_THUNDERX,\t \"ThunderX\" },\n> +\t{ CAVIUM_CPU_PART_THUNDERX_81XX, \"ThunderX 81XX\" },\n> +\t{ CAVIUM_CPU_PART_THUNDERX_83XX, \"ThunderX 83XX\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part qcom_hw_part[] = {\n> +\t{ QCOM_CPU_PART_FALKOR_V1,\t\"Falkor v1\" },\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part unknown_hw_part[] = {\n> +\t{ (-1), \"unknown\" }\t\t/* Potenza == 0, unfortunately */\n> +};\n> +\n> +struct hw_impl {\n> +\tu8\t\t\tid;\n> +\tconst struct hw_part\t*parts;\n> +\tchar\t\t\t*name;\n> +};\n> +\n> +static const struct hw_impl hw_implementer[] = {\n> +\t{ ARM_CPU_IMP_ARM,\tarm_hw_part,\t\"ARM Ltd.\" },\n> +\t{ ARM_CPU_IMP_APM,\tapm_hw_part,\t\"Applied Micro\" },\n> +\t{ ARM_CPU_IMP_CAVIUM,\tcavium_hw_part,\t\"Cavium\" },\n> +\t{ ARM_CPU_IMP_BRCM,\tbrcm_hw_part,\t\"Broadcom\" },\n> +\t{ ARM_CPU_IMP_QCOM,\tqcom_hw_part,\t\"Qualcomm\" },\n> +\t{ 0, unknown_hw_part, \"unknown\" }\n> +};\n> +\n> #ifdef CONFIG_COMPAT\n> static const char *const compat_hwcap_str[] = {\n> \t\"swp\",\n> @@ -116,6 +171,9 @@ static int c_show(struct seq_file *m, void *v)\n> {\n> \tint i, j;\n> \tbool compat = personality(current->personality) == PER_LINUX32;\n> +\tu8 impl;\n> +\tu16 part;\n> +\tconst struct hw_part *parts;\n> \n> \tfor_each_online_cpu(i) {\n> \t\tstruct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);\n> @@ -132,6 +190,32 @@ static int c_show(struct seq_file *m, void *v)\n> \t\t\tseq_printf(m, \"model name\\t: ARMv8 Processor rev %d (%s)\\n\",\n> \t\t\t\t MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);\n> \n> +\t\timpl = (u8) MIDR_IMPLEMENTOR(midr);\n> +\t\tfor (j = 0; hw_implementer[j].id != 0; j++) {\n> +\t\t\tif (hw_implementer[j].id == impl) {\n> +\t\t\t\tseq_printf(m, \"CPU name\\t: %s \",\n> +\t\t\t\t\t hw_implementer[j].name);\n> +\t\t\t\tparts = hw_implementer[j].parts;\n> +\t\t\t\tbreak;\n> +\t\t\t}\n> +\t\t}\n> +\t\tif (hw_implementer[j].id == 0) {\n> +\t\t\tseq_printf(m, \"CPU name\\t: %s \",\n> +\t\t\t\t hw_implementer[j].name);\n> +\t\t\tparts = hw_implementer[j].parts;\n> +\t\t}\n> +\n> +\t\tpart = (u16) MIDR_PARTNUM(midr);\n> +\t\tfor (j = 0; parts[j].id != (-1); j++) {\n> +\t\t\tif (parts[j].id == part) {\n> +\t\t\t\tseq_printf(m, \"%s\\n\", parts[j].name);\n> +\t\t\t\tbreak;\n> +\t\t\t}\n> +\t\t}\n> +\t\tif (parts[j].id == (-1))\n> +\t\t\tseq_printf(m, \"%s\", parts[j].name);\n> +\t\tseq_puts(m, \"\\n\");\n> +\n> \t\tseq_printf(m, \"BogoMIPS\\t: %lu.%02lu\\n\",\n> \t\t\t loops_per_jiffy / (500000UL/HZ),\n> \t\t\t loops_per_jiffy / (5000UL/HZ) % 100);\n> -- \n> 2.13.5\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"rMxK62fY\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2FtR26pCz9t16\n\tfor ;\n\tWed, 27 Sep 2017 21:27:59 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxAVP-0006a9-91; Wed, 27 Sep 2017 11:27:55 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxAVK-0006UX-Ki for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 11:27:52 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B8F6F1435;\n\tWed, 27 Sep 2017 04:27:28 -0700 (PDT)","from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t61AAC3F589; Wed, 27 Sep 2017 04:27:27 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=3F+H4NMO+WHiA6zqpGfn8nAu9oxQsJE4PN/E9C5ABjI=;\n\tb=rMxK62fYRJCwIt\n\tTuGZB4m1EPlZFe8v4aEWXNNj+EAYmqiNqMQUkDKD3ijGVl6eXaHFxegafhAwkZJSHINEXP5ECRGiA\n\tE8R5aRoxWcn2g/AvniYrt5/uy8agWDGF7BHFcbEI0dJSecbGYAL3Q75vl6ife3GBGrQVZrx+fJ85B\n\tAbIp5jtezyXt6uGursk0ezZKcgcuM40XWbBrhmaOd2kazEcS+OnG0LiPxoELSsBAxbPfQKqWAEKuh\n\tP8QjNl5DzE8MF758OXygdj4cTKIvtOZ8L49Md0Cj4bMWm367CMN58l6/BY1bqb0Nwn8hF0C7FjXkV\n\tNU2cmpGKfLzE3EfNYpfQ==;","Date":"Wed, 27 Sep 2017 12:26:01 +0100","From":"Mark Rutland ","To":"Al Stone ","Subject":"Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to\n\t/proc/cpuinfo","Message-ID":"<20170927112600.GD32150@leverpostej>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-3-ahs3@redhat.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170926222324.17409-3-ahs3@redhat.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_042750_698091_2801AD77 ","X-CRM114-Status":"GOOD ( 21.25 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Catalin Marinas ,\n\tWill Deacon , linux-kernel@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org,\n\tSuzuki K Poulose ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776266,"web_url":"http://patchwork.ozlabs.org/comment/1776266/","msgid":"<20170927113356.GE32150@leverpostej>","list_archive_url":null,"date":"2017-09-27T11:33:56","subject":"Re: [PATCH 1/3] arm64: cpuinfo: add MPIDR value to /proc/cpuinfo","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"On Tue, Sep 26, 2017 at 04:23:22PM -0600, Al Stone wrote:\n> When displaying cpuinfo on an arm64 system, include the MPIDR register\n> value which can be used to understand the CPU topology on a platform.\n> This can serve as a cross-check to the information provided in sysfs,\n> and has been useful in understanding CPU and NUMA allocation issues.\n\nAs mentioend in the cover letter, NAK to modifiying /proc/cpuinfo.\n\nHowever, I do think that we could expose this elsewhere in a structured\nway.\n\nFor debugging bringup issues, I think we can update our secondary\nbringup messages in dmesg to log the MPIDR (as we do for the boot CPU).\nI'll send a patch for that.\n\n> @@ -159,6 +160,12 @@ static int c_show(struct seq_file *m, void *v)\n> \t\t}\n> \t\tseq_puts(m, \"\\n\");\n> \n> +\t\tseq_printf(m, \"CPU MPIDR\\t: 0x%016llx \", mpidr);\n> +\t\tseq_printf(m, \"(Aff3 %d Aff2 %d Aff1 %d Aff0 %d)\\n\",\n> +\t\t\t (u8) MPIDR_AFFINITY_LEVEL(mpidr, 3),\n> +\t\t\t (u8) MPIDR_AFFINITY_LEVEL(mpidr, 2),\n> +\t\t\t (u8) MPIDR_AFFINITY_LEVEL(mpidr, 1),\n> +\t\t\t (u8) MPIDR_AFFINITY_LEVEL(mpidr, 0));\n\nPlease don't decode the register like this. We're stuck doing it with\nthe MIDR for historical reasons, but we shouldn't do it for new\nregisters.\n\nIt's possible (and I suspect likely) that MPIDR will gain more fields in\nfuture, and it creates futher ABI problems (e.g. adding them might break\napplications).\n\nIf we're going to expose this, we should expose the raw value under\nsysfs. Users who require this information will know how to decode it.\n\nThanks,\nMark.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"juCQN5Y3\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2G3Y56CKz9tXp\n\tfor ;\n\tWed, 27 Sep 2017 21:35:51 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxAd1-0003ja-BH; Wed, 27 Sep 2017 11:35:47 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxAcy-0003M3-KL for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 11:35:46 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 110BE80D;\n\tWed, 27 Sep 2017 04:35:24 -0700 (PDT)","from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tD1C093F589; Wed, 27 Sep 2017 04:35:22 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=3q/1whLXhfnYZHbV6M5AbL1SGEPhuPMsboQT+Jn9m3M=;\n\tb=juCQN5Y34ykdFc\n\tbMmlVL3tnF8PsJ3oirPFTgUfu8n9LKcD0pI1oBE0ZWTxXqiGdY0HXaQoIyjVjNKS5eUvrN1UxDF9F\n\tnFsftpkxLstyDeYiO7f/UoNGUNjk4JhCd+Hdk03mSG9+tQropNOh3fXhdA0FhpP6eigt9yci1hF3G\n\tmHKvfCanjOYVsArO+3B2Vked7JbKfC5Sp87Nk0zmWSa0WZ97RU9O0WqpgL96WU4XIAjNvJQKoQb7Z\n\t1d48VSOMdql+ZkWvCqsKMpzzhrwNlalSuTaagH2jbyoJyjWPW4eQAwrcWoSXHXupaSvntGvEXPU0H\n\trCJzRtcfQhb8vCoKdGGQ==;","Date":"Wed, 27 Sep 2017 12:33:56 +0100","From":"Mark Rutland ","To":"Al Stone ","Subject":"Re: [PATCH 1/3] arm64: cpuinfo: add MPIDR value to /proc/cpuinfo","Message-ID":"<20170927113356.GE32150@leverpostej>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-2-ahs3@redhat.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170926222324.17409-2-ahs3@redhat.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_043544_677572_D3DBF3F0 ","X-CRM114-Status":"GOOD ( 13.82 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Catalin Marinas ,\n\tWill Deacon , linux-kernel@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org,\n\tSuzuki K Poulose ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776271,"web_url":"http://patchwork.ozlabs.org/comment/1776271/","msgid":"<20170927113648.GF32150@leverpostej>","list_archive_url":null,"date":"2017-09-27T11:36:48","subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi Al,\n\nOn Tue, Sep 26, 2017 at 04:23:24PM -0600, Al Stone wrote:\n> While it is very useful to know what CPU is being used, it is also\n> useful to know who made the platform being used. On servers, this\n> can point to the right person to contact when a server is having\n> trouble.\n> \n> Go get the product info -- manufacturer, product name and version --\n> from DMI (aka SMBIOS) and display it in /proc/cpuinfo. To look more\n> like other server platforms, include the CPU type and frequency when\n> displaying the product info, too.\n\nAs mentioned on the cover letter, NAK to modifiying /proc/cpuinfo.\n\nI note this is all DMI information, which I thought we already exposed\nunder sysfs (in an architecture-neutral format).\n\nIs that not the case?\n\n... or do existing tools not pick that up today?\n\nThanks,\nMark.\n\n> \n> Signed-off-by: Al Stone \n> Cc: Catalin Marinas \n> Cc: Will Deacon \n> Cc: Suzuki K Poulose \n> Cc: Mark Rutland \n> ---\n> arch/arm64/kernel/cpuinfo.c | 135 +++++++++++++++++++++++++++++++++++++++++++-\n> 1 file changed, 134 insertions(+), 1 deletion(-)\n> \n> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c\n> index 0b4261884862..6a9dbad5ee3f 100644\n> --- a/arch/arm64/kernel/cpuinfo.c\n> +++ b/arch/arm64/kernel/cpuinfo.c\n> @@ -19,10 +19,12 @@\n> #include \n> #include \n> #include \n> +#include \n> \n> #include \n> #include \n> #include \n> +#include \n> #include \n> #include \n> #include \n> @@ -31,6 +33,7 @@\n> #include \n> #include \n> #include \n> +#include \n> #include \n> #include \n> #include \n> @@ -167,6 +170,111 @@ static const char *const compat_hwcap2_str[] = {\n> };\n> #endif /* CONFIG_COMPAT */\n> \n> +/* Details needed when extracting fields from DMI info */\n> +#define DMI_ENTRY_BASEBOARD_MIN_LENGTH\t8\n> +#define DMI_ENTRY_PROCESSOR_MIN_LENGTH\t48\n> +\n> +#define DMI_BASEBOARD_MANUFACTURER\t0x04\n> +#define DMI_BASEBOARD_PRODUCT\t\t0x05\n> +#define DMI_BASEBOARD_VERSION\t\t0x06\n> +#define DMI_PROCESSOR_MAX_SPEED\t\t0x14\n> +\n> +#define DMI_MAX_STRLEN\t\t\t80\n> +\n> +/* Values captured from DMI info */\n> +static u64 dmi_max_mhz;\n> +static char *dmi_product_info;\n> +\n> +/* Callback function used to retrieve the max frequency from DMI */\n> +static void find_dmi_mhz(const struct dmi_header *dm, void *private)\n> +{\n> +\tconst u8 *dmi_data = (const u8 *)dm;\n> +\tu16 *mhz = (u16 *)private;\n> +\n> +\tif (dm->type == DMI_ENTRY_PROCESSOR &&\n> +\t dm->length >= DMI_ENTRY_PROCESSOR_MIN_LENGTH) {\n> +\t\tu16 val = (u16)get_unaligned((const u16 *)\n> +\t\t\t\t(dmi_data + DMI_PROCESSOR_MAX_SPEED));\n> +\t\t*mhz = val > *mhz ? val : *mhz;\n> +\t}\n> +}\n> +\n> +/* Look up the max frequency in DMI */\n> +static u64 get_dmi_max_mhz(void)\n> +{\n> +\tu16 mhz = 0;\n> +\n> +\tdmi_walk(find_dmi_mhz, &mhz);\n> +\n> +\t/*\n> +\t * Real stupid fallback value, just in case there is no\n> +\t * actual value set.\n> +\t */\n> +\tmhz = mhz ? mhz : 1;\n> +\n> +\treturn (u64)mhz;\n> +}\n> +\n> +/* Helper function for the product info callback */\n> +static char *copy_string_n(char *dst, char *table, int idx)\n> +{\n> +\tchar *d = dst;\n> +\tchar *ptr = table;\n> +\tint ii;\n> +\n> +\t/* skip the first idx-1 strings */\n> +\tfor (ii = 1; ii < idx; ii++) {\n> +\t\twhile (*ptr)\n> +\t\t\tptr++;\n> +\t\tptr++;\n> +\t}\n> +\n> +\t/* copy in the string we need */\n> +\twhile (*ptr && (d - dst) < (DMI_MAX_STRLEN - 2))\n> +\t\t*d++ = *ptr++;\n> +\n> +\treturn d;\n> +}\n> +\n> +/* Callback function used to retrieve the product info DMI */\n> +static void find_dmi_product_info(const struct dmi_header *dm, void *private)\n> +{\n> +\tconst u8 *dmi_data = (const u8 *)dm;\n> +\tchar *ptr = (char *)private;\n> +\n> +\tif (dm->type == DMI_ENTRY_BASEBOARD &&\n> +\t dm->length >= DMI_ENTRY_BASEBOARD_MIN_LENGTH) {\n> +\t\tint idx;\n> +\n> +\t\tidx = (int)get_unaligned((const u8 *)\n> +\t\t\t\t(dmi_data + DMI_BASEBOARD_MANUFACTURER));\n> +\t\tptr = copy_string_n(ptr, (char *)(dmi_data + dm->length), idx);\n> +\t\t*ptr++ = ' ';\n> +\n> +\t\tidx = (int)get_unaligned((const u8 *)\n> +\t\t\t\t(dmi_data + DMI_BASEBOARD_PRODUCT));\n> +\t\tptr = copy_string_n(ptr, (char *)(dmi_data + dm->length), idx);\n> +\t\t*ptr++ = ' ';\n> +\n> +\t\tidx = (int)get_unaligned((const u8 *)\n> +\t\t\t\t(dmi_data + DMI_BASEBOARD_VERSION));\n> +\t\tptr = copy_string_n(ptr, (char *)(dmi_data + dm->length), idx);\n> +\t}\n> +}\n> +\n> +/* Look up the baseboard info in DMI */\n> +static void get_dmi_product_info(void)\n> +{\n> +\tif (!dmi_product_info) {\n> +\t\tdmi_product_info = kcalloc(DMI_MAX_STRLEN,\n> +\t\t\t\t\t sizeof(char), GFP_KERNEL);\n> +\t\tif (!dmi_product_info)\n> +\t\t\treturn;\n> +\t}\n> +\n> +\tdmi_walk(find_dmi_product_info, dmi_product_info);\n> +}\n> +\n> static int c_show(struct seq_file *m, void *v)\n> {\n> \tint i, j;\n> @@ -190,6 +298,31 @@ static int c_show(struct seq_file *m, void *v)\n> \t\t\tseq_printf(m, \"model name\\t: ARMv8 Processor rev %d (%s)\\n\",\n> \t\t\t\t MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);\n> \n> +\t\tif (IS_ENABLED(CONFIG_DMI)) {\n> +\t\t\tseq_puts(m, \"product name\\t: \");\n> +\n> +\t\t\tif (!dmi_product_info)\n> +\t\t\t\tget_dmi_product_info();\n> +\t\t\tif (dmi_product_info)\n> +\t\t\t\tseq_printf(m, \"%s\", dmi_product_info);\n> +\t\t\telse\n> +\t\t\t\tseq_puts(m, \"\");\n> +\n> +\t\t\tseq_printf(m, \", ARM 8.%d (r%dp%d) CPU\",\n> +\t\t\t\t MIDR_VARIANT(midr),\n> +\t\t\t\t MIDR_VARIANT(midr),\n> +\t\t\t\t MIDR_REVISION(midr));\n> +\n> +\t\t\tif (!dmi_max_mhz)\n> +\t\t\t\tdmi_max_mhz = get_dmi_max_mhz();\n> +\t\t\tif (dmi_max_mhz)\n> +\t\t\t\tseq_printf(m, \" @ %d.%02dGHz\\n\",\n> +\t\t\t\t\t (int)(dmi_max_mhz / 1000),\n> +\t\t\t\t\t (int)(dmi_max_mhz % 1000));\n> +\t\t\telse\n> +\t\t\t\tseq_puts(m, \" @ GHz\\n\");\n> +\t\t}\n> +\n> \t\timpl = (u8) MIDR_IMPLEMENTOR(midr);\n> \t\tfor (j = 0; hw_implementer[j].id != 0; j++) {\n> \t\t\tif (hw_implementer[j].id == impl) {\n> @@ -208,7 +341,7 @@ static int c_show(struct seq_file *m, void *v)\n> \t\tpart = (u16) MIDR_PARTNUM(midr);\n> \t\tfor (j = 0; parts[j].id != (-1); j++) {\n> \t\t\tif (parts[j].id == part) {\n> -\t\t\t\tseq_printf(m, \"%s\\n\", parts[j].name);\n> +\t\t\t\tseq_printf(m, \"%s \", parts[j].name);\n> \t\t\t\tbreak;\n> \t\t\t}\n> \t\t}\n> -- \n> 2.13.5\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"ENiWVOn9\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2G6p6zcgz9tXp\n\tfor ;\n\tWed, 27 Sep 2017 21:38:42 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxAfn-0005PQ-QD; Wed, 27 Sep 2017 11:38:39 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxAfk-0005KY-Jb for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 11:38:38 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5F4C280D;\n\tWed, 27 Sep 2017 04:38:16 -0700 (PDT)","from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t07A473F589; Wed, 27 Sep 2017 04:38:14 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=EHL48D1vMpB5y94Kno34zO4mzLo/279lH35C90BJGCw=;\n\tb=ENiWVOn9slvr+t\n\t9QnVXeIzfoXtvwFTpy1gT5FRvKhzzGdHdU0ya97NQzkEwexGMduZsyBkbTBkbLJz0doSG1Lz/J+jm\n\tDVOkQGc146wxXPdgS7UrkJI7QFRLWszIpu7IGCg8tsGjTKxTDvJMtOITMmEHJFKCRdWtChTh0ah8d\n\tp4hLcRCzl1Zomid5+YlKjJo8t72c3wd50k6Pq4D9U4VnrbGsZTFKEQ7GYF37TB3qApDADi8yz51FS\n\tMU/GknjzQSha8Dyx2CXUW/4Op2Ap/dmtZxipwE+70eCLO68IkJiorhgqz2M+PCiOV+0y5ymU+nBYQ\n\t4JF5PEbnzo/P6WtGei2g==;","Date":"Wed, 27 Sep 2017 12:36:48 +0100","From":"Mark Rutland ","To":"Al Stone ","Subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","Message-ID":"<20170927113648.GF32150@leverpostej>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-4-ahs3@redhat.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170926222324.17409-4-ahs3@redhat.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_043836_661381_B21B474F ","X-CRM114-Status":"GOOD ( 21.87 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Catalin Marinas ,\n\tWill Deacon , linux-kernel@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org,\n\tSuzuki K Poulose ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776352,"web_url":"http://patchwork.ozlabs.org/comment/1776352/","msgid":"<20170927133931.GH32150@leverpostej>","list_archive_url":null,"date":"2017-09-27T13:39:32","subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi,\n\nOn Wed, Sep 27, 2017 at 11:42:07AM +0100, Robin Murphy wrote:\n> On 26/09/17 23:23, Al Stone wrote:\n> > +\t\t\tseq_printf(m, \", ARM 8.%d (r%dp%d) CPU\",\n> > +\t\t\t\t MIDR_VARIANT(midr),\n> > +\t\t\t\t MIDR_VARIANT(midr),\n> > +\t\t\t\t MIDR_REVISION(midr));\n> \n> What is \"ARM 8.1\" meant to infer for, say, a typical Cortex-A57?\n\nJust to make Robin's point a little clearer, MIDR_EL1.Variant is\nIMPLEMENTATION DEFINED, and doesn't describe the ARMv8.x architecture\nrevision.\n\nFor example, on Cortex A57 is contains the major revision number of the\nCPU, and is 1 for any r1pY Cortex-A57 (e.g. those on Juno R1).\n\nFor better or worse, the architecture provides us no mechanism to\ndetermine the architecture revision.\n\nThanks,\nMark.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"sC7u3O9x\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2JrS6Yb0z9sRm\n\tfor ;\n\tWed, 27 Sep 2017 23:41:28 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxCaZ-0000Dn-VA; Wed, 27 Sep 2017 13:41:23 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxCaW-0000Ba-TB for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 13:41:22 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 072781529;\n\tWed, 27 Sep 2017 06:41:00 -0700 (PDT)","from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tA47EE3F589; Wed, 27 Sep 2017 06:40:58 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=9qodfwCZQSph/HFN6/3t26LDuWTps+HJo2ihwaJTlt4=;\n\tb=sC7u3O9xSE+4NH\n\t+nbwWFPrKq+XoESvkqW01WoFlcUVFr/vWSjoi/pRwqTxSsBxxJfzAvzNV5NDAxnrzDR4FOaHkRrzP\n\t2+sWyDcTCOJQc81+yzURjbF4DTG53ZlsWQD4/FrvOl6GK1SrPBOf4Fhxi2YTufvgA7Velt9XH7Nyh\n\tnqIOrMRBdManhL3I3aD6JPNKR28ofyHOHGQjSmnExKG+Zw/n09IiSjN5iwuUbGQ3pjJUmmLs4VRPM\n\tqn7jOVcdc52h2rJm08EewpilMF3rU+oUfOnrTdAyMjD+1jwlQ9FNp7uMtkHG2lDb4q5Cxzw6KF61s\n\t+qIXmMvYA3GXpzv8KgOw==;","Date":"Wed, 27 Sep 2017 14:39:32 +0100","From":"Mark Rutland ","To":"Robin Murphy ","Subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","Message-ID":"<20170927133931.GH32150@leverpostej>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-4-ahs3@redhat.com>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_064120_954819_E22AEC39 ","X-CRM114-Status":"UNSURE ( 8.66 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Suzuki K Poulose ,\n\tCatalin Marinas ,\n\tWill Deacon , \n\tlinux-kernel@vger.kernel.org, Al Stone ,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1783292,"web_url":"http://patchwork.ozlabs.org/comment/1783292/","msgid":"<7e1bd635-8c17-634e-aaae-ac7ec4a1e351@redhat.com>","list_archive_url":null,"date":"2017-10-09T22:46:17","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":64880,"url":"http://patchwork.ozlabs.org/api/people/64880/","name":"Al Stone","email":"ahs3@redhat.com"},"content":"On 09/27/2017 04:34 AM, Mark Rutland wrote:\n> On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:\n>> As ARMv8 servers get deployed, I keep getting the same set of questions\n>> from end-users of those systems: what do all the hex numbers mean in \n>> /proc/cpuinfo and could you make them so I don't have to carry a cheat\n>> sheet with me all the time?\n> \n> I appreciate that /proc/cpuinfo can be opaque to end users, but I do not\n> believe that this is the right solution to that problem.\n> \n> There are a number of issues stemming from the face that /proc/cpuinfo\n> is ill-defined and overused for a number of cases. Changes to it almost\n> certainly violate brittle de-facto ABI details people are relying on,\n> and there's a very long tail on fallout resulting from this. In\n> addition, many niceties come at an excessive maintenance cost, and are\n> simply unreliable as an ABI.\n\nInstead of dealing with the replies to the specific patches, I'd like to deal\nwith the real gist of the matter first -- details can be worked out later.\n\nWhile I don't disagree -- cpuinfo is enormously fragile -- what _is_ a good\nsolution, then? Right now, things are not terribly useful. Yes, it is true\n/sys/firmware/dmi has info in it, but again it is all numeric (or in a file\nnamed 'raw'). Any one who wishes to read the values will need to put some\ninterpretation on them somehow. My personal preference is that the kernel\ncontrol that interpretation instead of random admin tools scattered over a raft\nof different companies.\n\n> So, as with all other patches modifying /proc/cpuinfo, I must NAK this\n> series.\n\nHrm. I suggest that policy needs to be rethought. I understand the reasoning,\nbut it puts my end-users in a very difficult position; they now have to justify\nmodifying management software that is already in operation in order to purchase\nand integrate ARM servers. And while I really don't want distro-specific code,\nI'd have to consider it as a possibility.\n\nTo be completely fair, though, I'm not completely fixated on cpuinfo as the only\npossible answer. It has been the most requested, however.\n\n> For the MPIDR and product info, I think we can expose this in a more\n> structured way (e.g. under sysfs). IIUC the product info is all derived\n> from DMI -- do we not expose that already?\n\nAgreed; the MPIDR I think could just as easily be in /sys/devices/cpu/* as\na hex value. It doesn't have the value to end-users that the other info does,\neither -- for debugging, definitely, but not necessarily sysadmin. I'll put\nsomething together for this.\n\nThe DMI info is in sysfs but it is not in a fashion normally consumed, hence\nthe questions from end-users, in a way. They're not expecting to have to do\nthe interpretation, and they are expecting the platform to be able to tell\nthem what \"Model: 2\" means.\n\n> For the human-readable names I must NAK such patches. This is an\n> extremely brittle ABI that cannot be forwards compatible, and comes with\n> hilarious political problems. This should be managed in userspace alone.\n> \n> I thought tools like lscpu and lshw were intended to gather such\n> information for users. What are these missing today?\n\nAll of the above human-readable parts -- lscpu reads model information from\n/proc/cpuinfo, for example, and would require new code to read this info from\nsomewhere else, and then figure out how to interpret it. All I get is a lovely\n'2' for 'model' :). We could obviously change the userspace tools, but I'm\nguessing it just moves the political hilarity from the kernel to userspace,\ncorrect? It also runs the risk of even greater silliness, like perhaps lscpu\ngets a product name right, but lshw calls it something different, and so on.\n\nThe other approach that occurs to me is to blend what x86 does and sysfs; i.e.,\nwould it be acceptable to modify cputype.h to include comments (as x86 does)\nthat are then munged by a script somewhat like arch/x86/kernel/cpu/mkcapflags.sh\nthat then produces a header file with proper human-readable content that can\nthen be exposed in sysfs? I don't think we can ever remove the brittleness\ncompletely, but perhaps this would at least mitigate it. This would still\nrequire userspace modifications, too, but they could at least rely on a uniform\nsource of data -- and perhaps a single place to focus when hilarity ensues :).\nI'll bodge some patches together and maybe start over as an RFC, if there's a\nchance this would be accepted.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"apdhiJ8B\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y9wNB4Sksz9t5R\n\tfor ;\n\tTue, 10 Oct 2017 09:46:50 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e1gow-0006nD-Km; Mon, 09 Oct 2017 22:46:46 +0000","from mail-io0-f171.google.com ([209.85.223.171])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e1gor-0006jN-HT for linux-arm-kernel@lists.infradead.org;\n\tMon, 09 Oct 2017 22:46:44 +0000","by mail-io0-f171.google.com with SMTP id z187so22420924ioz.12\n\tfor ;\n\tMon, 09 Oct 2017 15:46:20 -0700 (PDT)","from fidelio.ahs3 (c-67-165-232-89.hsd1.co.comcast.net.\n\t[67.165.232.89]) by smtp.gmail.com with ESMTPSA id\n\th81sm4634846itb.18.2017.10.09.15.46.18\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 09 Oct 2017 15:46:18 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:Reply-To:List-Subscribe:List-Help:\n\tList-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date\n\t:Message-ID:From:References:To:Subject:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=8WtFSmnpH5Ho2Oj8XDk1TMhoM8QxZKm8if7aql5znJk=;\n\tb=apdhiJ8Bh9LoC0\n\tWgzUsSOiUtumOEig7/UaPvCbC3L5diq0J78qelSyU7kCqU6I+Y+2A6+QdGVYmvqxz1DjvhG/6MPW7\n\tqKY9PDnWsYZIlxPqxNo5pwnrhGfxP3x5ZIYa8k2U+cNJglQjAOukNIKeXAiFGzmnf2ZDu+ciND+VF\n\tj4AiHvCUD/urwTbx7EkOHI3h8jxcyuGBLgx569DpHAr0OcjnL9ylukSUVFk8YkrtAMiP8qJoWPOPu\n\t8yEcmVaHkln5vz0QvHUmlFOINCalRFHB3rpA+R4MG4IKLe6iaOcUHfm8QW3vh1SVjNJb+PmHfyhKE\n\taE4LKuyqtogsm/PaPblA==;","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:reply-to:subject:to:cc:references:from\n\t:organization:message-id:date:user-agent:mime-version:in-reply-to\n\t:content-language:content-transfer-encoding;\n\tbh=1dHwkryYFTvwtz4vjkPbazYsLt2+1GfeWx36IipQq88=;\n\tb=jK8xKi5lMLMnZR6trv/VWbDSxG9dABQxtNRW3JZnD0lndtvaRgCiAKUPZITFoexgHm\n\tz2Mec35mOAUUfL0wbSXX8da6GeA+B/5/KTnDpejo/4hCmgmOjqwXDNmDme5Ebx5Dqn+h\n\tSsEcS1ZGGJZJ2LBL2zBNYBGcRoTMSYFXQPxzzbBT4EgOhyNrhLbquRXskFIqAL0g2glK\n\tIQBwGaomiIFf0TTRoJM4HQO1HYgkQXYGg/vdFjov6cH5vnzWIJeJFWnPszBpTnc1HIF0\n\tqJufOi86RcGGl9zCej2IsnkuBE1+37akZ/U1s977+iCrBiEzBkqZqEH8PURfchO/ZnR+\n\tL7XQ==","X-Gm-Message-State":"AMCzsaXkKUKn7EaaPNbHRcv9l2xJerFFsF9wWnGJv3eoPCGdbXVO2cia\n\tE8nvRUEfvmvB2cCZcncCFFFjJJJibXw=","X-Google-Smtp-Source":"AOwi7QBd+s7g8f60cDzgoWa623nNLajogbkBz/of2Yp7zCWfC1zwZAlj6J8Wd1DzU9VhJZ+w9FwKag==","X-Received":"by 10.107.129.166 with SMTP id l38mr7769549ioi.244.1507589179320;\n\tMon, 09 Oct 2017 15:46:19 -0700 (PDT)","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","To":"Mark Rutland ","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>","From":"Al Stone ","Organization":"Red Hat, Inc.","Message-ID":"<7e1bd635-8c17-634e-aaae-ac7ec4a1e351@redhat.com>","Date":"Mon, 9 Oct 2017 16:46:17 -0600","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170927103406.GC32150@leverpostej>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171009_154641_619793_8D8A12E3 ","X-CRM114-Status":"GOOD ( 24.26 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.223.171 listed in dnsbl.sorbs.net]\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno trust [209.85.223.171 listed in list.dnswl.org]\n\t-2.8 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)\n\t[209.85.223.171 listed in wl.mailspike.net]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"ahs3@redhat.com","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1786281,"web_url":"http://patchwork.ozlabs.org/comment/1786281/","msgid":"","list_archive_url":null,"date":"2017-10-13T13:39:09","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":66858,"url":"http://patchwork.ozlabs.org/api/people/66858/","name":"Timur Tabi","email":"timur@codeaurora.org"},"content":"On Wed, Sep 27, 2017 at 5:34 AM, Mark Rutland wrote:\n> Hi Al,\n>\n> On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:\n>> As ARMv8 servers get deployed, I keep getting the same set of questions\n>> from end-users of those systems: what do all the hex numbers mean in\n>> /proc/cpuinfo and could you make them so I don't have to carry a cheat\n>> sheet with me all the time?\n>\n> I appreciate that /proc/cpuinfo can be opaque to end users, but I do not\n> believe that this is the right solution to that problem.\n>\n> There are a number of issues stemming from the face that /proc/cpuinfo\n> is ill-defined and overused for a number of cases. Changes to it almost\n> certainly violate brittle de-facto ABI details people are relying on,\n> and there's a very long tail on fallout resulting from this. In\n> addition, many niceties come at an excessive maintenance cost, and are\n> simply unreliable as an ABI.\n>\n> So, as with all other patches modifying /proc/cpuinfo, I must NAK this\n> series.\n\nQualcomm Datacenter Technologies is very interested in seeing these\npatches (or some variant of them) accepted. Updates to /proc/cpuinfo\nare long overdue, and I'm asking you to reconsider your objections.\nWe're willing to work with distro vendors to get this information\nadded to their products while upstream is left behind, but I hope that\nwon't be necessary.\n\nI would even go so far as to say that we should be making\n/proc/cpuinfo for ARM match the x86 output as closely as possible,\neven using their terminology. We should be providing information like\nfrequencies and product names.\n\nHaving a human-readable /proc/cpuinfo with extensive details of the\nCPU spelled out is very useful, and Al's reasoning is valid. The fact\nthat it's \"fragile\" is not as important as the fact that on x86,\n/proc/cpuinfo is much more useful.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"Owb/4d+E\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"nu3W/4fF\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n\theader.d=codeaurora.org header.i=@codeaurora.org header.b=\"Rgm6DXSt\"; \n\tdkim-atps=neutral","pdx-caf-mail.web.codeaurora.org;\n\tdmarc=none (p=none dis=none) header.from=codeaurora.org","pdx-caf-mail.web.codeaurora.org;\n\tspf=none smtp.mailfrom=timur@codeaurora.org"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yD8304tKdz9sRm\n\tfor ;\n\tSat, 14 Oct 2017 00:39:40 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e30Bc-0008LH-TE; Fri, 13 Oct 2017 13:39:36 +0000","from smtp.codeaurora.org ([198.145.29.96])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e30BY-0008Al-SD for linux-arm-kernel@lists.infradead.org;\n\tFri, 13 Oct 2017 13:39:34 +0000","by smtp.codeaurora.org (Postfix, from userid 1000)\n\tid C899461BB1; Fri, 13 Oct 2017 13:39:11 +0000 (UTC)","from mail-oi0-f48.google.com (mail-oi0-f48.google.com\n\t[209.85.218.48])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\t(Authenticated sender: timur@smtp.codeaurora.org)\n\tby smtp.codeaurora.org (Postfix) with ESMTPSA id 0D1C461AFC\n\tfor ;\n\tFri, 13 Oct 2017 13:39:10 +0000 (UTC)","by mail-oi0-f48.google.com with SMTP id c202so14185296oih.9\n\tfor ;\n\tFri, 13 Oct 2017 06:39:10 -0700 (PDT)","by 10.157.14.9 with HTTP; Fri, 13 Oct 2017 06:39:09 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=E7La1XhneJNB+BK2hFwcggwTWePH1WcLUWkaBhkNBns=;\n\tb=Owb/4d+ET5zfYB\n\t67TBTCc3hjWcQS/u4dvCjpXJQaegSlxbd1uWz3kNhFU5EaOESVADCO7DTSzadD803BwNAe1foU3JV\n\tNvAp6PS2FM3e6MJbF31om/kM9/sdNSbxX2xzOtek+wwrPt6ov0CVyRgzw2s6ds/wYNCQYDbNJrZK3\n\tzvG0IyV4fJTpXKQD5SsZMhEy0+QB7esBr2kcm7BcXdVKqwWC8YenbEdgWW4yMatoiLfcCk3YheHbN\n\tpXY58awFO1VuX5rUPcdbKUpiRvnl2fEXAKILCgnAUkJvkd2dX6g37nGYjtvkaeY8xbZ516pZVZMO8\n\tTV1FmMeTGJsYaKWX4juQ==;","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507901952;\n\tbh=56GfLg1g0hMoRsKgqxpd0XcmtOjtxZr2ALPH2mcPCC8=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=nu3W/4fFV0Up9ynIKgkxkfvYyrK1dGXR+3hxSp1MGU56gJWh1Nvw7dFFXrJ5kQsPB\n\tB38orHxscNNEluenXEZ4uQ5ZjL/mbMzvWtYt8ifXufOZSn6EthnHh6ERhNvEIFpaLs\n\tJSiVjN0C/vf0XQ+bt5jMx0lTiQI8pflEZyQ4B/yw=","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507901951;\n\tbh=56GfLg1g0hMoRsKgqxpd0XcmtOjtxZr2ALPH2mcPCC8=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=Rgm6DXStITYQVWiQQ3vZYA8VnUfHzKXezhdOw51v04SevF8l1Glzvx00Cu0aAho3u\n\tmoR65j2PjeAT1objqjwce54KSzXrQS64bIMBHOpd2Yxr90Awh3EQJxxkvm/yJ7y6YF\n\t4tDnv+0FXF7jF+2zLayvLmysZGTD6eUihZ5kBzy8="],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tpdx-caf-mail.web.codeaurora.org","X-Spam-Level":"","X-Spam-Status":"No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00,\n\tDKIM_SIGNED,\n\tT_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0","DMARC-Filter":"OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0D1C461AFC","X-Gm-Message-State":"AMCzsaUe7M4XtdRlsvFIfySETu5gR475MKLIztxim4tGDNEa02TsOebf\n\tZJBTF0x1xq9JOUIWjobFHNfmWwc+F3DXwjSInRE=","X-Google-Smtp-Source":"AOwi7QBxEr6XHtFe3TFyM6u5FITnW/XOExW2m11HCrwjL0TkG0LJFrrtec2Lai5FTPEPJ91LbNAUynQBgEFiP1LtPm4=","X-Received":"by 10.157.11.193 with SMTP id 59mr965678oth.19.1507901950325;\n\tFri, 13 Oct 2017 06:39:10 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170927103406.GC32150@leverpostej>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>","From":"Timur Tabi ","Date":"Fri, 13 Oct 2017 08:39:09 -0500","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","To":"Mark Rutland ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171013_063932_966917_6EEAF774 ","X-CRM114-Status":"GOOD ( 16.97 )","X-Spam-Score":"-3.8 (---)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-3.8 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [198.145.29.96 listed in list.dnswl.org]\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.218.48 listed in dnsbl.sorbs.net]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"rruigrok@codeaurora.org, Jon Masters ,\n\tAl Stone , \"linux-arm-kernel@lists.infradead.org\"\n\t, \n\tlkml ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1786323,"web_url":"http://patchwork.ozlabs.org/comment/1786323/","msgid":"","list_archive_url":null,"date":"2017-10-13T14:16:52","subject":"Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to\n\t/proc/cpuinfo","submitter":{"id":66858,"url":"http://patchwork.ozlabs.org/api/people/66858/","name":"Timur Tabi","email":"timur@codeaurora.org"},"content":"On Tue, Sep 26, 2017 at 5:23 PM, Al Stone wrote:\n> In the interest of making things easier for humans to use, add a\n> \"CPU name\" line to /proc/cpuinfo for each CPU that uses plain old\n> words instead of hex values. For example, instead of printing only\n> CPU implementer 0x43 and CPU part 0x0A1, print also \"CPU name :\n> Cavium ThunderX\".\n>\n> Note that this is not meant to be an exhaustive list of all possible\n> implementers or CPUs (I'm not even sure that is knowable); this patch\n> is intentionally limited to only those willing to provide info in\n> arch/arm64/include/asm/cputype.h\n>\n> Signed-off-by: Al Stone \n> Cc: Catalin Marinas \n> Cc: Will Deacon \n> Cc: Suzuki K Poulose \n> Cc: Mark Rutland \n> ---\n> arch/arm64/kernel/cpuinfo.c | 84 +++++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 84 insertions(+)\n>\n> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c\n> index e505007138eb..0b4261884862 100644\n> --- a/arch/arm64/kernel/cpuinfo.c\n> +++ b/arch/arm64/kernel/cpuinfo.c\n> @@ -75,6 +75,61 @@ static const char *const hwcap_str[] = {\n> NULL\n> };\n>\n> +struct hw_part {\n> + u16 id;\n> + char *name;\n\nconst char *name ?\n\n> +};\n> +\n> +static const struct hw_part arm_hw_part[] = {\n> + { ARM_CPU_PART_AEM_V8, \"AEMv8 Model\" },\n\nAEMv8?\n\n> + { ARM_CPU_PART_FOUNDATION, \"Foundation Model\" },\n> + { ARM_CPU_PART_CORTEX_A57, \"Cortex A57\" },\n> + { ARM_CPU_PART_CORTEX_A53, \"Cortex A53\" },\n> + { ARM_CPU_PART_CORTEX_A73, \"Cortex A73\" },\n> + { (-1), \"unknown\" } /* Potenza == 0, unfortunately */\n\nSince Potenza is an Applied Micro CPU, why is this comment here?\n\n> +static const struct hw_part apm_hw_part[] = {\n> + { APM_CPU_PART_POTENZA, \"Potenza\" },\n> + { (-1), \"unknown\" } /* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part brcm_hw_part[] = {\n> + { BRCM_CPU_PART_VULCAN, \"Vulcan\" },\n> + { (-1), \"unknown\" } /* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part cavium_hw_part[] = {\n> + { CAVIUM_CPU_PART_THUNDERX, \"ThunderX\" },\n> + { CAVIUM_CPU_PART_THUNDERX_81XX, \"ThunderX 81XX\" },\n> + { CAVIUM_CPU_PART_THUNDERX_83XX, \"ThunderX 83XX\" },\n> + { (-1), \"unknown\" } /* Potenza == 0, unfortunately */\n> +};\n> +\n> +static const struct hw_part qcom_hw_part[] = {\n> + { QCOM_CPU_PART_FALKOR_V1, \"Falkor v1\" },\n\nI guess we should upstream our other part IDs.\n\n> + impl = (u8) MIDR_IMPLEMENTOR(midr);\n> + for (j = 0; hw_implementer[j].id != 0; j++) {\n> + if (hw_implementer[j].id == impl) {\n> + seq_printf(m, \"CPU name\\t: %s \",\n> + hw_implementer[j].name);\n> + parts = hw_implementer[j].parts;\n> + break;\n> + }\n> + }\n> + if (hw_implementer[j].id == 0) {\n> + seq_printf(m, \"CPU name\\t: %s \",\n> + hw_implementer[j].name);\n> + parts = hw_implementer[j].parts;\n> + }\n\nIs this intended to handle Potenza? I don't understand why a part ID\nof 0 is such a problem.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"EMmibkjh\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"SUH/DrMS\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n\theader.d=codeaurora.org header.i=@codeaurora.org header.b=\"AwiyXg8J\"; \n\tdkim-atps=neutral","pdx-caf-mail.web.codeaurora.org;\n\tdmarc=none (p=none dis=none) header.from=codeaurora.org","pdx-caf-mail.web.codeaurora.org;\n\tspf=none smtp.mailfrom=timur@codeaurora.org"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yD8tZ4W13z9sNr\n\tfor ;\n\tSat, 14 Oct 2017 01:17:26 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e30mB-0005ei-Lw; Fri, 13 Oct 2017 14:17:23 +0000","from smtp.codeaurora.org ([198.145.29.96])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e30m4-0005aT-74 for linux-arm-kernel@lists.infradead.org;\n\tFri, 13 Oct 2017 14:17:21 +0000","by smtp.codeaurora.org (Postfix, from userid 1000)\n\tid 290F3619EC; Fri, 13 Oct 2017 14:16:55 +0000 (UTC)","from mail-oi0-f41.google.com (mail-oi0-f41.google.com\n\t[209.85.218.41])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\t(Authenticated sender: timur@smtp.codeaurora.org)\n\tby smtp.codeaurora.org (Postfix) with ESMTPSA id F133561996\n\tfor ;\n\tFri, 13 Oct 2017 14:16:53 +0000 (UTC)","by mail-oi0-f41.google.com with SMTP id j126so14505905oib.8\n\tfor ;\n\tFri, 13 Oct 2017 07:16:53 -0700 (PDT)","by 10.157.14.9 with HTTP; Fri, 13 Oct 2017 07:16:52 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=Dgkhhi8nX0+lHdo6HJM/jrIdLb5IQW/n4klsPldw0GE=;\n\tb=EMmibkjhGzIB4j\n\t+j2cHJzi3UbEwOeV3cnfzTUTxjtKZaoJuk3Y7HRtuhTMt9jKuEeSQdW/sf2cv9z5GDVB4HZ/U3y0o\n\t7G2CXE6x6cK+YeK99uYFDpEMku2soNz8d3dPCsWeRUFgexJXrPHVE2G9Ir5Zaywo5Gd76nzwxf+7D\n\tNuDbhQ5mNNtDMQVy+qWGBl3jWezucnShdXJTCCNkNQ3OOcXj9CHUXoEEhT6MeFv9+jpdk7QXynQEl\n\tJci6/Wg0SHT7jxhWpf2u999/M1BkL17zLqYEh0W9rfFo16yf4sKY91Z1vzgaPD8vsmzC2T88o9haS\n\tJaznQLOpnKE/nKgYEN4A==;","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507904215;\n\tbh=FMQcf3med3Vpa35r9xN/d9bu4aM0GeJ/DKOZrV71yr8=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=SUH/DrMSxP+dx/TY2Mgd6ypAD9QYEfvTDNI+xAFpdPNbDbjCftdltc4NIiHs8s0L+\n\tgG6yO95TBpvX1oR8ppFngMVtPZIkrsEYS57klu+cx8JYcTKTScJTwMtrdqA6VeGawi\n\th41fuQvMMdypnqwLkQxIgd+wa3LTaVOvLxSkG6tw=","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507904214;\n\tbh=FMQcf3med3Vpa35r9xN/d9bu4aM0GeJ/DKOZrV71yr8=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=AwiyXg8JyHppRcisGpqoRdM+h7/QY74cQwuIucxDCFh52ehnK3hUoTYc8zSxCV2p4\n\tend8WtUdmBA34xEnirwMB7AVl/Od923DbChiA8ELBWIffF6/SlXUDvi0+UW4vGCG1D\n\t6+PJS+PNkfnj9iHu1hN9cURfS1HoMY87ZvDG7N1A="],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tpdx-caf-mail.web.codeaurora.org","X-Spam-Level":"","X-Spam-Status":"No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00,\n\tDKIM_SIGNED,\n\tT_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0","DMARC-Filter":"OpenDMARC Filter v1.3.2 smtp.codeaurora.org F133561996","X-Gm-Message-State":"AMCzsaVETjonIypudoO19Lcmo9rPer837eV+b7z6FtAe24AwR6QLwMjs\n\t07uEsyGSBkrJzFhwWFIJgX//H/CVD2Oaru3IFdw=","X-Google-Smtp-Source":"ABhQp+RiLR/LbBpywpkN96UG5FL77IeE95jXstJ73zv2lDudAgLfO8wI39eg5AW9wPQk/LR5I8xVB0RrGN3fW3yHMcc=","X-Received":"by 10.157.72.168 with SMTP id d37mr1038419otf.446.1507904212997; \n\tFri, 13 Oct 2017 07:16:52 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170926222324.17409-3-ahs3@redhat.com>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-3-ahs3@redhat.com>","From":"Timur Tabi ","Date":"Fri, 13 Oct 2017 09:16:52 -0500","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to\n\t/proc/cpuinfo","To":"Al Stone ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171013_071716_328573_DB143F66 ","X-CRM114-Status":"GOOD ( 19.81 )","X-Spam-Score":"-3.8 (---)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-3.8 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.218.41 listed in dnsbl.sorbs.net]\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [198.145.29.96 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Mark Rutland ,\n\tSuzuki K Poulose ,\n\tCatalin Marinas ,\n\tWill Deacon , lkml ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1786339,"web_url":"http://patchwork.ozlabs.org/comment/1786339/","msgid":"<20171013142724.GA5893@leverpostej>","list_archive_url":null,"date":"2017-10-13T14:27:25","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi Timur,\n\nOn Fri, Oct 13, 2017 at 08:39:09AM -0500, Timur Tabi wrote:\n> On Wed, Sep 27, 2017 at 5:34 AM, Mark Rutland wrote:\n> > On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:\n> >> As ARMv8 servers get deployed, I keep getting the same set of questions\n> >> from end-users of those systems: what do all the hex numbers mean in\n> >> /proc/cpuinfo and could you make them so I don't have to carry a cheat\n> >> sheet with me all the time?\n> >\n> > I appreciate that /proc/cpuinfo can be opaque to end users, but I do not\n> > believe that this is the right solution to that problem.\n> >\n> > There are a number of issues stemming from the face that /proc/cpuinfo\n> > is ill-defined and overused for a number of cases. Changes to it almost\n> > certainly violate brittle de-facto ABI details people are relying on,\n> > and there's a very long tail on fallout resulting from this. In\n> > addition, many niceties come at an excessive maintenance cost, and are\n> > simply unreliable as an ABI.\n> >\n> > So, as with all other patches modifying /proc/cpuinfo, I must NAK this\n> > series.\n> \n> Qualcomm Datacenter Technologies is very interested in seeing these\n> patches (or some variant of them) accepted. Updates to /proc/cpuinfo\n> are long overdue, and I'm asking you to reconsider your objections.\n\nI more than appreciate that there is information that people want access\nto, and I'd really like to expose that in a consistent and structured\nmanner.\n\nSo please propose exposing the information elsewhere, which I would be\nmore than happy with for information that the kernel already has access\nto.\n\nI object to /proc/cpuinfo changes because they impose an ABI break, and\nbecause some of the proposed changes impose new and requirements on the\nkernel that cannot be maintained in a forwards-compatible manner (which\nis liable to result in other ABI breaks).\n\nFor better or worse, we're stuck with the existing arch-specific format\nof /proc/cpuinfo, as this is parsed by a wide variety of applications,\nand any change risks breaking these.\n\n> We're willing to work with distro vendors to get this information\n> added to their products while upstream is left behind, but I hope that\n> won't be necessary.\n\nPlease understand that this is an ABI break, and that is why it is being\nNAK'd.\n\nI don't have the power to stop Red Hat or other vendors from\ndeliberately breaking ABI, but I would very strongly recommend that they\ndo not.\n\n> I would even go so far as to say that we should be making\n> /proc/cpuinfo for ARM match the x86 output as closely as possible,\n\nAs has been stated before, /proc/cpuinfo is an existing arch-specific ABI.\n\nFor better or worse, we're stuck with it as-is, regardless of what could\nbe nicer had we done something different from the outset.\n\nIt has never been portable across architectures, and applications\nrelying upon it have never been portable except by chance.\n\n> even using their terminology. We should be providing information like\n> frequencies and product names.\n\nAs has been stated before, the problem with exposing these is that we\ndon't have the relevant information.\n\nWe have no consistent mechanism for acquiring product names, and for\nthose cases where it is truly necessary to identify an implementation,\nthe MIDR+REVIDR provide the exact same information.\n\nFor frequencies, I'd be more than happy to expose this information when\nwe have it, in new files. In practice today, we do not have this\ninformation most of the time.\n\n> Having a human-readable /proc/cpuinfo with extensive details of the\n> CPU spelled out is very useful, and Al's reasoning is valid. The fact\n> that it's \"fragile\" is not as important as the fact that on x86,\n> /proc/cpuinfo is much more useful.\n\nI must disagree.\n\nWe care about that fragility so that we do not break userspace, which is\nthe most important upstream rule.\n\nI certainly agree that exposing the information that we have is useful,\nas I have stated several times. I'm not NAKing exposing this information\nelsewhere.\n\nIf you want a consistent cross-architecture interface for this\ninformation, then you need to propose a new one. That was we can\nactually solve the underlying issues, for all architectures, without\nbreaking ABI.\n\nI would be *very* interested in such an interface, and would be more\nthan happy to help.\n\nThanks,\nMark.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"tSVex7ZN\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yD9720XJ3z9sRV\n\tfor ;\n\tSat, 14 Oct 2017 01:28:14 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e30wa-0004jL-Ej; Fri, 13 Oct 2017 14:28:08 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e30wL-0004NB-BT for linux-arm-kernel@lists.infradead.org;\n\tFri, 13 Oct 2017 14:28:05 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 243F71529;\n\tFri, 13 Oct 2017 07:27:33 -0700 (PDT)","from leverpostej (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tE54373F3E1; Fri, 13 Oct 2017 07:27:31 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=3MgXSzxQv5CTmJ+DBd4PU7/d2pColaAJCC8iMhoiVno=;\n\tb=tSVex7ZNErSTOX\n\t0FBV3oJGwUFTT/TiQvA0FvYJC50SdjuSE3Q4e80WnXmlP8TixjcH+39+peo6EuRXSQLi9+qIBw5bF\n\t6TmmUnFaEOvIKEto0D1g9CAM/IizIwu8oUVFfpfvdtvd0XRrn3Ya6bIwFsR3hSxjMEiBQhVofk6n2\n\twcoMBOWK6llNCjcSjWf2ASe265960zHnJi0OgS3TC+rhRguKVC+a1IV30FRK7NC+uPQ8r83h+rKO5\n\tMuloL3LqO3CLNHJfyEiWNgBey/p8f3ohBJsxzqHDcOLGUWjqQ2BU94yjzQW5mwTYLK7lx0e6KDI4E\n\tVtSp65mS4grai36StC0w==;","Date":"Fri, 13 Oct 2017 15:27:25 +0100","From":"Mark Rutland ","To":"Timur Tabi ","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","Message-ID":"<20171013142724.GA5893@leverpostej>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171013_072753_543291_59836882 ","X-CRM114-Status":"GOOD ( 24.58 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"rruigrok@codeaurora.org, Jon Masters ,\n\tAl Stone , \"linux-arm-kernel@lists.infradead.org\"\n\t, \n\tlkml ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1786603,"web_url":"http://patchwork.ozlabs.org/comment/1786603/","msgid":"","list_archive_url":null,"date":"2017-10-13T19:27:33","subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","submitter":{"id":66858,"url":"http://patchwork.ozlabs.org/api/people/66858/","name":"Timur Tabi","email":"timur@codeaurora.org"},"content":"On Tue, Sep 26, 2017 at 5:23 PM, Al Stone wrote:\n> + if (IS_ENABLED(CONFIG_DMI)) {\n> + seq_puts(m, \"product name\\t: \");\n> +\n> + if (!dmi_product_info)\n> + get_dmi_product_info();\n> + if (dmi_product_info)\n> + seq_printf(m, \"%s\", dmi_product_info);\n\nThis line prints out like this:\n\nproduct name : QUALCOMM BASEBOARD ASSEMBLY, AMBERWIN\n 20-P7989-H1S , ARM 8.0 (r0p0) CPU @ 2.500GHz\n\nIs this a bug in our DMI table? 'dmidecode' reports this:\n\nHandle 0x0004, DMI type 2, 17 bytes\nBase Board Information\n Manufacturer: QUALCOMM\n Product Name: BASEBOARD ASSEMBLY, AMBERWIN..\n Version: 20-P7989-H1S\n\nI'm guessing that the actual string has a CR/LF at the end of \"AMBERWIN\"","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"cbLJ1sxR\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=codeaurora.org header.i=@codeaurora.org\n\theader.b=\"YniagN3o\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key)\n\theader.d=codeaurora.org header.i=@codeaurora.org header.b=\"FHs9KIeu\"; \n\tdkim-atps=neutral","pdx-caf-mail.web.codeaurora.org;\n\tdmarc=none (p=none dis=none) header.from=codeaurora.org","pdx-caf-mail.web.codeaurora.org;\n\tspf=none smtp.mailfrom=timur@codeaurora.org"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yDHn04d4pz9sRV\n\tfor ;\n\tSat, 14 Oct 2017 06:28:04 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e35cn-00040W-HL; Fri, 13 Oct 2017 19:28:01 +0000","from smtp.codeaurora.org ([198.145.29.96])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e35ck-0003yZ-1u for linux-arm-kernel@lists.infradead.org;\n\tFri, 13 Oct 2017 19:27:59 +0000","by smtp.codeaurora.org (Postfix, from userid 1000)\n\tid CD9F761ADD; Fri, 13 Oct 2017 19:27:36 +0000 (UTC)","from mail-oi0-f50.google.com (mail-oi0-f50.google.com\n\t[209.85.218.50])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\t(Authenticated sender: timur@smtp.codeaurora.org)\n\tby smtp.codeaurora.org (Postfix) with ESMTPSA id 4598561AB1\n\tfor ;\n\tFri, 13 Oct 2017 19:27:35 +0000 (UTC)","by mail-oi0-f50.google.com with SMTP id h200so15827657oib.4\n\tfor ;\n\tFri, 13 Oct 2017 12:27:35 -0700 (PDT)","by 10.157.14.9 with HTTP; Fri, 13 Oct 2017 12:27:33 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=0oeJmqNH8a+l0xmkjIhbKua1HeKK9GfsrmKdeQffW4Y=;\n\tb=cbLJ1sxRIAQAI9\n\tMKS2Z8QGt/5+sqstH9wZBS7ZUihUHS7mwS0LuexzZnXqESa+kXURllg3aquG62WgTWp+rB/3VLJcM\n\twV1hJZaTd5xfrsEojBGv6jm6Nn2LhVlQPV0ZMe9iNogsFYr1WGiAgk0n6q+/cC7eUOuBmXJJHmVbH\n\tcEaG5DNM79cF31MKRrgr1tGCz77Mt0Sdx29RtFL+znGmp71aDEXRvkMhePjDJsJaI6QYSpBrOoBHw\n\tzQmDKVoxo+YcvU+OtVCaKypvghcYjzA/0M4HnJ43i+Q78dF+v6kwBYEqnygf3UskEErYDKs0hVcuA\n\tO0JTlr3Cf33YRApXg1sw==;","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507922857;\n\tbh=9un7KqVp7RboaVg9tUpKhMfCOyPrHWxtqIGNd31fmc4=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=YniagN3o5pWYhOS+SYZu18ofLbww25c9HXLp6GDQarKtA6GLTvkuxqkEaXZF7GDmC\n\tO2BpFmokZ4aSoflrfuEXsufGl3PjVxAhRRF+DAsCG+ZMur6V0VLxQHm2yNvyixwDv+\n\teQwZ6jh6NsHFFFs0B2xFUf59zgRcSw9IHuvxL6Sk=","v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org;\n\ts=default; t=1507922855;\n\tbh=9un7KqVp7RboaVg9tUpKhMfCOyPrHWxtqIGNd31fmc4=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=FHs9KIeugU75L87QOuDoxf7Vl/JacdHBzIODeR77gUQuE6Md7tQlVoLVfkel5TX/c\n\tId9DPRHFjQmQ5QmIspnLhsQ/HGDRDgE/Ysc5IfezwCf64RkM5FvQMmzyBI285qwZyc\n\tjaBGa4K5YtWPLTxCBxv8iJEoQAZk2yxJztKWcszI="],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tpdx-caf-mail.web.codeaurora.org","X-Spam-Level":"","X-Spam-Status":"No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00,\n\tDKIM_SIGNED,\n\tT_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0","DMARC-Filter":"OpenDMARC Filter v1.3.2 smtp.codeaurora.org 4598561AB1","X-Gm-Message-State":"AMCzsaU4NfS10ArW2SxEAQxTK+tZoT7C2zWQIUvYKDbHxMVZf8APpcMf\n\tKameV7NsptI+3feReiAiz0vvdpe/BwZr3OlviwY=","X-Google-Smtp-Source":"ABhQp+SopyND/gp5qc/rDffsLFNKrHu0d1psdBmj9TD91CGnIovjyVoeVRO7jK0xFALZhkWUQR+EPFr0YhxWY4qqEbo=","X-Received":"by 10.202.191.196 with SMTP id\n\tp187mr1299584oif.162.1507922854287; \n\tFri, 13 Oct 2017 12:27:34 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170926222324.17409-4-ahs3@redhat.com>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170926222324.17409-4-ahs3@redhat.com>","From":"Timur Tabi ","Date":"Fri, 13 Oct 2017 14:27:33 -0500","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH 3/3] arm64: cpuinfo: display product info in\n\t/proc/cpuinfo","To":"Al Stone ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171013_122758_192663_89ED3C22 ","X-CRM114-Status":"GOOD ( 12.82 )","X-Spam-Score":"-3.8 (---)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-3.8 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [198.145.29.96 listed in list.dnswl.org]\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.218.50 listed in dnsbl.sorbs.net]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Mark Rutland ,\n\tSuzuki K Poulose ,\n\tCatalin Marinas ,\n\tWill Deacon , lkml ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1787889,"web_url":"http://patchwork.ozlabs.org/comment/1787889/","msgid":"","list_archive_url":null,"date":"2017-10-16T23:43:19","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":64880,"url":"http://patchwork.ozlabs.org/api/people/64880/","name":"Al Stone","email":"ahs3@redhat.com"},"content":"On 10/13/2017 08:27 AM, Mark Rutland wrote:\n> Hi Timur,\n> \n> On Fri, Oct 13, 2017 at 08:39:09AM -0500, Timur Tabi wrote:\n>> On Wed, Sep 27, 2017 at 5:34 AM, Mark Rutland wrote:\n>>> On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:\n>>>> As ARMv8 servers get deployed, I keep getting the same set of questions\n>>>> from end-users of those systems: what do all the hex numbers mean in\n>>>> /proc/cpuinfo and could you make them so I don't have to carry a cheat\n>>>> sheet with me all the time?\n>>>\n>>> I appreciate that /proc/cpuinfo can be opaque to end users, but I do not\n>>> believe that this is the right solution to that problem.\n>>>\n>>> There are a number of issues stemming from the face that /proc/cpuinfo\n>>> is ill-defined and overused for a number of cases. Changes to it almost\n>>> certainly violate brittle de-facto ABI details people are relying on,\n>>> and there's a very long tail on fallout resulting from this. In\n>>> addition, many niceties come at an excessive maintenance cost, and are\n>>> simply unreliable as an ABI.\n>>>\n>>> So, as with all other patches modifying /proc/cpuinfo, I must NAK this\n>>> series.\n>>\n>> Qualcomm Datacenter Technologies is very interested in seeing these\n>> patches (or some variant of them) accepted. Updates to /proc/cpuinfo\n>> are long overdue, and I'm asking you to reconsider your objections.\n> \n> I more than appreciate that there is information that people want access\n> to, and I'd really like to expose that in a consistent and structured\n> manner.\n> \n> So please propose exposing the information elsewhere, which I would be\n> more than happy with for information that the kernel already has access\n> to.\n> \n> I object to /proc/cpuinfo changes because they impose an ABI break, and\n> because some of the proposed changes impose new and requirements on the\n> kernel that cannot be maintained in a forwards-compatible manner (which\n> is liable to result in other ABI breaks).\n> \n> For better or worse, we're stuck with the existing arch-specific format\n> of /proc/cpuinfo, as this is parsed by a wide variety of applications,\n> and any change risks breaking these.\n> \n>> We're willing to work with distro vendors to get this information\n>> added to their products while upstream is left behind, but I hope that\n>> won't be necessary.\n> \n> Please understand that this is an ABI break, and that is why it is being\n> NAK'd.\n> \n> I don't have the power to stop Red Hat or other vendors from\n> deliberately breaking ABI, but I would very strongly recommend that they\n> do not.\n> \n>> I would even go so far as to say that we should be making\n>> /proc/cpuinfo for ARM match the x86 output as closely as possible,\n> \n> As has been stated before, /proc/cpuinfo is an existing arch-specific ABI.\n> \n> For better or worse, we're stuck with it as-is, regardless of what could\n> be nicer had we done something different from the outset.\n> \n> It has never been portable across architectures, and applications\n> relying upon it have never been portable except by chance.\n> \n>> even using their terminology. We should be providing information like\n>> frequencies and product names.\n> \n> As has been stated before, the problem with exposing these is that we\n> don't have the relevant information.\n> \n> We have no consistent mechanism for acquiring product names, and for\n> those cases where it is truly necessary to identify an implementation,\n> the MIDR+REVIDR provide the exact same information.\n> \n> For frequencies, I'd be more than happy to expose this information when\n> we have it, in new files. In practice today, we do not have this\n> information most of the time.\n> \n>> Having a human-readable /proc/cpuinfo with extensive details of the\n>> CPU spelled out is very useful, and Al's reasoning is valid. The fact\n>> that it's \"fragile\" is not as important as the fact that on x86,\n>> /proc/cpuinfo is much more useful.\n> \n> I must disagree.\n> \n> We care about that fragility so that we do not break userspace, which is\n> the most important upstream rule.\n> \n> I certainly agree that exposing the information that we have is useful,\n> as I have stated several times. I'm not NAKing exposing this information\n> elsewhere.\n> \n> If you want a consistent cross-architecture interface for this\n> information, then you need to propose a new one. That was we can\n> actually solve the underlying issues, for all architectures, without\n> breaking ABI.\n> \n> I would be *very* interested in such an interface, and would be more\n> than happy to help.\n\nI'm playing with some patches that do very similar things in sysfs, vs\nproc. Is that better :)? Obviously, you'll have to see the patches to\nproperly answer that, but what I'm playing with at present is placing\nthis info in new entries in /sys/devices/cpu and/or /sys/devices/system,\nand generating some of the content based on what's already in header files\n(e.g., in cputype.h). The idea of course is to keep this new info from\ntouching any existing info so we don't break compatibility -- does that\nfeel like a better direction, at least?\n\n> Thanks,\n> Mark.\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"JuzTBNhW\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yGFJk1Z5Xz9sRn\n\tfor ;\n\tTue, 17 Oct 2017 10:43:50 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e4F2w-0006FW-TZ; Mon, 16 Oct 2017 23:43:46 +0000","from mail-it0-f54.google.com ([209.85.214.54])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e4F2t-0006Db-1K for linux-arm-kernel@lists.infradead.org;\n\tMon, 16 Oct 2017 23:43:45 +0000","by mail-it0-f54.google.com with SMTP id c3so341146itc.3\n\tfor ;\n\tMon, 16 Oct 2017 16:43:21 -0700 (PDT)","from fidelio.ahs3 (c-67-165-232-89.hsd1.co.comcast.net.\n\t[67.165.232.89]) by smtp.gmail.com with ESMTPSA id\n\tp127sm3532572itb.30.2017.10.16.16.43.19\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 16 Oct 2017 16:43:20 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:Reply-To:List-Subscribe:List-Help:\n\tList-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date\n\t:Message-ID:From:References:To:Subject:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=50s1xXsnLCTdqCXQqCf0fwSYLY++Qt8R3+0erf5pG+4=;\n\tb=JuzTBNhWNAD13n\n\tFmdaxZqSwLatuCx2XJM04hhwPMXjQMfhb5OOS894yf+CObcHf1P1vJwQwvNOQV3Q2ZRTxq8pHyHtg\n\tp1XMy59gd6uqjDzgwI8sAWKmc4NqyiRJrdZ5MEj26J3XGApXzCSHr+yrASx4p9KqRbLXnaSPH16Ug\n\tcM1toPT02Nn34BxiBFsI/volVib0CY1nu1qdkwWncO4tfVhgrjiFGGr7h8KFYvLhVDf7u5BLbBEOH\n\tmxS0HqKhKBiKYVNnMnBrMe5FFVUT1GmW3+1SMPpknIOrZnlTwE0AwL0xhly6LBZCoU4CDMvP6VEB5\n\tCttFtEHlN7AyOzuD2ypQ==;","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:reply-to:subject:to:cc:references:from\n\t:organization:message-id:date:user-agent:mime-version:in-reply-to\n\t:content-language:content-transfer-encoding;\n\tbh=vrQ2ELJfQEV+YqRSQLxmrC66RAvR9/21Ff8l4GvxBbE=;\n\tb=gkpCOwxOVE2mcRzWcL29TLYUnn3ZXiBJVtDsueVkCDNuSHL8LyrfZ5Hm3QNmwx1z2X\n\tQQaJte7Np6y+mfKh8ZKCF7X9uM6NT6+cJ0p8QI8a0uoXjXZ1sXVv9ipJsW+77HAbiVVs\n\tuOhxfoKe5CbWM/cNgYzyUpFBSC04LHO3M5gSwpY66I9eQqMJFQARNirWZMZHhKdt/1t6\n\taDi4PSVnf+xLc2jKsSU1xhzGqdDGrspj6VJGUtS0JlekeKHG3/MTq8+VDv9dZQkGbCQ5\n\tMB6NH2Oiyvrq57SrGjtihR6TyjMfju6SgNPzH/A6MCkkBRDb3xsN0OX0PH6EiUo0Q1/i\n\tmKFQ==","X-Gm-Message-State":"AMCzsaWm/uN6RdtEZllPHPczmHVD+EbdZA4n2zSVreRXqvxQZTCDN+Ad\n\tMqCTTy2O+VOUROMZ6WElzsw7ZA==","X-Google-Smtp-Source":"ABhQp+TEP95peD6m061mQ0Y4TcvEBypyk0IfrJ+W682/Z5JiwRbqpT6qOsgcAU4W6ZtZUaDiIwwUmQ==","X-Received":"by 10.36.241.77 with SMTP id q13mr2924071iti.123.1508197400935; \n\tMon, 16 Oct 2017 16:43:20 -0700 (PDT)","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","To":"Mark Rutland , Timur Tabi ","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>\n\t\n\t<20171013142724.GA5893@leverpostej>","From":"Al Stone ","Organization":"Red Hat, Inc.","Message-ID":"","Date":"Mon, 16 Oct 2017 17:43:19 -0600","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171013142724.GA5893@leverpostej>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171016_164343_198465_21C1F982 ","X-CRM114-Status":"GOOD ( 31.26 )","X-Spam-Score":"-2.1 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.1 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.214.54 listed in dnsbl.sorbs.net]\n\t-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/,\n\tlow trust [209.85.214.54 listed in list.dnswl.org]\n\t-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)\n\t[209.85.214.54 listed in wl.mailspike.net]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"ahs3@redhat.com","Cc":"Jon Masters , lkml ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, rruigrok@codeaurora.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1791580,"web_url":"http://patchwork.ozlabs.org/comment/1791580/","msgid":"<20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com>","list_archive_url":null,"date":"2017-10-20T16:10:53","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":8806,"url":"http://patchwork.ozlabs.org/api/people/8806/","name":"Mark Rutland","email":"mark.rutland@arm.com"},"content":"Hi Al,\n\nOn Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:\n> On 10/13/2017 08:27 AM, Mark Rutland wrote:\n> > I certainly agree that exposing the information that we have is useful,\n> > as I have stated several times. I'm not NAKing exposing this information\n> > elsewhere.\n> > \n> > If you want a consistent cross-architecture interface for this\n> > information, then you need to propose a new one. That was we can\n> > actually solve the underlying issues, for all architectures, without\n> > breaking ABI.\n> > \n> > I would be *very* interested in such an interface, and would be more\n> > than happy to help.\n> \n> I'm playing with some patches that do very similar things in sysfs, vs\n> proc. Is that better :)?\n\nExposing data under sysfs is certainly better, yes. :)\n\n> Obviously, you'll have to see the patches to\n> properly answer that, but what I'm playing with at present is placing\n> this info in new entries in /sys/devices/cpu and/or /sys/devices/system,\n> and generating some of the content based on what's already in header files\n> (e.g., in cputype.h). \n\nMy opposition to MIDR -> string mapping applies regardless of\nlocation...\n\n> The idea of course is to keep this new info from touching any existing\n> info so we don't break compatibility -- does that feel like a better\n> direction, at least?\n\n... but otherwise this sounds good to me!\n\nThanks,\nMark.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"LEXMqld0\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yJW4t3ZqWz9t4b\n\tfor ;\n\tSat, 21 Oct 2017 03:11:26 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5ZtJ-0001Zs-MV; Fri, 20 Oct 2017 16:11:21 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5ZtF-0001XX-ND for linux-arm-kernel@lists.infradead.org;\n\tFri, 20 Oct 2017 16:11:19 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 63B401435;\n\tFri, 20 Oct 2017 09:10:57 -0700 (PDT)","from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com\n\t[10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t30BAC3F58F; Fri, 20 Oct 2017 09:10:56 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=b2WJPvc1pp5UUtp1upJ4Y4gPIIcmioNvjMFiJ6i/zRc=;\n\tb=LEXMqld0L6tcW1\n\tIgsiSR1h+AEdgKEYZzMvifISV7WKYfXVIZV38NuVscBxLBu7zc+qpFWXzQZB57DOUl5terK1KNrJd\n\tYUotsvo3yQp5gzLpCzsy2YmOH4yXwpGC0DW6AV7t4eb2UagO6MOrWMYYb8PkihOmtRwWcN8OgrI/k\n\t/a0thXBRwa0n8mu2h8gBi+MGMYvUQNPC+XcRrDKFvokeFYiNWAn+TyUjzI5aBmuiEjtBe+vHOZdk2\n\tTmWWI+GNlwQwPCviAnPlGEg6o1lS0+9psFGvb5TwGbVkkz3xaBao16qIilphGAwoPELJIvMwmgdU7\n\tD/05w3iMQNLFwTN2NQqA==;","Date":"Fri, 20 Oct 2017 17:10:53 +0100","From":"Mark Rutland ","To":"Al Stone ","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","Message-ID":"<20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com>","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>\n\t\n\t<20171013142724.GA5893@leverpostej>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171020_091117_767751_8010BD69 ","X-CRM114-Status":"GOOD ( 17.57 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Jon Masters , Timur Tabi ,\n\tlkml ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, rruigrok@codeaurora.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1791639,"web_url":"http://patchwork.ozlabs.org/comment/1791639/","msgid":"","list_archive_url":null,"date":"2017-10-20T17:24:25","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":1882,"url":"http://patchwork.ozlabs.org/api/people/1882/","name":"Jon Masters","email":"jcm@redhat.com"},"content":"Hi Mark,\n\nOn 10/20/2017 12:10 PM, Mark Rutland wrote:\n\n> On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:\n\n>> Obviously, you'll have to see the patches to\n>> properly answer that, but what I'm playing with at present is placing\n>> this info in new entries in /sys/devices/cpu and/or /sys/devices/system,\n>> and generating some of the content based on what's already in header files\n>> (e.g., in cputype.h). \n> \n> My opposition to MIDR -> string mapping applies regardless of\n> location...\n\nWell, we do need to have the name to display to the user. Two things\nthat absolutely need to be in a clear, easy to find place:\n\n1). The make and model of the CPU in human readable format\n2). The nominal and operating frequency of the CPU(s)\n\nObviously, I want this to be in /proc/cpuinfo, but if it goes elsewhere\n(and other arches get behind it), then that could work. For the mapping\nof name to model, I agree that hard coding stuff in the kernel is ugly.\nThis means that we need to either leverage DMI/SMBIOS data or add a new\nAPI to something like PSCI (ugly, maybe dangerous) to get the info.\n\nHere are some reasons that I care:\n\n1). The first thing people do when they get an Arm server is to cat\n/proc/cpuinfo. They then come complaining that it's not like x86. They\ncan't get the output their looking for and this results in bug filing,\nand countless hours on phone calls discussing over and over again.\nWorse, there are some parts of the stack that really need this.\n\n2). I have seen entire Arm server SoCs get a bad review because the\nperson running some test couldn't get the frequency reported in a\nsensible enough place that they noticed it was an early part clocked at\nhalf the frequency. Today, they have little opportunity to notice the\nfrequency and a lot of chance to start spreading rumors that some part\n\"sucks\". Sure, bogomips, other numbers are all lies. But if I had a\npenny for every time someone said \"man, this server only runs at 100/400\nMHz! that's so slow!\" (arch timer)\n\nSo we're going to clean this up. I've spoken with all of the vendors and\nthere's general agreement that this needs changing for Enterprise users.\nBut how it's done - definitely there's flexibility there. One thing that\nwe won't do is have no solution. While it would be very unfortunate to\ncarry something just in RHEL, we'll do it (hopefully in collaboration\nwith other distros) if this isn't resolvable upstream.\n\nThanks,\n\nJon.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"IoRt3r4/\"; dkim-atps=neutral","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jcm@redhat.com"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yJXjq1BNfz9t48\n\tfor ;\n\tSat, 21 Oct 2017 04:24:58 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5b2V-0001Ce-F7; Fri, 20 Oct 2017 17:24:55 +0000","from mx1.redhat.com ([209.132.183.28])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5b2R-0000vV-1M for linux-arm-kernel@lists.infradead.org;\n\tFri, 20 Oct 2017 17:24:53 +0000","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 9E3AB8210B;\n\tFri, 20 Oct 2017 17:24:29 +0000 (UTC)","from washington.bos.jonmasters.org (ovpn-125-151.rdu2.redhat.com\n\t[10.10.125.151])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 69C67600C2;\n\tFri, 20 Oct 2017 17:24:26 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=2LjLT0MJDomwPKGP0qixQuG9CIOMIFYfe/fnk1dlyVg=;\n\tb=IoRt3r4/5nBLE7\n\tQYB5EkNbQDm/NtElni/vsqCt8RsyYTiZfkets2bjupxnSvg7dajrsHpDGtGM2Py6GGETgzru/4HiA\n\tLT0mv3FU2ZkjbuibpXAPuBsd4cJHfW7kpxvvVIwTEv1GT9wN+rRMFHziZ0gEHoIFe25qSO8HocRoM\n\tJNvQYQ4G0jpvm0e7w5JAs28CcMskPahkiKonejQyyjq6CIex5HbLo9H+ch2g6dwydbMYISdsCUKGh\n\tDf+1CDmOjePQ3mib0eK4LC4U2CUheBQznamMaQDUHQc2XCVB2sFC5WtCJ+EgDwQDlh4SAKbpuxtm0\n\tyz9/femoh/j5h1tEMVjA==;","DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 9E3AB8210B","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","To":"Mark Rutland , Al Stone ","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>\n\t\n\t<20171013142724.GA5893@leverpostej>\n\t\n\t<20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com>","From":"Jon Masters ","Message-ID":"","Date":"Fri, 20 Oct 2017 13:24:25 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.0","MIME-Version":"1.0","In-Reply-To":"<20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com>","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]); Fri, 20 Oct 2017 17:24:29 +0000 (UTC)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171020_102451_132481_19C6DA86 ","X-CRM114-Status":"GOOD ( 18.75 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [209.132.183.28 listed in list.dnswl.org]\n\t-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)\n\t[209.132.183.28 listed in wl.mailspike.net]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-0.0 SPF_HELO_PASS SPF: HELO matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Timur Tabi , lkml , \n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, rruigrok@codeaurora.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1791800,"web_url":"http://patchwork.ozlabs.org/comment/1791800/","msgid":"<89947f32-0833-fb67-6bba-02bcac8ef01c@redhat.com>","list_archive_url":null,"date":"2017-10-20T23:26:19","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":64880,"url":"http://patchwork.ozlabs.org/api/people/64880/","name":"Al Stone","email":"ahs3@redhat.com"},"content":"On 10/20/2017 10:10 AM, Mark Rutland wrote:\n> Hi Al,\n> \n> On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:\n>> On 10/13/2017 08:27 AM, Mark Rutland wrote:\n>>> I certainly agree that exposing the information that we have is useful,\n>>> as I have stated several times. I'm not NAKing exposing this information\n>>> elsewhere.\n>>>\n>>> If you want a consistent cross-architecture interface for this\n>>> information, then you need to propose a new one. That was we can\n>>> actually solve the underlying issues, for all architectures, without\n>>> breaking ABI.\n>>>\n>>> I would be *very* interested in such an interface, and would be more\n>>> than happy to help.\n>>\n>> I'm playing with some patches that do very similar things in sysfs, vs\n>> proc. Is that better :)?\n> \n> Exposing data under sysfs is certainly better, yes. :)\n> \n>> Obviously, you'll have to see the patches to\n>> properly answer that, but what I'm playing with at present is placing\n>> this info in new entries in /sys/devices/cpu and/or /sys/devices/system,\n>> and generating some of the content based on what's already in header files\n>> (e.g., in cputype.h). \n> \n> My opposition to MIDR -> string mapping applies regardless of\n> location...\n\nHarumph. This is the one thing I get asked for most often, however (second most\nis frequency). It turns out humans are not nearly as good at indexed lookups as\ncomputers, hence the requests.\n\nWhatever the root of the opposition is, it needs to get fixed. My fear is that\nif it doesn't get fixed in the firmware or the kernel, it will get fixed in some\nfar messier, less controllable way somewhere else (more likely several somewhere\nelses) and just exacerbate the problem.\n\n>> The idea of course is to keep this new info from touching any existing\n>> info so we don't break compatibility -- does that feel like a better\n>> direction, at least?\n> \n> ... but otherwise this sounds good to me!\n> \n> Thanks,\n> Mark.\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"I9NnHT7n\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yJhlP52R6z9t3H\n\tfor ;\n\tSat, 21 Oct 2017 10:26:57 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5ggg-0003ZA-LP; Fri, 20 Oct 2017 23:26:46 +0000","from mail-io0-f193.google.com ([209.85.223.193])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5ggc-0003XI-Vp for linux-arm-kernel@lists.infradead.org;\n\tFri, 20 Oct 2017 23:26:44 +0000","by mail-io0-f193.google.com with SMTP id 101so14839903ioj.3\n\tfor ;\n\tFri, 20 Oct 2017 16:26:22 -0700 (PDT)","from fidelio.ahs3 (c-67-165-232-89.hsd1.co.comcast.net.\n\t[67.165.232.89]) by smtp.gmail.com with ESMTPSA id\n\ta205sm998483itg.33.2017.10.20.16.26.20\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 20 Oct 2017 16:26:20 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:Reply-To:List-Subscribe:List-Help:\n\tList-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date\n\t:Message-ID:From:References:To:Subject:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=w7RS8SpEHipp3R7sAsRXeRQJ/CPYsKvZTZQ9hnxAfUM=;\n\tb=I9NnHT7ngzp5RX\n\tHmIPga4qe2PMb3cJyoTdqZcQ/22LDjnGk9Xzqiko4E+uH1bKnkGt5BG3aVjShDv+Vo9T5hknyvnpm\n\t1dda2p2D1Qb3i7DPRj0huYGSDejjQ50guAbXhkqEjdBBzZ5mpjXZxGFsLGyqgpyA5EntKTGmN0tLn\n\tfDpRHq+EicuzFzYmi7vLYmLaLLCJyqpjNsw+4Aq2cHTVJw9DgOzzMvgBMNdnF0gH4lZFVczGNz/cI\n\tk/XNBEoZLIaCrHJEidJDzgwny8X4NT5+SeyFPrZRWAVsxxguXyouxZhANiYbZ7vD3LtVeU8T1qsRf\n\tEDoFsJQ7mnzHf/lY5bdg==;","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:reply-to:subject:to:cc:references:from\n\t:organization:message-id:date:user-agent:mime-version:in-reply-to\n\t:content-language:content-transfer-encoding;\n\tbh=y29SifqrlWlWrH2sVElyzkvsrB4DrhuEm9XzMYituAw=;\n\tb=FN1SxnLvgQin+EDv9RG26PMJtcr7WdQ6x1QsK52pHjTITcJyMVl9jT9f2AbIN3ndRh\n\tgbwhVBQLkgliP/CS3F8WkRNH652f1Le5dTSwXqE+KZlJ3cbvTnfRY+nj88H1Xq/0Hrmp\n\t8AKBCcW0RqBqvhqX6HE9Sl1a/+Ot32KJOkBcnBgmtS13lIsn3VZLd7xrggUoZjrGEEjs\n\tgWb6bYDyIUuRnTvCYQycURnRtxkFDLpI2KRnZovA1rDHMY5DVcA6yp1mN/c6b3EC9XEb\n\tuVkIccgPFIQdnq/gNxcwrFQeVbcw91aG/8hh25tCVOe0WEp5jNIXfzE8vJ+pj/AANtVu\n\tXX/A==","X-Gm-Message-State":"AMCzsaXJ8eZoEPrDrIv7ljCUFIi1EDRIg5z/rpzj3faLTbt86vY+L8Aq\n\twM0XNsyplTiMksv2ygwokFfdGCBWi28=","X-Google-Smtp-Source":"ABhQp+Qv/GaR4IbKijQ7cPdtBmJUdff2P8mNZDdddNnsqlujjGEcTtKYR6WFQgaCfVK8+83P9bcEWg==","X-Received":"by 10.107.140.18 with SMTP id o18mr8224374iod.35.1508541981740; \n\tFri, 20 Oct 2017 16:26:21 -0700 (PDT)","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","To":"Mark Rutland ","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>\n\t\n\t<20171013142724.GA5893@leverpostej>\n\t\n\t<20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com>","From":"Al Stone ","Organization":"Red Hat, Inc.","Message-ID":"<89947f32-0833-fb67-6bba-02bcac8ef01c@redhat.com>","Date":"Fri, 20 Oct 2017 17:26:19 -0600","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171020_162643_066407_635D91AF ","X-CRM114-Status":"GOOD ( 17.96 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-4.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.223.193 listed in dnsbl.sorbs.net]\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno trust [209.85.223.193 listed in list.dnswl.org]\n\t-2.8 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)\n\t[209.85.223.193 listed in wl.mailspike.net]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"ahs3@redhat.com","Cc":"Jon Masters , Timur Tabi ,\n\tlkml ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, rruigrok@codeaurora.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1791825,"web_url":"http://patchwork.ozlabs.org/comment/1791825/","msgid":"<626f32d8-c6df-7c25-0391-f912be5665cf@redhat.com>","list_archive_url":null,"date":"2017-10-21T00:50:42","subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","submitter":{"id":1882,"url":"http://patchwork.ozlabs.org/api/people/1882/","name":"Jon Masters","email":"jcm@redhat.com"},"content":"On 10/20/2017 01:24 PM, Jon Masters wrote:\n\n> 1). The first thing people do when they get an Arm server is to cat\n> /proc/cpuinfo. They then come complaining that it's not like x86. They\n> can't get the output their looking for and this results in bug filing,\n> and countless hours on phone calls discussing over and over again.\n> Worse, there are some parts of the stack that really need this.\n\nWithin 6 hours of sending this, I get a ping about this week's \"Works On\nArm\" newsletter and...people reporting bugs with not getting CPU\ncapabilities in /proc/cpuinfo. This madness is going to end. Soon.\n\nJon.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"GLSnFFjc\"; dkim-atps=neutral","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jcm@redhat.com"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yJkcj6pRwz9t3B\n\tfor ;\n\tSat, 21 Oct 2017 11:51:17 +1100 (AEDT)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5i0M-0004Nj-N1; Sat, 21 Oct 2017 00:51:10 +0000","from mx1.redhat.com ([209.132.183.28])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e5i0J-0004ML-R1 for linux-arm-kernel@lists.infradead.org;\n\tSat, 21 Oct 2017 00:51:09 +0000","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id D71F48763C;\n\tSat, 21 Oct 2017 00:50:46 +0000 (UTC)","from washington.bos.jonmasters.org (ovpn-125-151.rdu2.redhat.com\n\t[10.10.125.151])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 981AB5D6A4;\n\tSat, 21 Oct 2017 00:50:43 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=uxHvYVQURK+2u0Hfv4G/KDUft9HS7WlBcFzp9yjZ2Lo=;\n\tb=GLSnFFjcMTbysC\n\tR54I+u37E3eFBqdoezSXzJP3YGFVLz9XEvEItgbcTnuFti6QKlkrSCikkHhshIT6m2a0g4gpziZ2A\n\tMuFcLMgOaxukIVyUy4XfkBCySh8U5wioSH5KY4cpxG+5gimf5G6HAZ3zns+WXVFoeNKSIALCgYZ7s\n\tO/LexS8RQwCrQq2EzYeW+FXVbMII0NpBZR+TKGaNJIzvsus3E6xQScThJd3EAcaUk8vQC8iha7Kvz\n\tIb0TY7UPDmkyyN8a+CSxGe5YvF6sGiBQAlJ7DUQRbncctlO08LEzZiEa6dc82z2HX73B6iTiYcWVm\n\tnfbuE35YPPotKjj1vuyQ==;","DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com D71F48763C","Subject":"Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more\n\thuman-readable","To":"Mark Rutland , Al Stone ","References":"<20170926222324.17409-1-ahs3@redhat.com>\n\t<20170927103406.GC32150@leverpostej>\n\t\n\t<20171013142724.GA5893@leverpostej>\n\t\n\t<20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com>\n\t","From":"Jon Masters ","Message-ID":"<626f32d8-c6df-7c25-0391-f912be5665cf@redhat.com>","Date":"Fri, 20 Oct 2017 20:50:42 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.0","MIME-Version":"1.0","In-Reply-To":"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]); Sat, 21 Oct 2017 00:50:47 +0000 (UTC)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171020_175107_910379_C9FF9571 ","X-CRM114-Status":"GOOD ( 10.99 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [209.132.183.28 listed in list.dnswl.org]\n\t-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)\n\t[209.132.183.28 listed in wl.mailspike.net]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-0.0 SPF_HELO_PASS SPF: HELO matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Timur Tabi , lkml , \n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, rruigrok@codeaurora.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]