Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4172332imm; Mon, 17 Sep 2018 09:17:42 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaWEVZ9ZFKhOSflAxeHuK3LO9mPl/SfGBC91F7dKO852nXxXkKDY+1OZ+wzHaBdAYd5YkRQ X-Received: by 2002:a17:902:bd95:: with SMTP id q21-v6mr25600575pls.284.1537201062043; Mon, 17 Sep 2018 09:17:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537201062; cv=none; d=google.com; s=arc-20160816; b=OwZ4o9X68w9wBV2ISj9vYdzqGhX5Wikc6hbm8beXrHKIKmVgwc9eryFAXSM7hgdyzW djt0II0YDvz7/I6dFMq557YbjNwwUsohDEilQpxrmooPfqGV9UeMDsfoT5E2KhKgpn1B EG+FwJC/HMxeVKCOekhFz2zAuTKNHah7UpiLgJBhiWVucWppJpykdRwCgULK31FAwOCy cQQn+khJrDaNMSpxYrnhYy3+ozRbbKhV5cqzUT0ovpoCOUuBtLiv+YMg6lJuXuC8CZ9S /TN5/FQ4bHnAA17ZgdhYyZK285z0W3dwkM0SF/xeCk9z6P+ZRhcTCX9RGxE+ziYnTxai 3j4Q== 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:organization:from:references:to:subject:cc; bh=wuKR6PAPayjgAEXrgyZ0GPVKXJbZZG8qs3GOxHncufo=; b=buip90CaNRIdVKrZufDLVK3vNdGpwSlL6sqk+D94nhNvbSpvrAAWCi/QX3sIJbvZ9q MYh3BtctV3UncOXQrhYtE++OP0cHLDwYx8qpQ+5lQU3pWPgluNba8c0ZS+m3GyjNSdgR Z5ipWCwrX2YmXiold0ADkgeQ1zBBblK5py5IG+zJa0n+i299VadGKT+TxKupxuqTbG3y dngFXyrKKWB+JYMrmjsQh6eSCY66ERzwo6t7f2Ql4YNMzVoqq1r5FdE3LMfJWye2CI9a Wm0igPZd75d8oGjC2NLf1FU0O0grF+d1xuN/B7v84dyebykDWcgnWYJiGizFo6bQinS9 ziHQ== 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 i9-v6si15521057pgk.403.2018.09.17.09.17.26; Mon, 17 Sep 2018 09:17:42 -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 S1728541AbeIQVpN (ORCPT + 99 others); Mon, 17 Sep 2018 17:45:13 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:33472 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726795AbeIQVpN (ORCPT ); Mon, 17 Sep 2018 17:45:13 -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 D76DCED1; Mon, 17 Sep 2018 09:17:10 -0700 (PDT) Received: from [10.4.12.116] (e107155-lin.emea.arm.com [10.4.12.116]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 71AA63F557; Mon, 17 Sep 2018 09:17:09 -0700 (PDT) Cc: Sudeep Holla , linux-kernel@vger.kernel.org, vkilari@codeaurora.org Subject: Re: [PATCH v2 2/2] ACPI/PPTT: Handle architecturally unknown cache types To: Jeffrey Hugo , gregkh@linuxfoundation.org, rjw@rjwysocki.net, linux-acpi@vger.kernel.org, jeremy.linton@arm.com References: <1536942489-4018-1-git-send-email-jhugo@codeaurora.org> <1536942489-4018-3-git-send-email-jhugo@codeaurora.org> From: Sudeep Holla Organization: ARM Message-ID: <71208e0e-fba9-ad6c-7578-a53fd1aa3f40@arm.com> Date: Mon, 17 Sep 2018 17:17:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1536942489-4018-3-git-send-email-jhugo@codeaurora.org> Content-Type: text/plain; charset=utf-8 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 On 14/09/18 17:28, 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. > > Fixes: 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing) > Reported-by: Vijaya Kumar K > Signed-off-by: Jeffrey Hugo > --- > drivers/acpi/pptt.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > index d1e26cb..bb00ed9 100644 > --- a/drivers/acpi/pptt.c > +++ b/drivers/acpi/pptt.c > @@ -402,11 +402,18 @@ 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 either the cache has > + * been fully specified in PPTT, or 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) > + 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; I thought I did mention that we can drop the valid_flags altogether unless Jeremy has reasons not to. -- Regards, Sudeep