Re: [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables

On Tue, Feb 24, 2015 at 09:41:10AM +0000, Lee Jones wrote:

On Mon, 23 Feb 2015, Brian Norris wrote:

quoted

On Tue, Feb 10, 2015 at 03:46:34PM +0800, Lee Jones wrote:

quoted

On Thu, 05 Feb 2015, Brian Norris wrote:

[snip other discussion]

quoted

Now, unless you were able to provide an additional enlightening
viewpoint, then the following paragraph likely all holds true:

quoted

quoted

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?

quoted

quoted

quoted

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.

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html