- Mar 19, 2022
-
-
Miquel Raynal authored
SPI NOR core changes: - move vendor specific code out of the core into vendor drivers. - unify all function and object names in the vendor modules. - make setup() callback optional to improve readability. - skip erase logic when the SPI_NOR_NO_ERASE flag is set at flash declaration. Signed-off-by:Miquel Raynal <miquel.raynal@bootlin.com>
-
- Mar 15, 2022
-
-
Miquel Raynal authored
Avoid random build errors with architectures which do not select HAS_IOMEM by depending on it in Kconfig. This fixes the following warning: /home/mraynal/0day/gcc-11.2.0-nolibc/s390-linux/bin/s390-linux-ld: drivers/mtd/nand/ecc-mxic.o: in function `mxic_ecc_probe': ecc-mxic.c:(.text+0x2244): undefined reference to `devm_platform_ioremap_resource' Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Colin Ian King authored
Don't populate the read-only arrays possible_strength and spare_size on the stack but instead make them static const. Also makes the object code a little smaller. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
The AM65x HyperBus controller is only present on Texas Instruments AM65x SoCs. Hence add a dependency on ARCH_K3, to prevent asking the user about this driver when configuring a kernel without support for the Texas Instruments Inc. K3 multicore SoC architecture. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Tudor Ambarus authored
partid and partname debugfs files were used just by SPI NOR, but they were replaced by sysfs entries. Since these debugfs files are no longer used in mtd, remove dead code. The directory is kept as it is used by nandsim, mtdswap and docg3. Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by:
Pratyush Yadav <p.yadav@ti.com> Signed-off-by:
-
Rafał Miłecki authored
This helps validating DTS files. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Amit Kumar Mahapatra authored
While calculating speed during mtd_speedtest, the time interval (i.e., start - finish) is rounded off to the nearest milliseconds by ignoring the fractional part. This leads to miscalculation of speed. The miscalculation is more visible while running speed test on small partition sizes(i.e., when partition size is equal to eraseblock size or twice the eraseblock size) at higher spi frequencies. For e.g., while calculating eraseblock read speed for a mtd partition with size equal to the eraseblock size(i.e., 64KiB) the eraseblock read time interval comes out to be 966490 nanosecond. This is then converted to millisecond(i.e., 0.966 msec.). The integer part (i.e., 0 msec) of the value is considered and the fractional part (i.e., 0.966) is ignored,for calculating the eraseblock read speed. So the reported eraseblock read speed is 0 KiB/s, which is incorrect. There are two approaches to fix this issue. First approach will be to...
-
- Mar 08, 2022
-
-
Tudor Ambarus authored
Even if SPI_NOR_NO_ERASE was set, one could still send erase opcodes to the flash. It is not recommended to send unsupported opcodes to flashes. Fix the logic and do not set mtd->_erase when SPI_NOR_NO_ERASE is specified. With this users will not be able to issue erase opcodes to flashes and instead they will recive an -ENOTSUPP error. Fixes: b199489d ("mtd: spi-nor: add the framework for SPI NOR") Signed-off-by:
Michael Walle <michael@walle.cc> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220228163334.277730-1-tudor.ambarus@microchip.com
-
- Feb 26, 2022
-
-
Michael Walle authored
As we have deleted some flag, lets renumber them so there are no holes. Signed-off-by:
-
Michael Walle authored
Now that there is almost no special case code left in spi_nor_sr_ready(), the return check looks odd. Move the function call closer to the return code checking. Signed-off-by:
-
Michael Walle authored
Drop the generic spi_nor prefix for all the spansion functions. Signed-off-by:
-
Michael Walle authored
Now that all functions using that flag are local to the spansion module, we can convert the flag to a manufacturer one. Signed-off-by:
-
Michael Walle authored
The clear status register flags is only available on spansion flashes. Move all the functions around that into the spanion module. Signed-off-by:
-
Michael Walle authored
Don't return early when the flash is smaller than or equal to 16MiB. We need to be able to register hooks for all sizes of flashes. This also has the benefit that it increases the readability of the code because the action, i.e. registering the fixups, is connected to the condition, i.e. flashes larger than 16MiB. Signed-off-by:
-
Michael Walle authored
Drop the generic spi_nor prefix for all the micron-st functions. Signed-off-by:
-
Michael Walle authored
Now that all functions using that flag are local to the micron module, we can convert the flag to a manufacturer one. Signed-off-by:
-
Michael Walle authored
The flag status register is only available on micron flashes. Move all the functions around that into the micron module. This is almost a mechanical move except for the spi_nor_fsr_ready() which now also checks the normal status register. Previously, this was done in spi_nor_ready(). Signed-off-by:
-
Michael Walle authored
XRDSR is a combination of xilinx and the RDSR opcode, but the register is just the status register. Correct the debug message. Signed-off-by:
-
Michael Walle authored
Drop the generic spi_nor prefix for all the xilinx functions. Signed-off-by:
-
Michael Walle authored
Mechanically move all the xilinx functions to its own module. Then register the new flash specific ready() function. Signed-off-by:
-
Michael Walle authored
The _page_size marco parameter was missing parentheses around it. Add them. Signed-off-by:
-
Michael Walle authored
We will move vendor specific code into the vendor modules and thus we will have to export these functions so they can be called. Signed-off-by:
-
Michael Walle authored
Xilinx and Micron flashes have their own implementation of the spi_nor_ready() function. At the moment, the core will figure out which one to call according to some flags. Lay the foundation to make it possible that a flash can register its own ready() function. Signed-off-by:
-
Michael Walle authored
Instead of always using a function pointer (and initializing it to our default), just call the default function if the flash didn't set its own one. That will make the call flow easier to follow. Also mark the parameter as optional now. Signed-off-by:
-
- Feb 25, 2022
-
-
Michael Walle authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
