From: Trent Piepho <tpiepho@impinj.com>
To: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
        "linux@armlinux.org.uk" <linux@armlinux.org.uk>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "cyrille.pitchen@wedev4u.fr" <cyrille.pitchen@wedev4u.fr>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "computersforpeace@gmail.com" <computersforpeace@gmail.com>,
        "boris.brezillon@free-electrons.com" 
        <boris.brezillon@free-electrons.com>,
        "vigneshr@ti.com" <vigneshr@ti.com>, "richard@nod.at" <richard@nod.at>,
        "marek.vasut@gmail.com" <marek.vasut@gmail.com>
CC: "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>,
        "robh@kernel.org" <robh@kernel.org>,
        "radu.pirea@microchip.com" <radu.pirea@microchip.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD
 and SPI
Thread-Topic: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between
 MTD and SPI
Thread-Index: AQHTfHXFw6hvEl9zL0SstW+hyzuciaNV+niA
Date: Tue, 26 Dec 2017 18:45:28 +0000
Message-ID: <1514313927.26695.19.camel@impinj.com>
References: <cover.1514087323.git.cyrille.pitchen@wedev4u.fr>
In-Reply-To: <cover.1514087323.git.cyrille.pitchen@wedev4u.fr>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9F4DA121DFBF5C468E6931A7F02B59B9@namprd06.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2409cba0-a0d4-4a44-6d89-08d54c90d58b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Dec 2017 18:45:28.3698
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6de70f0f-7357-4529-a415-d8cbb7e93e5e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0601MB3759
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id vBQIjbl2031060
Content-Length: 1535
Lines: 31

On Sun, 2017-12-24 at 05:36 +0100, Cyrille Pitchen wrote:
> this series tries to solve a long time issue of compatibility between the
> MTD and SPI sub-systems about whether we should use DMA-safe memory.

Can this should replace SoC specific fixes like:

c687c46e9e45
spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble

7094576ccdc3
spi: atmel: fix corrupted data issue on SAM9 family SoCs

Or, since this only fixes instances of DMA-unsafe buffers used in
access to SPI NOR flash chips, and since there are other SPI master
interface users, those chip specific fixes in some/all spi master
drivers are still needed to fix transfers not originated via spi-nor? 
Or are all the previous fixes necessary because of spi-nor flash (via
ubifs or jffs2) and once that's fixed via this series there are no more
originators of dma-unsafe buffers?

> The SPI sub-system has already implemented a work-around on its side,
> based on the spi_map_buf() function. However this function has its own
> limitation too. Especially, even if it builds a 'struct scatterlist' from
> a vmalloc'ed buffer, calling dma_map_sg() is still not safe on all
> architectures. Especially, on ARM cores using either VIPT or VIVT data
> caches, dma_map_sg() doesn't take the cache aliases issue into account.
> Then numerous crashes were reported for such architectures.

Could the above issue also be fixed via calls to
flush_kernel_vmap_range() and invalidate_kernel_vmap_range() to keep
the data cache valid?  Or is there a reason that won't work?