summaryrefslogtreecommitdiffstats
path: root/drivers/mtd/spi-nor/sst.c
Commit message (Collapse)AuthorAgeFilesLines
* mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`Csókás, Bence2024-09-141-20/+19
| | | | | | | | | | | | | | | | Writing to the Flash in `sst_nor_write()` is a 3-step process: first an optional one-byte write to get 2-byte-aligned, then the bulk of the data is written out in vendor-specific 2-byte writes. Finally, if there's a byte left over, another one-byte write. This was implemented 3 times in the body of `sst_nor_write()`. To reduce code duplication, factor out these sub-steps to their own function. Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu> Reviewed-by: Pratyush Yadav <pratyush@kernel.org> [pratyush@kernel.org: fixup whitespace, use %zu instead of %i in WARN()] Signed-off-by: Pratyush Yadav <pratyush@kernel.org> Link: https://lore.kernel.org/r/20240710091401.1282824-1-csokas.bence@prolan.hu
* mtd: spi-nor: use kernel sized types instead of c99 typesTudor Ambarus2023-11-151-3/+3
| | | | | | | | The kernel offers and prefers the kernel sized types instead of the c99 types when not in the uapi directory, use them. Link: https://lore.kernel.org/r/20231101145853.524045-2-tudor.ambarus@linaro.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: sst: sort flash_info databaseMichael Walle2023-09-191-45/+45
| | | | | | | | | | The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-38-e60548861b10@kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: sst: convert flash_info to new formatMichael Walle2023-09-191-58/+104
| | | | | | | | | The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-27-e60548861b10@kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: remove or move flash_info commentsMichael Walle2023-09-191-1/+0
| | | | | | | | | Most of the comments are a relict of the past when the flash_info was just one table. Most of them are useless. Remove them. Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-16-e60548861b10@kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: drop .parse_sfdpMichael Walle2023-09-191-1/+0
| | | | | | | | | | | | | | | Drop the size parameter to indicate we need to do SFDP, we can do that because it is guaranteed that the size will be set by SFDP and because PARSE_SFDP forced the SFDP parsing it must be overwritten. There is a (very tiny) chance that this might break block protection support: we now rely on the SFDP reported size of the flash for the BP calculation. OTOH, if the flash reports its size wrong, we are in bigger trouble than just having the BP calculation wrong. Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-11-e60548861b10@kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: Add support for sst26vf032b flashMiquel Raynal2023-08-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Describe this new part. The datasheet is public. Link: https://ww1.microchip.com/downloads/aemDocuments/documents/MPD/ProductDocuments/DataSheets/SST26VF032B-SST26VF032BA-2.5V-3.0V-32-Mbit-Serial-Quad-IO-%28SQI%29-Flash-Memory-20005218K.pdf Here are the sfdp tables plus base testing to show it works. $ cat /sys/bus/spi/devices/spi0.0/spi-nor/partname sst26vf032b $ cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id bf2642 $ cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer sst $ xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp 53464450060102ff00060110300000ff81000106000100ffbf0001180002 0001fffffffffffffffffffffffffffffffffd20f1ffffffff0144eb086b 083b80bbfeffffffffff00ffffff440b0c200dd80fd810d820914824806f 1d81ed0f773830b030b0f7ffffff29c25cfff030c080ffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffff0004fff37f0000f57f0000f9ff 3d00f57f0000f37f0000ffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffbf2642ffb95ffdff30f260f332ff0a122346ff0f19320f1919ffffff ffffffff00669938ff05013506040232b03072428de89888a585c09faf5a ffff06ec060c0003080bffffffffff07ffff0202ff060300fdfd040600fc 0300fefe0202070e $ md5sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp e7efddddb3d5ee89ca37bf6b6e789645 /sys/bus/spi/devices/spi0.0/spi-nor/sfdp $ dd if=/dev/urandom of=./qspi_test bs=1M count=1 1+0 records in 1+0 records out $ mtd_debug write /dev/mtd0 0 1048576 qspi_test Copied 1048576 bytes from qspi_test to address 0x00000000 in flash $ mtd_debug erase /dev/mtd0 0 1048576 Erased 1048576 bytes from address 0x00000000 in flash $ mtd_debug read /dev/mtd0 0 1048576 qspi_read Copied 1048576 bytes from address 0x00000000 in flash to qspi_read $ hexdump qspi_read 0000000 ffff ffff ffff ffff ffff ffff ffff ffff * 0100000 $ mtd_debug write /dev/mtd0 0 1048576 qspi_test Copied 1048576 bytes from qspi_test to address 0x00000000 in flash $ mtd_debug read /dev/mtd0 0 1048576 qspi_read Copied 1048576 bytes from address 0x00000000 in flash to qspi_read $ sha1sum qspi_test qspi_read 2f2f191c7a937eca5db21a1c39e79e7327587cc1 qspi_test 2f2f191c7a937eca5db21a1c39e79e7327587cc1 qspi_read Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20230808075001.223150-1-miquel.raynal@bootlin.com Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: spansion: use CLPEF as an alternative to CLSRTakahiro Kuwano2023-07-261-2/+6
| | | | | | | | | | | | | | | Infineon S28Hx (SEMPER Octal) and S25FS256T (SEMPER Nano) support Clear Program and Erase Failure Flags (CLPEF, 82h) instead of CLSR(30h). Introduce a new mfr_flag together with the infrastructure to allow manufacturer private data in the core. With this we remove the need to have if checks in the code at runtime and instead set the correct opcodes at probe time. S25Hx (SEMPER QSPI) supports CLSR but it may be disabled by CFR3x[2] while CLPEF is always available. Therefore, the mfr_flag is also applied to S25Hx for safety. Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Link: https://lore.kernel.org/r/20230726075257.12985-2-tudor.ambarus@linaro.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: Reorder the preparation vs. locking stepsMiquel Raynal2023-03-291-1/+1
| | | | | | | | | | | | | | | The ->prepare()/->unprepare() hooks are now legacy, we no longer accept new drivers supporting them. The only remaining controllers using them acquires a per-chip mutex, which should not interfere with the rest of the operation done in the core. As a result, we should be safe to reorganize these helpers to first perform the preparation, before acquiring the core locks. This is necessary in order to be able to improve the locking mechanism in the core (coming next). No side effects are expected. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20230328154105.448540-4-miquel.raynal@bootlin.com Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
* mtd: spi-nor: sst: unify function namesMichael Walle2022-02-251-22/+22
| | | | | | | | | | | | | | | To avoid name clashes unify all the function and static object names and use one of the following prefixes which should be sufficiently unique: - <vendor>_nor_ - <flash_family>_nor_ - <flash_part>_ There are no functional changes. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Acked-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20220223134358.1914798-14-michael@walle.cc
* mtd: spi-nor: Rework the flash_info flagsTudor Ambarus2021-12-071-39/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clarify for what the flash_info flags are used for. Split them in four categories and a bool: 1/ FLAGS: flags that indicate support that is not defined by the JESD216 standard in its SFDP tables. 2/ NO_SFDP_FLAGS: these flags are used when the flash does not define the SFDP tables. These flags indicate support that can be discovered via SFDP. Used together with SPI_NOR_SKIP_SFDP flag. 3/ FIXUP_FLAGS: flags that indicate support that can be discovered via SFDP ideally, but can not be discovered for this particular flash because the SFDP table that indicates this support is not defined by the flash. In case the table for this support is defined but has wrong values, one should instead use a post_sfdp() hook to set the SNOR_F equivalent flag. 4/ MFR_FLAGS: manufacturer private flags. Used in the manufacturer fixup hooks to differentiate support between flashes of the same manufacturer. 5/ PARSE_SFDP: sets info->parse_sfdp to true. All flash_info entries that support SFDP should be converted to set info->parse_sfdp to true. SPI NOR flashes that statically declare one of the SPI_NOR_{DUAL, QUAD, OCTAL, OCTAL_DTR}_READ flags and do not support the RDSFDP command are gratuiously receiving the RDSFDP command in the attempt of parsing the SFDP tables. It is not desirable to issue commands that are not supported, so introduce PARSE_SFDP to help on this situation. New flash additions/updates should be declared/updated to use either PARSE_SFDP or SPI_NOR_SKIP_SFDP. Once all the flash_info entries are converted to use SPI_NOR_SKIP_SFDP or PARSE_SFDP, we can get rid of the SPI_NOR_SKIP_SFDP flag and use just the bool nor->info->parse_sfdp to determine whether to parse SFDP or not. SPI_NOR_SKIP_SFDP flag is kept just as a way to differentiate whether a flash is converted to the new flags logic or not. Support that can be discovered when parsing SFDP should not be duplicated by explicit flags at flash declaration. All the flash parameters will be discovered when parsing SFDP. Sometimes manufacturers wrongly define some fields in the SFDP tables. If that's the case, SFDP data can be amended with the fixups() hooks. It is not common, but if the SFDP tables are entirely wrong, and it does not worth the hassle to tweak the SFDP parameters by using the fixups hooks, or if the flash does not define the SFDP tables at all, then statically init the flash with the SPI_NOR_SKIP_SFDP flag and specify the rest of flash capabilities with the flash info flags. With time, we want to convert all flashes to use PARSE_SFDP and stop triggering the SFDP parsing with the SPI_NOR_{DUAL, QUAD, OCTAL*}_READ flags. Getting rid of the SPI_NOR_{OCTAL, OCTAL_DTR}_READ trigger is easily achievable, the rest are a long term goal. Manufacturer specific flags like USE_CLSR, USE_FSR, SPI_NOR_XSR_RDY, will be removed in a future series. No functional changes intended in this patch. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20211207140254.87681-7-tudor.ambarus@microchip.com
* mtd: spi-nor: core: Introduce flash_info mfr_flagsTudor Ambarus2021-12-071-10/+31
| | | | | | | | | | | Used in the manufacturer fixup hooks to differentiate support between flashes of the same manufacturer. Not used in the SPI NOR core. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Michael Walle <michael@walle.cc> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20211207140254.87681-6-tudor.ambarus@microchip.com
* mtd: spi-nor: sst: Use manufacturer late_init() to set _write()Tudor Ambarus2021-11-171-2/+2
| | | | | | | | | | | Setting the correct nor->mtd._write in a fixup hook was misleading, since this is not a fixup, just a specific setting for SST, that differs from the SPI NOR core default init. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Michael Walle <michael@walle.cc> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20211029172633.886453-11-tudor.ambarus@microchip.com
* mtd: spi-nor: sst: Use flash late_init() for lockingTudor Ambarus2021-11-171-2/+2
| | | | | | | | | | Locking is not described in JESD216 SFDP standard, place the locking init in late_init(). Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Michael Walle <michael@walle.cc> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20211029172633.886453-8-tudor.ambarus@microchip.com
* mtd: spi-nor: sst: Add support for Global Unlock on sst26vfTudor Ambarus2021-02-051-2/+50
| | | | | | | | | | | | | | | | | | | Even if sst26vf shares the SPINOR_OP_GBULK opcode with Macronix (ex. MX25U12835F) and Winbound (ex. W25Q128FV), it has its own Individual Block Protection scheme, which is also capable to read-lock individual parameter blocks. Thus the sst26vf's Individual Block Protection scheme will reside in the sst.c manufacturer driver. Add support to unlock the entire flash memory. The device is write-protected by default after a power-on reset cycle (volatile software protection), in order to avoid inadvertent writes during power-up. Could do an erase, write, read back, and compare when MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE=y. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20210121110546.382633-2-tudor.ambarus@microchip.com
* mtd: spi-nor: keep lock bits if they are non-volatileMichael Walle2020-12-071-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally, Linux unlocks the whole flash because there are legacy devices which has the write protection bits set by default at startup. If you actually want to use the flash protection bits, eg. because there is a read-only part for a bootloader, this automatic unlocking is harmful. If there is no hardware write protection in place (usually called WP#), a startup of the kernel just discards this protection. I've gone through the datasheets of all the flashes (except the Intel ones where I could not find any datasheet nor reference) which supports the unlocking feature and looked how the sector protection was implemented. The currently supported flashes can be divided into the following two categories: (1) block protection bits are non-volatile. Thus they keep their values at reset and power-cycle (2) flashes where these bits are volatile. After reset or power-cycle, the whole memory array is protected. (a) some devices needs a special "Global Unprotect" command, eg. the Atmel AT25DF041A. (b) some devices require to clear the BPn bits in the status register. Due to the reasons above, we do not want to clear the bits for flashes which belong to category (1). Fortunately for us, only Atmel flashes fall into category (2a). Implement the "Global Protect" and "Global Unprotect" commands for these. For (2b) we can use normal block protection locking scheme. This patch adds a new flag to indicate the case (2). Only if we have such a flash we unlock the whole flash array. To be backwards compatible it also introduces a kernel configuration option which restores the complete legacy behavior ("Disable write protection on any flashes"). Hopefully, this will clean up "unlock the entire flash for legacy devices" once and for all. For reference here are the actually commits which introduced the legacy behavior (and extended the behavior to other chip manufacturers): commit f80e521c916cb ("mtd: m25p80: add support for the Intel/Numonyx {16,32,64}0S33B SPI flash chips") commit ea60658a08f8f ("mtd: m25p80: disable SST software protection bits by default") commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be copied to") Actually, this might also fix handling of the Atmel AT25DF flashes, because the original commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be copied to") was writing a 0 to the status register, which is a "Global Unprotect". This might not be the case in the current code which only handles the block protection bits BP2, BP1 and BP0. Thus, it depends on the current contents of the status register if this unlock actually corresponds to a "Global Unprotect" command. In the worst case, the current code might leave the AT25DF flashes in a write protected state. The commit 191f5c2ed4b6f ("mtd: spi-nor: use 16-bit WRR command when QE is set on spansion flashes") changed that behavior by just clearing BP2 to BP0 instead of writing a 0 to the status register. Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling of block write protection") expanded the unlock_all() feature to ANY flash which supports locking. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-8-michael@walle.cc
* mtd: spi-nor: sst: remove global protection flagMichael Walle2020-12-071-18/+12
| | | | | | | | | | | | | | | | | | | | | | | | | This is considered bad for the following reasons: (1) We only support the block protection with BPn bits for write protection. Not all SST parts support this. (2) Newly added flash chip will automatically inherit the "has locking" support and thus needs to explicitly tested. Better be opt-in instead of opt-out. (3) There are already supported flashes which doesn't support the locking scheme. So I assume this wasn't properly tested before adding that chip; which enforces my previous argument that locking support should be an opt-in. Remove the global flag and add individual flags to all flashes which supports BP locking. In particular the following flashes don't support the BP scheme: - SST26VF016B - SST26WF016B - SST26VF064B Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-5-michael@walle.cc
* mtd: spi-nor: sst: fix BPn bits for the SST25VF064CMichael Walle2020-12-071-1/+2
| | | | | | | | | | | | | | This flash part actually has 4 block protection bits. Please note, that this patch is just based on information of the datasheet of the datasheet and wasn't tested. Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection") Reported-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-2-michael@walle.cc
* mtd: spi-nor: Move SST bits out of core.cBoris Brezillon2020-03-171-0/+151
Create a SPI NOR manufacturer driver for SST chips, and move the SST definitions outside of core.c. Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 10:37:32 +0000