From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751406AbdJSFTG (ORCPT ); Thu, 19 Oct 2017 01:19:06 -0400 Received: from mail-bn3nam01on0082.outbound.protection.outlook.com ([104.47.33.82]:35280 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750777AbdJSFTB (ORCPT ); Thu, 19 Oct 2017 01:19:01 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Tomasz.Nowicki@cavium.com; Subject: Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing To: Jeremy Linton , Tomasz Nowicki , linux-acpi@vger.kernel.org Cc: mark.rutland@arm.com, Jonathan.Zhang@cavium.com, Jayachandran.Nair@cavium.com, lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, linux-pm@vger.kernel.org, jhugo@codeaurora.org, gregkh@linuxfoundation.org, sudeep.holla@arm.com, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, will.deacon@arm.com, wangxiongfeng2@huawei.com, viresh.kumar@linaro.org, hanjun.guo@linaro.org, catalin.marinas@arm.com, ahs3@redhat.com, linux-arm-kernel@lists.infradead.org References: <20171012194856.13844-1-jeremy.linton@arm.com> <20171012194856.13844-2-jeremy.linton@arm.com> <38c63cfd-4c13-9461-0d4a-74b0943be0fd@semihalf.com> <2ce92b90-fc2c-3fff-a3e3-b9517057ab2c@arm.com> <4ee4af4d-d987-33f9-4d55-67bfede3ebfa@caviumnetworks.com> <47d8ef93-a3ce-6d40-f8db-2bc7d527ac6f@arm.com> From: Tomasz Nowicki Message-ID: <2605aa54-95f7-4619-e632-0a95a68e5fb0@caviumnetworks.com> Date: Thu, 19 Oct 2017 07:18:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <47d8ef93-a3ce-6d40-f8db-2bc7d527ac6f@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [31.172.191.173] X-ClientProxiedBy: AM5PR0701CA0012.eurprd07.prod.outlook.com (2603:10a6:203:51::22) To SN4PR0701MB3663.namprd07.prod.outlook.com (2603:10b6:803:4d::17) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 67c79d34-1eb9-4a18-3b80-08d516b0e518 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:SN4PR0701MB3663; X-Microsoft-Exchange-Diagnostics: 1;SN4PR0701MB3663;3:dyYiq2vEO/o/XiIZtWIMc6gNOaMhjjfLytHnXZABouwkbY3L4MMtXKl/VfJV/vzq5X1y+N+ttsLRVQsyRF811IIUKnESBzsbB/POJIrKKjdSdBndFqNofzmLfu+YoH1Wfy21rv/FmWH9gbYMRDnbVlZbfU8oZRU6kUVn+dUXIxr5/hTQqpcu+P02Q5cXSowgwqCIUAED/yYP8SonSQTC1kBX8VM9dXfljGN/sl7ZliM94YI1fd3BuencPwIGi82i;25:9KlfH1hB9aH+vxI+bOPModmc1EldcmJ8nGUnrW7wugib9s1mMP3T+bV0ZZUmGFTOjrF29buKq6+3oLjvze6Kaz4N3jR71Y30Bbwby/bYnixdwYhLqgJF6YxBMKD9DYKw/e7v/5QBV4XJ68rY5uc0dA1QDOergK7YVbKjBxhbUnVzvjJmti+32LqJOaY2kF1hcmdzYauJf1FjQDRyU4G0cwlnFVRR6HUBiIPjV1mTFsXgfg3rGPgZuS/aCYUNX3jXG5ZxrFQ7DGJy+B1QITNnNN/RNatNaEjyFcoolOSdqeWuSeoSkGCO3RMkQ9iH/U9lzHNucCE+1+C/WIdtePFBjQ==;31:c1z5vCbunEddBD/tdDF1LpJ0ITcIfhilj/u5gtLmuJHTFkzXIniO6lCSfBnM8sMkXVEkjWAlFwYrZcZhzlskU/t78FSbW42U/5nB2MZVCoo9HXfv+GnPKR7X4PKQVtmwELP2jBJ4wrae79lXOISCFmNp8eJ3XMPu0ncucRZ7Ych697SQdXpa5i9b3yeTHRwmty7Mql61Fi76Z8SccEYXaJWTpTnBPI0/bOLkcMa6Ha0= X-MS-TrafficTypeDiagnostic: SN4PR0701MB3663: X-Microsoft-Exchange-Diagnostics: 1;SN4PR0701MB3663;20:VOJCFDiFDxCVxJnti3Q/arZ1REmJrWH0h1xwU9MvdNFv1HBCojChKLyrLzSsn6emtiQ635QArl+i6HiOaOw9VfoKj+K84CLcPFzOkkzAm8cxlyKgQ/QfGQTsSB+oLRidJ9GmaMPr4WoMzkuitszB1CjRBGFcKHdhXArgiSztoSwClaj7/fTmTnmCxQDP8HYlEoVrCT4CvM7FPclHsBXn3elunaALXzh/SnJjuGh6SfSwha+BHS+dxsQBZc7LxXfEw1cFUsmZ/PYOFpiaD7tPTX7IJR3TGfrPXMO0D5QTyz5zJwOc1yceYpRARuY5iERcU6uR8ClzBGg+umjMtZZDPfzJahdI2v6aZIZfJxSgpDJW0dz87JV5n60NWC2O+lvJh94coha2CTfXrFgSTw2EWPsfUEb1WLRPz/aVHgeVdCTtMv2AHdLE0WRB+bnLTN9hXNrfKovPWzvcMrH2bipxaQ4UZYeFx7r14NrziAYCdILECbiRngPoUMDONB5pXzv5Yx3TPQ8r1otQhIlqnK7QXg+w5/71cBuxG7SC8+ITnlZMfuZmnJ/NgDRmLJStwN2u1PssKmqSX0/dX5WFMuOeJUdMImBeBmS/pMcUTXAAynY=;4:PWgRK8iAtQb8/Pw+sh2PREuEg3lXIkVpHJL+OBwCmjk1a6G2ySLgmI6i7AzrNKAXyG1YBzeL2amxyC6ZdF5GRAntPvWCw9LWytwKnq3i5X7eW60zmIj92Lo8lS7R8SlmBCvWS6WhzyO/esnPJXOqC3vyNyt0n0R59iCZrh2YEaGUk8tpg7LgoJFFa4El9J1WvbdP5r59V4BguQcwN15T4WUyzk77VzOocZot7y0R3ZFBYoNrkToz6lcLXrP0GLXxU97XXDKhd6uyGf/boMD5Tad9zUUYtz50cbHjfoxW03o= X-Exchange-Antispam-Report-Test: UriScan:(180628864354917); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:SN4PR0701MB3663;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SN4PR0701MB3663; X-Forefront-PRVS: 0465429B7F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(6049001)(346002)(376002)(189002)(377454003)(199003)(24454002)(305945005)(33646002)(25786009)(76176999)(97736004)(72206003)(101416001)(7736002)(23676002)(575784001)(31696002)(478600001)(54356999)(229853002)(77096006)(53546010)(2906002)(105586002)(6116002)(53936002)(2870700001)(6666003)(50986999)(81156014)(3846002)(6486002)(6246003)(81166006)(8936002)(4326008)(8676002)(31686004)(2950100002)(189998001)(66066001)(42882006)(16526018)(36756003)(68736007)(50466002)(47776003)(316002)(7520500002)(7416002)(16576012)(93886005)(83506001)(5660300001)(58126008)(65956001)(106356001)(110136005)(64126003)(2004002);DIR:OUT;SFP:1101;SCL:1;SRVR:SN4PR0701MB3663;H:[10.0.0.85];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjRQUjA3MDFNQjM2NjM7MjM6OExRcW5LV1lCQlpld05aeXZ2RXM1VEZy?= =?utf-8?B?Z3U1cEZhS201a1BPa2Rpb1pyMldSSER4SzBHODloL2xYV0RtUXVKS09WS01n?= =?utf-8?B?QjlPMEhyQkRaenJva1F3VjVGekpyaCtpRm5QMDZiazJFSDV6ZUExV0MwUWda?= =?utf-8?B?T1lRZlFwRXRDYW0wNS9EYmJnZ29yZkNQWHdTMlFGQWtBSjRFbU8rSE94RXdn?= =?utf-8?B?U2tNNnEvelh0bTd0b0h4eCsxY2N5L0NlV2NtZUdBWmEzazJBZ3ZLWllWTldV?= =?utf-8?B?Q0xSSmg3Z3VFb200VUowTmtFTmFSa1ZMdUdjZ0JiV1VlTDU0MmQ1YnRIVml3?= =?utf-8?B?Wk54aFFYME1SVW5UMjlHTjVsTXpJOGRNbC9oQlVUQkxQUzd1QnF6bS9ITkxQ?= =?utf-8?B?QVZPRHhCM0dFanRNdkQ5bFNZR0VKME9PTm1IbnlDVjAyRjQ1ekFob2hJSzFz?= =?utf-8?B?dnlyRmx5NHgwT3k2RnZtQUw1OVIwT3hReXZ4ZTZOZjE0MHpwVXlnZ2orcHpM?= =?utf-8?B?VHA3eHBjRUhQNGROSnhRMjFJYm1JTnI2K1Q1emJKTjlMRUZ4V2NiNUdKUEdq?= =?utf-8?B?dytlSko1bWVQSGh5Tk9DcDdnazV0Qi9zTHQ3UDU5SWJ6M1VXTjY3TlZtZDcx?= =?utf-8?B?L2c3L3dRMm9OTlhac0wrMXRua1prdkpVZmxNQ2JrUHB4TEZxSldUalZLcTR3?= =?utf-8?B?djRsYUY3Z2NGRS9TMXZ3dGxZTVUxclNaYk1iUm92eUZ3clZwZFZ3Y1VWWi8r?= =?utf-8?B?M3VFWHVKSnJlSk1ldFlnS0pFL2JJNlZvQWVTSkxrdzRDU0xwOVRkZjFYak1V?= =?utf-8?B?TTl6UmR3cDlRWWhxNUxMNThlTDNUZFhBMmY1OTdWWEg5M0FraERwS3YyV3FY?= =?utf-8?B?bngxSXZZdG9CZlhxZUQ3TWNmdEYvY3hWQWRZc0NUeDZBUFNOQmdGRXhSdldZ?= =?utf-8?B?czdJYmY3aEQyd2xXWjNDUS9PbXRNWE5UNU5ycE1QNVdBSUh6Z2ppNjMyL281?= =?utf-8?B?R1kreVYxb2V1cUxHR09PY3ZRWnFEZ0cxRTRCMlRmSkdPSENPb3c0RGJBTHBV?= =?utf-8?B?SkVuN0MvUDQ4WlpMWjhZdFJxZWdPOWNjQy9UL3k4YVZCNFB2NkxQUXVmYmZo?= =?utf-8?B?QkFPekthckJLSGx0SGliQmJnQmFKR09EUkpJa2dpUzM4TDV4cWNxYy8vTFM1?= =?utf-8?B?TzJQK2lpS1lxT2I4eVNhQ1ZjR3Z1OHd4WFRVeEdZV0FaMWJsRW1vTTk2ZDBY?= =?utf-8?B?QWFmMGg1VENRRmJJaVZNZGNWY0V4V0dQUHNFQ0RETnJCYXFxNENtMDVJNGJ0?= =?utf-8?B?cHFhc2FyU2ZRc0lFN1ZlRjFzWG43RnFhWWdpUzR2L3M0ekkxejNkMVRlRWU4?= =?utf-8?B?c3p1eUQxZ09tcWFnRjY2RGhIYm9DTEovcDNOdGMxcytEa1QreSs5VXY1Rzlj?= =?utf-8?B?OWZnbHRnb1lhNnhMWkpBUDk0eVdHNmdZK2ZGaysvdWwzWjhNSGpPa1drbHRO?= =?utf-8?B?VUVnbFJxSzR5Y1poQlpacERRMkVMWHZLOVpqSzZYMVFLQi80K05mMlFLSFo3?= =?utf-8?B?T1g0WkhTRklweDg3bzhpVzRVUk50VzNGbU1LQ1FlS1hFYW5QY0VLalVQTjh5?= =?utf-8?B?Q1orcmhTUitsZktyeDltRTFod3cxOWxibks5SDE3QWJwKzZzUTRJVEE4Z0g5?= =?utf-8?B?Z3pLVWdSNWNKVHdNdmpXTFc5SHF0dVd6MFJRTWYweEVFMng0ZCtuVXJVMGlG?= =?utf-8?B?V1hWODB3c1llZS9KVUY2YlMrN1kybGNKaGYzUktTdFlLVUUyVS9pNDQ1RGdK?= =?utf-8?B?bGZ2d1lacFhwanM2dHU2bUVVZmFybytxcXl4NjJzeGt5aUM1UXJYK2dIazR0?= =?utf-8?B?NHk5YTgrZHd3L1pzNnp2bW5aVXlRbXhGUjVnTVJqUXNsU0tHRUJremw4UXZL?= =?utf-8?B?VEwvTEUxdXBkRWc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1;SN4PR0701MB3663;6:YCYhloPvoIV8qlu3ePOimY9uD292PFVyk0PSITV0a4AUeRxh6i3rHXN5bfmCrNN83/m9XIWyyBtbzJ0CLJFJy9yYzkoEfFQeT2N6ycfKLnaBJJc0uMYi3TSYkSTa+ZiFXQic9GbPyQuIBa1+MKk2VN8kAzONfVif4GpZLRdxTFO2hA9pWSk32w9oPDlVS2lD0QUyW8aZAseGR8GpaxzU2iRJAnU6qcajEWC4u9yy01+03Rb6Pv+NgtCKMmZcfEpQ31nGFnA+FYQU191mmBRl3R96v9kU+BgTPFMtm1EXUf/bqVW9qmD+yiZQzlztrJ82ZFzCMkhrv24m4d18hm8WLg==;5:X+ewWe1AN35xhXEZCwS/RTWH5pPQbdyifo0ghWzwiqXxCx3t6r14h9VK58GToSH79xTxZRPkL10wNjqKFMDEbJJe4QB2UjCAkoCfE3US0I/G+pdgibxD/azFamoSoQFo6F2KLIUQbbtUST3qmtxZIg==;24:ukfXHW6EZgA63g4wknYPqpgITVbLW/Fp9JupY/4yzqaxoKNcZkH0Kj2Y95OcqZe/Y4mgF8FkOdz3gbUJeyDR/oZvLkuW3iSY5pNorRm1sdo=;7:Wb+9nfEjYnH8XCxCbc7/0ArXBZ1dTZjGyG6NVYR2AIVBPt1YKMjzCHc/rLZ97k5px79DE0zlsrSinpSWaAKdNW+uSxzr+8QhsdSudft5lSSpCvh92o3J0aq9cFaIX/sRLAYWfVcPnhSz+vTUYblSUX3smFusY+0Ah8sAU6EqbdzzeOyuJpJIJO4tywWLnLCn9AGPSMy6NAUjmMM15dPJuzhoOkFn+MIwPx+/ikdztbc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2017 05:18:51.9699 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0701MB3663 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18.10.2017 19:30, Jeremy Linton wrote: > On 10/18/2017 05:24 AM, Tomasz Nowicki wrote: >> On 18.10.2017 07:39, Tomasz Nowicki wrote: >>> Hi, >>> >>> On 17.10.2017 17:22, Jeremy Linton wrote: >>>> Hi, >>>> >>>> On 10/17/2017 08:25 AM, Tomasz Nowicki wrote: >>>>> Hi Jeremy, >>>>> >>>>> I did second round of review and have some more comments, please >>>>> see below: >>>>> >>>>> On 12.10.2017 21:48, Jeremy Linton wrote: >>>>>> ACPI 6.2 adds a new table, which describes how processing units >>>>>> are related to each other in tree like fashion. Caches are >>>>>> also sprinkled throughout the tree and describe the properties >>>>>> of the caches in relation to other caches and processing units. >>>>>> >>>>>> Add the code to parse the cache hierarchy and report the total >>>>>> number of levels of cache for a given core using >>>>>> acpi_find_last_cache_level() as well as fill out the individual >>>>>> cores cache information with cache_setup_acpi() once the >>>>>> cpu_cacheinfo structure has been populated by the arch specific >>>>>> code. >>>>>> >>>>>> Further, report peers in the topology using setup_acpi_cpu_topology() >>>>>> to report a unique ID for each processing unit at a given level >>>>>> in the tree. These unique id's can then be used to match related >>>>>> processing units which exist as threads, COD (clusters >>>>>> on die), within a given package, etc. >>>>>> >>>>>> Signed-off-by: Jeremy Linton >>>>>> --- >>>>>>   drivers/acpi/pptt.c | 485 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>   1 file changed, 485 insertions(+) >>>>>>   create mode 100644 drivers/acpi/pptt.c >>>>>> >>>>>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c >>>>>> new file mode 100644 >>>>>> index 000000000000..c86715fed4a7 >>>>>> --- /dev/null >>>>>> +++ b/drivers/acpi/pptt.c >>>>>> @@ -0,1 +1,485 @@ >>>>>> +/* >>>>>> + * Copyright (C) 2017, ARM >>>>>> + * >>>>>> + * This program is free software; you can redistribute it and/or >>>>>> modify it >>>>>> + * under the terms and conditions of the GNU General Public License, >>>>>> + * version 2, as published by the Free Software Foundation. >>>>>> + * >>>>>> + * This program is distributed in the hope it will be useful, but >>>>>> WITHOUT >>>>>> + * ANY WARRANTY; without even the implied warranty of >>>>>> MERCHANTABILITY or >>>>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public >>>>>> License for >>>>>> + * more details. >>>>>> + * >>>>>> + * This file implements parsing of Processor Properties Topology >>>>>> Table (PPTT) >>>>>> + * which is optionally used to describe the processor and cache >>>>>> topology. >>>>>> + * Due to the relative pointers used throughout the table, this >>>>>> doesn't >>>>>> + * leverage the existing subtable parsing in the kernel. >>>>>> + */ >>>>>> +#define pr_fmt(fmt) "ACPI PPTT: " fmt >>>>>> + >>>>>> +#include >>>>>> +#include >>>>>> +#include >>>>>> + >>>>>> +/* >>>>>> + * Given the PPTT table, find and verify that the subtable entry >>>>>> + * is located within the table >>>>>> + */ >>>>>> +static struct acpi_subtable_header *fetch_pptt_subtable( >>>>>> +    struct acpi_table_header *table_hdr, u32 pptt_ref) >>>>>> +{ >>>>>> +    struct acpi_subtable_header *entry; >>>>>> + >>>>>> +    /* there isn't a subtable at reference 0 */ >>>>>> +    if (!pptt_ref) >>>>>> +        return NULL; >>>>>> + >>>>>> +    if (pptt_ref + sizeof(struct acpi_subtable_header) > >>>>>> table_hdr->length) >>>>>> +        return NULL; >>>>>> + >>>>>> +    entry = (struct acpi_subtable_header *)((u8 *)table_hdr + >>>>>> pptt_ref); >>>>>> + >>>>>> +    if (pptt_ref + entry->length > table_hdr->length) >>>>>> +        return NULL; >>>>>> + >>>>>> +    return entry; >>>>>> +} >>>>>> + >>>>>> +static struct acpi_pptt_processor *fetch_pptt_node( >>>>>> +    struct acpi_table_header *table_hdr, u32 pptt_ref) >>>>>> +{ >>>>>> +    return (struct acpi_pptt_processor >>>>>> *)fetch_pptt_subtable(table_hdr, pptt_ref); >>>>>> +} >>>>>> + >>>>>> +static struct acpi_pptt_cache *fetch_pptt_cache( >>>>>> +    struct acpi_table_header *table_hdr, u32 pptt_ref) >>>>>> +{ >>>>>> +    return (struct acpi_pptt_cache >>>>>> *)fetch_pptt_subtable(table_hdr, pptt_ref); >>>>>> +} >>>>>> + >>>>>> +static struct acpi_subtable_header *acpi_get_pptt_resource( >>>>>> +    struct acpi_table_header *table_hdr, >>>>>> +    struct acpi_pptt_processor *node, int resource) >>>>>> +{ >>>>>> +    u32 ref; >>>>>> + >>>>>> +    if (resource >= node->number_of_priv_resources) >>>>>> +        return NULL; >>>>>> + >>>>>> +    ref = *(u32 *)((u8 *)node + sizeof(struct acpi_pptt_processor) + >>>>>> +              sizeof(u32) * resource); >>>>>> + >>>>>> +    return fetch_pptt_subtable(table_hdr, ref); >>>>>> +} >>>>>> + >>>>>> +/* >>>>>> + * given a pptt resource, verify that it is a cache node, then walk >>>>>> + * down each level of caches, counting how many levels are found >>>>>> + * as well as checking the cache type (icache, dcache, unified). >>>>>> If a >>>>>> + * level & type match, then we set found, and continue the search. >>>>>> + * Once the entire cache branch has been walked return its max >>>>>> + * depth. >>>>>> + */ >>>>>> +static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr, >>>>>> +                int local_level, >>>>>> +                struct acpi_subtable_header *res, >>>>>> +                struct acpi_pptt_cache **found, >>>>>> +                int level, int type) >>>>>> +{ >>>>>> +    struct acpi_pptt_cache *cache; >>>>>> + >>>>>> +    if (res->type != ACPI_PPTT_TYPE_CACHE) >>>>>> +        return 0; >>>>>> + >>>>>> +    cache = (struct acpi_pptt_cache *) res; >>>>>> +    while (cache) { >>>>>> +        local_level++; >>>>>> + >>>>>> +        if ((local_level == level) && >>>>>> +            (cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) && >>>>>> +            ((cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) == >>>>>> type)) { >>>>> >>>>> Attributes have to be shifted: >>>>> >>>>> (cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) >> 2 >>>> >>>> Hmmm, I'm not sure that is true, the top level function in this >>>> routine convert the "linux" constant to the ACPI version of that >>>> constant. In that case the "type" field is pre-shifted, so that it >>>> matches the result of just anding against the field... That is >>>> unless I messed something up, which I don't see at the moment (and >>>> the code of course has been tested with PPTT's from multiple people >>>> at this point). >>> >>> For ThunderX2 I got lots of errors in dmesg: >>> Found duplicate cache level/type unable to determine uniqueness >>> >>> So I fixed "type" macros definitions (without shifting) and shift it >>> here which fixes the issue. As you said, it can be pre-shifted as well. > > Ah, yah right... If you removed the shift per your original comment then > it breaks this. Yes, and the type definitions for cache type aren't > wrong in this version because the unified state has the 3rd bit set for > both the 0x3 and 0x2 values and its only used to covert from the linux > type to the ACPI type (and not back because we don't mess with whatever > the original "detection" was). I'm not really planning on changing that > because I don't think it helps "readability" (and it converts a compile > time constant to a runtime shift). > >>> >>>> >>>> >>>>> >>>>>> +            if (*found != NULL) >>>>>> +                pr_err("Found duplicate cache level/type unable >>>>>> to determine uniqueness\n"); >> >> Actually I still see this error messages in my dmesg. It is because >> the following ThunderX2 per-core L1 and L2 cache hierarchy: >> >> Core >>   ------------------ >> |                  | >> | L1i -----        | >> |         |        | >> |          ----L2  | >> |         |        | >> | L1d -----        | >> |                  | >>   ------------------ >> >> In this case we have two paths which lead to L2 cache and hit above >> case. Is it really error case? > > No, but its not deterministic unless we mark the node, which doesn't > solve the problem of a table constructed like > > L1i->L2 (unified) > L1d->L2 (unified) > > or various other structures which aren't disallowed by the spec and have > non-deterministic real world meanings, anymore than constructing the > table like: > > L1i > Lid->L2(unified) > > which I tend to prefer because with a structuring like that it can be > deterministic (and in a way actually represents the non-coherent > behavior of (most?) ARM64 core's i-caches, as could be argued the first > example if the allocation policies are varied between the L2 nodes). > > The really ugly bits here happen if you add another layer: > > L1i->L2i-L3 > L1d------^ > > which is why I made that an error message, not including the fact that > since the levels aren't tagged the numbering and meaning isn't clear. > > (the L1i in the above example might be better called an L0i to avoid > throwing off the reset of the hierarchy numbering, also so it could be > ignored). > > Summary: > > I'm not at all happy with this specification's attempt to leave out > pieces of information which make parsing things more deterministic. In > this case I'm happy to demote the message level, but not remove it > entirely but I do think the obvious case you list shouldn't be the > default one. > > Lastly: > > I'm assuming the final result is that the table is actually being parsed > correctly despite the ugly message? Indeed, the ThunderX2 PPTT table is being parsed so that topology shown in lstopo and lscpu is correct. Thanks, Tomasz