From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4A24C76196 for ; Thu, 6 Apr 2023 07:31:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235747AbjDFHbs (ORCPT ); Thu, 6 Apr 2023 03:31:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235697AbjDFHbp (ORCPT ); Thu, 6 Apr 2023 03:31:45 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6311C76BD for ; Thu, 6 Apr 2023 00:31:42 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3224016F8; Thu, 6 Apr 2023 00:32:26 -0700 (PDT) Received: from [192.168.1.12] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 616F83F73F; Thu, 6 Apr 2023 00:31:39 -0700 (PDT) Message-ID: <43d05005-052e-dd32-cf1e-17c569ebe2d9@arm.com> Date: Thu, 6 Apr 2023 09:31:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 2/3] cacheinfo: Check cache properties are present in DT Content-Language: en-US To: Conor Dooley Cc: linux-kernel@vger.kernel.org, Radu Rendec , Catalin Marinas , Will Deacon , Greg Kroah-Hartman , "Rafael J. Wysocki" , Sudeep Holla , Akihiko Odaki , Palmer Dabbelt , Gavin Shan , Jeremy Linton , linux-arm-kernel@lists.infradead.org, Alexandre Ghiti References: <20230327115953.788244-1-pierre.gondois@arm.com> <20230327115953.788244-3-pierre.gondois@arm.com> <20230404-hatred-swimmer-6fecdf33b57a@spud> From: Pierre Gondois In-Reply-To: <20230404-hatred-swimmer-6fecdf33b57a@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Conor, On 4/4/23 21:29, Conor Dooley wrote: > Hey Pierre, > > On Mon, Mar 27, 2023 at 01:59:50PM +0200, Pierre Gondois wrote: >> If a Device Tree (DT) is used, the presence of cache properties is >> assumed. Not finding any is not considered. For arm64 platforms, >> cache information can be fetched from the clidr_el1 register. >> Checking whether cache information is available in the DT >> allows to switch to using clidr_el1. >> >> init_of_cache_level() >> \-of_count_cache_leaves() >> will assume there a 2 cache leaves (L1 data/instruction caches), which >> can be different from clidr_el1 information. >> >> cache_setup_of_node() tries to read cache properties in the DT. >> If there are none, this is considered a success. Knowing no >> information was available would allow to switch to using clidr_el1. >> > > Alex reported seeing a bunch of messages in his boot log in QEMU since > -rc1 which appears to be the fault of, as far as I can tell, e0df442ee49 > ("cacheinfo: Check 'cache-unified' property to count cache leaves") > like: > cacheinfo: Unable to detect cache hierarchy for CPU N > > The RISC-V QEMU virt machine doesn't define any cache properties of any > sort in the dtb, and unlike the arm64 virt machine I tried (a72) doesn't > have some registers that cache info is discoverable from. > When we call of_count_cache_leaves() from init_of_cache_level() and > there are of course no reasons to increment leaves, we hit the return 2 > case you mention above, setting num_leaves to 2. > > As you mention, when we hit cache_setup_of_node(), levels is not going > to be set to one, so we trigger the condition (this_leaf->level != 1) > and, as there are no cache nodes, break out of the loop without > incrementing index. Index is therefore less than 2, and thus we return > -ENOENT. > This is of course propagated back out to detect_cache_attributes() and > triggers the "Unable to detect..." printout :( > > With this patch(set), the spurious error prints go away, but we are left > with a "Early cacheinfo failed, ret = -22" which will need to be fixed. > > So I think this also needs to be: > Fixes: de0df442ee49 ("cacheinfo: Check 'cache-unified' property to count cache leaves") > > Probably also needs a: > Reported-by: Alexandre Ghiti > since he's found an actual, rather than theoretical, problem! Ok yes indeed, I will do this and the other comments you made, Regards, Pierre > > Cheers, > Conor. >