lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 2 Apr 2017 20:32:08 +0200
From:   Marek Vasut <>
To:     Cyrille Pitchen <>,
        Cyrille Pitchen <>,,,,
Subject: Re: [PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI

On 03/29/2017 06:45 PM, Cyrille Pitchen wrote:
> Hi all,
> Le 23/03/2017 à 00:33, Cyrille Pitchen a écrit :
>> Hi all,
>> based on git-hub/spi-nor and likely applicable on linux-next within the
>> next few days.
>> This new series of patchs aims to upgrade to spi-nor framework. We need to
>> take into account latest SPI memories which cannot be handled correctly by
>> the current implementation.
>> For instance, SPI NOR memories like Spansion S25FS512S or Macronix
>> MX25U4035 support only the Fast Read 1-4-4 (EBh) command but not the
>> Fast Read 1-1-4 (6Bh) command. However the current spi-nor framework
>> supports only Fast Read 1-1-4 (6Bh).
>> Also the Spansion S25FS512S memory (and others) may use a non-uniform
>> sector erase map, whereas the spi-nor framework assumes that a single
>> sector erase size and opcode can be used anywhere inside the data array.
>> This assumption is no longer valid.
>> Then parsing SFDP tables is an attempt to solve many of those issues by
>> discovering dynamically most of the parameters and settings of the SPI NOR
>> memory:
>> - the flash size
>> - the page size for Page Program commands
>> - the supported Fast Read commands with the associated opcodes and number
>>   of mode/wait-state (dummy) cycles.
>> - the supported Sector/Block Erase commands with the associated opcodes
>>   and sizes.
>> - the erase sector map (for non-uniform memory).
>> Besides, most QSPI controllers from the different vendors are capable to
>> support the SPI 1-2-2 and 1-4-4 protocols but the spi-nor framework was
>> not ready to use them. This series also fixes this issue and computes the
>> best match between the hardware capabilies of both the SPI memory and the
>> SPI controler (master) to select the right opcodes and dummy cycles for
>> Fast Read and Page Program operations.
>> The new 'struct spi_nor_hwcaps' uses a bitmask to describe all the
>> supported hardware capabilies and makes the difference between Fast Read
>> and Page Program operations and also between the different SPI protocols
>> (SPI 1-1-2 vs SPI 1-2-2 or SPI 1-1-4 vs SPI 1-4-4).
>> IMHO, the first 3 patches of this series are ready to be merged into the
>> github/spi-nor tree. Marek, do you agree with that?
> Marek, if you have no comment on them, I will merge patches 1, 2, 3 in
> the spi-nor tree within the next few days. Hence, people like Cédric
> waiting for the series to merged could base their work on these patches.

Hm well, you could've at least poked me about this, I was so snowed
under that I didn't have any chance to take a look :(

Best regards,
Marek Vasut

Powered by blists - more mailing lists