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 71FD7C46467 for ; Wed, 4 Jan 2023 12:21:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239298AbjADMVG (ORCPT ); Wed, 4 Jan 2023 07:21:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239197AbjADMU0 (ORCPT ); Wed, 4 Jan 2023 07:20:26 -0500 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B74EA3B928; Wed, 4 Jan 2023 04:19:11 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1AFD75C016C; Wed, 4 Jan 2023 07:19:08 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Wed, 04 Jan 2023 07:19:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1672834748; x=1672921148; bh=PKp//PUcPl ATzvWVd6Xv2r7lr60JNRd0OJM9+iZsPUo=; b=TzdKUjktPVF29RGzt79d4JMhWU RLeXQbUAmaZIfjooDAmWrX/xV3HlmYGb6w99qWzC1jsXWPlkbXJGbGjbmbispKAL jkWOi+zyoK9Go03dJ7ZZXn6P9HaJxW/lL6ViMABml566QZe/I5WyVJgZHBDKLoDP 8BbWhji+6KtVJ+qX53VyK0kEB4I9GyovHPo+j8AXSa9/xw17g2QrVM5brKqJPNQH 0cISFbbFtyL6lw8BNnJMw74JAiHU6VHMl4WWyaJEdzFEpdmv12t25X+zucpvpY7m b4gclV3TpHtk/niVI+jQHX9JHxwSuKqlh8/5Qx6LdKA/MqqHKM/BTfBxQD2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672834748; x=1672921148; bh=PKp//PUcPlATzvWVd6Xv2r7lr60J NRd0OJM9+iZsPUo=; b=RxKXxfp863lPw897yGPAfp3FxiKDhweFKNrdC1umzkio wiSZvG2aggiTGe97fVKZORNaDSKYfyQ+MBaVk++UGQlJ4Q1oTdewas0y//oz0Djb pQ1YOofViasq/pIbiXh4YZU9Wtwl8mPaQf+LmbAFFUmwFXELY0vl00yXWi63Y0GQ lCt4T6Pzn8ZXSC0aJ62d8kPMqvfstftfXQlSaDiNo1YHZm8Jewc7joE4heocmfni WYAI3PXCwGtWfqnuqkQTdBV1sToW73kiUB4f7OkJaziJ78hlEMk9ERbEJ6Ze0Mlr +9IMM3ou2tPMuU88lldIEShNe8/HTFdWZS8Ve978Tw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeeigdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 20FCCB60086; Wed, 4 Jan 2023 07:19:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 Mime-Version: 1.0 Message-Id: <1b7d4caa-2c9c-4aef-81ac-47288d3a652c@app.fastmail.com> In-Reply-To: References: <20230103210400.3500626-10-conor@kernel.org> <43aee000-5b89-4d94-98d2-b37b1a18a83e@app.fastmail.com> Date: Wed, 04 Jan 2023 13:18:45 +0100 From: "Arnd Bergmann" To: "Conor Dooley" Cc: "Palmer Dabbelt" , Prabhakar , "Conor.Dooley" , "Andrew Jones" , "Albert Ou" , "Anup Patel" , "Atish Patra" , "Biju Das" , devicetree@vger.kernel.org, "Geert Uytterhoeven" , guoren , "Christoph Hellwig" , =?UTF-8?Q?Heiko_St=C3=BCbner?= , "Jisheng Zhang" , krzysztof.kozlowski+dt@linaro.org, linux-kernel@vger.kernel.org, Linux-Renesas , linux-riscv@lists.infradead.org, "Magnus Damm" , "Nathan Chancellor" , "Paul Walmsley" , "Philipp Tomsich" , "Lad, Prabhakar" , "Rob Herring" , "Samuel Holland" , soc@kernel.org, "Daire McNamara" Subject: Re: [RFC v5.1 9/9] [DON'T APPLY] cache: sifive-ccache: add cache flushing capability Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 4, 2023, at 12:56, Conor Dooley wrote: > On Wed, Jan 04, 2023 at 11:19:44AM +0100, Arnd Bergmann wrote: >> On Wed, Jan 4, 2023, at 10:23, Conor Dooley wrote: >> I would try to replace both of these indirections and instead >> handle it all from C code in arch_sync_dma_for_device() directly, >> for the purpose of readability and maintainability. >> static inline void dma_cache_clean(void *vaddr, size_t size) >> { >> if (!cache_maint_ops.clean) >> zicbom_cache_clean(vaddr, size, riscv_cbom_block_size); > > And I figure that this function is effectively a wrapper around ALT_CMO_OP()? > >> else >> cache_maint_ops.clean(vaddr, size, riscv_cbom_block_size); > > And this one gets registered by the driver using an interface like the > one I already proposed, just with the cache_maint_ops struct expanded? Yes, exactly. > Extrapolating, with these changes having an errata would not even be > needed in order to do cache maintenance. > Since the ALT_CMO_OP() version would only be used inside > zicbom_cache_clean(), assuming I understood correctly, a driver could > just register cache_maint_ops for a given platform without having to > muck around with errata. That is the idea, and ALT_CMO_OP() itself can just go away as by just putting the inline asm without the alternative into the zicbom_cache_clean() version, making the THEAD branch yet another cache_maint_ops instance. >> which then makes it very clear what the actual code path >> is, while leaving the zicbom case free of indirect function >> calls. You can still use a static_branch() to optimize the >> conditional, but I would try to avoid any extra indirection >> levels or errata checks. > > The other thing that I like about this is we can then remove the various > calls to ALT_CMO_OP() that are scattered around arch/riscv now & replace > them with functions that have more understandable names. I only see them in arch/riscv/mm/dma-noncoherent.c and arch/riscv/mm/pmem.c, but yes, both of these should just call the new functions, whatever the calling conventions end up being. Arnd