LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Brian Norris <computersforpeace@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kernel@stlinux.com,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables
Date: Tue, 10 Feb 2015 15:46:34 +0800	[thread overview]
Message-ID: <20150210074634.GD8020@x1> (raw)
In-Reply-To: <20150206042744.GK18140@ld-irv-0074>

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.  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.  The description above is pertaining to the
different/new way in which we obtain and request syscfg registers.

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 think I asked this previously, and I didn't get an answer.

Not sure if you did or not to be honest.

> 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.

> What's the possibility of dropping all this 4-byte address toggling
> shenanigans? This will be a blocker to merging with spi-nor.c.
> 
> > In the process we are deprecating the old generic compatible string and
> > providing 3 shiny new ones for each of the support platforms.  The
> > deprecated compatible string will be removed in due course.
> 
> Aren't you already removing the compatible string? (You changed this in
> the latest revision.)

You're right.  I need to remove this line from the commit log.

> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> 
> [snip]
> 
> Brian

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-02-10  7:46 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 [this message]
2015-02-24  5:04       ` Brian Norris
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20150210074634.GD8020@x1 \
    --to=lee.jones@linaro.org \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@stlinux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --subject='Re: [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).