2020-03-14 03:42:37 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2005, Intec Automation Inc.
|
|
|
|
* Copyright (C) 2014, Freescale Semiconductor, Inc.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __LINUX_MTD_SPI_NOR_INTERNAL_H
|
|
|
|
#define __LINUX_MTD_SPI_NOR_INTERNAL_H
|
|
|
|
|
|
|
|
#include "sfdp.h"
|
|
|
|
|
2020-03-14 03:42:38 +08:00
|
|
|
#define SPI_NOR_MAX_ID_LEN 6
|
|
|
|
|
2020-03-14 03:42:53 +08:00
|
|
|
enum spi_nor_option_flags {
|
|
|
|
SNOR_F_USE_FSR = BIT(0),
|
|
|
|
SNOR_F_HAS_SR_TB = BIT(1),
|
|
|
|
SNOR_F_NO_OP_CHIP_ERASE = BIT(2),
|
|
|
|
SNOR_F_READY_XSR_RDY = BIT(3),
|
|
|
|
SNOR_F_USE_CLSR = BIT(4),
|
|
|
|
SNOR_F_BROKEN_RESET = BIT(5),
|
|
|
|
SNOR_F_4B_OPCODES = BIT(6),
|
|
|
|
SNOR_F_HAS_4BAIT = BIT(7),
|
|
|
|
SNOR_F_HAS_LOCK = BIT(8),
|
|
|
|
SNOR_F_HAS_16BIT_SR = BIT(9),
|
|
|
|
SNOR_F_NO_READ_CR = BIT(10),
|
|
|
|
SNOR_F_HAS_SR_TB_BIT6 = BIT(11),
|
2020-03-18 20:06:14 +08:00
|
|
|
SNOR_F_HAS_4BIT_BP = BIT(12),
|
|
|
|
SNOR_F_HAS_SR_BP3_BIT6 = BIT(13),
|
2020-10-05 23:31:31 +08:00
|
|
|
SNOR_F_IO_MODE_EN_VOLATILE = BIT(14),
|
2020-10-05 23:31:34 +08:00
|
|
|
SNOR_F_SOFT_RESET = BIT(15),
|
mtd: spi-nor: keep lock bits if they are non-volatile
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
2020-12-04 00:29:59 +08:00
|
|
|
SNOR_F_SWP_IS_VOLATILE = BIT(16),
|
2020-03-14 03:42:53 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct spi_nor_read_command {
|
|
|
|
u8 num_mode_clocks;
|
|
|
|
u8 num_wait_states;
|
|
|
|
u8 opcode;
|
|
|
|
enum spi_nor_protocol proto;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct spi_nor_pp_command {
|
|
|
|
u8 opcode;
|
|
|
|
enum spi_nor_protocol proto;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum spi_nor_read_command_index {
|
|
|
|
SNOR_CMD_READ,
|
|
|
|
SNOR_CMD_READ_FAST,
|
|
|
|
SNOR_CMD_READ_1_1_1_DTR,
|
|
|
|
|
|
|
|
/* Dual SPI */
|
|
|
|
SNOR_CMD_READ_1_1_2,
|
|
|
|
SNOR_CMD_READ_1_2_2,
|
|
|
|
SNOR_CMD_READ_2_2_2,
|
|
|
|
SNOR_CMD_READ_1_2_2_DTR,
|
|
|
|
|
|
|
|
/* Quad SPI */
|
|
|
|
SNOR_CMD_READ_1_1_4,
|
|
|
|
SNOR_CMD_READ_1_4_4,
|
|
|
|
SNOR_CMD_READ_4_4_4,
|
|
|
|
SNOR_CMD_READ_1_4_4_DTR,
|
|
|
|
|
|
|
|
/* Octal SPI */
|
|
|
|
SNOR_CMD_READ_1_1_8,
|
|
|
|
SNOR_CMD_READ_1_8_8,
|
|
|
|
SNOR_CMD_READ_8_8_8,
|
|
|
|
SNOR_CMD_READ_1_8_8_DTR,
|
2020-10-05 23:31:26 +08:00
|
|
|
SNOR_CMD_READ_8_8_8_DTR,
|
2020-03-14 03:42:53 +08:00
|
|
|
|
|
|
|
SNOR_CMD_READ_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
enum spi_nor_pp_command_index {
|
|
|
|
SNOR_CMD_PP,
|
|
|
|
|
|
|
|
/* Quad SPI */
|
|
|
|
SNOR_CMD_PP_1_1_4,
|
|
|
|
SNOR_CMD_PP_1_4_4,
|
|
|
|
SNOR_CMD_PP_4_4_4,
|
|
|
|
|
|
|
|
/* Octal SPI */
|
|
|
|
SNOR_CMD_PP_1_1_8,
|
|
|
|
SNOR_CMD_PP_1_8_8,
|
|
|
|
SNOR_CMD_PP_8_8_8,
|
2020-10-05 23:31:26 +08:00
|
|
|
SNOR_CMD_PP_8_8_8_DTR,
|
2020-03-14 03:42:53 +08:00
|
|
|
|
|
|
|
SNOR_CMD_PP_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_nor_erase_type - Structure to describe a SPI NOR erase type
|
|
|
|
* @size: the size of the sector/block erased by the erase type.
|
|
|
|
* JEDEC JESD216B imposes erase sizes to be a power of 2.
|
|
|
|
* @size_shift: @size is a power of 2, the shift is stored in
|
|
|
|
* @size_shift.
|
|
|
|
* @size_mask: the size mask based on @size_shift.
|
|
|
|
* @opcode: the SPI command op code to erase the sector/block.
|
|
|
|
* @idx: Erase Type index as sorted in the Basic Flash Parameter
|
|
|
|
* Table. It will be used to synchronize the supported
|
|
|
|
* Erase Types with the ones identified in the SFDP
|
|
|
|
* optional tables.
|
|
|
|
*/
|
|
|
|
struct spi_nor_erase_type {
|
|
|
|
u32 size;
|
|
|
|
u32 size_shift;
|
|
|
|
u32 size_mask;
|
|
|
|
u8 opcode;
|
|
|
|
u8 idx;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_nor_erase_command - Used for non-uniform erases
|
|
|
|
* The structure is used to describe a list of erase commands to be executed
|
|
|
|
* once we validate that the erase can be performed. The elements in the list
|
|
|
|
* are run-length encoded.
|
|
|
|
* @list: for inclusion into the list of erase commands.
|
|
|
|
* @count: how many times the same erase command should be
|
|
|
|
* consecutively used.
|
|
|
|
* @size: the size of the sector/block erased by the command.
|
|
|
|
* @opcode: the SPI command op code to erase the sector/block.
|
|
|
|
*/
|
|
|
|
struct spi_nor_erase_command {
|
|
|
|
struct list_head list;
|
|
|
|
u32 count;
|
|
|
|
u32 size;
|
|
|
|
u8 opcode;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_nor_erase_region - Structure to describe a SPI NOR erase region
|
|
|
|
* @offset: the offset in the data array of erase region start.
|
|
|
|
* LSB bits are used as a bitmask encoding flags to
|
|
|
|
* determine if this region is overlaid, if this region is
|
|
|
|
* the last in the SPI NOR flash memory and to indicate
|
|
|
|
* all the supported erase commands inside this region.
|
|
|
|
* The erase types are sorted in ascending order with the
|
|
|
|
* smallest Erase Type size being at BIT(0).
|
|
|
|
* @size: the size of the region in bytes.
|
|
|
|
*/
|
|
|
|
struct spi_nor_erase_region {
|
|
|
|
u64 offset;
|
|
|
|
u64 size;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define SNOR_ERASE_TYPE_MAX 4
|
|
|
|
#define SNOR_ERASE_TYPE_MASK GENMASK_ULL(SNOR_ERASE_TYPE_MAX - 1, 0)
|
|
|
|
|
|
|
|
#define SNOR_LAST_REGION BIT(4)
|
|
|
|
#define SNOR_OVERLAID_REGION BIT(5)
|
|
|
|
|
|
|
|
#define SNOR_ERASE_FLAGS_MAX 6
|
|
|
|
#define SNOR_ERASE_FLAGS_MASK GENMASK_ULL(SNOR_ERASE_FLAGS_MAX - 1, 0)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_nor_erase_map - Structure to describe the SPI NOR erase map
|
|
|
|
* @regions: array of erase regions. The regions are consecutive in
|
|
|
|
* address space. Walking through the regions is done
|
|
|
|
* incrementally.
|
|
|
|
* @uniform_region: a pre-allocated erase region for SPI NOR with a uniform
|
|
|
|
* sector size (legacy implementation).
|
|
|
|
* @erase_type: an array of erase types shared by all the regions.
|
|
|
|
* The erase types are sorted in ascending order, with the
|
|
|
|
* smallest Erase Type size being the first member in the
|
|
|
|
* erase_type array.
|
|
|
|
* @uniform_erase_type: bitmask encoding erase types that can erase the
|
|
|
|
* entire memory. This member is completed at init by
|
|
|
|
* uniform and non-uniform SPI NOR flash memories if they
|
|
|
|
* support at least one erase type that can erase the
|
|
|
|
* entire memory.
|
|
|
|
*/
|
|
|
|
struct spi_nor_erase_map {
|
|
|
|
struct spi_nor_erase_region *regions;
|
|
|
|
struct spi_nor_erase_region uniform_region;
|
|
|
|
struct spi_nor_erase_type erase_type[SNOR_ERASE_TYPE_MAX];
|
|
|
|
u8 uniform_erase_type;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_nor_locking_ops - SPI NOR locking methods
|
|
|
|
* @lock: lock a region of the SPI NOR.
|
|
|
|
* @unlock: unlock a region of the SPI NOR.
|
|
|
|
* @is_locked: check if a region of the SPI NOR is completely locked
|
|
|
|
*/
|
|
|
|
struct spi_nor_locking_ops {
|
|
|
|
int (*lock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
|
|
|
|
int (*unlock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
|
|
|
|
int (*is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
|
|
|
|
};
|
|
|
|
|
mtd: spi-nor: add OTP support
SPI flashes sometimes have a special OTP area, which can (and is) used to
store immutable properties like board serial number or vendor assigned
network hardware addresses.
The MTD subsystem already supports accessing such areas and some (non
SPI NOR) flashes already implement support for it. It differentiates
between user and factory areas. User areas can be written by the user and
factory ones are pre-programmed and locked down by the vendor, usually
containing an "electrical serial number". This patch will only add support
for the user areas.
Lay the foundation and implement the MTD callbacks for the SPI NOR and add
necessary parameters to the flash_info structure. If a flash supports OTP
it can be added by the convenience macro OTP_INFO(). Sometimes there are
individual regions, which might have individual offsets. Therefore, it is
possible to specify the starting address of the first regions as well as
the distance between two regions (e.g. Winbond devices uses this method).
Additionally, the regions might be locked down. Once locked, no further
write access is possible.
For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
by offset addressing; except that you either have to use special read/write
commands (Winbond) or you have to enter (and exit) a specific OTP mode
(Macronix, Micron).
Thus we introduce four operations to which the MTD callbacks will be
mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
ops will be given an address offset to operate on while the locking ops use
regions because locking always affects a whole region. It is up to the
flash driver to implement these ops.
Signed-off-by: Michael Walle <michael@walle.cc>
[ta: use div64_u64(), IS_ALIGNED, params->otp.org. unsigned int region,
drop comment, add rlen local variable in spi_nor_mtd_otp_lock()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210321235140.8308-2-michael@walle.cc
2021-03-22 07:51:38 +08:00
|
|
|
/**
|
|
|
|
* struct spi_nor_otp_organization - Structure to describe the SPI NOR OTP regions
|
|
|
|
* @len: size of one OTP region in bytes.
|
|
|
|
* @base: start address of the OTP area.
|
|
|
|
* @offset: offset between consecutive OTP regions if there are more
|
|
|
|
* than one.
|
|
|
|
* @n_regions: number of individual OTP regions.
|
|
|
|
*/
|
|
|
|
struct spi_nor_otp_organization {
|
|
|
|
size_t len;
|
|
|
|
loff_t base;
|
|
|
|
loff_t offset;
|
|
|
|
unsigned int n_regions;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_nor_otp_ops - SPI NOR OTP methods
|
|
|
|
* @read: read from the SPI NOR OTP area.
|
|
|
|
* @write: write to the SPI NOR OTP area.
|
|
|
|
* @lock: lock an OTP region.
|
2021-06-07 19:27:44 +08:00
|
|
|
* @erase: erase an OTP region.
|
mtd: spi-nor: add OTP support
SPI flashes sometimes have a special OTP area, which can (and is) used to
store immutable properties like board serial number or vendor assigned
network hardware addresses.
The MTD subsystem already supports accessing such areas and some (non
SPI NOR) flashes already implement support for it. It differentiates
between user and factory areas. User areas can be written by the user and
factory ones are pre-programmed and locked down by the vendor, usually
containing an "electrical serial number". This patch will only add support
for the user areas.
Lay the foundation and implement the MTD callbacks for the SPI NOR and add
necessary parameters to the flash_info structure. If a flash supports OTP
it can be added by the convenience macro OTP_INFO(). Sometimes there are
individual regions, which might have individual offsets. Therefore, it is
possible to specify the starting address of the first regions as well as
the distance between two regions (e.g. Winbond devices uses this method).
Additionally, the regions might be locked down. Once locked, no further
write access is possible.
For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
by offset addressing; except that you either have to use special read/write
commands (Winbond) or you have to enter (and exit) a specific OTP mode
(Macronix, Micron).
Thus we introduce four operations to which the MTD callbacks will be
mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
ops will be given an address offset to operate on while the locking ops use
regions because locking always affects a whole region. It is up to the
flash driver to implement these ops.
Signed-off-by: Michael Walle <michael@walle.cc>
[ta: use div64_u64(), IS_ALIGNED, params->otp.org. unsigned int region,
drop comment, add rlen local variable in spi_nor_mtd_otp_lock()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210321235140.8308-2-michael@walle.cc
2021-03-22 07:51:38 +08:00
|
|
|
* @is_locked: check if an OTP region of the SPI NOR is locked.
|
|
|
|
*/
|
|
|
|
struct spi_nor_otp_ops {
|
|
|
|
int (*read)(struct spi_nor *nor, loff_t addr, size_t len, u8 *buf);
|
2021-04-03 14:09:31 +08:00
|
|
|
int (*write)(struct spi_nor *nor, loff_t addr, size_t len,
|
|
|
|
const u8 *buf);
|
mtd: spi-nor: add OTP support
SPI flashes sometimes have a special OTP area, which can (and is) used to
store immutable properties like board serial number or vendor assigned
network hardware addresses.
The MTD subsystem already supports accessing such areas and some (non
SPI NOR) flashes already implement support for it. It differentiates
between user and factory areas. User areas can be written by the user and
factory ones are pre-programmed and locked down by the vendor, usually
containing an "electrical serial number". This patch will only add support
for the user areas.
Lay the foundation and implement the MTD callbacks for the SPI NOR and add
necessary parameters to the flash_info structure. If a flash supports OTP
it can be added by the convenience macro OTP_INFO(). Sometimes there are
individual regions, which might have individual offsets. Therefore, it is
possible to specify the starting address of the first regions as well as
the distance between two regions (e.g. Winbond devices uses this method).
Additionally, the regions might be locked down. Once locked, no further
write access is possible.
For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
by offset addressing; except that you either have to use special read/write
commands (Winbond) or you have to enter (and exit) a specific OTP mode
(Macronix, Micron).
Thus we introduce four operations to which the MTD callbacks will be
mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
ops will be given an address offset to operate on while the locking ops use
regions because locking always affects a whole region. It is up to the
flash driver to implement these ops.
Signed-off-by: Michael Walle <michael@walle.cc>
[ta: use div64_u64(), IS_ALIGNED, params->otp.org. unsigned int region,
drop comment, add rlen local variable in spi_nor_mtd_otp_lock()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210321235140.8308-2-michael@walle.cc
2021-03-22 07:51:38 +08:00
|
|
|
int (*lock)(struct spi_nor *nor, unsigned int region);
|
2021-06-07 19:27:44 +08:00
|
|
|
int (*erase)(struct spi_nor *nor, loff_t addr);
|
mtd: spi-nor: add OTP support
SPI flashes sometimes have a special OTP area, which can (and is) used to
store immutable properties like board serial number or vendor assigned
network hardware addresses.
The MTD subsystem already supports accessing such areas and some (non
SPI NOR) flashes already implement support for it. It differentiates
between user and factory areas. User areas can be written by the user and
factory ones are pre-programmed and locked down by the vendor, usually
containing an "electrical serial number". This patch will only add support
for the user areas.
Lay the foundation and implement the MTD callbacks for the SPI NOR and add
necessary parameters to the flash_info structure. If a flash supports OTP
it can be added by the convenience macro OTP_INFO(). Sometimes there are
individual regions, which might have individual offsets. Therefore, it is
possible to specify the starting address of the first regions as well as
the distance between two regions (e.g. Winbond devices uses this method).
Additionally, the regions might be locked down. Once locked, no further
write access is possible.
For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
by offset addressing; except that you either have to use special read/write
commands (Winbond) or you have to enter (and exit) a specific OTP mode
(Macronix, Micron).
Thus we introduce four operations to which the MTD callbacks will be
mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
ops will be given an address offset to operate on while the locking ops use
regions because locking always affects a whole region. It is up to the
flash driver to implement these ops.
Signed-off-by: Michael Walle <michael@walle.cc>
[ta: use div64_u64(), IS_ALIGNED, params->otp.org. unsigned int region,
drop comment, add rlen local variable in spi_nor_mtd_otp_lock()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210321235140.8308-2-michael@walle.cc
2021-03-22 07:51:38 +08:00
|
|
|
int (*is_locked)(struct spi_nor *nor, unsigned int region);
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct spi_nor_otp - SPI NOR OTP grouping structure
|
|
|
|
* @org: OTP region organization
|
|
|
|
* @ops: OTP access ops
|
|
|
|
*/
|
|
|
|
struct spi_nor_otp {
|
|
|
|
const struct spi_nor_otp_organization *org;
|
|
|
|
const struct spi_nor_otp_ops *ops;
|
|
|
|
};
|
|
|
|
|
2020-03-14 03:42:53 +08:00
|
|
|
/**
|
|
|
|
* struct spi_nor_flash_parameter - SPI NOR flash parameters and settings.
|
|
|
|
* Includes legacy flash parameters and settings that can be overwritten
|
|
|
|
* by the spi_nor_fixups hooks, or dynamically when parsing the JESD216
|
|
|
|
* Serial Flash Discoverable Parameters (SFDP) tables.
|
|
|
|
*
|
|
|
|
* @size: the flash memory density in bytes.
|
2020-12-01 18:27:10 +08:00
|
|
|
* @writesize Minimal writable flash unit size. Defaults to 1. Set to
|
|
|
|
* ECC unit size for ECC-ed flashes.
|
2020-03-14 03:42:53 +08:00
|
|
|
* @page_size: the page size of the SPI NOR flash memory.
|
2020-10-05 23:31:28 +08:00
|
|
|
* @rdsr_dummy: dummy cycles needed for Read Status Register command.
|
|
|
|
* @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register
|
|
|
|
* command.
|
2020-03-14 03:42:53 +08:00
|
|
|
* @hwcaps: describes the read and page program hardware
|
|
|
|
* capabilities.
|
|
|
|
* @reads: read capabilities ordered by priority: the higher index
|
|
|
|
* in the array, the higher priority.
|
|
|
|
* @page_programs: page program capabilities ordered by priority: the
|
|
|
|
* higher index in the array, the higher priority.
|
|
|
|
* @erase_map: the erase map parsed from the SFDP Sector Map Parameter
|
|
|
|
* Table.
|
2021-10-30 01:26:09 +08:00
|
|
|
* @otp: SPI NOR OTP info.
|
2020-10-05 23:31:33 +08:00
|
|
|
* @octal_dtr_enable: enables SPI NOR octal DTR mode.
|
2020-09-04 15:47:20 +08:00
|
|
|
* @quad_enable: enables SPI NOR quad mode.
|
2020-03-14 03:42:53 +08:00
|
|
|
* @set_4byte_addr_mode: puts the SPI NOR in 4 byte addressing mode.
|
|
|
|
* @convert_addr: converts an absolute address into something the flash
|
|
|
|
* will understand. Particularly useful when pagesize is
|
|
|
|
* not a power-of-2.
|
2022-02-23 21:43:43 +08:00
|
|
|
* @setup: (optional) configures the SPI NOR memory. Useful for
|
|
|
|
* SPI NOR flashes that have peculiarities to the SPI NOR
|
|
|
|
* standard e.g. different opcodes, specific address
|
|
|
|
* calculation, page size, etc.
|
2020-03-14 03:42:53 +08:00
|
|
|
* @locking_ops: SPI NOR locking methods.
|
|
|
|
*/
|
|
|
|
struct spi_nor_flash_parameter {
|
|
|
|
u64 size;
|
2020-12-01 18:27:10 +08:00
|
|
|
u32 writesize;
|
2020-03-14 03:42:53 +08:00
|
|
|
u32 page_size;
|
2020-10-05 23:31:28 +08:00
|
|
|
u8 rdsr_dummy;
|
|
|
|
u8 rdsr_addr_nbytes;
|
2020-03-14 03:42:53 +08:00
|
|
|
|
|
|
|
struct spi_nor_hwcaps hwcaps;
|
|
|
|
struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
|
|
|
|
struct spi_nor_pp_command page_programs[SNOR_CMD_PP_MAX];
|
|
|
|
|
|
|
|
struct spi_nor_erase_map erase_map;
|
mtd: spi-nor: add OTP support
SPI flashes sometimes have a special OTP area, which can (and is) used to
store immutable properties like board serial number or vendor assigned
network hardware addresses.
The MTD subsystem already supports accessing such areas and some (non
SPI NOR) flashes already implement support for it. It differentiates
between user and factory areas. User areas can be written by the user and
factory ones are pre-programmed and locked down by the vendor, usually
containing an "electrical serial number". This patch will only add support
for the user areas.
Lay the foundation and implement the MTD callbacks for the SPI NOR and add
necessary parameters to the flash_info structure. If a flash supports OTP
it can be added by the convenience macro OTP_INFO(). Sometimes there are
individual regions, which might have individual offsets. Therefore, it is
possible to specify the starting address of the first regions as well as
the distance between two regions (e.g. Winbond devices uses this method).
Additionally, the regions might be locked down. Once locked, no further
write access is possible.
For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
by offset addressing; except that you either have to use special read/write
commands (Winbond) or you have to enter (and exit) a specific OTP mode
(Macronix, Micron).
Thus we introduce four operations to which the MTD callbacks will be
mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
ops will be given an address offset to operate on while the locking ops use
regions because locking always affects a whole region. It is up to the
flash driver to implement these ops.
Signed-off-by: Michael Walle <michael@walle.cc>
[ta: use div64_u64(), IS_ALIGNED, params->otp.org. unsigned int region,
drop comment, add rlen local variable in spi_nor_mtd_otp_lock()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210321235140.8308-2-michael@walle.cc
2021-03-22 07:51:38 +08:00
|
|
|
struct spi_nor_otp otp;
|
2020-03-14 03:42:53 +08:00
|
|
|
|
2020-10-05 23:31:33 +08:00
|
|
|
int (*octal_dtr_enable)(struct spi_nor *nor, bool enable);
|
2020-09-04 15:47:20 +08:00
|
|
|
int (*quad_enable)(struct spi_nor *nor);
|
2020-03-14 03:42:53 +08:00
|
|
|
int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
|
|
|
|
u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
|
|
|
|
int (*setup)(struct spi_nor *nor, const struct spi_nor_hwcaps *hwcaps);
|
|
|
|
|
|
|
|
const struct spi_nor_locking_ops *locking_ops;
|
|
|
|
};
|
|
|
|
|
2020-03-14 03:42:38 +08:00
|
|
|
/**
|
|
|
|
* struct spi_nor_fixups - SPI NOR fixup hooks
|
|
|
|
* @default_init: called after default flash parameters init. Used to tweak
|
|
|
|
* flash parameters when information provided by the flash_info
|
|
|
|
* table is incomplete or wrong.
|
|
|
|
* @post_bfpt: called after the BFPT table has been parsed
|
|
|
|
* @post_sfdp: called after SFDP has been parsed (is also called for SPI NORs
|
|
|
|
* that do not support RDSFDP). Typically used to tweak various
|
|
|
|
* parameters that could not be extracted by other means (i.e.
|
|
|
|
* when information provided by the SFDP/flash_info tables are
|
|
|
|
* incomplete or wrong).
|
2021-10-30 01:26:13 +08:00
|
|
|
* @late_init: used to initialize flash parameters that are not declared in the
|
|
|
|
* JESD216 SFDP standard, or where SFDP tables not defined at all.
|
|
|
|
* Will replace the default_init() hook.
|
2020-03-14 03:42:38 +08:00
|
|
|
*
|
|
|
|
* Those hooks can be used to tweak the SPI NOR configuration when the SFDP
|
|
|
|
* table is broken or not available.
|
|
|
|
*/
|
|
|
|
struct spi_nor_fixups {
|
|
|
|
void (*default_init)(struct spi_nor *nor);
|
|
|
|
int (*post_bfpt)(struct spi_nor *nor,
|
|
|
|
const struct sfdp_parameter_header *bfpt_header,
|
2021-03-06 17:50:00 +08:00
|
|
|
const struct sfdp_bfpt *bfpt);
|
2020-03-14 03:42:38 +08:00
|
|
|
void (*post_sfdp)(struct spi_nor *nor);
|
2021-10-30 01:26:13 +08:00
|
|
|
void (*late_init)(struct spi_nor *nor);
|
2020-03-14 03:42:38 +08:00
|
|
|
};
|
|
|
|
|
mtd: spi-nor: Rework the flash_info flags
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
2021-12-07 22:02:46 +08:00
|
|
|
/**
|
|
|
|
* struct flash_info - SPI NOR flash_info entry.
|
|
|
|
* @name: the name of the flash.
|
|
|
|
* @id: the flash's ID bytes. The first three bytes are the
|
|
|
|
* JEDIC ID. JEDEC ID zero means "no ID" (mostly older chips).
|
|
|
|
* @id_len: the number of bytes of ID.
|
|
|
|
* @sector_size: the size listed here is what works with SPINOR_OP_SE, which
|
|
|
|
* isn't necessarily called a "sector" by the vendor.
|
|
|
|
* @n_sectors: the number of sectors.
|
|
|
|
* @page_size: the flash's page size.
|
|
|
|
* @addr_width: the flash's address width.
|
|
|
|
*
|
|
|
|
* @parse_sfdp: true when flash supports SFDP tables. The false value has no
|
|
|
|
* meaning. If one wants to skip the SFDP tables, one should
|
|
|
|
* instead use the SPI_NOR_SKIP_SFDP sfdp_flag.
|
|
|
|
* @flags: flags that indicate support that is not defined by the
|
|
|
|
* JESD216 standard in its SFDP tables. Flag meanings:
|
|
|
|
* SPI_NOR_HAS_LOCK: flash supports lock/unlock via SR
|
|
|
|
* SPI_NOR_HAS_TB: flash SR has Top/Bottom (TB) protect bit. Must be
|
|
|
|
* used with SPI_NOR_HAS_LOCK.
|
|
|
|
* SPI_NOR_TB_SR_BIT6: Top/Bottom (TB) is bit 6 of status register.
|
|
|
|
* Must be used with SPI_NOR_HAS_TB.
|
|
|
|
* SPI_NOR_4BIT_BP: flash SR has 4 bit fields (BP0-3) for block
|
|
|
|
* protection.
|
|
|
|
* SPI_NOR_BP3_SR_BIT6: BP3 is bit 6 of status register. Must be used with
|
|
|
|
* SPI_NOR_4BIT_BP.
|
|
|
|
* SPI_NOR_SWP_IS_VOLATILE: flash has volatile software write protection bits.
|
|
|
|
* Usually these will power-up in a write-protected
|
|
|
|
* state.
|
|
|
|
* SPI_NOR_NO_ERASE: no erase command needed.
|
|
|
|
* NO_CHIP_ERASE: chip does not support chip erase.
|
|
|
|
* SPI_NOR_NO_FR: can't do fastread.
|
|
|
|
* USE_CLSR: use CLSR command.
|
|
|
|
* USE_FSR: use flag status register
|
|
|
|
* SPI_NOR_XSR_RDY: S3AN flashes have specific opcode to read the
|
|
|
|
* status register.
|
|
|
|
*
|
|
|
|
* @no_sfdp_flags: flags that indicate support that can be discovered via SFDP.
|
|
|
|
* Used when SFDP tables are not defined in the flash. These
|
|
|
|
* flags are used together with the SPI_NOR_SKIP_SFDP flag.
|
|
|
|
* SPI_NOR_SKIP_SFDP: skip parsing of SFDP tables.
|
|
|
|
* SECT_4K: SPINOR_OP_BE_4K works uniformly.
|
|
|
|
* SECT_4K_PMC: SPINOR_OP_BE_4K_PMC works uniformly.
|
|
|
|
* SPI_NOR_DUAL_READ: flash supports Dual Read.
|
|
|
|
* SPI_NOR_QUAD_READ: flash supports Quad Read.
|
|
|
|
* SPI_NOR_OCTAL_READ: flash supports Octal Read.
|
|
|
|
* SPI_NOR_OCTAL_DTR_READ: flash supports octal DTR Read.
|
|
|
|
* SPI_NOR_OCTAL_DTR_PP: flash supports Octal DTR Page Program.
|
|
|
|
*
|
|
|
|
* @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.
|
|
|
|
*
|
|
|
|
* SPI_NOR_4B_OPCODES: use dedicated 4byte address op codes to support
|
|
|
|
* memory size above 128Mib.
|
|
|
|
* SPI_NOR_IO_MODE_EN_VOLATILE: flash enables the best available I/O mode
|
|
|
|
* via a volatile bit.
|
|
|
|
* @mfr_flags: manufacturer private flags. Used in the manufacturer fixup
|
|
|
|
* hooks to differentiate support between flashes of the same
|
|
|
|
* manufacturer.
|
|
|
|
* @otp_org: flash's OTP organization.
|
|
|
|
* @fixups: part specific fixup hooks.
|
|
|
|
*/
|
2020-03-14 03:42:38 +08:00
|
|
|
struct flash_info {
|
mtd: spi-nor: Rework the flash_info flags
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
2021-12-07 22:02:46 +08:00
|
|
|
char *name;
|
|
|
|
u8 id[SPI_NOR_MAX_ID_LEN];
|
|
|
|
u8 id_len;
|
|
|
|
unsigned sector_size;
|
|
|
|
u16 n_sectors;
|
|
|
|
u16 page_size;
|
|
|
|
u16 addr_width;
|
|
|
|
|
|
|
|
bool parse_sfdp;
|
|
|
|
u16 flags;
|
|
|
|
#define SPI_NOR_HAS_LOCK BIT(0)
|
|
|
|
#define SPI_NOR_HAS_TB BIT(1)
|
|
|
|
#define SPI_NOR_TB_SR_BIT6 BIT(2)
|
|
|
|
#define SPI_NOR_4BIT_BP BIT(3)
|
|
|
|
#define SPI_NOR_BP3_SR_BIT6 BIT(4)
|
|
|
|
#define SPI_NOR_SWP_IS_VOLATILE BIT(5)
|
|
|
|
#define SPI_NOR_NO_ERASE BIT(6)
|
|
|
|
#define NO_CHIP_ERASE BIT(7)
|
|
|
|
#define SPI_NOR_NO_FR BIT(8)
|
|
|
|
#define USE_CLSR BIT(9)
|
|
|
|
#define USE_FSR BIT(10)
|
|
|
|
#define SPI_NOR_XSR_RDY BIT(11)
|
|
|
|
|
|
|
|
u8 no_sfdp_flags;
|
|
|
|
#define SPI_NOR_SKIP_SFDP BIT(0)
|
|
|
|
#define SECT_4K BIT(1)
|
|
|
|
#define SECT_4K_PMC BIT(2)
|
|
|
|
#define SPI_NOR_DUAL_READ BIT(3)
|
|
|
|
#define SPI_NOR_QUAD_READ BIT(4)
|
|
|
|
#define SPI_NOR_OCTAL_READ BIT(5)
|
|
|
|
#define SPI_NOR_OCTAL_DTR_READ BIT(6)
|
|
|
|
#define SPI_NOR_OCTAL_DTR_PP BIT(7)
|
|
|
|
|
|
|
|
u8 fixup_flags;
|
|
|
|
#define SPI_NOR_4B_OPCODES BIT(0)
|
|
|
|
#define SPI_NOR_IO_MODE_EN_VOLATILE BIT(1)
|
|
|
|
|
|
|
|
u8 mfr_flags;
|
2020-03-14 03:42:38 +08:00
|
|
|
|
mtd: spi-nor: add OTP support
SPI flashes sometimes have a special OTP area, which can (and is) used to
store immutable properties like board serial number or vendor assigned
network hardware addresses.
The MTD subsystem already supports accessing such areas and some (non
SPI NOR) flashes already implement support for it. It differentiates
between user and factory areas. User areas can be written by the user and
factory ones are pre-programmed and locked down by the vendor, usually
containing an "electrical serial number". This patch will only add support
for the user areas.
Lay the foundation and implement the MTD callbacks for the SPI NOR and add
necessary parameters to the flash_info structure. If a flash supports OTP
it can be added by the convenience macro OTP_INFO(). Sometimes there are
individual regions, which might have individual offsets. Therefore, it is
possible to specify the starting address of the first regions as well as
the distance between two regions (e.g. Winbond devices uses this method).
Additionally, the regions might be locked down. Once locked, no further
write access is possible.
For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
by offset addressing; except that you either have to use special read/write
commands (Winbond) or you have to enter (and exit) a specific OTP mode
(Macronix, Micron).
Thus we introduce four operations to which the MTD callbacks will be
mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
ops will be given an address offset to operate on while the locking ops use
regions because locking always affects a whole region. It is up to the
flash driver to implement these ops.
Signed-off-by: Michael Walle <michael@walle.cc>
[ta: use div64_u64(), IS_ALIGNED, params->otp.org. unsigned int region,
drop comment, add rlen local variable in spi_nor_mtd_otp_lock()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210321235140.8308-2-michael@walle.cc
2021-03-22 07:51:38 +08:00
|
|
|
const struct spi_nor_otp_organization otp_org;
|
2020-03-14 03:42:38 +08:00
|
|
|
const struct spi_nor_fixups *fixups;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Used when the "_ext_id" is two bytes at most */
|
mtd: spi-nor: Rework the flash_info flags
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
2021-12-07 22:02:46 +08:00
|
|
|
#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors) \
|
2020-03-14 03:42:38 +08:00
|
|
|
.id = { \
|
|
|
|
((_jedec_id) >> 16) & 0xff, \
|
|
|
|
((_jedec_id) >> 8) & 0xff, \
|
|
|
|
(_jedec_id) & 0xff, \
|
|
|
|
((_ext_id) >> 8) & 0xff, \
|
|
|
|
(_ext_id) & 0xff, \
|
|
|
|
}, \
|
|
|
|
.id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))), \
|
|
|
|
.sector_size = (_sector_size), \
|
|
|
|
.n_sectors = (_n_sectors), \
|
|
|
|
.page_size = 256, \
|
|
|
|
|
mtd: spi-nor: Rework the flash_info flags
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
2021-12-07 22:02:46 +08:00
|
|
|
#define INFO6(_jedec_id, _ext_id, _sector_size, _n_sectors) \
|
2020-03-14 03:42:38 +08:00
|
|
|
.id = { \
|
|
|
|
((_jedec_id) >> 16) & 0xff, \
|
|
|
|
((_jedec_id) >> 8) & 0xff, \
|
|
|
|
(_jedec_id) & 0xff, \
|
|
|
|
((_ext_id) >> 16) & 0xff, \
|
|
|
|
((_ext_id) >> 8) & 0xff, \
|
|
|
|
(_ext_id) & 0xff, \
|
|
|
|
}, \
|
|
|
|
.id_len = 6, \
|
|
|
|
.sector_size = (_sector_size), \
|
|
|
|
.n_sectors = (_n_sectors), \
|
|
|
|
.page_size = 256, \
|
|
|
|
|
mtd: spi-nor: Rework the flash_info flags
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
2021-12-07 22:02:46 +08:00
|
|
|
#define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_width) \
|
2020-03-14 03:42:38 +08:00
|
|
|
.sector_size = (_sector_size), \
|
|
|
|
.n_sectors = (_n_sectors), \
|
|
|
|
.page_size = (_page_size), \
|
|
|
|
.addr_width = (_addr_width), \
|
mtd: spi-nor: Rework the flash_info flags
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
2021-12-07 22:02:46 +08:00
|
|
|
.flags = SPI_NOR_NO_ERASE | SPI_NOR_NO_FR, \
|
2020-03-14 03:42:38 +08:00
|
|
|
|
|
|
|
#define S3AN_INFO(_jedec_id, _n_sectors, _page_size) \
|
|
|
|
.id = { \
|
|
|
|
((_jedec_id) >> 16) & 0xff, \
|
|
|
|
((_jedec_id) >> 8) & 0xff, \
|
|
|
|
(_jedec_id) & 0xff \
|
|
|
|
}, \
|
|
|
|
.id_len = 3, \
|
|
|
|
.sector_size = (8*_page_size), \
|
|
|
|
.n_sectors = (_n_sectors), \
|
|
|
|
.page_size = _page_size, \
|
|
|
|
.addr_width = 3, \
|
2020-03-14 03:42:50 +08:00
|
|
|
.flags = SPI_NOR_NO_FR | SPI_NOR_XSR_RDY,
|
2020-03-14 03:42:38 +08:00
|
|
|
|
mtd: spi-nor: add OTP support
SPI flashes sometimes have a special OTP area, which can (and is) used to
store immutable properties like board serial number or vendor assigned
network hardware addresses.
The MTD subsystem already supports accessing such areas and some (non
SPI NOR) flashes already implement support for it. It differentiates
between user and factory areas. User areas can be written by the user and
factory ones are pre-programmed and locked down by the vendor, usually
containing an "electrical serial number". This patch will only add support
for the user areas.
Lay the foundation and implement the MTD callbacks for the SPI NOR and add
necessary parameters to the flash_info structure. If a flash supports OTP
it can be added by the convenience macro OTP_INFO(). Sometimes there are
individual regions, which might have individual offsets. Therefore, it is
possible to specify the starting address of the first regions as well as
the distance between two regions (e.g. Winbond devices uses this method).
Additionally, the regions might be locked down. Once locked, no further
write access is possible.
For SPI NOR flashes the OTP area is accessed like the normal memory, e.g.
by offset addressing; except that you either have to use special read/write
commands (Winbond) or you have to enter (and exit) a specific OTP mode
(Macronix, Micron).
Thus we introduce four operations to which the MTD callbacks will be
mapped: .read(), .write(), .lock() and .is_locked(). The read and the write
ops will be given an address offset to operate on while the locking ops use
regions because locking always affects a whole region. It is up to the
flash driver to implement these ops.
Signed-off-by: Michael Walle <michael@walle.cc>
[ta: use div64_u64(), IS_ALIGNED, params->otp.org. unsigned int region,
drop comment, add rlen local variable in spi_nor_mtd_otp_lock()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210321235140.8308-2-michael@walle.cc
2021-03-22 07:51:38 +08:00
|
|
|
#define OTP_INFO(_len, _n_regions, _base, _offset) \
|
|
|
|
.otp_org = { \
|
|
|
|
.len = (_len), \
|
|
|
|
.base = (_base), \
|
|
|
|
.offset = (_offset), \
|
|
|
|
.n_regions = (_n_regions), \
|
|
|
|
},
|
|
|
|
|
mtd: spi-nor: Rework the flash_info flags
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
2021-12-07 22:02:46 +08:00
|
|
|
#define PARSE_SFDP \
|
|
|
|
.parse_sfdp = true, \
|
|
|
|
|
|
|
|
#define FLAGS(_flags) \
|
|
|
|
.flags = (_flags), \
|
|
|
|
|
|
|
|
#define NO_SFDP_FLAGS(_no_sfdp_flags) \
|
|
|
|
.no_sfdp_flags = (_no_sfdp_flags), \
|
|
|
|
|
|
|
|
#define FIXUP_FLAGS(_fixup_flags) \
|
|
|
|
.fixup_flags = (_fixup_flags), \
|
|
|
|
|
2021-12-07 22:02:45 +08:00
|
|
|
#define MFR_FLAGS(_mfr_flags) \
|
|
|
|
.mfr_flags = (_mfr_flags), \
|
|
|
|
|
2020-03-14 03:42:39 +08:00
|
|
|
/**
|
|
|
|
* struct spi_nor_manufacturer - SPI NOR manufacturer object
|
|
|
|
* @name: manufacturer name
|
|
|
|
* @parts: array of parts supported by this manufacturer
|
|
|
|
* @nparts: number of entries in the parts array
|
|
|
|
* @fixups: hooks called at various points in time during spi_nor_scan()
|
|
|
|
*/
|
|
|
|
struct spi_nor_manufacturer {
|
|
|
|
const char *name;
|
|
|
|
const struct flash_info *parts;
|
|
|
|
unsigned int nparts;
|
|
|
|
const struct spi_nor_fixups *fixups;
|
|
|
|
};
|
|
|
|
|
2021-05-03 23:56:50 +08:00
|
|
|
/**
|
|
|
|
* struct sfdp - SFDP data
|
|
|
|
* @num_dwords: number of entries in the dwords array
|
|
|
|
* @dwords: array of double words of the SFDP data
|
|
|
|
*/
|
|
|
|
struct sfdp {
|
|
|
|
size_t num_dwords;
|
|
|
|
u32 *dwords;
|
|
|
|
};
|
|
|
|
|
2020-03-14 03:42:39 +08:00
|
|
|
/* Manufacturer drivers. */
|
|
|
|
extern const struct spi_nor_manufacturer spi_nor_atmel;
|
2020-03-14 03:42:49 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_catalyst;
|
2020-03-14 03:42:40 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_eon;
|
2020-03-14 03:42:41 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_esmt;
|
2020-03-14 03:42:41 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_everspin;
|
2020-03-14 03:42:42 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_fujitsu;
|
2020-03-14 03:42:43 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_gigadevice;
|
2020-03-14 03:42:43 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_intel;
|
2020-03-14 03:42:44 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_issi;
|
2020-03-14 03:42:45 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_macronix;
|
2020-03-14 03:42:46 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_micron;
|
|
|
|
extern const struct spi_nor_manufacturer spi_nor_st;
|
2020-03-14 03:42:46 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_spansion;
|
2020-03-14 03:42:47 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_sst;
|
2020-03-14 03:42:48 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_winbond;
|
2020-03-14 03:42:50 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_xilinx;
|
2020-03-14 03:42:50 +08:00
|
|
|
extern const struct spi_nor_manufacturer spi_nor_xmc;
|
2020-03-14 03:42:39 +08:00
|
|
|
|
2021-05-03 23:56:51 +08:00
|
|
|
extern const struct attribute_group *spi_nor_sysfs_groups[];
|
|
|
|
|
2020-10-05 23:31:26 +08:00
|
|
|
void spi_nor_spimem_setup_op(const struct spi_nor *nor,
|
|
|
|
struct spi_mem_op *op,
|
|
|
|
const enum spi_nor_protocol proto);
|
2020-03-14 03:42:38 +08:00
|
|
|
int spi_nor_write_enable(struct spi_nor *nor);
|
|
|
|
int spi_nor_write_disable(struct spi_nor *nor);
|
|
|
|
int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable);
|
|
|
|
int spi_nor_write_ear(struct spi_nor *nor, u8 ear);
|
|
|
|
int spi_nor_wait_till_ready(struct spi_nor *nor);
|
2021-01-21 19:05:45 +08:00
|
|
|
int spi_nor_global_block_unlock(struct spi_nor *nor);
|
2020-03-14 03:42:38 +08:00
|
|
|
int spi_nor_lock_and_prep(struct spi_nor *nor);
|
|
|
|
void spi_nor_unlock_and_unprep(struct spi_nor *nor);
|
2020-09-04 15:47:20 +08:00
|
|
|
int spi_nor_sr1_bit6_quad_enable(struct spi_nor *nor);
|
|
|
|
int spi_nor_sr2_bit1_quad_enable(struct spi_nor *nor);
|
|
|
|
int spi_nor_sr2_bit7_quad_enable(struct spi_nor *nor);
|
mtd: spi-nor: keep lock bits if they are non-volatile
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
2020-12-04 00:29:59 +08:00
|
|
|
int spi_nor_read_sr(struct spi_nor *nor, u8 *sr);
|
2021-01-21 19:05:46 +08:00
|
|
|
int spi_nor_read_cr(struct spi_nor *nor, u8 *cr);
|
mtd: spi-nor: keep lock bits if they are non-volatile
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
2020-12-04 00:29:59 +08:00
|
|
|
int spi_nor_write_sr(struct spi_nor *nor, const u8 *sr, size_t len);
|
2020-12-04 00:29:58 +08:00
|
|
|
int spi_nor_write_sr_and_check(struct spi_nor *nor, u8 sr1);
|
2021-03-22 07:51:39 +08:00
|
|
|
int spi_nor_write_16bit_cr_and_check(struct spi_nor *nor, u8 cr);
|
2020-03-14 03:42:37 +08:00
|
|
|
|
2020-03-14 03:42:38 +08:00
|
|
|
int spi_nor_xread_sr(struct spi_nor *nor, u8 *sr);
|
2020-03-14 03:42:37 +08:00
|
|
|
ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t len,
|
|
|
|
u8 *buf);
|
2020-03-14 03:42:38 +08:00
|
|
|
ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,
|
|
|
|
const u8 *buf);
|
2021-06-07 19:27:44 +08:00
|
|
|
int spi_nor_erase_sector(struct spi_nor *nor, u32 addr);
|
2020-03-14 03:42:37 +08:00
|
|
|
|
2021-03-22 07:51:39 +08:00
|
|
|
int spi_nor_otp_read_secr(struct spi_nor *nor, loff_t addr, size_t len, u8 *buf);
|
2021-04-03 14:09:31 +08:00
|
|
|
int spi_nor_otp_write_secr(struct spi_nor *nor, loff_t addr, size_t len,
|
|
|
|
const u8 *buf);
|
2021-06-07 19:27:44 +08:00
|
|
|
int spi_nor_otp_erase_secr(struct spi_nor *nor, loff_t addr);
|
2021-03-22 07:51:39 +08:00
|
|
|
int spi_nor_otp_lock_sr2(struct spi_nor *nor, unsigned int region);
|
|
|
|
int spi_nor_otp_is_locked_sr2(struct spi_nor *nor, unsigned int region);
|
|
|
|
|
2020-03-14 03:42:37 +08:00
|
|
|
int spi_nor_hwcaps_read2cmd(u32 hwcaps);
|
|
|
|
u8 spi_nor_convert_3to4_read(u8 opcode);
|
2020-10-05 23:31:28 +08:00
|
|
|
void spi_nor_set_read_settings(struct spi_nor_read_command *read,
|
|
|
|
u8 num_mode_clocks,
|
|
|
|
u8 num_wait_states,
|
|
|
|
u8 opcode,
|
|
|
|
enum spi_nor_protocol proto);
|
2020-03-14 03:42:37 +08:00
|
|
|
void spi_nor_set_pp_settings(struct spi_nor_pp_command *pp, u8 opcode,
|
|
|
|
enum spi_nor_protocol proto);
|
|
|
|
|
|
|
|
void spi_nor_set_erase_type(struct spi_nor_erase_type *erase, u32 size,
|
|
|
|
u8 opcode);
|
|
|
|
struct spi_nor_erase_region *
|
|
|
|
spi_nor_region_next(struct spi_nor_erase_region *region);
|
|
|
|
void spi_nor_init_uniform_erase_map(struct spi_nor_erase_map *map,
|
|
|
|
u8 erase_mask, u64 flash_size);
|
|
|
|
|
|
|
|
int spi_nor_post_bfpt_fixups(struct spi_nor *nor,
|
|
|
|
const struct sfdp_parameter_header *bfpt_header,
|
2021-03-06 17:50:00 +08:00
|
|
|
const struct sfdp_bfpt *bfpt);
|
2020-03-14 03:42:37 +08:00
|
|
|
|
2021-03-22 15:51:30 +08:00
|
|
|
void spi_nor_init_default_locking_ops(struct spi_nor *nor);
|
|
|
|
void spi_nor_try_unlock_all(struct spi_nor *nor);
|
2021-12-07 22:02:43 +08:00
|
|
|
void spi_nor_set_mtd_locking_ops(struct spi_nor *nor);
|
|
|
|
void spi_nor_set_mtd_otp_ops(struct spi_nor *nor);
|
2021-03-22 15:51:30 +08:00
|
|
|
|
2021-10-30 01:26:10 +08:00
|
|
|
static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
|
2020-03-14 03:42:38 +08:00
|
|
|
{
|
2021-10-30 01:26:10 +08:00
|
|
|
return container_of(mtd, struct spi_nor, mtd);
|
2020-03-14 03:42:38 +08:00
|
|
|
}
|
|
|
|
|
2020-03-14 03:42:37 +08:00
|
|
|
#endif /* __LINUX_MTD_SPI_NOR_INTERNAL_H */
|