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: Mon, 23 Feb 2015 21:04:52 -0800	[thread overview]
Message-ID: <20150224050452.GG18140@ld-irv-0074> (raw)
In-Reply-To: <20150210074634.GD8020@x1>

On Tue, Feb 10, 2015 at 03:46:34PM +0800, Lee Jones wrote:
> On Thu, 05 Feb 2015, Brian Norris wrote:
> > On Wed, Jan 21, 2015 at 03:24:20PM +0000, Lee Jones wrote:
> > > To trim down on the amount of properties used by this driver and to conform
> > > to the newly agreed method of acquiring syscfg registers/offsets, we now
> > > obtain this information using match tables.
> > 
> > Where did this agreement happen? Are you only referring to the previous
> > patch?
> I think your interpretation of the above text and my intentions are
> not the same.

To be clear: I'm simply asking what do you mean by "agreed method". I
never agreed to syscfg registers/offsets. So who did? Are you agreeing
with yourself?

> I have no idea why there is a different configuration
> depending on if we booted from SPI NOR or not and hence can not answer
> your query below.

Seriously? That's all you can come up with? Sheesh. And you wonder why I
called you out on not understanding the code that you're sending me.

> The description above is pertaining to the
> different/new way in which we obtain and request syscfg registers.

OK. So you're dealing with the "how" but not the "why." That is not a
reasonable way to develop good code.

> In previous incarnations of this patchset, we were defining new vendor
> specific properties in order to request and register and the mask:
>   st,boot-device-reg = <0x958>;
>   st,boot-device-spi = <0x1a>;
> ... this is not optimal, as DT properties should only be created if
> there are no other way to obtain platform specific information.  As
> there are few supported platforms and this configuration does not
> change through variants, we are now supplying it via static tables,
> which can be obtained easily using the DT match framework.

I understand what you're doing with syscfg and these register offsets.
But if you follow the code as to what they're actually producing, you
see that it yields the 'booted_from_spi' boolean. That's a pretty simple

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.
> You have reached the boundaries of my knowledge on this.  Perhaps
> Angus (BCC'ed) would be kind enough to assist.

And so we have also reached the boundaries of my willingness to review
your code. There's a significant technical point here that drove you to
define several new DT compatible strings. I propose (and am now more
convinced) that this is not actually necessary. But apparently you are
not equipped to have a discussion about this.

I'm tempted to:

  git rm drivers/mtd/devices/st_spi_fsm.c

(Along with the appropriate Kconfig and Makefile entries, of course.)

> > What's the possibility of dropping all this 4-byte address toggling
> > shenanigans? This will be a blocker to merging with spi-nor.c.


  reply	other threads:[~2015-02-24  5:04 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 [this message]
2015-02-24  9:41         ` Lee Jones
2015-03-13 16:06           ` Brian Norris
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=20150224050452.GG18140@ld-irv-0074 \ \ \ \ \ \ \ \
    --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).