LKML Archive on
help / color / mirror / Atom feed
From: Brian Norris <>
To: Lee Jones <>
Subject: Re: [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables
Date: Fri, 13 Mar 2015 09:06:01 -0700	[thread overview]
Message-ID: <20150313160601.GI12966@brian-ubuntu> (raw)
In-Reply-To: <20150224094110.GA20969@x1>

On Tue, Feb 24, 2015 at 09:41:10AM +0000, Lee Jones wrote:
> On Mon, 23 Feb 2015, Brian Norris wrote:
> > On Tue, Feb 10, 2015 at 03:46:34PM +0800, Lee Jones wrote:
> > > On Thu, 05 Feb 2015, Brian Norris wrote:

[snip other discussion]

> > Now, unless you were able to provide an additional enlightening
> > viewpoint, then the following paragraph likely all holds true:
> > 
> > > > Also, I realized that all this boot device / syscfg gymnastics is just
> > > > for one simple fact; your driver is trying to hide the fact that your
> > > > system can't reliably handle 4-byte addressing for the boot device. Even
> > > > if you try your best at toggling 4-byte addressing before/after each
> > > > read/write/erase, you still are vulnerable to power cuts during the
> > > > operation. This is a bad design, and we have consistently agreed that we
> > > > aren't going to work around that in Linux.
> > > > 
> > > > Better solutions: hook up a reset line to your flash; improve your boot
> > > > ROM / bootloader to handle 4-byte addressing for large flash.
> Okay, I'm re-read the code and have a new understanding about the
> boot-from-spi 'gymnastics'. 

Great! See, much of that could be done by reading your own code (yeah,
yeah, not "yours"; but still) and honestly dealing with my questions,
rather than giving up and deferring to me or your MIA authorities. I'm
happy to return to technical points and avoid the other unpleasantness.

> There is a separate controller on the platform which acts as a boot
> device and makes the NOR chip appear as though it is memory mapped.
> This expects the NOR Controller to be in its default state [24-bit
> addressing] on boot.  The issue arises if a warm-reset occurs and the
> device is still in 32-bit addressing mode.

OK, this is all familiar. This is common to many other systems.

> To minimise the risk, the
> controller attempts to stay in 24-bit addressing mode for as long as
> possible.

This is the part where we differ, I suppose. The "as long as possible"
statement is still not sufficient; I believe this still leaves holes
that simply cannot be fixed in Linux.

> You mentioned power-cuts.  I do not believe this to be an issue, as
> when the power is completely removed the controller will reset back
> into default state.  Only warm-resets are an issue.

You're right: power cuts shouldn't be a problem. But what about other
unexpected warm resets? (Watchdogs?) Do you have any solution for them?

> > > > What's the possibility of dropping all this 4-byte address toggling
> > > > shenanigans? This will be a blocker to merging with spi-nor.c.
> We wouldn't be able to remove this code without significantly
> weakening resilience to warm-reset mishaps, and changing the hardware
> design for devices which have already been released is obviously out
> of the question.

Then maybe we can't solve this. That doesn't mean that upstream will
support you, though.

Problems like this are why "release early, release often" makes sense.
If your employer didn't take the "fire the engineers and dump software
support to the community" approach, but rather honestly engaged on
driver support earlier, then perhaps your employer could have fixed the
SoCs/boot ROMs/board designs earlier, rather than later, and you
wouldn't be stuck trying to wedge in upstream workarounds for bad
designs in the wild.


  reply	other threads:[~2015-03-13 16:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 15:24 [PATCH v4 00/10] mtd: st_spi_fsm: Align with ST's internal development Lee Jones
2015-01-21 15:24 ` [PATCH v4 01/10] mtd: st_spi_fsm: dt-bindings: Deprecate generic compatible string Lee Jones
2015-01-21 15:24 ` [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables Lee Jones
2015-02-06  4:27   ` Brian Norris
2015-02-10  7:46     ` Lee Jones
2015-02-24  5:04       ` Brian Norris
2015-02-24  9:41         ` Lee Jones
2015-03-13 16:06           ` Brian Norris [this message]
2015-03-16  8:13             ` Lee Jones
2015-03-30 18:16               ` Brian Norris
2015-01-21 15:24 ` [PATCH v4 03/10] mtd: st_spi_fsm: Add support for Micron N25Q512A Lee Jones
2015-01-21 15:24 ` [PATCH v4 04/10] mtd: st_spi_fsm: Add support for N25Q512 and N25Q00A devices Lee Jones
2015-01-21 15:24 ` [PATCH v4 05/10] mtd: st_spi_fsm: Update the JEDEC probe to handle extended READIDs Lee Jones
2015-01-21 15:24 ` [PATCH v4 06/10] mtd: st_spi_fsm: Update Spansion device entries Lee Jones
2015-01-21 15:24 ` [PATCH v4 07/10] mtd: st_spi_fsm: Improve busy wait handling Lee Jones
2015-01-21 15:24 ` [PATCH v4 08/10] mtd: st_spi_fsm: General tidy-up Lee Jones
2015-01-21 15:24 ` [PATCH v4 09/10] ARM: STi: stih416: Use new platform specific compatible string Lee Jones
2015-01-21 15:24 ` [PATCH v4 10/10] ARM: STi: stih416: Supply EMI clock reference to FSM SPI NOR Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150313160601.GI12966@brian-ubuntu \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).