#
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>
|