Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423034AbbENWnW (ORCPT ); Thu, 14 May 2015 18:43:22 -0400 Received: from mail-pd0-f181.google.com ([209.85.192.181]:35728 "EHLO mail-pd0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030200AbbENWnU (ORCPT ); Thu, 14 May 2015 18:43:20 -0400 Message-ID: <555524E2.6080700@gmail.com> Date: Thu, 14 May 2015 15:42:42 -0700 From: Florian Fainelli User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kevin Cernekee , Leonid Yegoshin CC: mina86@mina86.com, Linux MIPS Mailing List , Zubair.Kakakhel@imgtec.com, Ralf Baechle , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] MIPS: Flush cache after DMA_FROM_DEVICE for agressively speculative CPUs References: <20150514014924.36593.68642.stgit@ubuntu-yegoshin> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2047 Lines: 46 On 13/05/15 19:49, Kevin Cernekee wrote: > On Wed, May 13, 2015 at 6:49 PM, Leonid Yegoshin > wrote: >> Some MIPS CPUs have an aggressive speculative load and may erroneuosly load >> some cache line in the middle of DMA transaction. CPU discards result but cache >> doesn't. If DMA happens from device then additional cache invalidation is needed >> on that CPU's after DMA. >> >> Found in test. >> >> Signed-off-by: Leonid Yegoshin >> --- >> arch/mips/mm/dma-default.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c >> index 609d1241b0c4..ccf49ecfbf8c 100644 >> --- a/arch/mips/mm/dma-default.c >> +++ b/arch/mips/mm/dma-default.c >> @@ -67,11 +67,13 @@ static inline struct page *dma_addr_to_page(struct device *dev, >> * systems and only the R10000 and R12000 are used in such systems, the >> * SGI IP28 Indigo² rsp. SGI IP32 aka O2. >> */ >> -static inline int cpu_needs_post_dma_flush(struct device *dev) >> +static inline int cpu_needs_post_dma_flush(struct device *dev, >> + enum dma_data_direction direction) >> { >> return !plat_device_is_coherent(dev) && >> (boot_cpu_type() == CPU_R10000 || >> boot_cpu_type() == CPU_R12000 || >> + (cpu_has_maar && (direction != DMA_TO_DEVICE)) || >> boot_cpu_type() == CPU_BMIPS5000); > > Can all of these CPUs safely skip the post_dma_flush on DMA_TO_DEVICE > (not just maar)? Agreed that would seem like the logical thing to do. You could then just skip the call to cpu_needs_post_dma_flush() and move the direction test in arch/mips/mm/dma-default.c for instance? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/