2020-03-13 19:42:47 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2005, Intec Automation Inc.
|
|
|
|
* Copyright (C) 2014, Freescale Semiconductor, Inc.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/mtd/spi-nor.h>
|
|
|
|
|
|
|
|
#include "core.h"
|
|
|
|
|
2021-12-07 14:02:45 +00:00
|
|
|
/* SST flash_info mfr_flag. Used to specify SST byte programming. */
|
|
|
|
#define SST_WRITE BIT(0)
|
|
|
|
|
2021-01-21 11:05:46 +00:00
|
|
|
#define SST26VF_CR_BPNV BIT(3)
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
|
2021-01-21 11:05:46 +00:00
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
|
2021-01-21 11:05:46 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* We only support unlocking the entire flash array. */
|
|
|
|
if (ofs != 0 || len != nor->params->size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ret = spi_nor_read_cr(nor, nor->bouncebuf);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (!(nor->bouncebuf[0] & SST26VF_CR_BPNV)) {
|
|
|
|
dev_dbg(nor->dev, "Any block has been permanently locked\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return spi_nor_global_block_unlock(nor);
|
|
|
|
}
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static int sst26vf_nor_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
|
2021-01-21 11:05:46 +00:00
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static const struct spi_nor_locking_ops sst26vf_nor_locking_ops = {
|
|
|
|
.lock = sst26vf_nor_lock,
|
|
|
|
.unlock = sst26vf_nor_unlock,
|
|
|
|
.is_locked = sst26vf_nor_is_locked,
|
2021-01-21 11:05:46 +00:00
|
|
|
};
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static void sst26vf_nor_late_init(struct spi_nor *nor)
|
2021-01-21 11:05:46 +00:00
|
|
|
{
|
2022-02-23 13:43:39 +00:00
|
|
|
nor->params->locking_ops = &sst26vf_nor_locking_ops;
|
2021-01-21 11:05:46 +00:00
|
|
|
}
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static const struct spi_nor_fixups sst26vf_nor_fixups = {
|
|
|
|
.late_init = sst26vf_nor_late_init,
|
2021-01-21 11:05:46 +00:00
|
|
|
};
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static const struct flash_info sst_nor_parts[] = {
|
2020-03-13 19:42:47 +00:00
|
|
|
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
|
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 14:02:46 +00:00
|
|
|
{ "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP |
|
|
|
|
SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K) },
|
|
|
|
{ "sst25wf512", INFO(0xbf2501, 0, 64 * 1024, 1)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25wf010", INFO(0xbf2502, 0, 64 * 1024, 2)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25wf020", INFO(0xbf2503, 0, 64 * 1024, 4)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25wf020a", INFO(0x621612, 0, 64 * 1024, 4)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K) },
|
|
|
|
{ "sst25wf040b", INFO(0x621613, 0, 64 * 1024, 8)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K) },
|
|
|
|
{ "sst25wf040", INFO(0xbf2504, 0, 64 * 1024, 8)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst25wf080", INFO(0xbf2505, 0, 64 * 1024, 16)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K)
|
2021-12-07 14:02:45 +00:00
|
|
|
MFR_FLAGS(SST_WRITE) },
|
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 14:02:46 +00:00
|
|
|
{ "sst26wf016b", INFO(0xbf2651, 0, 64 * 1024, 32)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
|
2020-03-13 19:42:47 +00:00
|
|
|
SPI_NOR_QUAD_READ) },
|
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 14:02:46 +00:00
|
|
|
{ "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ) },
|
|
|
|
{ "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128)
|
|
|
|
FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
|
|
|
|
NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
|
2022-02-23 13:43:39 +00:00
|
|
|
.fixups = &sst26vf_nor_fixups },
|
2020-03-13 19:42:47 +00:00
|
|
|
};
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static int sst_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
|
|
|
|
size_t *retlen, const u_char *buf)
|
2020-03-13 19:42:47 +00:00
|
|
|
{
|
|
|
|
struct spi_nor *nor = mtd_to_spi_nor(mtd);
|
|
|
|
size_t actual = 0;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
|
|
|
|
|
|
|
|
ret = spi_nor_lock_and_prep(nor);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = spi_nor_write_enable(nor);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
nor->sst_write_second = false;
|
|
|
|
|
|
|
|
/* Start write from odd address. */
|
|
|
|
if (to % 2) {
|
|
|
|
nor->program_opcode = SPINOR_OP_BP;
|
|
|
|
|
|
|
|
/* write one byte. */
|
|
|
|
ret = spi_nor_write_data(nor, to, 1, buf);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
|
|
|
WARN(ret != 1, "While writing 1 byte written %i bytes\n", ret);
|
|
|
|
ret = spi_nor_wait_till_ready(nor);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
to++;
|
|
|
|
actual++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Write out most of the data here. */
|
|
|
|
for (; actual < len - 1; actual += 2) {
|
|
|
|
nor->program_opcode = SPINOR_OP_AAI_WP;
|
|
|
|
|
|
|
|
/* write two bytes. */
|
|
|
|
ret = spi_nor_write_data(nor, to, 2, buf + actual);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
|
|
|
WARN(ret != 2, "While writing 2 bytes written %i bytes\n", ret);
|
|
|
|
ret = spi_nor_wait_till_ready(nor);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
to += 2;
|
|
|
|
nor->sst_write_second = true;
|
|
|
|
}
|
|
|
|
nor->sst_write_second = false;
|
|
|
|
|
|
|
|
ret = spi_nor_write_disable(nor);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
ret = spi_nor_wait_till_ready(nor);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* Write out trailing byte if it exists. */
|
|
|
|
if (actual != len) {
|
|
|
|
ret = spi_nor_write_enable(nor);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
nor->program_opcode = SPINOR_OP_BP;
|
|
|
|
ret = spi_nor_write_data(nor, to, 1, buf + actual);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
|
|
|
WARN(ret != 1, "While writing 1 byte written %i bytes\n", ret);
|
|
|
|
ret = spi_nor_wait_till_ready(nor);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
actual += 1;
|
|
|
|
|
|
|
|
ret = spi_nor_write_disable(nor);
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
*retlen += actual;
|
|
|
|
spi_nor_unlock_and_unprep(nor);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static void sst_nor_late_init(struct spi_nor *nor)
|
2020-03-13 19:42:47 +00:00
|
|
|
{
|
2021-12-07 14:02:45 +00:00
|
|
|
if (nor->info->mfr_flags & SST_WRITE)
|
2022-02-23 13:43:39 +00:00
|
|
|
nor->mtd._write = sst_nor_write;
|
2020-03-13 19:42:47 +00:00
|
|
|
}
|
|
|
|
|
2022-02-23 13:43:39 +00:00
|
|
|
static const struct spi_nor_fixups sst_nor_fixups = {
|
|
|
|
.late_init = sst_nor_late_init,
|
2020-03-13 19:42:47 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
const struct spi_nor_manufacturer spi_nor_sst = {
|
|
|
|
.name = "sst",
|
2022-02-23 13:43:39 +00:00
|
|
|
.parts = sst_nor_parts,
|
|
|
|
.nparts = ARRAY_SIZE(sst_nor_parts),
|
|
|
|
.fixups = &sst_nor_fixups,
|
2020-03-13 19:42:47 +00:00
|
|
|
};
|