Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1247599imm; Fri, 28 Sep 2018 14:53:04 -0700 (PDT) X-Google-Smtp-Source: ACcGV603bNvlty8k/4VoJcawCOgB6JIk6V7OuL4wqB1Duf4+/YuhEF2OPsTGueMvWh1Kk+PkDMUq X-Received: by 2002:a63:fb54:: with SMTP id w20-v6mr446099pgj.321.1538171584444; Fri, 28 Sep 2018 14:53:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538171584; cv=none; d=google.com; s=arc-20160816; b=nKvRGycFrsddIIoBEC72X2VKSOFuco35NbQ7MrPXus8TnfuTojUcGuzdCfwkxBLZj/ 6z6c/N68VhmNWO9SCULrnd2HUKl4QWF84LQSg4PMs501luFxTwDbu9k+U7ElZvedGkSb oJ5TRZwUZV+A4V621/XRxgOSbSY7mPYdY6qRJd0bsWQpaURFCpiK4oFBcpmFngnapQLv M4rIvQ1ixS+ISzAJD+Pef6vi0Krg10LswVqKZqJ5xY+qsOcAVH1M/MDshF7EuLu8s4lD xEFH4Q+DVb3P9Tm0/cGUJSNk1q2DRXOTdIjKpMTkLFgJvvK/PhucW6g+cyIqunRLvORI nJPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=E5JGP7oSnDVT4K5zconbOR8XxeLudnY86ywN7IHwXPQ=; b=niMQkDvnCEaEzyLQNWw7WV2WOmsopzHOzg37NtN0c8D8VIYHWnGXOpRZVSUJFTOO2I 0lBoAaBUtfggKZZn5GSQ3DDtoUTNopmAV7aDjbacqNT0i7+4dWpFA+3eqoT0y0WPFwoP YTmrmIo2QOLoTFLWdmgcJCrMNavzRH+9hw16dXfLFP67LDhS1oBSlBMjcMHf9/sQ2CJi 7X4iIrTw2uSugGj0eJAvrRbTa6x5XFNXVJ4ksyu1wkUQOs1IeNJFKqNBK3KhSSaXhuAo lt7V/c96TE3eg0i+l+uyzUTPO4UEgERnIVl55GLwxqvUjQ1p/CT3iBwmVGd+yKTaeNuh vIMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e22-v6si6001546pfb.185.2018.09.28.14.52.50; Fri, 28 Sep 2018 14:53:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727355AbeI2ERz (ORCPT + 99 others); Sat, 29 Sep 2018 00:17:55 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56244 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727234AbeI2ERz (ORCPT ); Sat, 29 Sep 2018 00:17:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 34B9D18A; Fri, 28 Sep 2018 14:52:14 -0700 (PDT) Received: from [192.168.100.242] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B625B3F5B3; Fri, 28 Sep 2018 14:52:13 -0700 (PDT) Subject: Re: [PATCH v3 2/2] ACPI/PPTT: Handle architecturally unknown cache types To: Jeffrey Hugo , sudeep.holla@arm.com, gregkh@linuxfoundation.org, rjw@rjwysocki.net, linux-acpi@vger.kernel.org Cc: linux-kernel@vger.kernel.org, vkilari@codeaurora.org References: <1538103477-15513-1-git-send-email-jhugo@codeaurora.org> <1538103477-15513-3-git-send-email-jhugo@codeaurora.org> From: Jeremy Linton Message-ID: <377f840c-6c4f-9a17-7aa5-cc2fa4f7b244@arm.com> Date: Fri, 28 Sep 2018 16:52:10 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1538103477-15513-3-git-send-email-jhugo@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 09/27/2018 09:57 PM, Jeffrey Hugo wrote: > The type of a cache might not be specified by architectural mechanisms (ie > system registers), but its type might be specified in the PPTT. In this > case, we should populate the type of the cache, rather than leave it > undefined. > > This fixes the issue where the cacheinfo driver will not populate sysfs > for such caches, resulting in the information missing from utilities like > lstopo and lscpu, thus degrading the user experience. The code looks fine to me. Reviewed-by: Jeremy Linton Thanks! > > Fixes: 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing) > Reported-by: Vijaya Kumar K PS: Although, if you end up re-spinning this, I think its appropriate to add in the commit message that what this is really working around is firmware that has declined to fill out all the fields in the cache description. > Signed-off-by: Jeffrey Hugo > --- > drivers/acpi/pptt.c | 30 +++++++++++++----------------- > 1 file changed, 13 insertions(+), 17 deletions(-) > > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > index d1e26cb..38ac30e 100644 > --- a/drivers/acpi/pptt.c > +++ b/drivers/acpi/pptt.c > @@ -357,25 +357,15 @@ static void update_cache_properties(struct cacheinfo *this_leaf, > struct acpi_pptt_cache *found_cache, > struct acpi_pptt_processor *cpu_node) > { > - int valid_flags = 0; > - > this_leaf->fw_token = cpu_node; > - if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) { > + if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) > this_leaf->size = found_cache->size; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) { > + if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) > this_leaf->coherency_line_size = found_cache->line_size; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) { > + if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) > this_leaf->number_of_sets = found_cache->number_of_sets; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) { > + if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) > this_leaf->ways_of_associativity = found_cache->associativity; > - valid_flags++; > - } > if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) { > switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) { > case ACPI_PPTT_CACHE_POLICY_WT: > @@ -402,11 +392,17 @@ static void update_cache_properties(struct cacheinfo *this_leaf, > } > } > /* > - * If the above flags are valid, and the cache type is NOCACHE > - * update the cache type as well. > + * If cache type is NOCACHE, then the cache hasn't been specified > + * via other mechanisms. Update the type if a cache type has been > + * provided. > + * > + * Note, we assume such caches are unified based on conventional system > + * design and known examples. Significant work is required elsewhere to > + * fully support data/instruction only type caches which are only > + * specified in PPTT. > */ > if (this_leaf->type == CACHE_TYPE_NOCACHE && > - valid_flags == PPTT_CHECKED_ATTRIBUTES) > + found_cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) > this_leaf->type = CACHE_TYPE_UNIFIED; > } > >