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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D04D2C433EF for ; Fri, 1 Jul 2022 11:13:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qbufLFr5xXzzUlQJ2/mwQSaS/ICSSUea0X91RaJzRKg=; b=pN5jBbO9ecNbW3 WFpA+6sDEGYGZ76sD5TKkc+6JxBUpHaBlifJ3uj8d3Us9og9cydmhgw/l0089z+27bl0mV5dhadCl 97yHnut2vVu+Hja9mRR9KAWt78DBhdS/Zxs0ROj4s8n58N7kCvOTjFXpd2z6zReqbT2v0pte4RKHY +yQRY2mynLaHGfsMYKIhFti7gTJCDkWvJKUOanqjP6y/1D8OV00HMj0l1+JOHU/bPqcPB/GCSgd1h pKxwNJrvAA9+KXEGiuQTgzZFq3fgf/T5mCU8PGcBIBsJ6Pyi54kCx3s+4cFEYjiq6QliSWyc8PGxN 9h1wZjAdklrCewL4bOjQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o7EZG-004HIB-O5; Fri, 01 Jul 2022 11:12:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o7EZD-004HEc-5G; Fri, 01 Jul 2022 11:12:08 +0000 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 883761424; Fri, 1 Jul 2022 04:12:02 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1BE093F66F; Fri, 1 Jul 2022 04:11:58 -0700 (PDT) Date: Fri, 1 Jul 2022 12:11:56 +0100 From: Sudeep Holla To: Conor.Dooley@microchip.com Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, atishp@atishpatra.org, atishp@rivosinc.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, wangqing@vivo.com, robh+dt@kernel.org, rafael@kernel.org, ionela.voinescu@arm.com, pierre.gondois@arm.com, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, gshan@redhat.com, Valentina.FernandezAlanis@microchip.com Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo Message-ID: <20220701111156.dqmdrj2hzjadojz2@bogus> References: <03433f57-04ed-44a9-a2f6-5577df94f11e@microchip.com> <20220630103958.tcear5oz3orsqwg6@bogus> <9d9e80b8-17e2-b1d9-14fa-f1d8d7dfbd9a@microchip.com> <20220630173513.dyrrmjbpxzi3e6fe@bogus> <3840dbf7-ca18-b7ab-4d7a-92c9305476fa@microchip.com> <20220630200717.zlc6z6zcqbsw7euk@bogus> <20220630202141.37p5qhppkiz6wrcb@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220701_041207_340395_57A214A6 X-CRM114-Status: GOOD ( 24.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 30, 2022 at 10:07:49PM +0000, Conor.Dooley@microchip.com wrote: > > > On 30/06/2022 21:21, Sudeep Holla wrote: > > On Thu, Jun 30, 2022 at 08:13:55PM +0000, Conor.Dooley@microchip.com wrote: > >> > >> I didn't have the time to go digging into things, but the following > >> macro looked odd: > >> #define per_cpu_cacheinfo_idx(cpu, idx) \ > >> (per_cpu_cacheinfo(cpu) + (idx)) > >> Maybe it is just badly named, but is this getting the per_cpu_cacheinfo > >> and then incrementing intentionally, or is it meant to get the > >> per_cpu_cacheinfo of cpu + idx? > > > > OK, basically per_cpu_cacheinfo(cpu) get the information for a cpu > > while per_cpu_cacheinfo_idx(cpu, idx) will fetch the information for a > > given cpu and given index within the cpu. So we are incrementing the > > pointer by the index. These work just fine on arm64 platform. > > Right, that's what I figured but wanted to be sure. > OK > > > > Not sure if compiler is optimising something as I still can't understand > > how we can end up with valid llc but fw_token as NULL. > See idk about that. The following fails to boot. > index 167abfa6f37d..9d45c37fb004 100644 > --- a/drivers/base/cacheinfo.c > +++ b/drivers/base/cacheinfo.c > @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu) > static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf, > struct cacheinfo *sib_leaf) > { > + if (!this_leaf || !sib_leaf) > + return false; Did you hit this ? > /* > * For non DT/ACPI systems, assume unique level 1 caches, > * system-wide shared caches for all other levels. This will be used > @@ -74,8 +76,12 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y) > > llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1); > llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1); > + if (!llc_x || !llc_y){ > + printk("llc was null\n"); Or this ? > + return false; > + } > > - return cache_leaves_are_shared(llc_x, llc_y); > + return false; //cache_leaves_are_shared(llc_x, llc_y); Even the above change fails to boot ? Coz you are always returning false here too. > } > > #ifdef CONFIG_OF > > and this boots: > > diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c > index 167abfa6f37d..01900908fe31 100644 > --- a/drivers/base/cacheinfo.c > +++ b/drivers/base/cacheinfo.c > @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu) > static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf, > struct cacheinfo *sib_leaf) > { > + if (!this_leaf || !sib_leaf) > + return false; > /* > * For non DT/ACPI systems, assume unique level 1 caches, > * system-wide shared caches for all other levels. This will be used > @@ -75,7 +77,7 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y) > llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1); > llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1); > You are just missing the checks for llc_x and llc_y and it works which means llc_x and llc_y is where things are going wrong. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel