[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180724194110.GA190016@ban.mtv.corp.google.com>
Date: Tue, 24 Jul 2018 12:41:10 -0700
From: Brian Norris <computersforpeace@...il.com>
To: NeilBrown <neilb@...e.com>
Cc: Boris Brezillon <boris.brezillon@...tlin.com>,
Zhiqiang Hou <Zhiqiang.Hou@....com>,
linux-mtd@...ts.infradead.org,
Linux Kernel <linux-kernel@...r.kernel.org>,
David Woodhouse <dwmw2@...radead.org>,
Boris BREZILLON <boris.brezillon@...e-electrons.com>,
Marek Vasut <marek.vasut@...il.com>,
Richard Weinberger <richard@....at>,
Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>
Subject: Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when
exiting
Hi,
On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
> On Tue, Jul 24 2018, Boris Brezillon wrote:
> > On Tue, 24 Jul 2018 08:46:33 +1000
> > NeilBrown <neilb@...e.com> wrote:
> >> One possibility that occurred to me when I was exploring this issue is
> >> to revert to 3-byte mode whenever 4-byte was not actively in use.
> >> So any access beyond 16Meg is:
> >> switch-to-4-byte ; perform IO ; switch to 3-byte
> >> or similar. On my hardware it would be more efficient to
> >> use the 4-byte opcode to perform the IO, then reset the cached
> >> 4th address byte that the NOR chip transparently remembered.
Do these chips cache the last 4th-byte used? I don't recall reading
that, but that would be interesting. It also sounds like that would make
things even more difficult to do robustly.
> >> This adds a little overhead, but should be fairly robust.
> >> It doesn't help if something goes terribly wrong while IO is happening,
> >> but I don't think any other software solution does either.
> >>
> >> How would you see that approach?
> >
> > I think the problem stands: people that have proper HW mitigation for
> > this problem (NOR chip is reset when the Processor is reset) don't want
> > to pay the overhead. So, even if we go for this approach, we probably
> > want to only do that for broken HW.
If it actually saves bytes on the wire to stay in 3-byte mode more
often, then that could be helpful to all systems. But otherwise, yes, it
doesn't really belong on a properly-designed system.
> I agree that a "my-hardware-is-suboptimal" flag is appropriate.
> I was addressing the suggestion that the current approach doesn't handle
> all corner cases and was suggesting a different approach that might
> handle more corner-cases. I should have been more explicit about that.
If you want to talk about optimizing the broken-hardware hack, then
fine. That's not my interest at all.
Brian
Powered by blists - more mailing lists