From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932656AbcHJAUX (ORCPT ); Tue, 9 Aug 2016 20:20:23 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:33904 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752499AbcHJAUU (ORCPT ); Tue, 9 Aug 2016 20:20:20 -0400 Subject: Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE To: Laura Abbott , Sumit Semwal , John Stultz , =?UTF-8?Q?Arve_Hj=c3=b8nnev=c3=a5g?= , Riley Andrews References: <1470678577-14010-1-git-send-email-labbott@redhat.com> <1470678577-14010-3-git-send-email-labbott@redhat.com> Cc: devel@driverdev.osuosl.org, Jon Medhurst , Android Kernel Team , Greg Kroah-Hartman , Daniel Vetter , Will Deacon , Russell King , linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Rohit kumar , Bryan Huntsman , Jeremy Gebben , Eun Taik Lee , Catalin Marinas , Liviu Dudau , Mitchel Humpherys , linux-arm-kernel@lists.infradead.org From: Florian Fainelli Message-ID: <905897d4-7528-80a6-980d-18520069f321@gmail.com> Date: Tue, 9 Aug 2016 17:20:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/09/2016 05:13 PM, Laura Abbott wrote: > On 08/09/2016 02:56 PM, Florian Fainelli wrote: >> On 08/08/2016 10:49 AM, Laura Abbott wrote: >>> arm may need the kernel_force_cache APIs to guarantee data consistency. >>> Implement versions of these APIs based on the DMA APIs. >>> >>> Signed-off-by: Laura Abbott >>> --- >>> arch/arm/include/asm/cacheflush.h | 4 ++ >>> arch/arm/mm/dma-mapping.c | 119 >>> -------------------------------------- >>> arch/arm/mm/flush.c | 115 >>> ++++++++++++++++++++++++++++++++++++ >> >> Why is the code moved between dma-mapping.c and flush.c? It was not >> obvious while looking at these patches why this is needed. >> > > I wanted to use the cache flushing routines from dma-mapping.c and > it seemed better to pull them out vs. trying to put more generic > cache flushing code in dma-mapping.c. flush.c seemed like an > appropriate place although I forgot about the dependency on CONFIG_MMU. > It can certainly remain in dma-mapping.c if deemed appropriate. My concern is that this is an area of the kernel where you might be looking for stable backports, so avoiding churn in there is desireable and if the new cache APIs become accepted and standard, since they are building directly on top of the DMA-API, keeping them in dma-mapping.c seems consistent. My 2 cents. -- Florian From mboxrd@z Thu Jan 1 00:00:00 1970 From: f.fainelli@gmail.com (Florian Fainelli) Date: Tue, 9 Aug 2016 17:20:17 -0700 Subject: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE In-Reply-To: References: <1470678577-14010-1-git-send-email-labbott@redhat.com> <1470678577-14010-3-git-send-email-labbott@redhat.com> Message-ID: <905897d4-7528-80a6-980d-18520069f321@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/09/2016 05:13 PM, Laura Abbott wrote: > On 08/09/2016 02:56 PM, Florian Fainelli wrote: >> On 08/08/2016 10:49 AM, Laura Abbott wrote: >>> arm may need the kernel_force_cache APIs to guarantee data consistency. >>> Implement versions of these APIs based on the DMA APIs. >>> >>> Signed-off-by: Laura Abbott >>> --- >>> arch/arm/include/asm/cacheflush.h | 4 ++ >>> arch/arm/mm/dma-mapping.c | 119 >>> -------------------------------------- >>> arch/arm/mm/flush.c | 115 >>> ++++++++++++++++++++++++++++++++++++ >> >> Why is the code moved between dma-mapping.c and flush.c? It was not >> obvious while looking at these patches why this is needed. >> > > I wanted to use the cache flushing routines from dma-mapping.c and > it seemed better to pull them out vs. trying to put more generic > cache flushing code in dma-mapping.c. flush.c seemed like an > appropriate place although I forgot about the dependency on CONFIG_MMU. > It can certainly remain in dma-mapping.c if deemed appropriate. My concern is that this is an area of the kernel where you might be looking for stable backports, so avoiding churn in there is desireable and if the new cache APIs become accepted and standard, since they are building directly on top of the DMA-API, keeping them in dma-mapping.c seems consistent. My 2 cents. -- Florian