From: Trent Piepho <tpiepho@impinj.com>
To: "broonie@kernel.org" <broonie@kernel.org>
CC: "nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
        "radu.pirea@microchip.com" <radu.pirea@microchip.com>,
        "linux@armlinux.org.uk" <linux@armlinux.org.uk>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
        "robh@kernel.org" <robh@kernel.org>,
        "cyrille.pitchen@wedev4u.fr" <cyrille.pitchen@wedev4u.fr>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "computersforpeace@gmail.com" <computersforpeace@gmail.com>,
        "vigneshr@ti.com" <vigneshr@ti.com>,
        "boris.brezillon@free-electrons.com" 
        <boris.brezillon@free-electrons.com>,
        "richard@nod.at" <richard@nod.at>,
        "marek.vasut@gmail.com" <marek.vasut@gmail.com>
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+niAgAEJoICAAKHHgA==
Date: Wed, 27 Dec 2017 20:15:11 +0000
Message-ID: <1514405711.26695.67.camel@impinj.com>
References: <cover.1514087323.git.cyrille.pitchen@wedev4u.fr>
         <1514313927.26695.19.camel@impinj.com> <20171227103609.GQ1827@finisterre>
In-Reply-To: <20171227103609.GQ1827@finisterre>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <FA2545AD1CB5704BB88FF465EC11F6C8@namprd06.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d460141-7b34-4986-81a4-08d54d6688d8
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2017 20:15:11.9905
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6de70f0f-7357-4529-a415-d8cbb7e93e5e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0601MB3754
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 vBRKFLYi001703
Content-Length: 2187
Lines: 43

On Wed, 2017-12-27 at 10:36 +0000, Mark Brown wrote:
> On Tue, Dec 26, 2017 at 06:45:28PM +0000, Trent Piepho wrote:
> 
> > 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? 
> 
> SPI client drivers are *supposed* to use DMA safe memory already.  How
> often that happens in cases where it matters is a separate question, we
> definitely have users with smaller transfers that don't do the right
> thing but they're normally done using PIO anyway.

I wonder what the end goal is here?

A random collection of spi master drivers will accept DMA-unsafe
buffers in some way.  In some cases a framework like spi-nor provides
the fixup to spi-nor master drivers (none so far) and in other cases
(atmel-quadspi), the spi-nor master driver has its own fixes.

Generic spi masters like spi-atmel, spi-ti-qspi, and spi-davinci will
have their fixes for certain cases.

Perhaps spi flash drivers like m25p80 will have fixes too?

Some spi clients, like spidev, will have internal bounce buffers,
rather than userspace addresses or commands in stack variables, so that
they follow the rules about DMA safe buffers.

What exactly is caught as DMA unsafe and what is not will of course
vary greatly from driver to driver.  Some drivers will catch highmem
memory while other drivers will only detect vmalloc memory.  Some will
only catch an unsafe buffer if a specific SoC known to the driver to
have an aliasing cache is enabled.  Some will check buffers that arrive
via the spi_flash_read interface but not via generic spi transfers,
while others will check all spi transfer buffers.

Obviously, I don't think this path will lead to a desirable end.  Maybe
the basic assumption, that clients should provide DMA safe buffers,
should be revisited.  Experience has shown that it's too much to ask
for and spi clients will never get it right.  It would be better to try
to fix this at some common point between the clients and masters so it
can be done once and for all.