summaryrefslogtreecommitdiff
path: root/drivers/mtd
AgeCommit message (Collapse)AuthorFilesLines
2023-11-10Merge tag 'mips_6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds3-135/+0
Pull MIPS updates from Thomas Bogendoerfer: - removed AR7 platform support - cleanups and fixes * tag 'mips_6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: AR7: remove platform watchdog: ar7_wdt: remove driver to prepare for platform removal vlynq: remove bus driver mtd: parsers: ar7: remove support serial: 8250: remove AR7 support arch: mips: remove ReiserFS from defconfig MIPS: lantiq: Remove unnecessary include of <linux/of_irq.h> MIPS: lantiq: Fix pcibios_plat_dev_init() "no previous prototype" warning MIPS: KVM: Fix a build warning about variable set but not used MIPS: Remove dead code in relocate_new_kernel mips: dts: ralink: mt7621: rename to GnuBee GB-PC1 and GnuBee GB-PC2 mips: dts: ralink: mt7621: define each reset as an item mips: dts: ingenic: Remove unneeded probe-type properties MIPS: loongson32: Remove dma.h and nand.h
2023-11-05Merge tag 'ubifs-for-linus-6.7-rc1' of ↵Linus Torvalds9-113/+164
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs Pull UBI and UBIFS updates from Richard Weinberger: - UBI Fastmap improvements - Minor issues found by static analysis bots in both UBI and UBIFS - Fix for wrong dentry length UBIFS in fscrypt mode * tag 'ubifs-for-linus-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs: ubifs: ubifs_link: Fix wrong name len calculating when UBIFS is encrypted ubi: block: Fix use-after-free in ubiblock_cleanup ubifs: fix possible dereference after free ubi: fastmap: Add control in 'UBI_IOCATT' ioctl to reserve PEBs for filling pools ubi: fastmap: Add module parameter to control reserving filling pool PEBs ubi: fastmap: Fix lapsed wear leveling for first 64 PEBs ubi: fastmap: Get wl PEB even ec beyonds the 'max' if free PEBs are run out ubi: fastmap: may_reserve_for_fm: Don't reserve PEB if fm_anchor exists ubi: fastmap: Remove unneeded break condition while filling pools ubi: fastmap: Wait until there are enough free PEBs before filling pools ubi: fastmap: Use free pebs reserved for bad block handling ubi: Replace erase_block() with sync_erase() ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmap ubi: fastmap: erase_block: Get erase counter from wl_entry rather than flash ubi: fastmap: Fix missed ec updating after erasing old fastmap data block ubifs: Fix missing error code err ubifs: Fix memory leak of bud->log_hash ubifs: Fix some kernel-doc comments
2023-11-04Merge tag 'mtd/for-6.7' of ↵Linus Torvalds67-986/+1797
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull mtd updates from Miquel Raynal: "The main set of changes is related to Uwe's work converting platform remove callbacks to return void. Comes next (in number of changes) Kees' additional structures annotations to improve the sanitizers. The usual amount of cleanups apply. About the more substancial contribution, one main function of the partitions core could return an error which was not checked, this is now fixed. On the bindings side, fixed partitions can now have a compression property. Finally, an erroneous situation is now always avoided in the MAP RAM driver. CFI: - A several years old byte swap has been fixed. NAND: - The subsystem has, as usual, seen a bit of cleanup being done this cycle, typically return values of platform_get_irq() and devm_kasprintf(). 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. SPI NOR: - 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" * tag 'mtd/for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (91 commits) mtd: cfi_cmdset_0001: Byte swap OTP info mtd: rawnand: meson: check return value of devm_kasprintf() mtd: rawnand: intel: check return value of devm_kasprintf() mtd: rawnand: sh_flctl: Convert to module_platform_driver() mtd: spi-nor: micron-st: use SFDP table for mt25qu512a mtd: spi-nor: micron-st: enable lock/unlock for mt25qu512a mtd: rawnand: Remove unused of_gpio.h inclusion mtd: spinand: Add support for XTX XT26xxxDxxxxx mtd: spinand: winbond: add support for serial NAND flash mtd: rawnand: cadence: Annotate struct cdns_nand_chip with __counted_by mtd: rawnand: Annotate struct mtk_nfc_nand_chip with __counted_by mtd: spinand: add support for FORESEE F35SQA002G mtd: rawnand: rockchip: Use struct_size() mtd: rawnand: arasan: Include ECC syndrome along with in-band data while checking for ECC failure mtd: Use device_get_match_data() mtd: spi-nor: nxp-spifi: Convert to platform remove callback returning void mtd: spi-nor: hisi-sfc: Convert to platform remove callback returning void mtd: maps: sun_uflash: Convert to platform remove callback returning void mtd: maps: sa1100-flash: Convert to platform remove callback returning void mtd: maps: pxa2xx-flash: Convert to platform remove callback returning void ...
2023-11-04Merge tag 'nand/for-6.7' into mtd/nextMiquel Raynal17-15/+304
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>
2023-11-04Merge tag 'spi-nor/for-6.7' into mtd/nextMiquel Raynal21-873/+1407
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: Miquel Raynal <miquel.raynal@bootlin.com>
2023-11-03Merge tag 'char-misc-6.7-rc1' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc updates from Greg KH: "Here is the big set of char/misc and other small driver subsystem changes for 6.7-rc1. Included in here are: - IIO subsystem driver updates and additions (largest part of this pull request) - FPGA subsystem driver updates - Counter subsystem driver updates - ICC subsystem driver updates - extcon subsystem driver updates - mei driver updates and additions - nvmem subsystem driver updates and additions - comedi subsystem dependency fixes - parport driver fixups - cdx subsystem driver and core updates - splice support for /dev/zero and /dev/full - other smaller driver cleanups All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (326 commits) cdx: add sysfs for subsystem, class and revision cdx: add sysfs for bus reset cdx: add support for bus enable and disable cdx: Register cdx bus as a device on cdx subsystem cdx: Create symbol namespaces for cdx subsystem cdx: Introduce lock to protect controller ops cdx: Remove cdx controller list from cdx bus system dts: ti: k3-am625-beagleplay: Add beaglecc1352 greybus: Add BeaglePlay Linux Driver dt-bindings: net: Add ti,cc1352p7 dt-bindings: eeprom: at24: allow NVMEM cells based on old syntax dt-bindings: nvmem: SID: allow NVMEM cells based on old syntax Revert "nvmem: add new config option" MAINTAINERS: coresight: Add missing Coresight files misc: pci_endpoint_test: Add deviceID for J721S2 PCIe EP device support firmware: xilinx: Move EXPORT_SYMBOL_GPL next to zynqmp_pm_feature definition uacce: make uacce_class constant ocxl: make ocxl_class constant cxl: make cxl_class constant misc: phantom: make phantom_class constant ...
2023-10-31Merge tag 'gpio-updates-for-v6.7-rc1' of ↵Linus Torvalds1-12/+0
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "We don't have any new drivers. The loongson driver is getting extended with support for new models. There's a big refactor of gpio-pca953x and many small improvements to others. The GPIO code in the kernel has acquired a lot of cruft over the years as well as many abusers of the API across the kernel tree. This release cycle we have started a major cleanup and improvement effort that will most likely span several releases. We have started by converting external users of struct gpio_chip to accessing the wrapper around it - struct gpio_device. This is because the latter is reference counted while the former is removed when the provider is unbound. We also removed several instances of drivers accessing private GPIOLIB structures and including the private header from drivers/gpio/. To that end you'll see several commits aimed at different subsystems (acked by relevant maintainers) as well as two merges from the x86/platform tree. We'll then rework the locking in GPIOLIB which currently uses a big spinlock for many different things and could use becoming more fine-grained, especially as it doesn't even get the locking right. We'll also use SRCU for protecting the gpio_chip pointer against in-kernel hot-unplug crashes similar to what we saw triggered from user-space and fixed with semaphores in gpiolib-cdev. The core GPIOLIB is still vulnerable to these use-cases. I'm just mentioning the plans here, this is not part of this PR. You'll see some new instances of using __free(). We've added a gpio_device_put cleanup helper similar to the put_device one introduced by Peter Zijlstra and used it according to the preferred pattern except where it didn't make sense. GPIOLIB core: - provide interfaces allowing users to retrieve, manage and query the reference counted GPIO device instead of accessing the private gpio_chip structure - replace gpiochip_find() with gpio_device_find() - remove unused acpi_get_and_request_gpiod() - improve the ignore_interrupt functionality in GPIO ACPI - correct notifier return codes in gpiolib-of - unexport gpiod_set_transitory() as it's unused outside of core GPIO code - while there are still external users accessing struct gpio_chip, let's make gpiochip_get_desc() public so that they at least use the preferred helper - improve locking for lookup tables - annotate struct linereq with __counted_by - improve GPIOLIB docs - add an OF quirk for LED trigger sources Driver improvements: - convert all GPIO drivers with .remove() callbacks to using the new variant returning void instead of int - stop accessing the GPIOLIB private structures in gpio-mockup, i2c-mux-gpio, hte-tegra194, gpio-sim - use the recommended pattern for autofree variables in gpio-sim - add support for more models to gpio-loongson - use a notifier chain to notify other blocks about interrupts in gpio-eic-sprd instead of looking up GPIO devices on every interrupt - convert gpio-pca953x and gpio-fx6408 to using the maple tree regmap cache - don't include GPIOLIB internal headers in drivers which don't need them - move the ingenic NAND quirk into gpiolib-of - add an ignore interrupt quirk for Peaq C1010 - drop static GPIO base from gpio-omap, gpio-f7188x - use the preferred device_get_match_data() function in drivers that still don't - refactor gpio-pca953x: switch to using DEFINE_SIMPLE_DEV_PM_OPS(), use cleanup helpers, use dev_err_probe() where it makes sense, fully convert to using devres and some other minor tweaks DT bindings: - add support for a new model to gpio-vf610 and update existing properties - add support for more loongson models - add missing support for imx models that are used but undocumented - convert bindings for Intel IXP4xx to schema Minor stuff: - deprecate gpio-mockup in favor of gpio-sim - include missing headers here and there - stop using gpiochip_find() in OMAP1 board files - minor tweaks in gpio-vf610, gpio-hisi - remove unneeded 'extern' specifiers from headers" * tag 'gpio-updates-for-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (108 commits) hte: tegra194: add GPIOLIB dependency hte: tegra194: don't access struct gpio_chip gpiolib: provide gpio_device_get_base() i2c: mux: gpio: don't fiddle with GPIOLIB internals gpiolib: provide gpiod_to_gpio_device() gpiolib: provide gpio_device_to_device() gpio: hisi: Fix format specifier gpiolib: provide gpio_device_find_by_fwnode() gpio: acpi: remove acpi_get_and_request_gpiod() gpio: Use device_get_match_data() gpio: vf610: update comment for i.MX8ULP and i.MX93 legacy compatibles platform/x86: int3472: Switch to devm_get_gpiod() platform/x86: int3472: Stop using gpiod_toggle_active_low() platform/x86: int3472: Add new skl_int3472_gpiod_get_from_temp_lookup() helper platform/x86: int3472: Add new skl_int3472_fill_gpiod_lookup() helper gpio: vf610: simplify code by dropping data check gpio: vf610: add i.MX8ULP of_device_id entry dt-bindings: gpio: vf610: add i.MX95 compatible dt-bindings: gpio: vf610: correct i.MX8ULP and i.MX93 dt-bindings: gpio: vf610: update gpio-ranges ...
2023-10-28ubi: block: Fix use-after-free in ubiblock_cleanupZhaoLong Wang1-1/+3
The following BUG is reported when a ubiblock is removed: ================================================================== BUG: KASAN: slab-use-after-free in ubiblock_cleanup+0x88/0xa0 [ubi] Read of size 4 at addr ffff88810c8f3804 by task ubiblock/1716 CPU: 5 PID: 1716 Comm: ubiblock Not tainted 6.6.0-rc2+ #135 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x37/0x50 print_report+0xd0/0x620 kasan_report+0xb6/0xf0 ubiblock_cleanup+0x88/0xa0 [ubi] ubiblock_remove+0x121/0x190 [ubi] vol_cdev_ioctl+0x355/0x630 [ubi] __x64_sys_ioctl+0xc7/0x100 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f08d7445577 Code: b3 66 90 48 8b 05 11 89 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 8 RSP: 002b:00007ffde05a3018 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007f08d7445577 RDX: 0000000000000000 RSI: 0000000000004f08 RDI: 0000000000000003 RBP: 0000000000816010 R08: 00000000008163a7 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000000003 R13: 00007ffde05a3130 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 1715: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x7f/0x90 __alloc_disk_node+0x40/0x2b0 __blk_mq_alloc_disk+0x3e/0xb0 ubiblock_create+0x2ba/0x620 [ubi] vol_cdev_ioctl+0x581/0x630 [ubi] __x64_sys_ioctl+0xc7/0x100 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 0: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 __kasan_slab_free+0x10e/0x190 __kmem_cache_free+0x96/0x220 bdev_free_inode+0xa4/0xf0 rcu_core+0x496/0xec0 __do_softirq+0xeb/0x384 The buggy address belongs to the object at ffff88810c8f3800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 4 bytes inside of freed 1024-byte region [ffff88810c8f3800, ffff88810c8f3c00) The buggy address belongs to the physical page: page:00000000d03de848 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10c8f0 head:00000000d03de848 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x200000000000840(slab|head|node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000840 ffff888100042dc0 ffffea0004244400 dead000000000002 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810c8f3700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88810c8f3780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88810c8f3800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88810c8f3880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88810c8f3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fix it by using a local variable to record the gendisk ID. Fixes: 77567b25ab9f ("ubi: use blk_mq_alloc_disk and blk_cleanup_disk") Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com> Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Add control in 'UBI_IOCATT' ioctl to reserve PEBs for filling ↵Zhihao Cheng1-1/+1
pools This patch imports a new field 'need_resv_pool' in struct 'ubi_attach_req' to control whether or not reserving free PEBs for filling pool/wl_pool. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Add module parameter to control reserving filling pool PEBsZhihao Cheng3-6/+25
Adding 6th module parameter in 'mtd=xxx' to control whether or not reserving PEBs for filling pool/wl_pool. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Fix lapsed wear leveling for first 64 PEBsZhihao Cheng4-3/+8
The anchor PEB must be picked from first 64 PEBs, these PEBs could have large erase counter greater than other PEBs especially when free space is nearly running out. The ubi_update_fastmap will be called as long as pool/wl_pool is empty, old anchor PEB is erased when updating fastmap. Given an UBI device with N PEBs, free PEBs is nearly running out and pool will be filled with 1 PEB every time ubi_update_fastmap invoked. So t=N/POOL_SIZE[1]/64 means that in worst case the erase counter of first 64 PEBs is t times greater than other PEBs in theory. After running fsstress for 24h, the erase counter statistics for two UBI devices shown as follow(CONFIG_MTD_UBI_WL_THRESHOLD=128): Device A(1024 PEBs, pool=50, wl_pool=25): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 0 0 0 0 10000 .. 99999: 960 29224 29282 29362 100000 .. inf: 64 117897 117934 117940 --------------------------------------------------------- Total : 1024 29224 34822 117940 Device B(8192 PEBs, pool=256, wl_pool=128): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 8128 2253 2321 2387 10000 .. 99999: 64 35387 35387 35388 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 8192 2253 2579 35388 The key point is reducing fastmap updating frequency by enlarging POOL_SIZE, so let UBI reserve ubi->fm_pool.max_size PEBs during attaching. Then POOL_SIZE will become ubi->fm_pool.max_size/2 even in free space running out case. Given an UBI device with 8192 PEBs(16384\8192\4096 is common large-capacity flash), t=8192/128/64=1. The fastmap updating will happen in either wl_pool or pool is empty, so setting fm_pool_rsv_cnt as ubi->fm_pool.max_size can fill wl_pool in full state. After pool reservation, running fsstress for 24h: Device A(1024 PEBs, pool=50, wl_pool=25): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 0 0 0 0 10000 .. 99999: 1024 33801 33997 34056 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 1024 33801 33997 34056 Device B(8192 PEBs, pool=256, wl_pool=128): ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 0 0 0 0 1000 .. 9999: 8192 2205 2397 2460 10000 .. 99999: 0 0 0 0 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 8192 2205 2397 2460 The difference of erase counter between first 64 PEBs and others is under WL_FREE_MAX_DIFF(2*UBI_WL_THRESHOLD=2*128=256). Device A: 34056 - 33801 = 255 Device B: 2460 - 2205 = 255 Next patch will add a switch to control whether UBI needs to reserve PEBs for filling pool. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Get wl PEB even ec beyonds the 'max' if free PEBs are run outZhihao Cheng2-16/+44
This is the part 2 to fix cyclically reusing single fastmap data PEBs. Consider one situation, if there are four free PEBs for fm_anchor, pool, wl_pool and fastmap data PEB with erase counter 100, 100, 100, 5096 (ubi->beb_rsvd_pebs is 0). PEB with erase counter 5096 is always picked for fastmap data according to the realization of find_wl_entry(), since fastmap data PEB is not scheduled for wl, finally there are two PEBs (fm data) with great erase counter than other PEBS. Get wl PEB even its erase counter exceeds the 'max' in find_wl_entry() when free PEBs are run out after filling pools and fm data. Then the PEB with biggest erase conter is taken as wl PEB, it can be scheduled for wl. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: may_reserve_for_fm: Don't reserve PEB if fm_anchor existsZhihao Cheng2-4/+7
This is the part 1 to fix cyclically reusing single fastmap data PEBs. After running fsstress on UBIFS for a while, UBI (16384 blocks, fastmap takes 2 blocks) has an erase block(PEB: 8031) with big erase counter greater than any other pebs: ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 532 84 92 99 100 .. 999: 15787 100 147 229 1000 .. 9999: 64 4699 4765 4826 10000 .. 99999: 0 0 0 0 100000 .. inf: 1 272935 272935 272935 --------------------------------------------------------- Total : 16384 84 180 272935 Not like fm_anchor, there is no candidate PEBs for fastmap data area, so old fastmap data pebs will be reused after all free pebs are filled into pool/wl_pool: ubi_update_fastmap for (i = 1; i < new_fm->used_blocks; i++) erase_block(ubi, old_fm->e[i]->pnum) new_fm->e[i] = old_fm->e[i] According to wear leveling algorithm, UBI selects one small erase counter PEB from ubi->used and one big erase counter PEB from wl_pool, the reused fastmap data PEB is not in these trees. UBI won't schedule this PEB for wl even it is in ubi->used because wl algorithm expects small erase counter for used PEB. Don't reserve PEB for fastmap in may_reserve_for_fm() if fm_anchor already exists. Otherwise, when UBI is running out of free PEBs, the only one free PEB (pnum < 64) will be skipped and fastmap data will be written on the same old PEB. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Remove unneeded break condition while filling poolsZhihao Cheng1-3/+2
Change pool filling stop condition. Commit d09e9a2bddba ("ubi: fastmap: Fix high cpu usage of ubi_bgt by making sure wl_pool not empty") reserves fastmap data PEBs after filling 1 PEB in wl_pool. Now wait_free_pebs_for_pool() makes enough free PEBs before filling pool, there will still be at least 1 PEB in pool and 1 PEB in wl_pool after doing ubi_refill_pools(). Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Wait until there are enough free PEBs before filling poolsZhihao Cheng5-16/+65
Wait until there are enough free PEBs before filling pool/wl_pool, sometimes erase_worker is not scheduled in time, which causes two situations: A. There are few PEBs filled in pool, which makes ubi_update_fastmap is frequently called and leads first 64 PEBs are erased more times than other PEBs. So waiting free PEBs before filling pool reduces fastmap updating frequency and prolongs flash service life. B. In situation that space is nearly running out, ubi_refill_pools() cannot make sure pool and wl_pool are filled with free PEBs, caused by the delay of erase_worker. After this patch applied, there must exist free PEBs in pool after one call of ubi_update_fastmap. Besides, this patch is a preparetion for fixing large erase counter in fastmap data block and fixing lapsed wear leveling for first 64 PEBs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Use free pebs reserved for bad block handlingZhihao Cheng1-11/+5
If new bad PEBs occur, UBI firstly consumes ubi->beb_rsvd_pebs, and then ubi->avail_pebs, finally UBI becomes read-only if above two items are 0, which means that the amount of PEBs for user volumes is not effected. Besides, UBI reserves count of free PBEs is ubi->beb_rsvd_pebs while filling wl pool or getting free PEBs, but ubi->avail_pebs is not reserved. So ubi->beb_rsvd_pebs and ubi->avail_pebs have nothing to do with the usage of free PEBs, UBI can use all free PEBs. Commit 78d6d497a648 ("UBI: Move fastmap specific functions out of wl.c") has removed beb_rsvd_pebs checking while filling pool. Now, don't reserve ubi->beb_rsvd_pebs while filling wl_pool. This will fill more PEBs in pool and also reduce fastmap updating frequency. Also remove beb_rsvd_pebs checking in ubi_wl_get_fm_peb. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: Replace erase_block() with sync_erase()Zhihao Cheng3-51/+7
Since erase_block() has same logic with sync_erase(), just replace it with sync_erase(), also rename 'sync_erase()' to 'ubi_sync_erase()'. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Allocate memory with GFP_NOFS in ubi_update_fastmapZhihao Cheng1-5/+5
Function ubi_update_fastmap could be called in IO context, for example: ubifs_writepage do_writepage ubifs_jnl_write_data write_head ubifs_wbuf_write_nolock ubifs_leb_write ubi_leb_write ubi_eba_write_leb try_write_vid_and_data ubi_wl_get_peb ubi_update_fastmap erase_block So it's better to allocate memory with GFP_NOFS mode, in case waiting page writeback(dead loop). Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: erase_block: Get erase counter from wl_entry rather than flashZhihao Cheng1-18/+9
Just like sync_erase() does, getting erase counter from wl_entry is faster than reading from flash. Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28ubi: fastmap: Fix missed ec updating after erasing old fastmap data blockZhihao Cheng1-10/+15
After running fsstress on ubifs for a long time, UBI(16384 blocks, fastmap takes 2 blocks) has an erase block with different erase counters displayed from two views: From ubiscan view: PEB 8031 has erase counter 31581 ========================================================= from to count min avg max --------------------------------------------------------- 0 .. 9: 0 0 0 0 10 .. 99: 0 0 0 0 100 .. 999: 16383 290 315 781 1000 .. 9999: 0 0 0 0 10000 .. 99999: 1 31581 31581 31581 100000 .. inf: 0 0 0 0 --------------------------------------------------------- Total : 16384 290 317 31581 From detailed_erase_block_info view: PEB 8031 has erase counter 7 physical_block_number erase_count 8030 421 8031 7 # mem info is different from disk info 8032 434 8033 425 8034 431 Following process missed updating erase counter in wl_entry(in memory): ubi_update_fastmap for (i = 1; i < new_fm->used_blocks; i++) // update fastmap data if (!tmp_e) if (old_fm && old_fm->e[i]) erase_block(ubi, old_fm->e[i]->pnum) ret = ubi_io_sync_erase(ubi, pnum, 0) ec = be64_to_cpu(ec_hdr->ec) ec += ret ec_hdr->ec = cpu_to_be64(ec) ubi_io_write_ec_hdr(ubi, pnum, ec_hdr) // ec is updated on flash // ec is not updated in old_fm->e[i] (in memory) Fix it by passing wl_enter into erase_block() and updating erase counter in erase_block(). Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2023-10-28mtd: block2mtd: Convert to bdev_open_by_dev/path()Jan Kara1-22/+29
Convert block2mtd to use bdev_open_by_dev() and bdev_open_by_path() and pass the handle around. CC: Joern Engel <joern@lazybastard.org> CC: linux-mtd@lists.infradead.org Acked-by: Christoph Hellwig <hch@lst.de> Acked-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230927093442.25915-12-jack@suse.cz Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-10-27mtd: cfi_cmdset_0001: Byte swap OTP infoLinus Walleij1-2/+18
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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231020-mtd-otp-byteswap-v4-1-0d132c06aa9d@linaro.org
2023-10-27mtd: rawnand: meson: check return value of devm_kasprintf()Yi Yang1-0/+3
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: 1e4d3ba66888 ("mtd: rawnand: meson: fix the clock") Signed-off-by: Yi Yang <yiyang13@huawei.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231019065548.318443-1-yiyang13@huawei.com
2023-10-27mtd: rawnand: intel: check return value of devm_kasprintf()Yi Yang1-0/+10
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: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Yi Yang <yiyang13@huawei.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231019065537.318391-1-yiyang13@huawei.com
2023-10-27mtd: rawnand: sh_flctl: Convert to module_platform_driver()Uwe Kleine-König1-1/+2
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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231016103540.1566865-2-u.kleine-koenig@pengutronix.de
2023-10-27Revert "nvmem: add new config option"Rafał Miłecki1-1/+0
This reverts commit 517f14d9cf3533d5ab4fded195ab6f80a92e378f. Config option "no_of_node" is no longer needed since adding a more explicit and targeted option "add_legacy_fixed_of_cells". That "no_of_node" config option was needed *earlier* to help mtd's case. DT nodes of MTD partitions (that are also NVMEM devices) may contain subnodes. Those SHOULD NOT be treated as NVMEM fixed cells. To prevent NVMEM core code from parsing subnodes a "no_of_node" option was added (and set to true in mtd) to make for_each_child_of_node() in NVMEM a no-op. That was a bit hacky because it was messing with "of_node" pointer to achieve some side-effect. With the introduction of "add_legacy_fixed_of_cells" config option things got more explicit. MTD subsystem simply tells NVMEM when to look for fixed cells and there is no need to hack "of_node" pointer anymore. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231023102759.31529-1-zajec5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-21nvmem: add explicit config option to read old syntax fixed OF cellsRafał Miłecki1-0/+2
Binding for fixed NVMEM cells defined directly as NVMEM device subnodes has been deprecated. It has been replaced by the "fixed-layout" NVMEM layout binding. New syntax is meant to be clearer and should help avoiding imprecise bindings. NVMEM subsystem already supports the new binding. It should be a good idea to limit support for old syntax to existing drivers that actually support & use it (we can't break backward compatibility!). That way we additionally encourage new bindings & drivers to ignore deprecated binding. It wasn't clear (to me) if rtc and w1 code actually uses old syntax fixed cells. I enabled them to don't risk any breakage. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> [for meson-{efuse,mx-efuse}.c] Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [for mtk-efuse.c, nvmem/core.c, nvmem-provider.h] Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [MT8192, MT8195 Chromebooks] Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [for microchip-otpc.c] Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> [SAMA7G5-EK] Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-20Merge tag 'mtd/fixes-for-6.6-rc7' of ↵Linus Torvalds9-5/+67
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "In the raw NAND subsystem, the major fix prevents using cached reads with devices not supporting it. There was two bug reports about this. Apart from that, three drivers (pl353, arasan and marvell) could sometimes hide page program failures due to their their own program page helper not being fully compliant with the specification (many drivers use the default helpers shared by the core). Adding a missing check prevents these situation. Finally, the Qualcomm driver had a broken error path. In the SPI-NAND subsystem one Micron device used a wrong bitmak reporting possibly corrupted ECC status. Finally, the physmap-core got stripped from its map_rom fallback by mistake, this feature is added back" * tag 'mtd/fixes-for-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: Ensure the nand chip supports cached reads mtd: rawnand: qcom: Unmap the right resource upon probe failure mtd: rawnand: pl353: Ensure program page operations are successful mtd: rawnand: arasan: Ensure program page operations are successful mtd: spinand: micron: correct bitmask for ecc status mtd: physmap-core: Restore map_rom fallback mtd: rawnand: marvell: Ensure program page operations are successful
2023-10-19mtd: parsers: ar7: remove supportWolfram Sang3-135/+0
AR7 is going to be removed from the Kernel, so remove its support for MTD. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-10-18mtd: spi-nor: micron-st: use SFDP table for mt25qu512aMamta Shukla1-3/+13
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.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2023-10-18mtd: spi-nor: micron-st: enable lock/unlock for mt25qu512aMamta Shukla1-0/+2
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: Mamta Shukla <mamta.shukla@leica-geosystems.com> Link: https://lore.kernel.org/r/20231017074711.12167-1-tudor.ambarus@linaro.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2023-10-16mtd: rawnand: Remove unused of_gpio.h inclusionAndy Shevchenko2-2/+0
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: Miquel Raynal <miquel.raynal@bootlin.com>
2023-10-16mtd: spinand: Add support for XTX XT26xxxDxxxxxBruce Suen1-0/+134
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=495 Signed-off-by: Bruce Suen <bruce_suen@163.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231012102412.10581-1-bruce_suen@163.com
2023-10-16mtd: spinand: winbond: add support for serial NAND flashSridharan S N1-0/+45
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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231012064134.4068621-1-quic_sridsn@quicinc.com
2023-10-16mtd: rawnand: cadence: Annotate struct cdns_nand_chip with __counted_byKees Cook1-1/+1
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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231006201734.work.060-kees@kernel.org
2023-10-16mtd: rawnand: Annotate struct mtk_nfc_nand_chip with __counted_byKees Cook1-1/+1
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: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231006201728.work.750-kees@kernel.org
2023-10-16mtd: spinand: add support for FORESEE F35SQA002GMartin Kurbanov3-1/+97
Add support for FORESEE F35SQA002G SPI NAND. Datasheet: https://www.longsys.com/uploads/LM-00006FORESEEF35SQA002GDatasheet_1650183701.pdf Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231002140458.147605-1-mmkurbanov@salutedevices.com
2023-10-16mtd: rawnand: rockchip: Use struct_size()Christophe JAILLET1-3/+2
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: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/481721c2c7fe570b4027dbe231d523961c953d5a.1696146232.git.christophe.jaillet@wanadoo.fr
2023-10-16mtd: rawnand: arasan: Include ECC syndrome along with in-band data while ↵Amit Kumar Mahapatra1-1/+1
checking for ECC failure 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: 88ffef1b65cf ("mtd: rawnand: arasan: Support the hardware BCH ECC engine") Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20230927055621.2906454-1-amit.kumar-mahapatra@amd.com
2023-10-16mtd: Use device_get_match_data()Rob Herring3-20/+12
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: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231009172923.2457844-1-robh@kernel.org
2023-10-16mtd: spi-nor: nxp-spifi: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-21-u.kleine-koenig@pengutronix.de
2023-10-16mtd: spi-nor: hisi-sfc: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-20-u.kleine-koenig@pengutronix.de
2023-10-16mtd: maps: sun_uflash: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-18-u.kleine-koenig@pengutronix.de
2023-10-16mtd: maps: sa1100-flash: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-17-u.kleine-koenig@pengutronix.de
2023-10-16mtd: maps: pxa2xx-flash: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-16-u.kleine-koenig@pengutronix.de
2023-10-16mtd: maps: plat-ram: Convert to platform remove callback returning voidUwe Kleine-König1-5/+3
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-15-u.kleine-koenig@pengutronix.de
2023-10-16mtd: maps: physmap-core: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-14-u.kleine-koenig@pengutronix.de
2023-10-16mtd: maps: lantiq-flash: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-13-u.kleine-koenig@pengutronix.de
2023-10-16mtd: lpddr2_nvm: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-12-u.kleine-koenig@pengutronix.de
2023-10-16mtd: hyperbus: rpc-if: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-11-u.kleine-koenig@pengutronix.de