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 C8378C46467 for ; Sat, 7 Jan 2023 22:22:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232774AbjAGWWF (ORCPT ); Sat, 7 Jan 2023 17:22:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229964AbjAGWWC (ORCPT ); Sat, 7 Jan 2023 17:22:02 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0829E1181F; Sat, 7 Jan 2023 14:21:59 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 62D2B60BCB; Sat, 7 Jan 2023 22:21:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1F77C433D2; Sat, 7 Jan 2023 22:21:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673130118; bh=PiDekM/SMRsMOKh2h1xaaJ+LnnT+/grSKCgTvgHsl1I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vb2K7A+rHO9P3ICGMHyIN5P0UCTgP0QX/GYeQnKSVy4VTkeV7vAflTFmB/ligLYeN InpxaSFlIkdCBtTI8TjQgxq7EbnoUHylguttF6ItTXv04spS+QF5/gjbICMZH6N0l2 dR/QFLQNeDF9W1dGpqDHbnCwz7F1gKiKM3Xdc08zOdzl6k5Lt8hI8T9lt6Z2vqUJ0i tP01T1SSaswaz6li6J82FA5RyNlcmHkonOIoaD3O24jKLPOs0UZuzty13REeA8yjqG UTkoE0Zs283AIHSZtoZ/EUVRAZA6Yd+sg1/zuvKuSbATKTySlz7wbH8NnKNhxp8jQH qXOVj/FAF1VRw== Date: Sat, 7 Jan 2023 22:21:52 +0000 From: Conor Dooley To: Arnd Bergmann Cc: Prabhakar , "Conor.Dooley" , Geert Uytterhoeven , Heiko =?iso-8859-1?Q?St=FCbner?= , guoren , Andrew Jones , Paul Walmsley , Palmer Dabbelt , Albert Ou , "open list:RISC-V ARCHITECTURE" , open list , devicetree@vger.kernel.org, Linux-Renesas , "Lad, Prabhakar" , Philipp Tomsich , Nathan Chancellor , Atish Patra , Anup Patel , Tsukasa OI , Jisheng Zhang , Mayuresh Chitale Subject: Re: [RFC PATCH v6 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management Message-ID: References: <20230106185526.260163-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20230106185526.260163-2-prabhakar.mahadev-lad.rj@bp.renesas.com> <6f7d06ef-d74d-4dfc-9b77-6ae83e0d7816@app.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wPdXWhj8wEQMz5ZG" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --wPdXWhj8wEQMz5ZG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 07, 2023 at 10:52:55PM +0100, Arnd Bergmann wrote: > On Sat, Jan 7, 2023, at 00:29, Conor Dooley wrote: > > On Fri, Jan 06, 2023 at 11:31:33PM +0100, Arnd Bergmann wrote: > >> On Fri, Jan 6, 2023, at 19:55, Prabhakar wrote: > >> > From: Lad Prabhakar > >> > +struct riscv_cache_ops zicbom_cmo_ops =3D { > >> > + .clean_range =3D &zicbom_cmo_clean_range, > >> > + .inv_range =3D &zicbom_cmo_inval_range, > >> > + .flush_range =3D &zicbom_cmo_flush_range, > >> > +}; > >> > +#else > >> > +struct riscv_cache_ops zicbom_cmo_ops =3D { > >> > + .clean_range =3D NULL, > >> > + .inv_range =3D NULL, > >> > + .flush_range =3D NULL, > >> > + .riscv_dma_noncoherent_cmo_ops =3D NULL, > >> > +}; > >> > +#endif > >> > +EXPORT_SYMBOL(zicbom_cmo_ops); > >>=20 > >> Same here: If the ZICBOM ISA is disabled, nothing should > >> reference zicbom_cmo_ops. > > > >> Also, since ZICBOM is a standard > >> extension, I think it makes sense to always have it enabled, > >> at least whenever noncoherent DMA is supported, that way > >> it can be the default that gets used in the absence of any > >> nonstandard cache controller. > > > > While I think of it, this is not possible as Zicbom requires toolchain > > support whereas the alternative methods for non-coherent DMA do not. >=20 > Ah, I see. Would it be possible to use the same .long trick > as in the other ones though? Something like >=20 > #if CONFIG_AS_VERSION >=3D 23600 /* or whichever version */ > /* proper inline asm */ > #else > /* .long hack */ > #endif >=20 > That way everyone can use it, and the hack would automatically > go away in a few years after linux requires a newer toolchain. > Alternatively, the entire noncoherent-dma support could be > made to depend on whichever toolchain introduced Zicbom. Ehh, I don't think that's a great idea. It'd require far too recent a toolchain IMO. Ideally, in my opinion, we'd just do something like what Drew has proposed for Zicboz, negating the need for a check at all: https://lore.kernel.org/linux-riscv/20221027130247.31634-4-ajones@ventanami= cro.com/ Been waiting for that to be re-spun and Palmer to accept it before doing the same thing for Zicbom. At present we have this in the arch Kconfig: config TOOLCHAIN_HAS_ZICBOM bool default y depends on !64BIT || $(cc-option,-mabi=3Dlp64 -march=3Drv64ima_zicbom) depends on !32BIT || $(cc-option,-mabi=3Dilp32 -march=3Drv32ima_zicbom) depends on LLD_VERSION >=3D 150000 || LD_VERSION >=3D 23800 config RISCV_ISA_ZICBOM bool "Zicbom extension support for non-coherent DMA operation" depends on TOOLCHAIN_HAS_ZICBOM The linker version check is entirely due to the linker having issues if it sees zicbom in the ISA string in object files. I'd been intending to do that for Zicbom anyway, so I guess I'll just go do it & Prabhakar can attach it to his v7.. Thanks, Conor. --wPdXWhj8wEQMz5ZG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCY7nwgAAKCRB4tDGHoIJi 0knOAQD/AxXaV4xpsQxTE+igjsO7v2ITKUJoibgZqFqyuxZRHwEAlQbeOIbKC6Qc 8Zq/AaT9dL2pwKITsgEjv/2IEYLx7Qo= =ZbEQ -----END PGP SIGNATURE----- --wPdXWhj8wEQMz5ZG--