- 04 Nov, 2023 2 commits
-
-
Miquel Raynal authored
The raw NAND subsystem has, as usual, seen a bit of cleanup being done this cycle, typically return values of platform_get_irq() and devm_kasprintf(), plus structure annotations for sanitizers. There is also a better ECC check in the Arasan driver. This comes with smaller misc changes. In the SPI-NAND world there is now support for Foresee F35SQA002G, Winbond W25N and XTX XT26 chips. Signed-off-by:Miquel Raynal <miquel.raynal@bootlin.com>
-
Miquel Raynal authored
For SPI NOR we cleaned the flash info entries in order to have them slimmer and self explanatory. In order to make the entries as slim as possible, we introduced sane default values so that the actual flash entries don't need to specify them. We now use a flexible macro to specify the flash ID instead of the previous INFOx() macros that had hardcoded ID lengths. Instead of: - { "w25q512nwm", INFO(0xef8020, 0, 64 * 1024, 0) - OTP_INFO(256, 3, 0x1000, 0x1000) }, We now use: + .id = SNOR_ID(0xef, 0x80, 0x20), + .name = "w25q512nwm", + .otp = SNOR_OTP(256, 3, 0x1000, 0x1000), We also removed some flash entries: the very old Catalyst SPI EEPROMs that were introduced once with the SPI-NOR subsystem, and a Fujitsu MRAM. Both should use the at25 EEPROM driver. The latter even has device tree bindings for the at25 driver. We made sure that the conversion didn't introduce any unwanted changes by comparing the .rodata segment before and after the conversion. The patches landed in linux-next immediately after v6.6-rc2, we haven't seen any regressions yet. Apart of the autumn cleaning we introduced a new flash entry, at25ff321a, and added block protection support for mt25qu512a. Signed-off-by:
-
- 27 Oct, 2023 4 commits
-
-
Linus Walleij authored
Currently the offset into the device when looking for OTP bits can go outside of the address of the MTD NOR devices, and if that memory isn't readable, bad things happen on the IXP4xx (added prints that illustrate the problem before the crash): cfi_intelext_otp_walk walk OTP on chip 0 start at reg_prot_offset 0x00000100 ixp4xx_copy_from copy from 0x00000100 to 0xc880dd78 cfi_intelext_otp_walk walk OTP on chip 0 start at reg_prot_offset 0x12000000 ixp4xx_copy_from copy from 0x12000000 to 0xc880dd78 8<--- cut here --- Unable to handle kernel paging request at virtual address db000000 [db000000] *pgd=00000000 (...) This happens in this case because the IXP4xx is big endian and the 32- and 16-bit fields in the struct cfi_intelext_otpinfo are not properly byteswapped. Compare to how the code in read_pri_intelext() byteswaps the fields in struct cfi_pri_intelext. Adding a small byte swapping loop for the OTP in read_pri_intelext() and the crash goes away. The problem went unnoticed for many years until I enabled CONFIG_MTD_OTP on the IXP4xx as well, triggering the bug. Cc: stable@vger.kernel.org Reviewed-by:
Nicolas Pitre <nico@fluxnic.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Yi Yang authored
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Fixes: 1e4d3ba6 ("mtd: rawnand: meson: fix the clock") Signed-off-by:
Yi Yang <yiyang13@huawei.com> Signed-off-by:
-
Yi Yang authored
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Fixes: 0b1039f0 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by:
-
Uwe Kleine-König authored
The driver doesn't benefit from the advantages that module_platform_driver_probe() allows (i.e. putting the probe function in .init.text and the .remove function into .exit.text). So use module_platform_driver() instead which allows to bind the driver also after booting (or module loading) and unbinding via sysfs. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
- 18 Oct, 2023 2 commits
-
-
Mamta Shukla authored
Parse SFDP table to get size and functions of mt25qu512a. BFPT wrongly advertises 16bit SR support and made the locking fail. Add a post BFPT fixup hook to clear the 16bit SR support. cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/jedec_id 20bb20104400 cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/manufacturer st cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/partname mt25qu512a xxd -p /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/sfdp 53464450060101ff00060110300000ff84000102800000ffffffffffffff ffffffffffffffffffffffffffffffffffffe520fbffffffff1f29eb276b 273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e 03e1ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff ffffffffffffffffffe7ffff21dcffff md5sum /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/sfdp 610efba1647e00ac6db18beb11e84c04 /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/sfdp Signed-off-by:
Mamta Shukla <mamta.shukla@leica-geosystems.com> Reviewed-by:
Pratyush Yadav <pratyush@kernel.org> Link: https://lore.kernel.org/r/20231017074711.12167-2-tudor.ambarus@linaro.orgSigned-off-by:
Tudor Ambarus <tudor.ambarus@linaro.org>
-
Mamta Shukla authored
mt25qu512a supports locking/unlocking through the SR BP bits. Enable locking support. Tested with mtd-utils- flash_lock/flash_unlock on MT25QU512ABB8E12. Signed-off-by:
-
- 16 Oct, 2023 29 commits
-
-
Andy Shevchenko authored
The of_gpio.h is not and shouldn't be used in the drivers. Remove it. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Bruce Suen authored
Add Support XTX Technology XT26G01DXXXXX, XT26G11DXXXXX, XT26Q01DXXXXX, XT26G02DXXXXX, XT26G12DXXXXX, XT26Q02DXXXXX, XT26G04DXXXXX, and XT26Q04DXXXXX SPI NAND. These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die ECC(8bit strength per 512bytes). Datasheet Links: - http://www.xtxtech.com/download/?AId=458 - http://www.xtxtech.com/download/?AId=495Signed-off-by:
Bruce Suen <bruce_suen@163.com> Signed-off-by:
-
Sridharan S N authored
Add support for W25N01JW, W25N02JWZEIF, W25N512GW, W25N02KWZEIR and W25N01GWZEIG. W25N02KWZEIR has 8b/512b on-die ECC capability and other four has 4b/512b on-die ECC capability. Signed-off-by:
Sridharan S N <quic_sridsn@quicinc.com> Signed-off-by:
Md Sadre Alam <quic_mdalam@quicinc.com> Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct cdns_nand_chip. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Roger Quadros <rogerq@kernel.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Yang Yingliang <yangyingliang@huawei.com> Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: Valentin Korenblit <vkorenblit@sequans.com> Cc: ye xingchen <ye.xingchen@zte.com.cn> Cc: linux-mtd@lists.infradead.org Cc: linux-hardening@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct mtk_nfc_nand_chip. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Thierry Reding <treding@nvidia.com> Cc: Roger Quadros <rogerq@kernel.org> Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: Cai Huoqing <cai.huoqing@linux.dev> Cc: Chuanhong Guo <gch981213@gmail.com> Cc: Rob Herring <robh@kernel.org> Cc: Li Zetao <lizetao1@huawei.com> Cc: linux-mtd@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: linux-hardening@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by:
-
Martin Kurbanov authored
Add support for FORESEE F35SQA002G SPI NAND. Datasheet: https://www.longsys.com/uploads/LM-00006FORESEEF35SQA002GDatasheet_1650183701.pdfSigned-off-by:
Martin Kurbanov <mmkurbanov@salutedevices.com> Signed-off-by:
-
Christophe JAILLET authored
Use struct_size() instead of hand writing it. This is less verbose and more robust. While at it, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). Also remove a useless comment about the position of a flex-array in a structure. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Amit Kumar Mahapatra authored
Following an ECC failure condition upon page reads, we shall distinguish between a real ECC failure and an empty page. This is handled with a call to nand_check_erased_ecc_chunk() which looks at the data and counts the number of bits which are not 'ones'. If we get less zeros than the ECC strength, we assume the page was erased and we are in the presence of natural bitflips. Otherwise, if we are above, we assume some data was written and the ECC engine could not recover it all, so we report an ECC failure. In order for this logic to be as close as the reality as we can (this is already a simplified condition but we can hardly be more precise), we should check all the data that is covered by the ECC step not only the in-band data, so we should also include the ECC syndrome in the check. Fixes: 88ffef1b ("mtd: rawnand: arasan: Support the hardware BCH ECC engine") Signed-off-by:
Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Signed-off-by:
-
Rob Herring authored
Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Rafał Miłecki authored
parse_mtd_partitions() may return an error so it should be checked and optionally passed up Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
-
Simon Glass authored
Sometimes the contents of a partition are compressed. Add a property to express this and define the algorithm used. Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
-
ZhaoLong Wang authored
If the driver cannot read all the requested data, -EBADMSG or -EUCLEAN should never be returned. Add a WARN_ON_ONCE() to help driver developers detect this error. Signed-off-by:
ZhaoLong Wang <wangzhaolong1@huawei.com> Signed-off-by:
-
- 27 Sep, 2023 1 commit
-
-
Nicolas Ferre authored
Add the at25ff321a 4MB SPI flash which is able to provide SFDP information. Link: https://www.renesas.com/us/en/document/dst/at25ff321a-datasheetSigned-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20230926131655.51224-1-nicolas.ferre@microchip.comSigned-off-by:
-
- 22 Sep, 2023 2 commits
-
-
Shivamurthy Shastri authored
When the DT property no-unaligned-direct-access is set, map->phys is set to NO_XIP. With this property set, the flash should not be exposed directly to MTD users, since it cannot be mapped. map_ram() exposes the flash direct access unconditionally which leads to access errors (when the bus width does not match the RAM width). Therefore do not set point and unpoint when NO_XIP is set. Signed-off-by:
Shivamurthy Shastri <shivamurthy.shastri@linutronix.de> Reviewed-by:
Benedikt Spranger <b.spranger@linutronix.de> Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct sunxi_nand_chip. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Samuel Holland <samuel@sholland.org> Cc: Manuel Dipolt <mdipolt@robart.cc> Cc: linux-mtd@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-sunxi@lists.linux.dev Signed-off-by:
-
