Received: by 10.192.165.148 with SMTP id m20csp677935imm; Fri, 27 Apr 2018 05:51:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqkRMpg/6wmZ+B3La9KwJYqPpLcbgGeFD7AhA9gsSajOZrnfVfJ6L0E0ynxI6nMKvk7JJ2u X-Received: by 2002:a63:6fc9:: with SMTP id k192-v6mr2076404pgc.143.1524833485730; Fri, 27 Apr 2018 05:51:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524833485; cv=none; d=google.com; s=arc-20160816; b=eQoGYoLU7drYU+KIFIpRm+EokYNGSkkg2Al+q8bg+Zv1eCOzrFQTlNHLzMqIaFiidv fiH1NxCr4yulYQ8bTsxuQONUFPMczS/MJaXq53ZPs4kxWSX/S+18AcGAIun6599IJLYu VYEiT1+Ok0C76EXevWErqNfWyNzTFUyaarYlAmEK863OZcExnhlhHer1RE4/umrjR1lt l7wdoI2JjgsQ8m6ffn1cl9DKWgMuKmc+nJg8cuFflTXOcT1+Ck9cZKTxl1IKaCQzLnbx PdTN7a3R6Ek98kjcmGCu3/70RKDlepysYfomJAkigYVoVZl+QgBAixoYP4dblFS7BM9/ j1xw== 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 :arc-authentication-results; bh=RZMy8Vva5Z6l0IEYwvM4CexewWI6mTCnVdJmvMk7w/A=; b=JW72eoPxpxrljpfiAop4WSSFVIEHBMLmf9SL2yuESxFwtXexd8HTGyVgSxWdMbvvy9 qksjN1ENRz4ftc6l6fjx3jIzA/c6Qoyv7GWgNKPm3p3WkPAjK2kCVouRZzLa0I737cHF 0ITB/9GBTtY+2JtTfb92pyCjRbLsXcWNauPs4nLXhWJMvx80lw3qGrwRgHfnJo7vise6 rxBLMcE2ujxw35fVoUkg9m8O1ySB5iUQ1tk7p7SpU7wIAsXvt2ojpmCQb6+TetutbkT9 J5ocrIleSgG3pfeZ/uC6/grnntDoc/1VEG8jWBgIiF39u7kOVpgSxFmOxfoVaNvLNFsD sggg== 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 u193-v6si1201778pgc.186.2018.04.27.05.51.11; Fri, 27 Apr 2018 05:51:25 -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 S1758128AbeD0MuD (ORCPT + 99 others); Fri, 27 Apr 2018 08:50:03 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:39662 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757241AbeD0MuC (ORCPT ); Fri, 27 Apr 2018 08:50:02 -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 A4C761529; Fri, 27 Apr 2018 05:50:01 -0700 (PDT) Received: from [10.1.210.28] (e107155-lin.cambridge.arm.com [10.1.210.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 654713F4FF; Fri, 27 Apr 2018 05:49:53 -0700 (PDT) Cc: Sudeep Holla , linux-arm-kernel@lists.infradead.org, Lorenzo.Pieralisi@arm.com, hanjun.guo@linaro.org, rjw@rjwysocki.net, Will.Deacon@arm.com, Catalin.Marinas@arm.com, gregkh@linuxfoundation.org, Mark.Rutland@arm.com, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, wangxiongfeng2@huawei.com, vkilari@codeaurora.org, ahs3@redhat.com, Dietmar.Eggemann@arm.com, Morten.Rasmussen@arm.com, palmer@sifive.com, lenb@kernel.org, john.garry@huawei.com, austinwc@codeaurora.org, tnowicki@caviumnetworks.com, jhugo@qti.qualcomm.com, timur@qti.qualcomm.com, ard.biesheuvel@linaro.org Subject: Re: [PATCH v8 07/13] drivers: base cacheinfo: Add support for ACPI based firmware tables To: Jeremy Linton , linux-acpi@vger.kernel.org References: <20180425233121.13270-1-jeremy.linton@arm.com> <20180425233121.13270-8-jeremy.linton@arm.com> <48bd3299-a95a-8aa6-524d-b3aa01dd9ef2@arm.com> From: Sudeep Holla Organization: ARM Message-ID: <14062628-d6bb-2e46-fd7c-edce814b5d22@arm.com> Date: Fri, 27 Apr 2018 13:49:51 +0100 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: <48bd3299-a95a-8aa6-524d-b3aa01dd9ef2@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/04/18 19:57, Jeremy Linton wrote: > Hi, > > On 04/26/2018 06:05 AM, Sudeep Holla wrote: >> >> >> On 26/04/18 00:31, Jeremy Linton wrote: >>> Call ACPI cache parsing routines from base cacheinfo code if ACPI >>> is enable. Also stub out cache_setup_acpi() so that individual >>> architectures can enable ACPI topology parsing. >>> >> >> [...] >> >>> +#ifndef CONFIG_ACPI >>> +static inline int acpi_find_last_cache_level(unsigned int cpu) >>> +{ >>> +    /* ACPI kernels should be built with PPTT support */ >> >> This sounds incorrect for x86. But I understand why you have it there. >> Does it makes sense to change above to .. ? >> >> #if !defined(CONFIG_ACPI) || (defined(CONFIG_ACPI) && >> !(CONFIG_ACPI_PPTT)) >> > I'm not sure what that buys us, if anything you want more non-users of > the function to be falling through to the function prototype rather than > the static inline. The only place any of this matters (as long as the > compiler/linker is tossing the static inline) is arm64 because its the > only arch making a call to acpi_find_last_cache_level(). ACPI_PPTT is > also only visible on arm64 at the moment due to being wrapped in a if > ARM64 in the Kconfig > Fair enough. > Put another way, I wouldn't expect an arch to have a 'user' visible > option to enable/disable parsing the PPTT. If an arch can handle > ACPI/PPTT topology then I would expect it to be fixed to the CONFIG_ACPI > state. What happens when acpi_find_last_cache_level() is called should > only be dependent on whether ACPI is enabled, the PPTT parser itself > will handle the cases of a missing table. Agreed. But technically that statement is still incorrect as x86 ACPI build need not have PPTT enabled. IMO you can reword it, but I will leave that to Rafael :) Other than that, it looks good. Acked-by: Sudeep Holla -- Regards, Sudeep