History log of /linux-master/drivers/mtd/spi-nor/macronix.c
Revision Date Author Comments
# b0eea634 07-Sep-2023 Michael Walle <mwalle@kernel.org>

mtd: spi-nor: macronix: sort flash_info database

The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.

Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-35-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# 09e5a29f 07-Sep-2023 Michael Walle <mwalle@kernel.org>

mtd: spi-nor: macronix: convert flash_info to new format

The INFOx() macros are going away. Convert the flash_info database to
the new format.

Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-24-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# da7e48db 07-Sep-2023 Michael Walle <mwalle@kernel.org>

mtd: spi-nor: remove or move flash_info comments

Most of the comments are a relict of the past when the flash_info was
just one table. Most of them are useless. Remove them.

Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-16-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# 3ea3f0ac 07-Sep-2023 Michael Walle <mwalle@kernel.org>

mtd: spi-nor: drop .parse_sfdp

Drop the size parameter to indicate we need to do SFDP, we can do that
because it is guaranteed that the size will be set by SFDP and because
PARSE_SFDP forced the SFDP parsing it must be overwritten.

There is a (very tiny) chance that this might break block protection
support: we now rely on the SFDP reported size of the flash for the
BP calculation. OTOH, if the flash reports its size wrong, we are
in bigger trouble than just having the BP calculation wrong.

Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-11-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# d534fd97 26-Jul-2023 Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: spi-nor: spansion: use CLPEF as an alternative to CLSR

Infineon S28Hx (SEMPER Octal) and S25FS256T (SEMPER Nano) support Clear
Program and Erase Failure Flags (CLPEF, 82h) instead of CLSR(30h).
Introduce a new mfr_flag together with the infrastructure to allow
manufacturer private data in the core. With this we remove the need
to have if checks in the code at runtime and instead set the correct
opcodes at probe time. S25Hx (SEMPER QSPI) supports CLSR but it may
be disabled by CFR3x[2] while CLPEF is always available. Therefore,
the mfr_flag is also applied to S25Hx for safety.

Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Link: https://lore.kernel.org/r/20230726075257.12985-2-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# 4e53ab0c 31-Mar-2023 Tudor Ambarus <tudor.ambarus@linaro.org>

mtd: spi-nor: Set the 4-Byte Address Mode method based on SFDP data

JESD216 SFDP defines in BFPT methods to enter and exit the
4-Byte Address Mode. The flash parameters and settings that are
retrieved from SFDP have higher precedence than the static
initialized ones, because they should be more accurate and less
error prone than those initialized statically. Parse and favor the
BFPT-parsed set_4byte_addr_mode methods.

Some regressions may be introduced by this patch, because the
params->set_4byte_addr_mode method that was set either in
spi_nor_init_default_params() or later overwritten in default_init()
hooks, are now be overwritten with a different value based on the
BFPT data. If that's the case, the fix is to introduce a post_bfpt
fixup hook where one should fix the wrong BFPT info.

Link: https://lore.kernel.org/r/20230331074606.3559258-7-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# d75c22f3 31-Mar-2023 Tudor Ambarus <tudor.ambarus@linaro.org>

mtd: spi-nor: core: Update name and description of spi_nor_set_4byte_addr_mode

Rename method to spi_nor_set_4byte_addr_mode_en4b_ex4b and extend its
description. This method is described in JESD216 BFPT[SFDP_DWORD(16)],
BIT(31) and BIT(23).

Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20230331074606.3559258-5-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# f0a499ac 31-Mar-2023 Miquel Raynal <miquel.raynal@bootlin.com>

mtd: spi-nor: macronix: Add support for mx25uw51245g with RWW

Describe this new part and provide the RWW flag for it.

There is no public datasheet, but here are the sfdp tables plus base
testing to show it works.

$ cat /sys/bus/spi/devices/spi0.0/spi-nor/partname
mx25uw51245g
$ cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id
c2813a
$ cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer
macronix
$ xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
53464450080104fd00070114400000ff8701011c900000ff0a0001080001
00ff05000105200100ff84000102340100ff0000000000000000ffffffff
ffffffffe5208affffffff1f00ff00ff00ff00ffeeffffffffff00ffffff
00ff0c2010d800ff00ff87790100821200e27704674630b030b0f4bdd55c
000000ff101000200000000000007ca14800000000008888000000000000
00400fd1fff30fd1fff300050090000500b1002b0095002b0096727103b8
727103b80000000090a3188200c069960000000000000000727100987271
00b8727100990000000072710098727100f872710099727100f900000000
00000000011501d0727106d8000086500000060100000000020001030002
00000000060100000000000072060002000000eec0697272717100d8f7f6
000a00001445988043060f0021dcffff
$ md5sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
047a884cf44d9ffc2a94d3ab37b48c63 /sys/bus/spi/devices/spi0.0/spi-nor/sfdp

$ dd if=/dev/urandom of=./qspi_test bs=1M count=6
6+0 records in
6+0 records out
$ mtd_debug write /dev/mtd1 0 6291456 qspi_test
Copied 6291456 bytes from qspi_test to address 0x00000000 in flash
$ mtd_debug erase /dev/mtd1 0 6291456
Erased 6291456 bytes from address 0x00000000 in flash
$ mtd_debug read /dev/mtd1 0 6291456 qspi_read
Copied 6291456 bytes from address 0x00000000 in flash to qspi_read
$ hexdump qspi_read
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0600000
$ mtd_debug write /dev/mtd1 0 6291456 qspi_test
Copied 6291456 bytes from qspi_test to address 0x00000000 in flash
$ mtd_debug read /dev/mtd1 0 6291456 qspi_read
Copied 6291456 bytes from address 0x00000000 in flash to qspi_read
$ sha1sum qspi_test qspi_read
d24a9523db829a0df688f34b8dc76a1383b74024 qspi_test
d24a9523db829a0df688f34b8dc76a1383b74024 qspi_read

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20230331194620.839899-2-miquel.raynal@bootlin.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>


# 86d4cdf8 25-Dec-2022 Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: spi-nor: sfdp: Rename BFPT_DWORD() macro to SFDP_DWORD()

BFPT_DWORD() converts 1-based indexing to 0-based indexing for C arrays,
and is used in BFPT parse. Per JESD216F.02, the conversion is applicable
to other parameter tables than BFPT. This patch renames the macro to
SFDP_DWORD() so that we can use it for other parameter tables than BFPT.

Suggested-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/e42feac840fe3a31187419e91b2d514d9f259d15.1672026365.git.Takahiro.Kuwano@infineon.com


# 0757201a 23-Feb-2022 Michael Walle <michael@walle.cc>

mtd: spi-nor: macronix: unify function names

To avoid name clashes unify all the function and static object names and
use one of the following prefixes which should be sufficiently unique:
- <vendor>_nor_
- <flash_family>_nor_
- <flash_part>_

There are no functional changes.

Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20220223134358.1914798-11-michael@walle.cc


# 65b54ff6 05-Nov-2021 Tudor Ambarus <tudor.ambarus@microchip.com>

mtd: spi-nor: Constify part specific fixup hooks

Constify 'struct spi_nor_fixups' in order to respect flash_info
structure declaration.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211106102915.153552-1-tudor.ambarus@microchip.com


# ec1c0e99 07-Dec-2021 Tudor Ambarus <tudor.ambarus@microchip.com>

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


# 7ea40b54 10-May-2021 David Bauer <mail@david-bauer.net>

mtd: spi-nor: enable locking support for MX25L12805D

Macronix MX25L12805D supports locking with 4 block
protection bits in its status register. Add the corresponding
flag in order to clear these bits when unloking the flash.

Otherwise, the flash might not be writable depending on the state
left by the bootloader.

Tested-on: Ubiquiti UniFi AC Lite (ath79)

Signed-off-by: David Bauer <mail@david-bauer.net>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Michael Walle <michael@walle.cc>


# d406f49b 02-Apr-2021 Tudor Ambarus <tudor.ambarus@microchip.com>

mtd: spi-nor: macronix: Fix name for mx66l51235f

According to macronix website, there is no mx66l51235l part number.
The chip detected as such is actually mx66l51235f. Rename the flash.
Do not update the mx66l51235l name from the spi_nor_dev_ids[], since
there are dt that are using this compatible.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>


# 46094049 02-Apr-2021 Tudor Ambarus <tudor.ambarus@microchip.com>

Revert "mtd: spi-nor: macronix: Add support for mx25l51245g"

This reverts commit 04b8edad262eec0d153005973dfbdd83423c0dcb.

mx25l51245g and mx66l51235l have the same flash ID. The flash
detection returns the first entry in the flash_info array that
matches the flash ID that was read, thus for the 0xc2201a ID,
mx25l51245g was always hit, introducing a regression for
mx66l51235l.

If one wants to differentiate the flash names, a better fix would be
to differentiate between the two at run-time, depending on SFDP,
and choose the correct name from a list of flash names, depending on
the SFDP differentiator.

Fixes: 04b8edad262e ("mtd: spi-nor: macronix: Add support for mx25l51245g")
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210402082031.19055-2-tudor.ambarus@microchip.com


# a580293a 06-Mar-2021 Tudor Ambarus <tudor.ambarus@microchip.com>

mtd: spi-nor: Get rid of duplicated argument in spi_nor_parse_sfdp()

spi_nor_parse_sfdp(nor, nor->params);
passes for the second argument a member within the first argument.
Drop the second argument and obtain it directly from the first,
and do it across all the children functions. This is a follow up for
'commit 69a8eed58cc0 ("mtd: spi-nor: Don't copy self-pointing struct around")'

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20210306095002.22983-4-tudor.ambarus@microchip.com


# 02892d40 14-Sep-2020 Robert Marko <robert.marko@sartura.hr>

mtd: spi-nor: macronix: Add SECT_4K to mx25l12805d

According to the mx25l12805d datasheet it supports using 4K or 64K sectors.
So lets add the SECT_4K to enable 4K sector usage.

Datasheet: https://www.mxic.com.tw/Lists/Datasheet/Attachments/7321/MX25L12805D,%203V,%20128Mb,%20v1.2.pdf

Cc: Luka Perkov <luka.perkov@sartura.hr>
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20200915100623.708736-1-robert.marko@sartura.hr


# 48029e62 20-Jul-2020 David Clear <dac2@pensando.io>

mtd: spi-nor: macronix: Add support for mx66u2g45g

The Macronix mx66u2g45g is a 1.8V, 2Gbit (256MB) device that
supports x1, x2, or x4 operation.

Tested on Pensando SoC hardware with a cadence quadspi controller
via drivers/spi/spi-cadence-quadspi.c, in x2 mode at 50MHz.
- random data write, erase, read - verified erase operations
- random data write, read/compare - verified write/read operations

Signed-off-by: David Clear <dac2@pensando.io>
Acked-by: Shannon Nelson <snelson@pensando.io>
Link: https://lore.kernel.org/r/20200720163656.38006-2-dac2@pensando.io
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>


# 482dcb2a 02-Jul-2020 Frieder Schrempf <frieder.schrempf@kontron.de>

mtd: spi-nor: macronix: Add support for MX25R1635F

The MX25R1635F is the smaller sibling of the MX25R3235F that is
already supported. It's only half the size (16Mb).

It was tested on the Kontron Electronics i.MX8MM SoM (N8010)
using raw read and write from and to the mtd device and
the 'flash_erase' command.

Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
[tudor.ambarus@microchip.com: update subject]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20200702140523.6811-1-frieder.schrempf@kontron.de


# 9f09e37d 23-Apr-2020 Mason Yang <masonccyang@mxic.com.tw>

mtd: spi-nor: macronix: Add support for mx25u51245g

mx25u51245g is a mass production for new design and
replace mx66u51235f(phase out).

Validated by read, erase, read back, write and read back
on Xilinx Zynq PicoZed FPGA board which included
Macronix SPI Host (driver/spi/spi-mxic.c).

Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>


# 04b8edad 23-Apr-2020 Mason Yang <masonccyang@mxic.com.tw>

mtd: spi-nor: macronix: Add support for mx25l51245g

mx25l51245g is a mass production for new design and
replace mx66l51235l(phase out).

Validated by read, erase, read back, write and read back
on Xilinx Zynq PicoZed FPGA board which included
Macronix SPI Host (driver/spi/spi-mxic.c).

Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>


# 829ec640 13-Mar-2020 Tudor Ambarus <tudor.ambarus@microchip.com>

mtd: spi-nor: Trim what is exposed in spi-nor.h

The SPI NOR controllers drivers must not be able to use structures that
are meant just for the SPI NOR core.

struct spi_nor_flash_parameter is filled at run-time with info gathered
from flash_info, manufacturer and sfdp data. struct spi_nor_flash_parameter
should be opaque to the SPI NOR controller drivers, make sure it is.

spi_nor_option_flags, spi_nor_read_command, spi_nor_pp_command,
spi_nor_read_command_index and spi_nor_pp_command_index are defined for the
core use, make sure they are opaque to the SPI NOR controller drivers.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>


# 10526d85 13-Mar-2020 Boris Brezillon <bbrezillon@kernel.org>

mtd: spi-nor: Move Macronix bits out of core.c

Create a SPI NOR manufacturer driver for Macronix chips, and move the
Macronix definitions outside of core.c.

Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Tested-by: Xiang Chen <chenxiang66@hisilicon.com>