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 66C72E92FF1 for ; Fri, 6 Oct 2023 07:43:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230519AbjJFHnT (ORCPT ); Fri, 6 Oct 2023 03:43:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231171AbjJFHm7 (ORCPT ); Fri, 6 Oct 2023 03:42:59 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14DA9386B for ; Fri, 6 Oct 2023 00:40:55 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 0AFDA6732D; Fri, 6 Oct 2023 09:40:46 +0200 (CEST) Date: Fri, 6 Oct 2023 09:40:45 +0200 From: Christoph Hellwig To: Jim Quinlan Cc: Christoph Hellwig , Linus Walleij , bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com, Russell King , Arnd Bergmann , Geert Uytterhoeven , "Russell King (Oracle)" , Andrew Morton , Jonathan Corbet , Thomas Gleixner , Sebastian Reichel , "Mike Rapoport (IBM)" , Eric DeVolder , Nathan Chancellor , "Kirill A. Shutemov" , Christophe Leroy , "moderated list:ARM PORT" , open list Subject: Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA Message-ID: <20231006074045.GA15303@lst.de> References: <20230926175208.9298-1-james.quinlan@broadcom.com> <20230926175208.9298-2-james.quinlan@broadcom.com> <20231002061628.GC911@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 05, 2023 at 01:53:33PM -0400, Jim Quinlan wrote: > > Yes, DMA_DIRECT_REMAP should only be used for platforms using the > > generic generic remap that plus straight into dma-direct and > > bypasses arch_dma_alloc. > > > > ARM first needs support to directly set the uncached/wc bits on > > the direct mapping for CMA, which should be fairly simple but require > > wide spread testing. > > > > I'd be happy to work with anyone who wants to look into this. > I'd like to look into this and help make it work for ARCH=arm but you > seem to be saying that you also need help from ARM the company? No, I don't care about companies. I just need someone (singular or plural) to test a wide range of arm systems. Here is my idea for the attack plan: As step 1 ignore the whole CMA direct map issue, and just to the trivial generic dma remap conversion. This should involved: - select DMA_DIRECT_REMAP - provide arch_dma_prep_coherent to flush out all dirty data by calling __dma_clear_buffer - remove the existing arch_dma_alloc/arch_dma_free and all their infrastructure With this things should work fine on any system not using CMA Then attack the CMA direct mapping: - modify the core DMA mapping code so that the ARCH_HAS_DMA_SET_UNCACHED code is only used conditionally I'm not quite sure what the right checks and right place is, but the intent is that it should allow arm to only use that path for CMA allocations. For all existing users of CONFIG_ARCH_HAS_DMA_SET_UNCACHED it should evaluate to a compile-time true to not change the behavior or code generation - then in arm select ARCH_HAS_DMA_SET_UNCACHED and implement arch_dma_set_uncached, arch_dma_clear_uncached and the new helper above