Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1320989

Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low

Show all headers | View raw

On Thu, Jan 28, 2016 at 04:24:50PM -0300, Ezequiel Garcia wrote:
> On 28 January 2016 at 14:59, Brian Norris <computersforpeace@gmail.com> wrote:
> > So, maybe we want to clear SR_SRWD only when we unlock the *entire*
> > flash? What do you think?

I'll paste in the relevant datasheet details from w25q32fw, to make sure
we're on the same page here, noting that 'SRP0' is our 'SR_SRWD', and
we're not touching SRP1 (i.e., SRP1=0):

 "SRP1=0, SRP0=0, /WP=X: Software Protection
    /WP pin has no control. The Status register can be written to after
    a Write Enable instruction, WEL=1. [Factory Default]
  SRP1=0, SRP0=1, /WP=0: Hardware Protected
    When /WP pin is low the Status Register locked [sic] and cannot be
    written to.
  SRP1=0, SRP0=1, /WP=1: Hardware Unprotected
    When /WP pin is high the Status register is unlocked and can be
    written to after a Write Enable instruction, WEL=1."

> How about this:
> 
> 1) ioctl(MEMLOCK) the entire flash (SR_SRWD is set)
> 2) ioctl(MEMUNLOCK) partially (SW_SRWD keeps set)
> 3) ioctl(MEMLOCK) the entire flash again

I might be confused; are you making a suggestion of a new behavior, or
are you just trying to clarify my proposal? Because this sounds like it
matches my proposal.

> Not sure this use case make sense,

I suppose it could make sense, if you (e.g.) have some intermediate
steps toward determining the locked regions during factory programming.
Maybe a process would start by doing #1 and #2, then decide
conditionally whether to do #3. And only after the whole process is done
does something assert /WP=0 (in my case, a factory process would tie /WP
low).

> but would (3)  be allowed given
> SW_SRWD is set?

Yes, if /WP=1 (high).

Brian

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/8] mtd: spi-nor: locking fixes and updates Brian Norris <computersforpeace@gmail.com> - 2016-01-28 07:00 +0100
  [PATCH 8/8] mtd: spi-nor: support lock/unlock for a few Winbond chips Brian Norris <computersforpeace@gmail.com> - 2016-01-28 07:00 +0100
  [PATCH 2/8] mtd: spi-nor: guard against underflows in stm_is_locked_sr Brian Norris <computersforpeace@gmail.com> - 2016-01-28 07:00 +0100
  [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low Brian Norris <computersforpeace@gmail.com> - 2016-01-28 07:00 +0100
    Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2016-01-28 15:40 +0100
      Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP#  is low Brian Norris <computersforpeace@gmail.com> - 2016-01-28 19:00 +0100
        Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2016-01-28 20:30 +0100
          Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP#  is low Brian Norris <computersforpeace@gmail.com> - 2016-01-28 20:50 +0100
            Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2016-01-29 14:30 +0100
              Re: [PATCH 4/8] mtd: spi-nor: disallow further writes to SR if WP#  is low Brian Norris <computersforpeace@gmail.com> - 2016-01-29 20:30 +0100
  [PATCH 5/8] mtd: spi-nor: use BIT() for flash_info flags Brian Norris <computersforpeace@gmail.com> - 2016-01-28 07:00 +0100
  [PATCH 6/8] mtd: spi-nor: add SPI_NOR_HAS_LOCK flag Brian Norris <computersforpeace@gmail.com> - 2016-01-28 07:00 +0100
  [PATCH 1/8] mtd: spi-nor: wait for SR_WIP to clear on initial unlock Brian Norris <computersforpeace@gmail.com> - 2016-01-28 07:00 +0100
  Re: [PATCH 0/8] mtd: spi-nor: locking fixes and updates Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> - 2016-01-28 15:50 +0100

csiph-web