[lkml]   [2019]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] dt-bindings: mtd: spi-nor: document new flag
Hi Michael,

>>> +- no-unlock : By default, linux unlocks the whole flash because there
>>> +           are legacy flash devices which are locked by default
>>> +           after reset. Set this flag if you don't want linux to
>>> +           unlock the whole flash automatically. In this case you
>>> +           can control the non-volatile bits by the
>>> +           flash_lock/flash_unlock tools.
>> Current SPI NOR framework unconditionally unlocks entire flash which
>> I agree is not the best thing to do, but I don't think we need
>> new DT property here. MTD cmdline partitions and DT partitions already
>> provide a way to specify that a partition should remain locked[1][2]
> I know that the MTD layer has the same kind of unlocking. But that
> unlocking is done on a per mtd partition basis. Eg. consider something
> like the following
>  mtd1 bootloader  (locked)
>  mtd2 firmware    (locked)
>  mtd3 kernel
>  mtd4 environment
> Further assume, that the end of mtd2 aligns with one of the possible
> locking areas which are supported by the flash chip. Eg. the first quarter.
> The mtd layer would do two (or four, if "lock" property is set) unlock()
> calls, one for mtd1 and one for mtd2.

> My point here is, that the mtd partitions doesn't always map to the
> locking regions of the SPI flash (at least if the are not merged together).

You are right! This will be an issue if existing partitions are not
aligned to locking regions.

I take my comments back... But I am not sure if a new DT property is the
needed. This does not describe HW and is specific to Linux SPI NOR
stack. How about a module parameter instead?
Module parameter won't provide per flash granularity in controlling
unlocking behavior. But I don't think that matters.


You had a patch doing something similar. Does module param sound good to


 \ /
  Last update: 2019-12-19 06:33    [W:0.053 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site