[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160123214918.GC24744@localhost>
Date: Sat, 23 Jan 2016 13:49:18 -0800
From: Brian Norris <computersforpeace@...il.com>
To: Rafał Miłecki <zajec5@...il.com>
Cc: "Maciej W. Rozycki" <macro@...ux-mips.org>,
Ralf Baechle <ralf@...ux-mips.org>,
Javier Martinez Canillas <javier@....samsung.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Fengguang Wu <fengguang.wu@...el.com>,
Michael Ellerman <mpe@...erman.id.au>,
Luis de Bethencourt <luisbg@....samsung.com>,
Jeremy Kerr <jk@...abs.org>,
Neelesh Gupta <neelegup@...ux.vnet.ibm.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
David Woodhouse <dwmw2@...radead.org>,
Cyril Bur <cyrilbur@...il.com>
Subject: Re: [PATCH] mtd: bcm47xxsflash: use devm_ioremap_nocache() instead
of KSEG0ADDR()
On Sat, Jan 16, 2016 at 01:38:11AM +0100, Rafał Miłecki wrote:
> So I wanted to stick to the cached mapping, [...]
I mentioned this earlier on, but I don't feel like I've gotten a clear
answer. Is a cached mapping actually safe here? From the looks of it,
the memory mapping is a read-only memory-mapped flash, and flash writes
/ erasures are done through a different bus (register writes vis BCMA
bus). So if we have a cached mapping of that memory, it doens't
naturally synchronize with any write/erase operations. Doesn't this mean
you might get stale data if you do a sequence of read / erase / read,
for instance, since the 2nd read will return cached data from the 1st
read?
IIUC, this could be solved by:
(a) using an uncached mapping or
(b) explicitly invalidating the relevant region after doing flash writes
or erasures
But I wonder why you haven't seen any problems if you've been using
KSEG0 (cached) this whole time. Maybe just luck? Or you don't actually
write to the flash that much?
Brian
Powered by blists - more mailing lists