[PATCH v2 35/35] docs: mtd: spi-nor: Add details about how to propose a new flash addition

Michael Walle michael at walle.cc
Tue Jul 27 01:49:26 PDT 2021


Am 2021-07-27 10:09, schrieb Tudor.Ambarus at microchip.com:
> On 7/27/21 10:22 AM, Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
>> the content is safe
>> 
>> Am 2021-07-27 06:52, schrieb Tudor Ambarus:
>>> Add some guideliness on how to propose a new flash addition.
>>> 
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus at microchip.com>
>>> ---
>>>  Documentation/driver-api/mtd/spi-nor.rst | 65 
>>> ++++++++++++++++++++++++
>>>  1 file changed, 65 insertions(+)
>>> 
>>> diff --git a/Documentation/driver-api/mtd/spi-nor.rst
>>> b/Documentation/driver-api/mtd/spi-nor.rst
>>> index 4a3adca417fd..ffb8d97a2766 100644
>>> --- a/Documentation/driver-api/mtd/spi-nor.rst
>>> +++ b/Documentation/driver-api/mtd/spi-nor.rst
>> [..]
>>> +Every new flash addition that define the SFDP tables, should hexdump
>>> its SFDP
>>> +tables in the patch's comment section below the --- line, so that we
>>> can
>>> +reference it in case of ID collisions.
>> 
>> Nice, but could you add some guidelines how to do it? That is the 
>> exact
>> commands, maybe with a notice one should use these whenever possible. 
>> I
>> want to prevent having all sorts of variations of the output and I 
>> want
>> to be able to reverse the operation and verify it.
> 
> ok, will do
> 
>> 
>> # xxd -p /path/to/sfdp
>> # md5sum /path/to/sfdp
> 
> maybe sha1sum here?

sure, that one doesn't really matter. any *sum will work.

>> # cat /path/to/jedec_id
>> # cat /path/to/partname
>> # cat /path/to/manufacturer
>> 
> 
> Will add some short examples of mtd_debug and the erase, verify,
> write, read back
> and compare too.
> 
> Do you have some locking test examples? I'll have to check those too.

Not really, I usually check the locking by looking at the BP bits,
but there is no easy method to look at them in linux.

-michael



More information about the linux-arm-kernel mailing list