This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 26 21:13:38 2024 >From mailfetcher Thu Nov 16 11:26:59 2017 Envelope-to: lkml@grols.ch Delivery-date: Thu, 16 Nov 2017 11:26:58 +0100 Received: from srv.grols.ch [5.172.41.101] by 0359fc81c977 with IMAP (fetchmail-6.3.26) for (single-drop); Thu, 16 Nov 2017 11:26:59 +0100 (CET) Received: from vger.kernel.org ([209.132.180.67]) by home.grols.ch with esmtp (Exim 4.89) (envelope-from ) id 1eFHNq-0008Bi-Er for lkml@grols.ch; Thu, 16 Nov 2017 11:26:58 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759691AbdKPK04 (ORCPT ); Thu, 16 Nov 2017 05:26:56 -0500 Received: from esa4.microchip.iphmx.com ([68.232.154.123]:52875 "EHLO esa4.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758104AbdKPK0y (ORCPT ); Thu, 16 Nov 2017 0 X-Ironport-AV: E=Sophos;i="5.43,434,1503385200"; d="scan'208";a="8658441" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa4.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2017 03:26:51 -0700 Received: from [10.145.4.41] (10.10.76.4) by chn-sv-exch07.mchp-main.com (10.10.76.108) with Microsoft SMTP Server id 14.3.352.0; Thu, 16 Nov 2017 03:26:47 -0700 Subject: Re: [RFC PATCH 2/2] spi: atmel: Fix DMA transfers data corruption To: Trent Piepho , "linux-spi@vger.kernel.org" , "nicolas.ferre@microchip.com" , "linux-kernel@vger.kernel.org" , "broon References: <1510763732-10151-1-git-send-email-radu.pirea@microchip.com> <1510763732-10151-3-git-send-email-radu.pirea@microchip.com> <1510772471.15881.17.camel@impinj.com> From: Radu Nicolae Pirea Message-Id: Date: Thu, 16 Nov 2017 12:26:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Mime-Version: 1.0 In-Reply-To: <1510772471.15881.17.camel@impinj.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org Received-SPF: none client-ip=209.132.180.67; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: 0.7 X-Spam-Score-Bar: / X-Spam-Action: no action X-Spam-Report: Action: no action Symbol: R_SPF_NA(0.00) Symbol: MIME_GOOD(-0.10) Symbol: MAILLIST(-0.20) Symbol: FROM_HAS_DN(0.00) Symbol: ASN(0.00) Symbol: RCVD_IN_DNSWL_HI(0.00) Symbol: TO_DN_SOME(0.00) Symbol: BAYES_SPAM(0.00) Symbol: RCPT_COUNT_FIVE(0.00) Symbol: R On 15.11.2017 21:01, Trent Piepho wrote: > On Wed, 2017-11-15 at 18:35 +0200, Radu Pirea wrote: >> If the cache model is VIVT, DMA data transfers may not be valid and to >> ensure the validity of the data cache must be flushed and invalidated. >> >> Signed-off-by: Radu Pirea >> >> +#ifdef CONFIG_SOC_SAM_V4_V5 >> + /* >> + * On Atmel SoCs based on ARM9 cores, the data cache follows the VIVT >> + * model, hence the cache aliases issue can occur when buffers are >> + * allocated from DMA-unsafe areas, by vmalloc() for instance, where >> + * cache coherency is not taken into account or at least not handled >> + * completely (cache lines of aliases are not flushed and invalidated). >> + * This is not a theorical issue: it was reproduced when trying to mount >> + * a UBI file-system on a at91sam9g35ek board. >> + */ >> + flush_kernel_vmap_range((void *)xfer->rx_buf, xfer->len); >> +#endif > > Does this call need to be inside an ifdef for a specific SOC? I > believe that flush_kernel_vmap_range should expand to a no-op if the > cache is not VIVT or aliasing VIPT. So it should be safe to always > call it. > > It also doesn't seem right that the SPI driver needs to know which SoCs > have what kind of cache. If there are more socs with more cache > details, does the spi driver need to expand the list? If another > driver does DMA, does it need the list too? Understood. I will find another way to call the function. > > >> /* Send both scatterlists */ >> rxdesc = dmaengine_prep_slave_sg(rxchan, >> xfer->rx_sg.sgl, xfer->rx_sg.nents, > > Does this problem also possibly affect all other users of dmaengine on > these SoCs? I2C, serial, crpto, etc. I couldn't find any other driver > that need to make flush_kernel_vmap_range(). Which seems odd, since > there are many drivers that use DMA and run on ARM9 cores. E.g., I > believe spi-mxs runs on ARM9 based iMX.23 and iMX.28 which also have > VIVT caches. It doesn't make flush_kernel_vmap_range calls. Does it > have this same bug?��칻�&�~�&���+-��ݶ��w��˛���m�b��l�(����ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z��w���?����&�)ߢf > Other users of dmaengine are not affected by this problem. I know nothing about spi-mxs, but i know spi-davinci have the same bug.