Scrambling mode is enabled by value (1 << 19). NFC_CMD_SCRAMBLER_ENABLE
is already (1 << 19), so there is no need to shift it again in CMDRWGEN
macro.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Cc: <Stable@vger.kernel.org>
Fixes: 8fae856c53 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240210214551.441610-1-avkrasnov@salutedevices.com
The variable bbtblocks is being assigned a value that is never
read. The assignment is redundant and can be removed.
Cleans up clang scan build warning:
drivers/mtd/nand/raw/nand_bbt.c:579:3: warning: Value stored to
'bbtblocks' is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240209174019.3933233-1-colin.i.king@gmail.com
Encoding bitmask flags into offset worsen the code readability. The
erase type mask and flags should be stored in dedicated members. Also,
erase_map.uniform_erase_type can be removed as it is redundant.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Suggested-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/8e5e9e4081ed9f16ea9dce30693304a4b54d19b1.1708404584.git.Takahiro.Kuwano@infineon.com
[ta: remove spi_nor_region_end()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
As far as anybody can tell, this product never shipped. If it did,
it shipped in 2007 and nobody has access to one any more. Remove the
mtd NOR driver.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231208224703.1603264-2-willy@infradead.org
In two functions the variable timeo is being initialized with a value
that is never read, it is being re-assigned later on. The initializations
are redundant and can be removed.
Cleans up clang scan build warning:
warning: Value stored to 'timeo' during its initialization is never
read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240215140106.2062858-1-colin.i.king@gmail.com
mtd-ram can potentially be larger than 4GB. get_bitmask_order() uses
fls() that is not guaranteed to work with values larger than 32-bit.
Specifically on aarch64 fls() returns 0 when all 32 LSB bits are clear.
Use fls64() instead.
Fixes: ba32ce95cb ("mtd: maps: Merge gpio-addr-flash.c into physmap-core.c")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/9fbf3664ce00f8b07867f1011834015f21d162a5.1707388458.git.baruch@tkos.co.il
In an ideal world we would like UBI to be used where ever possible on a
NAND chip. And with UBI support in ARM Trusted Firmware and U-Boot it
is possible to achieve an (almost-)all-UBI flash layout. Hence the need
for a way to also use UBI volumes to store board-level constants, such
as MAC addresses and calibration data of wireless interfaces.
Add UBI volume NVMEM driver module exposing UBI volumes as NVMEM
providers. Allow UBI devices to have a "volumes" firmware subnode with
volumes which may be compatible with "nvmem-cells".
Access to UBI volumes via the NVMEM interface at this point is
read-only, and it is slow, opening and closing the UBI volume for each
access due to limitations of the NVMEM provider API.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
Look for the 'volumes' subnode of an MTD partition attached to a UBI
device and attach matching child nodes to UBI volumes.
This allows UBI volumes to be referenced in device tree, e.g. for use
as NVMEM providers.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
Introduce a new notification type UBI_VOLUME_SHUTDOWN to inform users
that a volume is just about to be removed.
This is needed because users (such as the NVMEM subsystem) expect that
at the time their removal function is called, the parenting device is
still available (for removal of sysfs nodes, for example, in case of
NVMEM which otherwise WARNs on volume removal).
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
Introduce device tree compatible 'linux,ubi' and attach compatible MTD
devices using the MTD add notifier. This is needed for a UBI device to
be available early at boot (and not only after late_initcall), so
volumes on them can be used eg. as NVMEM providers for other drivers.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
Use UBI_VOLUME_ADDED notification to create ubiblock device specified
on kernel cmdline or module parameter.
This makes thing more simple and has the advantage that ubiblock devices
on volumes which are not present at the time the ubi module is probed
will still be created.
Suggested-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
In the error handling path `out_acc` of `ubi_resize_volume()`,
when `pebs < 0`, it indicates that the volume table record failed to
update when the volume was shrunk. In this case, the number of `ubi->avail_pebs`
and `ubi->rsvd_pebs` should be restored to their previous values to prevent
the UBI layer from reporting an incorrect number of available PEBs.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
When using the ioctl interface to resize a UBI volume, `ubi_resize_volume`
resizes the EBA table first but does not change `vol->reserved_pebs` in
the same atomic context, which may cause concurrent access to the EBA table.
For example, when a user shrinks UBI volume A by calling `ubi_resize_volume`,
while another thread is writing to volume B and triggering wear-leveling,
which may call `ubi_write_fastmap`, under these circumstances, KASAN may
report a slab-out-of-bounds error in `ubi_eba_get_ldesc+0xfb/0x130`.
This patch fixes race conditions in `ubi_resize_volume` and
`ubi_update_fastmap` to avoid out-of-bounds reads of `eba_tbl`. First,
it ensures that updates to `eba_tbl` and `reserved_pebs` are protected
by `vol->volumes_lock`. Second, it implements a rollback mechanism in case
of resize failure. It is also worth mentioning that for volume shrinkage
failures, since part of the volume has already been shrunk and unmapped,
there is no need to recover `{rsvd/avail}_pebs`.
==================================================================
BUG: KASAN: slab-out-of-bounds in ubi_eba_get_ldesc+0xfb/0x130 [ubi]
Read of size 4 at addr ffff88800f43f570 by task kworker/u16:0/7
CPU: 0 PID: 7 Comm: kworker/u16:0 Not tainted 5.16.0-rc7 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: writeback wb_workfn (flush-ubifs_0_0)
Call Trace:
<TASK>
dump_stack_lvl+0x4d/0x66
print_address_description.constprop.0+0x41/0x60
kasan_report.cold+0x83/0xdf
ubi_eba_get_ldesc+0xfb/0x130 [ubi]
ubi_update_fastmap.cold+0x60f/0xc7d [ubi]
ubi_wl_get_peb+0x25b/0x4f0 [ubi]
try_write_vid_and_data+0x9a/0x4d0 [ubi]
ubi_eba_write_leb+0x7e4/0x17d0 [ubi]
ubi_leb_map+0x1a0/0x2c0 [ubi]
ubifs_leb_map+0x139/0x270 [ubifs]
ubifs_add_bud_to_log+0xb40/0xf30 [ubifs]
make_reservation+0x86e/0xb00 [ubifs]
ubifs_jnl_write_data+0x430/0x9d0 [ubifs]
do_writepage+0x1d1/0x550 [ubifs]
ubifs_writepage+0x37c/0x670 [ubifs]
__writepage+0x67/0x170
write_cache_pages+0x259/0xa90
do_writepages+0x277/0x5d0
__writeback_single_inode+0xb8/0x850
writeback_sb_inodes+0x4b3/0xb20
__writeback_inodes_wb+0xc1/0x220
wb_writeback+0x59f/0x740
wb_workfn+0x6d0/0xca0
process_one_work+0x711/0xfc0
worker_thread+0x95/0xd00
kthread+0x3a6/0x490
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 711:
kasan_save_stack+0x1e/0x50
__kasan_kmalloc+0x81/0xa0
ubi_eba_create_table+0x88/0x1a0 [ubi]
ubi_resize_volume.cold+0x175/0xae7 [ubi]
ubi_cdev_ioctl+0x57f/0x1a60 [ubi]
__x64_sys_ioctl+0x13a/0x1c0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Last potentially related work creation:
kasan_save_stack+0x1e/0x50
__kasan_record_aux_stack+0xb7/0xc0
call_rcu+0xd6/0x1000
blk_stat_free_callback+0x28/0x30
blk_release_queue+0x8a/0x2e0
kobject_put+0x186/0x4c0
scsi_device_dev_release_usercontext+0x620/0xbd0
execute_in_process_context+0x2f/0x120
device_release+0xa4/0x240
kobject_put+0x186/0x4c0
put_device+0x20/0x30
__scsi_remove_device+0x1c3/0x300
scsi_probe_and_add_lun+0x2140/0x2eb0
__scsi_scan_target+0x1f2/0xbb0
scsi_scan_channel+0x11b/0x1a0
scsi_scan_host_selected+0x24c/0x310
do_scsi_scan_host+0x1e0/0x250
do_scan_async+0x45/0x490
async_run_entry_fn+0xa2/0x530
process_one_work+0x711/0xfc0
worker_thread+0x95/0xd00
kthread+0x3a6/0x490
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88800f43f500
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 112 bytes inside of
128-byte region [ffff88800f43f500, ffff88800f43f580)
The buggy address belongs to the page:
page:ffffea00003d0f00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xf43c
head:ffffea00003d0f00 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 001fffff80010200 ffffea000046ba08 ffffea0000457208 ffff88810004d1c0
raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88800f43f400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800f43f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88800f43f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc
^
ffff88800f43f580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800f43f600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
The following steps can used to reproduce:
Process 1: write and trigger ubi wear-leveling
ubimkvol /dev/ubi0 -s 5000MiB -N v1
ubimkvol /dev/ubi0 -s 2000MiB -N v2
ubimkvol /dev/ubi0 -s 10MiB -N v3
mount -t ubifs /dev/ubi0_0 /mnt/ubifs
while true;
do
filename=/mnt/ubifs/$((RANDOM))
dd if=/dev/random of=${filename} bs=1M count=$((RANDOM % 1000))
rm -rf ${filename}
sync /mnt/ubifs/
done
Process 2: do random resize
struct ubi_rsvol_req req;
req.vol_id = 1;
req.bytes = (rand() % 50) * 512KB;
ioctl(fd, UBI_IOCRSVOL, &req);
V3:
- Fix the commit message error.
V2:
- Add volumes_lock in ubi_eba_copy_leb() to avoid race caused by
updating eba_tbl.
V1:
- Rebase the patch on the latest mainline.
Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Now that the calculation of fastmap size in ubi_calc_fm_size() is
incorrect since it miss each user volume's ubi_fm_eba structure and the
Internal UBI volume info. Let's correct the calculation.
Cc: stable@vger.kernel.org
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
If the LEB size is smaller than a volume table record we cannot
have volumes.
In this case abort attaching.
Cc: Chenyuan Yang <cy54@illinois.edu>
Cc: stable@vger.kernel.org
Fixes: 801c135ce7 ("UBI: Unsorted Block Images")
Reported-by: Chenyuan Yang <cy54@illinois.edu>
Closes: https://lore.kernel.org/linux-mtd/1433EB7A-FC89-47D6-8F47-23BE41B263B3@illinois.edu/
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Pass the few limits ubiblock imposes directly to blk_mq_alloc_disk
instead of setting them one at a time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20240215070300.2200308-15-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Pass the few limits mtd_blkdevs imposes directly to blk_mq_alloc_disk
instead of setting them one at a time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20240215070300.2200308-14-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Pass a queue_limits to blk_mq_alloc_disk and apply it if non-NULL. This
will allow allocating queues with valid queue limits instead of setting
the values one at a time later.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20240213073425.1621680-11-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
In commit 8caab75fd2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/38bf50b391c117621e406fa8cd00c4daef78615c.1707324794.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The check in nand_base.c, nand_scan_tail() : has the following code:
(ecc->steps * ecc->size != mtd->writesize) which fails for some NAND chips.
Remove ECC entries in this driver which are not integral multiplications,
and adjust the number of chunks for entries which fails the above
calculation so it will calculate correctly (this was previously done
automatically before the check and was removed in a later commit).
Fixes: 68c18dae68 ("mtd: rawnand: marvell: add missing layouts")
Cc: stable@vger.kernel.org
Signed-off-by: Elad Nachman <enachman@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
According to the datasheets, the ESMT chips in question will return a 5
byte long identification code where the last 3 bytes are the JEDEC
continuation codes (7Fh). Although, I would have expected 4 continuation
codes as Powerchip Semiconductor (C8h, corresponding to the parameter
page data) is located in bank 5 of the JEDEC database.
By matching the full 5 bytes we can avoid clashes with GigaDevice NAND
flashes.
This fix allows the MT7688-based GARDENA smart Gateway to boot again.
Fixes: aa08bf187f ("mtd: spinand: esmt: add support for F50D2G41KA")
Signed-off-by: Ezra Buehler <ezra.buehler@husqvarnagroup.com>
Reviewed-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
Tested-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-3-ezra@easyb.ch
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/b7ee7d1b-49a2-41d8-9c8f-3674f1aecc43@web.de
The kfree() function was called in one case by
the ssfdcr_add_mtd() function during error handling
even if the passed data structure member contained a null pointer.
This issue was detected by using the Coccinelle software.
Thus use another label.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/56d92e42-db9e-4767-bcb1-9686bdf34a03@web.de
If during probe fsl_lbc_ctrl_dev is NULL that might just be because the
fsl_lbc driver didn't bind yet. So return -EPROBE_DEFER in this case to
make the driver core retry probing later.
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/20240115141245.3415035-2-u.kleine-koenig@pengutronix.de
Under normal conditions, the loop goes over all child partitions, and
'breaks' when the relevant partition is found. In this case we get a
reference to the partition node without ever releasing it. Indeed, right
after the mtd_check_of_node() function returns, we call of_node_get()
again over this very same node. It is probably safer to keep the
counters even in this helper and call of_node_put() before break-ing.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Closes: https://lore.kernel.org/r/202312250546.ISzglvM2-lkp@intel.com/
Cc: Christian Marangi <ansuelsmth@gmail.com>
Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240104081446.126540-1-miquel.raynal@bootlin.com
Some GigaDevice ecc_get_status functions use on-stack buffer for
spi_mem_op causes spi_mem_check_op failing, fix the issue by using
spinand scratchbuf.
Fixes: c40c7a990a ("mtd: spinand: Add support for GigaDevice GD5F1GQ4UExxG")
Signed-off-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231108150701.593912-1-han.xu@nxp.com
UBI:
- Use in-tree fault injection framework and add new injection types
- Fix for a memory leak in the block driver
UBIFS:
- kernel-doc fixes
- Various minor fixes
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEdgfidid8lnn52cLTZvlZhesYu8EFAmWi8k0WHHJpY2hhcmRA
c2lnbWEtc3Rhci5hdAAKCRBm+VmF6xi7wVMEEAClpCwGQ1zjViuDR+ly1etpd2VJ
SVH687jQ5bj92joMbJuX1n3iucDKu22KNR6tuePtEWousKEjiP5MU5Vhj4qcEZJj
ORwtLOhchF7EHokJ16O2zBTBjznQuSmy0TG8vB/4hKj1a9FHLYPoDpZ595i2ATIA
sh4+jfTRiOviX1SWe3qP9Hwx/WBXJpNluNNosabaEkTPe6CEAqnw92Hsm8PC8WY0
0F9zKPbRTiu/Mt8PoF0YHo9pNsX0TikJMPj+QuBSOt3tK5PmPFttL6ce5Zal+wi3
Df+8Qqw2QPchMDesaeZHtknZkZWbxtWPk+1U7EaLUwb6lw7cyI9SPWtQFYS4Ot6r
ieUW5mQt2arC6Yjj1u+pFLIvLJOYgg0kiPySvRiA4EKkAyTMBjQzeyf0XCVrgW2s
UeBiQTz5LkL4soAo/aWDyny81RXJjtuMpn/+WAq4o36LZkG4aiGXh+ue5l5d9Mq5
Fh/MNyRA9le5STebrqqH7TBtiOwBG+ZJ9yqYffzya+756od6wsnemGfaZ/pPzzSe
sp9MEYzrz4hhRvDHegKcIbxb+OUVFNJ1t5gdIUsZAqWARxcfYD9xeqyHVVhvFDjf
UzQhZXfKgdnwp4zWHtSBRkDKCEMvxG8Nw3Rnp9ayZwxiQBBalRV6MV33g5RXRIis
Xp+fCRu3gjlhBzlU6w==
=5I24
-----END PGP SIGNATURE-----
Merge tag 'ubifs-for-linus-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs
Pull UBI and UBIFS updates from Richard Weinberger:
"UBI:
- Use in-tree fault injection framework and add new injection types
- Fix for a memory leak in the block driver
UBIFS:
- kernel-doc fixes
- Various minor fixes"
* tag 'ubifs-for-linus-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs:
ubi: block: fix memleak in ubiblock_create()
ubifs: fix kernel-doc warnings
mtd: Add several functions to the fail_function list
ubi: Reserve sufficient buffer length for the input mask
ubi: Add six fault injection type for testing
ubi: Split io_failures into write_failure and erase_failure
ubi: Use the fault injection framework to enhance the fault injection capability
ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
ubifs: Check @c->dirty_[n|p]n_cnt and @c->nroot state under @c->lp_mutex
ubifs: describe function parameters
ubifs: auth.c: fix kernel-doc function prototype warning
ubifs: use crypto_shash_tfm_digest() in ubifs_hmac_wkm()
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmWcIOIQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpn6hD/9oO7U75PuxUwYYHZ9Uzxpw6gQ0LEmeyJmE
NQYCkfYHVq3IsgOdF7elI9v3qtr6v8V8CdB7cByrnn3DgwsMuiTKZZ0dK7vH37PO
DX+/xn349e8oH7RdRo7f3m95g1YbHfpfnj0Rc4mjTDV72Jr/HlLTVgGTQg8DEnCR
wBIFmeuBHHgeeLh87gsWLAP7ReReiy9V1uqpDFsko2/4BxRAM/8eedkwcAxD8aEy
rd+dT/SBQj2cOdQMUeExT3gWjwzHh6ZHx3f1WCLK5fdck6BogH2hBUeri6F/H98L
HoaXjBZYBTH68hB/mnO5I4g1ZlrVM74Vp7JPa3e1SFFtyEi6lsyrk2J3GoNh0E7r
pXqH5kAcaJwBsBrbRGuvEyGbn9RLTaN5Gvseud0VE4oMruyodTniQaHXuIGackgz
sMavMho4486EUWPaF7gIBdLNK1hO13w+IDZ4+3oBxhudMqdgZbk4iYpOCqQ7QY5G
2vkzAE/sZ+aVNXeaIQOI8dE5clBy8gJ+6+t8dm3DY1r1xdbcnU40iZ8/fri3h69r
vHs9bpQnVWZF0gEyEflY1pkcAPpIkvMmWCR7Ehy5YCkIfa+qfSL05o3dicpWovLP
N+gCtpkhTK2AvmUWsUMypMLRvoSOImyCIiobrr3qNBaUdgRP8xKfUa72RuRp8cGl
Vrj5oAiE3w==
=YAfp
-----END PGP SIGNATURE-----
Merge tag 'for-6.8/block-2024-01-08' of git://git.kernel.dk/linux
Pull block updates from Jens Axboe:
"Pretty quiet round this time around. This contains:
- NVMe updates via Keith:
- nvme fabrics spec updates (Guixin, Max)
- nvme target udpates (Guixin, Evan)
- nvme attribute refactoring (Daniel)
- nvme-fc numa fix (Keith)
- MD updates via Song:
- Fix/Cleanup RCU usage from conf->disks[i].rdev (Yu Kuai)
- Fix raid5 hang issue (Junxiao Bi)
- Add Yu Kuai as Reviewer of the md subsystem
- Remove deprecated flavors (Song Liu)
- raid1 read error check support (Li Nan)
- Better handle events off-by-1 case (Alex Lyakas)
- Efficiency improvements for passthrough (Kundan)
- Support for mapping integrity data directly (Keith)
- Zoned write fix (Damien)
- rnbd fixes (Kees, Santosh, Supriti)
- Default to a sane discard size granularity (Christoph)
- Make the default max transfer size naming less confusing
(Christoph)
- Remove support for deprecated host aware zoned model (Christoph)
- Misc fixes (me, Li, Matthew, Min, Ming, Randy, liyouhong, Daniel,
Bart, Christoph)"
* tag 'for-6.8/block-2024-01-08' of git://git.kernel.dk/linux: (78 commits)
block: Treat sequential write preferred zone type as invalid
block: remove disk_clear_zoned
sd: remove the !ZBC && blk_queue_is_zoned case in sd_read_block_characteristics
drivers/block/xen-blkback/common.h: Fix spelling typo in comment
blk-cgroup: fix rcu lockdep warning in blkg_lookup()
blk-cgroup: don't use removal safe list iterators
block: floor the discard granularity to the physical block size
mtd_blkdevs: use the default discard granularity
bcache: use the default discard granularity
zram: use the default discard granularity
null_blk: use the default discard granularity
nbd: use the default discard granularity
ubd: use the default discard granularity
block: default the discard granularity to sector size
bcache: discard_granularity should not be smaller than a sector
block: remove two comments in bio_split_discard
block: rename and document BLK_DEF_MAX_SECTORS
loop: don't abuse BLK_DEF_MAX_SECTORS
aoe: don't abuse BLK_DEF_MAX_SECTORS
null_blk: don't cap max_hw_sectors to BLK_DEF_MAX_SECTORS
...
Apart from preventing the mtdblk to run on top of ftl or ubiblk (which
may cause security issues and has no meaning anyway), there are a few
misc fixes.
* Raw NAND
Two meaningful changes this time. The conversion of the brcmnand driver
to the ->exec_op() API, this series brought additional changes to the
core in order to help controller drivers to handle themselves the WP pin
during destructive operations when relevant.
There is also a series bringing important fixes to the sequential read
feature.
As always, there is as well a whole bunch of miscellaneous W=1 fixes,
together with a few runtime fixes (double free, timeout value, OOB
layout, missing register initialization) and the usual load of remove
callbacks turned into void (which led to switch the txx9ndfmc driver to
use module_platform_driver()).
* SPI NOR
SPI NOR comes with die erase support for multi die flashes, with new
octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an updated
documentation about what the contributors shall consider when proposing
flash additions or updates.
Michael Walle stepped out from the reviewer role to maintainer.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmWFeUsACgkQJWrqGEe9
VoSBzQgAsUDieAMF4zIo5QN6l+8DpDMrkOK1Z5l4B/3goA2ZUz4cs80Kj/53l/kO
tD8Ckn5SA82ZrVZiCJS5D8yplB+4+IWFU9dV/TcoINafLew5R/bBqo4XwgfVgvwy
a4PuFlV9eedDW18cfbZA29TsnKoWdGaWxsyY+Gceukm94VuQbaZIPs3wkmBdWEOM
V+FZaWg7vLW99x2XFDNpBqKFSzjTPAt1W5WM2ASdrb3pSKVOlt02qFlvMFwodVeR
YExYwd1BNNsn9I6lKF/07a5wdX4NygXzqIpYytIaTzeBV3iRgN59uMfWbOh6tHeu
MOEnmWoc3RwsyBXlBTKGafk2DTB6zg==
=gbYM
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd updates from Miquel Raynal:
"MTD:
- Apart from preventing the mtdblk to run on top of ftl or ubiblk
(which may cause security issues and has no meaning anyway), there
are a few misc fixes.
Raw NAND:
- Two meaningful changes this time. The conversion of the brcmnand
driver to the ->exec_op() API, this series brought additional
changes to the core in order to help controller drivers to handle
themselves the WP pin during destructive operations when relevant.
- There is also a series bringing important fixes to the sequential
read feature.
- As always, there is as well a whole bunch of miscellaneous W=1
fixes, together with a few runtime fixes (double free, timeout
value, OOB layout, missing register initialization) and the usual
load of remove callbacks turned into void (which led to switch the
txx9ndfmc driver to use module_platform_driver()).
SPI NOR:
- SPI NOR comes with die erase support for multi die flashes, with
new octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an
updated documentation about what the contributors shall consider
when proposing flash additions or updates.
- Michael Walle stepped out from the reviewer role to maintainer"
* tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (39 commits)
mtd: rawnand: Clarify conditions to enable continuous reads
mtd: rawnand: Prevent sequential reads with on-die ECC engines
mtd: rawnand: Fix core interference with sequential reads
mtd: rawnand: Prevent crossing LUN boundaries during sequential reads
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
dt-bindings: mtd: partitions: u-boot: Fix typo
mtd: rawnand: s3c2410: fix Excess struct member description kernel-doc warnings
MAINTAINERS: change my mail to the kernel.org one
mtd: spi-nor: sfdp: get the 1-1-8 and 1-8-8 protocol from SFDP
mtd: spi-nor: drop superfluous debug prints
mtd: spi-nor: sysfs: hide the flash name if not set
mtd: spi-nor: mark the flash name as obsolete
mtd: spi-nor: print flash ID instead of name
mtd: maps: vmu-flash: Fix the (mtd core) switch to ref counters
mtd: ssfdc: Remove an unused variable
mtd: rawnand: diskonchip: fix a potential double free in doc_probe
mtd: rawnand: rockchip: Add missing title to a kernel doc comment
mtd: rawnand: rockchip: Rename a structure
mtd: rawnand: pl353: Fix kernel doc
mtd: spi-nor: micron-st: Add support for mt25qu01g
...
If idr_alloc() fails, dev->gd will be put after goto out_cleanup_disk in
ubiblock_create(), but dev->gd has not been assigned yet at this time, and
'gd' will not be put anymore. Fix it by putting 'gd' directly.
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
add mtd_read(), mtd_write(), mtd_erase(), mtd_block_markbad() to
fail_function list for testing purpose
- Specify the function to inject the fault
echo mtd_read > /sys/kernel/debug/fail_function/inject
- Specifies the return value of the function to inject the fault
printf %#x -12 > /sys/kernel/debug/fail_function/mtd_read/retval
- Specify other fault injection configuration parameters.
echo -1 > /sys/kernel/debug/fail_function/times
echo 100 > /sys/kernel/debug/fail_function/probability
echo 15 > /sys/kernel/debug/fail_function/space
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Because the mask received by the emulate_failures interface
is a 32-bit unsigned integer, ensure that there is sufficient
buffer length to receive and display this value.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
This commit adds six fault injection type for testing to cover the
abnormal path of the UBI driver.
Inject the following faults when the UBI reads the LEB:
+----------------------------+-----------------------------------+
| Interface name | emulate behavior |
+----------------------------+-----------------------------------+
| emulate_eccerr | ECC error |
+----------------------------+-----------------------------------+
| emulate_read_failure | read failure |
|----------------------------+-----------------------------------+
| emulate_io_ff | read content as all FF |
|----------------------------+-----------------------------------+
| emulate_io_ff_bitflips | content FF with MTD err reported |
+----------------------------+-----------------------------------+
| emulate_bad_hdr | bad leb header |
|----------------------------+-----------------------------------+
| emulate_bad_hdr_ebadmsg | bad header with ECC err |
+----------------------------+-----------------------------------+
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
The emulate_io_failures debugfs entry controls both write
failure and erase failure. This patch split io_failures
to write_failure and erase_failure.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
To make debug parameters configurable at run time, use the
fault injection framework to reconstruct the debugfs interface,
and retain the legacy fault injection interface.
Now, the file emulate_failures and fault_attr files control whether
to enable fault emmulation.
The file emulate_failures receives a mask that controls type and
process of fault injection. Generally, for ease of use, you can
directly enter a mask with all 1s.
echo 0xffff > /sys/kernel/debug/ubi/ubi0/emulate_failures
And you need to configure other fault-injection capabilities for
testing purpose:
echo 100 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/probability
echo 15 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/space
echo 2 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/verbose
echo -1 > /sys/kernel/debug/ubi/fault_inject/emulate_power_cut/times
The CONFIG_MTD_UBI_FAULT_INJECTION to enable the Fault Injection is
added to kconfig.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
The discard granularity now defaults to a single sector, so don't set
that value explicitly.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Richard Weinberger <richard@nod.at>
Link: https://lore.kernel.org/r/20231228075545.362768-10-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The most meaningful change being the conversion of the brcmnand driver
to the ->exec_op() API, this series brought additional changes to the
core in order to help controller drivers to handle themselves the WP pin
during destructive operations when relevant.
As always, there is as well a whole bunch of miscellaneous W=1 fixes,
together with a few runtime fixes (double free, timeout value, OOB
layout, missing register initialization) and the usual load of remove
callbacks turned into void (which led to switch the txx9ndfmc driver to
use module_platform_driver()).
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmWCs3IACgkQJWrqGEe9
VoTmRAf/XkCofpATQRzhvFFQXZhCNP/EAKnRM2Ubc7rnwscVWNX/0XyvN7wyy185
tYoJf/MuFFwLEsXz05EU+PDQKr3t2QGCRhxL/ATIIVeQUAJtNqrpkg+f0m+PX2+D
upCmhqS+uBpD4X67K59pi4qBtRCDC1uuenZgWF+7oNfJmvHIx9aF5+wgEZGv3TaC
3WZ9kNb+BcM0TuTxQYC/ehHMsN1dF7zpUUVj4cz++ZnBrQIZx2SwROiAb7MUxkLE
9QCsoBhurDGwF7CRULEm92AQ1SdFD3r0fsv+Y3+YVY+YTJCXnYR33qJuoRgqUaz1
y5ZwCRbkB2AOuP1k1cMyo/hqy7rECw==
=nfPx
-----END PGP SIGNATURE-----
Merge tag 'nand/for-6.8' into mtd/next
* Raw NAND
The most meaningful change being the conversion of the brcmnand driver
to the ->exec_op() API, this series brought additional changes to the
core in order to help controller drivers to handle themselves the WP pin
during destructive operations when relevant.
As always, there is as well a whole bunch of miscellaneous W=1 fixes,
together with a few runtime fixes (double free, timeout value, OOB
layout, missing register initialization) and the usual load of remove
callbacks turned into void (which led to switch the txx9ndfmc driver to
use module_platform_driver()).
octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an updated
documentation about what the contributors shall consider when proposing
flash additions or updates. Michael Walle stepped out from the reviewer
role to maintainer.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEHUIqys8OyG1eHf7fS1VPR6WNFOkFAmWD2u0ACgkQS1VPR6WN
FOnX4wgAoWAHaoGjY6adQirIf+vdO7fgwsDU6mNp3ynTAbUQeke/Kd+cleotV1Hv
Iz8HvWZdYni1lCEKJaUiFbBniSAuY0YwAYko+KzZRF5mmqx6MBXbGBYU8Nf+tODq
SxvmjoGc/Au82SUDm7ZbgNsn3pI7RoqpF93qWUOibFfcYU5kbPDsV2Vmazi5nrDM
4gLvRMaXzY/28GHDEg6MZ+ZLKy37iZ0hlr3qARFbxCzLJqensSh8wlAwVl1rb49G
GcSYXh9aW6JAIWa+wU5eJjnpUxl6YRQtkMjHZS0s9CUkCq5/4ZDA7MXNCum8wEPQ
tAQ7HTecw1jJbyiKrPdPNR/aqBwJYg==
=AprT
-----END PGP SIGNATURE-----
Merge tag 'spi-nor/for-6.8' into mtd/next
SPI NOR comes with die erase support for multi die flashes, with new
octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an updated
documentation about what the contributors shall consider when proposing
flash additions or updates. Michael Walle stepped out from the reviewer
role to maintainer.
The current logic is probably fine but is a bit convoluted. Plus, we
don't want partial pages to be part of the sequential operation just in
case the core would optimize the page read with a subpage read (which
would break the sequence). This may happen on the first and last page
only, so if the start offset or the end offset is not aligned with a
page boundary, better avoid them to prevent any risk.
Cc: stable@vger.kernel.org
Fixes: 003fe4b954 ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-5-miquel.raynal@bootlin.com
Some devices support sequential reads when using the on-die ECC engines,
some others do not. It is a bit hard to know which ones will break other
than experimentally, so in order to avoid such a difficult and painful
task, let's just pretend all devices should avoid using this
optimization when configured like this.
Cc: stable@vger.kernel.org
Fixes: 003fe4b954 ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-4-miquel.raynal@bootlin.com
A couple of reports pointed at some strange failures happening a bit
randomly since the introduction of sequential page reads support. After
investigation it turned out the most likely reason for these issues was
the fact that sometimes a (longer) read might happen, starting at the
same page that was read previously. This is optimized by the raw NAND
core, by not sending the READ_PAGE command to the NAND device and just
reading out the data in a local cache. When this page is also flagged as
being the starting point for a sequential read, it means the page right
next will be accessed without the right instructions. The NAND chip will
be confused and will not output correct data. In order to avoid such
situation from happening anymore, we can however handle this case with a
bit of additional logic, to postpone the initialization of the read
sequence by one page.
Reported-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Closes: https://lore.kernel.org/linux-mtd/CAP1tNvS=NVAm-vfvYWbc3k9Cx9YxMc2uZZkmXk8h1NhGX877Zg@mail.gmail.com/
Reported-by: Måns Rullgård <mans@mansr.com>
Closes: https://lore.kernel.org/linux-mtd/yw1xfs6j4k6q.fsf@mansr.com/
Reported-by: Martin Hundebøll <martin@geanix.com>
Closes: https://lore.kernel.org/linux-mtd/9d0c42fcde79bfedfe5b05d6a4e9fdef71d3dd52.camel@geanix.com/
Fixes: 003fe4b954 ("mtd: rawnand: Support for sequential cache reads")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-3-miquel.raynal@bootlin.com
The ONFI specification states that devices do not need to support
sequential reads across LUN boundaries. In order to prevent such event
from happening and possibly failing, let's introduce the concept of
"pause" in the sequential read to handle these cases. The first/last
pages remain the same but any time we cross a LUN boundary we will end
and restart (if relevant) the sequential read operation.
Cc: stable@vger.kernel.org
Fixes: 003fe4b954 ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-2-miquel.raynal@bootlin.com
If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
‘gluebi->desc’ in gluebi_read().
ubi_gluebi_init
ubi_register_volume_notifier
ubi_enumerate_volumes
ubi_notify_all
gluebi_notify nb->notifier_call()
gluebi_create
mtd_device_register
mtd_device_parse_register
add_mtd_device
blktrans_notify_add not->add()
ftl_add_mtd tr->add_mtd()
scan_header
mtd_read
mtd_read_oob
mtd_read_oob_std
gluebi_read mtd->read()
gluebi->desc - NULL
Detailed reproduction information available at the Link [1],
In the normal case, obtain gluebi->desc in the gluebi_get_device(),
and access gluebi->desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.
The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME.
Fixes: 2ba3d76a1e ("UBI: make gluebi a separate module")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1]
Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@nod.at/ [2]
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@huawei.com
BFPT 17th DWORD contains the information about 1-1-8 and 1-8-8.
Parse BFPT DWORD[17] instruction to determine whether flash
supports 1-1-8 and 1-8-8, and set its dummy cycles accordingly.
Validated only the 1-1-8 read using a macronix flash with
Xilinx board zynq-picozed.
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20231219102103.92738-2-jaimeliao.tw@gmail.com
[ta: update commit message, get rid of extra dereference]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The mtd data shall be obtained with the mtd ioctls or with
new debugfs entries if one cares. Drop the debug prints.
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231215082138.16063-5-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash name is not reliable as we saw flash ID collisions.
Hide the flash name if not set.
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Reviewed-by: Michael Walle <michael@walle.cc>
[ta: update commit subject and description and the sysfs description]
Link: https://lore.kernel.org/r/20231215082138.16063-4-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
We saw flash ID collisions which make the flash name unreliable. Print
the manufacturer and device ID instead of the flash name.
Lower the print to dev_dbg to stop polluting the kernel log.
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231215082138.16063-2-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
When nand_scan() fails, it has cleaned up related resources
in its error paths. Therefore, the following nand_cleanup()
may lead to a double-free. One possible trace is:
doc_probe
|-> nand_scan
| |-> nand_scan_with_ids
| |-> nand_scan_tail
| |-> kfree(chip->data_buf) [First free]
|
|-> nand_cleanup
|-> kfree(chip->data_buf) [Double free here]
Fix this by removing nand_cleanup() on failure of
nand_scan().
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231214072946.10285-1-dinghao.liu@zju.edu.cn
Robots are unhappy with the ecc_cnt_status structure because the kernel
doc says it should be called rk_ecc_cnt_status. In general, it is
considered a better practice to prefix all symbols in a file with the
same prexif, and thus it seems more relevant to rename the structure
rather than changing the kernel doc header.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312102130.geZ4dqyN-lkp@intel.com/
Fixes: 058e0e847d ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231211150704.109138-1-miquel.raynal@bootlin.com
JESD216 mentions die erase, but does not provide an opcode for it.
Check BFPT dword 11, bits 30:24, "Chip Erase, Typical time", it says:
"Typical time to erase one chip (die). User must poll device busy to
determine if the operation has completed. For a device consisting of
multiple dies, that are individually accessed, the time is for each die
to which a chip erase command is applied."
So when a flash consists of a single die, this is the erase time for the
full chip (die) erase, and when it consists of multiple dies, it's the
die erase time. Chip and die are the same thing.
Add support for die erase. For now, benefit of the die erase when addr
and len are aligned with die size. This could be improved however for
the uniform and non-uniform erases cases to use the die erase when
possible. For example if one requests that an erase of a 2 die device
starting from the last 64KB of the first die to the end of the flash
size, we could use just 2 commands, a 64KB erase and a die erase.
This improvement is left as an exercise for the reader.
Tested-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20231125123529.55686-2-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
exec_op implementation for Broadcom STB, Broadband and iProc SoC
This adds exec_op and removes the legacy interface. Based on changes
proposed by Boris Brezillon.
Link: 4ec6f8d8d8
Link: 11b4acffd7
Signed-off-by: David Regan <dregan@broadcom.com>
[Miquel Raynal: Misc style fixes]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231125012438.15191-4-dregan@broadcom.com
Pass host struct to bcmnand_ctrl_poll_status instead of ctrl struct
since real time status requires host, and ctrl is a member of host.
Real time status is required for low level commands vs cached status
since the NAND controller will not do an automatic status read at the
end of a low level command as it would with a high level command.
Signed-off-by: David Regan <dregan@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231125012438.15191-3-dregan@broadcom.com
Allow NAND controller to be responsible for write protect pin
handling during fast path and exec_op destructive operation
when controller_wp flag is set.
Signed-off-by: David Regan <dregan@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231125012438.15191-2-dregan@broadcom.com
Erase and program operations need the write protect (wp) pin to be
de-asserted to take effect. Add the concept of destructive
operation and pass the information to exec_op() so controllers know
when they should de-assert this pin without having to decode
the command opcode.
Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
Signed-off-by: David Regan <dregan@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231125012438.15191-1-dregan@broadcom.com
When the software reset command isn't supported, we now stop reporting
the warning message to avoid unnecessary warnings and potential confusion.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20231129064311.272422-2-acelan.kao@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit updates the SPI subsystem, particularly affecting "SPI MEM"
drivers and core parts, by replacing the -ENOTSUPP error code with
-EOPNOTSUPP.
The key motivations for this change are as follows:
1. The spi-nor driver currently uses EOPNOTSUPP, whereas calls to spi-mem
might return ENOTSUPP. This update aims to unify the error reporting
within the SPI subsystem for clarity and consistency.
2. The use of ENOTSUPP has been flagged by checkpatch as inappropriate,
mainly being reserved for NFS-related errors. To align with kernel coding
standards and recommendations, this change is being made.
3. By using EOPNOTSUPP, we provide more specific context to the error,
indicating that a particular operation is not supported. This helps
differentiate from the more generic ENOTSUPP error, allowing drivers to
better handle and respond to different error scenarios.
Risks and Considerations:
While this change is primarily intended as a code cleanup and error code
unification, there is a minor risk of breaking user-space applications
that rely on specific return codes for unsupported operations. However,
this risk is considered low, as such use-cases are unlikely to be common
or critical. Nevertheless, developers and users should be aware of this
change, especially if they have scripts or tools that specifically handle
SPI error codes.
This commit does not introduce any functional changes to the SPI subsystem
or the affected drivers.
Signed-off-by: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231129064311.272422-1-acelan.kao@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In case of MTD_OPS_AUTO_OOB mode, MTD/NAND layer fills/reads OOB buffer
according current OOB layout so we need to follow it in the driver.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231109053953.3863664-1-avkrasnov@salutedevices.com
Clock register must be also initialized during controller probing. If
this is not performed (for example by bootloader before) - controller
will not work.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231120064239.3304108-1-avkrasnov@salutedevices.com
Under heavy load it is likely that the controller is done
with its own task but the thread unlocking the wait is not
scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the
controller to respond within allowable timeslice of 1 sec.
fsl,ifc-nand 7e800000.nand: Controller is not responding
[<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a)
[<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c)
[<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c)
[<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
Fixes: 82771882d9 ("NAND Machine support for Integrated Flash Controller")
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Ronald Monthero <debug.penguin32@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231118083156.776887-1-debug.penguin32@gmail.com
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>
Link: https://lore.kernel.org/linux-mtd/20231102220246.3336154-10-u.kleine-koenig@pengutronix.de
txx9ndfmc_remove() is only called after txx9ndfmc_probe() completed
successfully. In this case platform_set_drvdata() was called with a
non-NULL argument and so platform_get_drvdata() won't return NULL.
Simplify by removing the if block with the always false condition.
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/20231102220246.3336154-9-u.kleine-koenig@pengutronix.de
While module_platform_driver_probe() offers the possibility to discard
.probe() and .remove() in some situations, the handling is difficult and
in today's systems the few hundred bytes that can be saved have little
importance. So convert the driver to be a normal driver that can be
bound and unbound at runtime as most other drivers, too.
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/20231102220246.3336154-8-u.kleine-koenig@pengutronix.de
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().
By changing the function brcmnand_remove() to return void several
drivers that use this function as remove callback can be converted to
.remove_new().
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20231102220246.3336154-7-u.kleine-koenig@pengutronix.de
- cleanups and fixes
-----BEGIN PGP SIGNATURE-----
iQJOBAABCAA4FiEEbt46xwy6kEcDOXoUeZbBVTGwZHAFAmVMnfAaHHRzYm9nZW5k
QGFscGhhLmZyYW5rZW4uZGUACgkQeZbBVTGwZHAnjBAAnz/uhqqZy1aU1Fna1Fr8
AqR3AeA3DfKGpZXY1HttgmZhd6nzktmek5hT1007eEWieYOuR32fin0XflL8KfrA
ecPva7WD3FMJRc56yQ1SI836kLKDuAVW+m6AvzqvWron1IyAScUjTtrjmY9ZxLh1
citiMwh8eHK1nT2voBQKzCKoXXsZO+yqvnVNWnGiRRjmYHk9Gpu6kcM5sw5xQWhP
jCA+stWY2VQdeTRrNA4pAgqoD0q4RA0Ntzdb8cZGFiFBxdmOlAl6P4t5WusP2shN
eIc4uEykWc1utkay4+o+c9dsABiaYPSQvuuVQrx7uFWSL7zEup5TUw46zN9ptxsh
CRLEKeJtaJvuUC4WdJRCAB6n7lAjfRtdsALlWv1gU0DWFdJbspv8YExZmBZhqgDM
8LkII39Hvi3oQYAjM9W+/FsPP3BNvIpS07c3hlcuSvbo3cHNzHL6wfNDpPV0TN3L
P30LZWybQj+lr2amw38r4zOh5nuz+9eyP7mes8cgorlMfjxv0vIMcg3XT1D3+YJK
7lLKmoHgBab6VNUeUPS92cfCNlb50TQeSMf21Xt/obrhpVGJnLHQ50jg8NaKENyc
gwLyvjbf/hIbgJAvKnaRGEcV8COwppcX+U3yEAbXJ2eAvYEXZCU41dH5x3/7WRuB
tvlRfkDcu9ddjyQDtZ4yv/M=
=g+6E
-----END PGP SIGNATURE-----
Merge tag 'mips_6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
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
- UBI Fastmap improvements
- Minor issues found by static analysis bots in both UBI and UBIFS
- Fix for wrong dentry length UBIFS in fscrypt mode
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEdgfidid8lnn52cLTZvlZhesYu8EFAmVHbHYWHHJpY2hhcmRA
c2lnbWEtc3Rhci5hdAAKCRBm+VmF6xi7wSdwEACWV8rZGKamOgnidf5WR8ycQUFd
mPnTwPaRAZNjCq5LgeoMPcV1osucWb+vN+dO7o3KQSk2N/UF1iC6Lhs6giMj8MuU
ZJ4v6bfPB0m0d5cQy+X8D1NH/yTQ7vzJrpuu3xDJeywLZFt7P6bSJRlX36Zr6WWC
BVmVKeiqaB0qnlkpTf4BkIbgXR8Pcv/pXkYjsRcHnSJzpLQD6ByBErQwL2LKGUkE
3ULajJW2oRs8FA6YWfzTcARS3BOpIPJtUyA8RFi8uWKWks16R1Vg4FFfjMVoTzf9
Fe6f2KB+SQxX4dzhGMuVQTGgJuRVacktiL6fLHzvpE2mcKY7E5/b0F39P3BnFhID
2QtojZMXtgFpqz/Vg2W1vNrvHrN++e0sVgqIoxrN8PaE4ciP0yhkhoTEQwx1HWu5
qIxNH8j6USMnfybLgyphVDIoLXzOzhQqY5RWzIYN454jsFg9PeNPkqB3SH9h63j+
nZZ8v+PHeq2wxyYTg4vV+GPKcAlQ/XdKzM9w2Hh+Gp+XIgcO9i4Ag5Qku2lnjPY3
HvKq9t19YSDZkwMnmqeUY/hPB5OK9c0ukirsipQ6ACcQYj0h5hpVHlBGhX8r2cc2
EhdPNP11FhnxR3EcjBDBtSYAKmBs/LDT7gYrjo0013ciMZpVHFREx8G8Icp97366
spp8j/xwAAOyvw6/xA==
=fJhk
-----END PGP SIGNATURE-----
Merge tag 'ubifs-for-linus-6.7-rc1' of 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
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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmVGJNgACgkQJWrqGEe9
VoQ5ggf/flUHU7RI02T7HNwkHayq/NOgaGIUkUZEwdfEBd6/8nLzpDeh9UuQCBvO
izOdRSiDDhcav6YsKs+7UKnonY0uZ5VwB3cjRcgWzsI/nyARs5CeV8VJxqxiGYqU
25rZVVVoNr/4eV6kb9Sx0yUTLobidlNKtpv0w0hLFoVu+eb35RzE/MHaYmialM87
W4W/aHxJH/Nsz9hi13FWE4CpbRYbg2hEBsQhaQV/Uvf4htxYZ+H0ItZGMm/Lsjk4
31eCbgH4yOP2DaQi5KRtvZauKMptqWOo+3ymjDGDi7soQe2qRa5BFsH8cz9/2lDk
hxLk/mGKB4jfnkAaOv5dc0CTcYsnuQ==
=V+qH
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-6.7' of 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
...
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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmVGIQoACgkQJWrqGEe9
VoTPOggAjxm9yHRE6kQh5QT1mLaU9VMchyl7+/rwxOc4TA3TLIcgACIjz0BDHTSu
+VBB+XzL5pV2Nxn2ixepIyiNsACFgNKJ6+5toQomCEgQSKyNXUghE29G6HZ8Mydr
+/o2GZy7nBoVtgnSjAto3tSwM9T5aE9rovJXp+sXjBkPdmUvH0vQs1EPqiHzlF1w
PBuaQYecODLli6/9Mlt2Los5BRUNzdRaHXFUI9Cr7+u37ZIA0McAtrSbFeEX+A1T
DRB2cPzosHK0IQ+093Rh9KNRPqhPB3KYaEf7/+VjuZxjzbjeeDT8Hhic9PJPcvSz
6CWta2A4g5nxUDArb2ZO9bTkw2es7Q==
=nCq+
-----END PGP SIGNATURE-----
Merge tag 'nand/for-6.7' into mtd/next
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>
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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEHUIqys8OyG1eHf7fS1VPR6WNFOkFAmUvhfgACgkQS1VPR6WN
FOlQUAf/ZFUi5nktXOERKghKIwQulTIWdxsV2ZitezzFEPeObHaXR/kiF53mKbyS
txutJglHFYpsLaLptGwrUja2bWVI5OEZCLknIsRRPH4wy3aWlyef1yonl6//U/O9
lWLEKcUFgsmJKTe+Ga6BWJFBlExCfhPM6Hu9q3O/z0cV107fNdHBo41p9Xvn2B3l
miNyxhsojdXfDIFexjZHC+kYS5cQv9fRLyBKDvWoAsjSj9HoPt9Y/46x2TKfsJ83
d8JJH8ABwk6hpgjcTECorqcljsB6FdQ80s+0klmrfqO1UBt0ptrS/OwcmYMuivZn
urpGYUAWFgFGivBb+nUfG/VgAQ3E7w==
=qzxq
-----END PGP SIGNATURE-----
Merge tag 'spi-nor/for-6.7' into mtd/next
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>
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.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZUTSzg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylH3QCfbZuG8MiglEZUd4slRLUNqcRQ5tQAn1yKpDFo
l3KLkxo1UTLMXbJBWe+b
=gafK
-----END PGP SIGNATURE-----
Merge tag 'char-misc-6.7-rc1' of 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
...
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmU7ixgACgkQEacuoBRx
13JwfxAA4CeZdXdUpx6EMUw+6ST4EWb5JanrPjNcQbyBxNFrHx+6yJJL4AOQJStQ
WkG+Zi8Li9uV3wZQixBDs0WN8xVwJU+4QLSwwtNhEjl2x9MkVjghh4la6TqBrMj8
e/iJufTyKUgcm2P4MRTDXFarAin4doBQUPKWfCgL18VvlKxLXG0KMndUl3jAd/Rm
YZLm4Z/iqWaxjfrm+E9LfWFmWS5T7t/g+7TYzMp2AHQ9dHFiwoodpiHTkdWH4dfL
zxF8Ek2132Up0BYC1lQlwz1aoLIlHcr9xVOqOrIxZI/B5xRcUfoXnQQmCCfH2UYr
wtfwKMI7IO2d5E+F7anFC67d9wm7tWacKEifw9lWUAD6xr6yv/13ZOU6aoWXj1Vq
xOMe6gEeZSboF/XiqlmrpZYH+ljDp/mYWkGcOJrUg7WYUgvUCFWu6l6DmuUFMr7m
ACtOUqwbTuWTXN28QtMOpjiQRqlAWyrY6PqhBCllhmcjsoVaZNgWEfriPlSOyoBg
EBRBcURXLs7/h86nEsK/8BIsC0myHbpNiNpG5qaMjrrYJxMh4qS4MIG83MWAy1dZ
8ZtYrxx4XClyaYwYomsIkseLaSCrBTIoYws7wmyTjYfKC7P/t6/XXPS1suyMnf9I
/n5tN8Rv1pDrnS3iQflHQVl9H5m4yezHOOBJUiWW+gs5MUr4vK0=
=1QF8
-----END PGP SIGNATURE-----
Merge tag 'gpio-updates-for-v6.7-rc1' of 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
...
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: 77567b25ab ("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>
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>
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>
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: dbb7d2a88d ("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>
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: dbb7d2a88d ("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>
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: dbb7d2a88d ("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>
Change pool filling stop condition. Commit d09e9a2bdd ("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>
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>
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 78d6d497a6 ("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>
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>
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>
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>
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: dbb7d2a88d ("UBI: Add fastmap core")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
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>
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
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: 1e4d3ba668 ("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
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: 0b1039f016 ("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
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
This reverts commit 517f14d9cf.
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>
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>
with devices not supporting it. There was two bug reports about
this. Aside, 3 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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmUyvxcACgkQJWrqGEe9
VoStmwf9HjOY3kNB37ip0NpG5viRWeLNC8hMxJOJaGZlyX6x9b/88xsBjVFc7z3s
hoCBGfOnUSDXk4KfxNiYps5YqfMgb+yLeIGdsDsLhNht6Mh/YOEFzXgcD8+iudKH
OpjjJnRzQHxNM3zA3Vauh1XD/j+6uvQ3BHlJpQfA+Ukv4+34Irin4/gKhZCoUedo
IJNVU5hurJexCkjGk2yO+B34qD8ZXGKWeXzwsKKYB/FE55iO69GrHNdLBMnFfxu+
uU6GcV+YKroPLDs5mKH2oojKhyAhrh3gQyrNJFnCqh/sVnNCAbD75N+YC6enHeBe
ovlc82AWmLUJVktsih27OsU58RnCxA==
=7Xq1
-----END PGP SIGNATURE-----
Merge tag 'mtd/fixes-for-6.6-rc7' of 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
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>
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>
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>
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>
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
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
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
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
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: 88ffef1b65 ("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
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
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
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
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
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
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
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
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
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
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
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
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-10-u.kleine-koenig@pengutronix.de
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-9-u.kleine-koenig@pengutronix.de
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-8-u.kleine-koenig@pengutronix.de
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-7-u.kleine-koenig@pengutronix.de
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-6-u.kleine-koenig@pengutronix.de
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-5-u.kleine-koenig@pengutronix.de
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-4-u.kleine-koenig@pengutronix.de
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: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230926065733.3240322-1-wangzhaolong1@huawei.com
Both the JEDEC and ONFI specification say that read cache sequential
support is an optional command. This means that we not only need to
check whether the individual controller supports the command, we also
need to check the parameter pages for both ONFI and JEDEC NAND flashes
before enabling sequential cache reads.
This fixes support for NAND flashes which don't support enabling cache
reads, i.e. Samsung K9F4G08U0F or Toshiba TC58NVG0S3HTA00.
Sequential cache reads are now only available for ONFI and JEDEC
devices, if individual vendors implement this, it needs to be enabled
per vendor.
Tested on i.MX6Q with a Samsung NAND flash chip that doesn't support
sequential reads.
Fixes: 003fe4b954 ("mtd: rawnand: Support for sequential cache reads")
Cc: stable@vger.kernel.org
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230922141717.35977-1-r.czerwinski@pengutronix.de
We have a special place for OF polarity quirks in gpiolib-of.c. Let's
move this over there so that it doesn't pollute the driver.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
We currently provide the physical address of the DMA region
rather than the output of dma_map_resource() which is obviously wrong.
Fixes: 7330fc505a ("mtd: rawnand: qcom: stop using phys_to_dma()")
Cc: stable@vger.kernel.org
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230913070702.12707-1-quic_bibekkum@quicinc.com
The NAND core complies with the ONFI specification, which itself
mentions that after any program or erase operation, a status check
should be performed to see whether the operation was finished *and*
successful.
The NAND core offers helpers to finish a page write (sending the
"PAGE PROG" command, waiting for the NAND chip to be ready again, and
checking the operation status). But in some cases, advanced controller
drivers might want to optimize this and craft their own page write
helper to leverage additional hardware capabilities, thus not always
using the core facilities.
Some drivers, like this one, do not use the core helper to finish a page
write because the final cycles are automatically managed by the
hardware. In this case, the additional care must be taken to manually
perform the final status check.
Let's read the NAND chip status at the end of the page write helper and
return -EIO upon error.
Cc: Michal Simek <michal.simek@amd.com>
Cc: stable@vger.kernel.org
Fixes: 08d8c62164 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/linux-mtd/20230717194221.229778-3-miquel.raynal@bootlin.com
The NAND core complies with the ONFI specification, which itself
mentions that after any program or erase operation, a status check
should be performed to see whether the operation was finished *and*
successful.
The NAND core offers helpers to finish a page write (sending the
"PAGE PROG" command, waiting for the NAND chip to be ready again, and
checking the operation status). But in some cases, advanced controller
drivers might want to optimize this and craft their own page write
helper to leverage additional hardware capabilities, thus not always
using the core facilities.
Some drivers, like this one, do not use the core helper to finish a page
write because the final cycles are automatically managed by the
hardware. In this case, the additional care must be taken to manually
perform the final status check.
Let's read the NAND chip status at the end of the page write helper and
return -EIO upon error.
Cc: Michal Simek <michal.simek@amd.com>
Cc: stable@vger.kernel.org
Fixes: 88ffef1b65 ("mtd: rawnand: arasan: Support the hardware BCH ECC engine")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/linux-mtd/20230717194221.229778-2-miquel.raynal@bootlin.com
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: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230919113320.16953-1-shivamurthy.shastri@linutronix.de
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: 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/20230915201300.never.057-kees@kernel.org
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 rnand_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: linux-mtd@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
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/20230915201254.never.511-kees@kernel.org
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 meson_nfc_nand_chip.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Liang Yang <liang.yang@amlogic.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: linux-mtd@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
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/20230915201249.never.509-kees@kernel.org
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 marvell_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: linux-mtd@lists.infradead.org
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/20230915201243.never.235-kees@kernel.org
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 ingenic_nfc.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Harvey Hunt <harveyhuntnexus@gmail.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
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/20230915201234.never.868-kees@kernel.org
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 denali_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: linux-mtd@lists.infradead.org
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/20230915201227.never.483-kees@kernel.org
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 atmel_nand.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Cc: linux-mtd@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230915201219.never.352-kees@kernel.org
The Atmel AT26DF321 and AT25DF321 have the same ID. Both were just
discovered by reading their IDs, that is, there is no probing by name.
Thus only the first one (the AT25DF321) in the list was ever probed.
Luckily, the AT25DF is also the newer series. Drop the AT26DF321.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-40-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-39-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-38-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-37-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-36-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-35-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-34-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-33-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-32-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash ID is the new primary key into our database. Sort the entry by
it. Keep the most specific ones first, because there might be ID
collisions between shorter and longer ones.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-31-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
There won't be any new entries, nor are the entries that much different
and the very odd page and sector sizes make the new format hard to read.
Therefore, convert the old S3AN_INFO() macro.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-29-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
After all the preparation, it is now time to introduce the new macros to
specify flashes in our database: SNOR_ID() and SNOR_OTP(). An flash_info
entry might now look like:
{
.id = SNOR_ID(0xef, 0x60, 0x16),
.otp = SNOR_OTP(256, 3, 0x1000, 0x1000),
.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
}
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-15-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Move the OTP ops out of the flash_info structure. Besides of saving some
space, there will be a new macro SNOR_OTP() which can be used to set the
ops:
.otp = SNOR_OTP(...),
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-14-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Create a new structure to hold a flash ID and its length. The goal is to
have a new macro SNOR_ID() which can have a flexible id length. This way
we can get rid of all the individual INFOx() macros.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-13-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The id will be converted to an own structure. To differentiate between
flashes with and without IDs, introduce a temporary macro INFO0() and
convert all flashes with no ID to use it. The difference between INFO0()
and INFOx() is that the former, doesn't have a pointer to the id
structure. Something which isn't possible to do within the INFOx()
macro.
After the flash_info conversion, that macro will be removed along with
all the other INFOx() macros.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-12-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Drop the size parameter to indicate we need to do SFDP, we can do that
because it is guaranteed that the size will be set by SFDP and because
PARSE_SFDP forced the SFDP parsing it must be overwritten.
There is a (very tiny) chance that this might break block protection
support: we now rely on the SFDP reported size of the flash for the
BP calculation. OTOH, if the flash reports its size wrong, we are
in bigger trouble than just having the BP calculation wrong.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-11-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Most of the (old, non-SFDP) flashes use a sector size of 64k. Make that
a default value so it can be optional in the flash_info database.
As a preparation for conversion to the new database format, set the
sector size to zero if the default value is used. This way, the actual
change is happening with this patch ant not with a later conversion
patch.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-10-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
4k sector erase sizes are only a thing with uniform erase types. Push
the "we want 4k erase sizes" handling into spi_nor_select_uniform_erase().
One might wonder why the former sector_size isn't used anymore. It is
because we either search for the largest erase size or if selected
through kconfig, the 4k erase size. Now, why is that correct? For this,
we have to differentiate between (1) flashes with SFDP and (2) without
SFDP. For (1), we just set one (or two if SECT_4K is set) erase types
and wanted_size is exactly one of these.
For (2) things are a bit more complicated. For flashes which we don't
have in our flash_info database, the generic driver is used and
sector_size was already 0, which in turn selected the largest erase
size. For flashes which had SFDP and an entry in flash_info, sector_size
was always the largest sector and thus the largest erase type.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-9-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
If .n_banks is not set in the flash_info database, the default value
should be 1. This way, we don't have to always set the .n_banks
parameter in flash_info.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-8-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
First, fixups might want to replace the n_banks parameter, thus we need
it in the (writable) parameter struct. Secondly, this way we can have a
default in the core and just skip setting the n_banks in the flash_info
database. Most of the flashes doesn't have more than one bank.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-7-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The INFO() macro always set the page_size to 256 bytes. Make that an
optional parameter. This default is a sane one for all older flashes,
newer ones will set the page size by its SFDP tables anyway.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-6-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
.n_sectors is rarely used. In fact it is only used in swp.c and to
calculate the flash size in the core. The use in swp.c might be
converted to use the (largest) flash erase size. For now, we just
locally calculate the sector size.
Simplify the flash_info database and set the size of the flash directly.
This also let us use the SZ_x macros.
Verified that there's no flash that specifies BP and sector size of zero
to make sure we avoid a division by zero in
spi_nor_get_min_prot_length_sr(). We'll protect from a possible division
by zero in a further patch by introducing a default value for
sector_size.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-5-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
In commit 5927318029 ("mtd: spi-nor: Create macros to define chip IDs
and geometries") SPI_NOR_ID() were introduced, but it did only update
the INFO() macro in core.h. Also use it in S3AN_INFO().
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-3-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
This part is not a flash but an EEPROM like FRAM. It is even has a DT
binding for the (correct) driver (at25), see
Documentation/devicetree/bindings/eeprom/at25.yaml. Just remove it.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-2-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
CAT25xx are actually EEPROMs manufactured by Catalyst. The devices are
ancient (DS are from 1998), there are not in-tree users, nor are there
any device tree bindings. Remove it. The correct driver is the at25.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-1-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The value of an arithmetic expression
1 << lpddr->qinfo->DevSizeShift is subject to overflow
due to a failure to cast operands to a larger data
type before performing arithmetic
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Arefev <arefev@swemel.ru>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230824130215.10396-1-arefev@swemel.ru
Refer to commit a85a6c86c2 ("driver core: platform: Clarify that IRQ
0 is invalid"). Do not check 0 for platform_get_irq(), because
platform_get_irq() never return zero, and use the return error code of
platform_get_irq() instead of -ENODEV.
Signed-off-by: Yi Yang <yiyang13@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230821084622.218442-1-yiyang13@huawei.com
Valid bitmask is 0x70 in the status register.
Fixes: a508e8875e ("mtd: spinand: Add initial support for Micron MT29F2G01ABAGD")
Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230905145637.139068-1-mmkurbanov@sberdevices.ru
When the exact mapping type driver was not available, the old
physmap_of_core driver fell back to mapping the region as ROM.
Unfortunately this feature was lost when the DT and pdata cases were
merged. Revive this useful feature.
Fixes: 642b1e8dbe ("mtd: maps: Merge physmap_of.c into physmap-core.c")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/550e8c8c1da4c4baeb3d71ff79b14a18d4194f9e.1693407371.git.geert+renesas@glider.be
The NAND core complies with the ONFI specification, which itself
mentions that after any program or erase operation, a status check
should be performed to see whether the operation was finished *and*
successful.
The NAND core offers helpers to finish a page write (sending the
"PAGE PROG" command, waiting for the NAND chip to be ready again, and
checking the operation status). But in some cases, advanced controller
drivers might want to optimize this and craft their own page write
helper to leverage additional hardware capabilities, thus not always
using the core facilities.
Some drivers, like this one, do not use the core helper to finish a page
write because the final cycles are automatically managed by the
hardware. In this case, the additional care must be taken to manually
perform the final status check.
Let's read the NAND chip status at the end of the page write helper and
return -EIO upon error.
Cc: stable@vger.kernel.org
Fixes: 02f26ecf8c ("mtd: nand: add reworked Marvell NAND controller driver")
Reported-by: Aviram Dali <aviramd@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Ravi Chandra Minnikanti <rminnikanti@marvell.com>
Link: https://lore.kernel.org/linux-mtd/20230717194221.229778-1-miquel.raynal@bootlin.com
There exists mtd devices with zero erasesize, which will trigger a
divide-by-zero exception while attaching ubi device.
Fix it by refusing attaching if mtd's erasesize is 0.
Fixes: 801c135ce7 ("UBI: Unsorted Block Images")
Reported-by: Yu Hao <yhao016@ucr.edu>
Link: https://lore.kernel.org/lkml/977347543.226888.1682011999468.JavaMail.zimbra@nod.at/T/
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
- Add support for the Cirrus Logic CS42L43 Audio CODEC
- Fix-ups
- Make use of specific printk() format tags for various optimisations
- Kconfig / module modifications / tweaking
- Simplify obtaining resources (memory, device data) using unified API helpers
- Bunch of Device Tree additions, conversions and adaptions
- Convert a bunch of Regmap configurations to use the Maple Tree cache
- Ensure correct includes are present and remove some that are not required
- Remove superfluous code
- Reduce amount of cycles spent in critical sections
- Omit the use of redundant casts and if relevant replace with better ones
- Swap out raw_spin_{un}lock_irq{save,restore}() for spin_{un}lock_irq{save,restore}()
- Bug Fixes
- Repair theoretical deadlock situation
- Fix some link-time dependencies
- Use more appropriate datatype when casting
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmT14v8ACgkQUa+KL4f8
d2F+jw/+MqR0pdOuHiwRAWkPB+Zpk1+aOySF/gZynViSv0aVA/IGXvdTiXSvueut
toCcA5LvfrEHzo4wOHF2NeHIs9ogGjuCPRhYTEnBWv8pRkD3fLI2x9nDCxrr6uje
6vvCoDZ8klHcjNw8AJTM/37UFCiqrN9EYb4aoKFVhc1331Fxhc3vYxPbCWr7MZyn
A3AVpM5pHeS0+/huwwCwX44azYc8wdBMrqQ5t0FB/YNyndz2Sd0WBUbxqiSn+i94
p6J7xhP8mG2JveCcezxX7ixVta4rkinGnlSNjt3ej41OTr4rbMCY55CHuyR3KnL2
KtRm8MqFofnOUqMGr8LH21mVm6QgLEel19QsG4HVkIKSAJ7xWnPS9Gw7RzUhKGJP
gHPqrwjgbzqyPBj5oCnVHiSuqjpnzYyMG1zUSYFzMY1eTe98fdHwAKHqsAQO9Zgp
lFACynrGIFfcjbV2PKbmshBUdpX2rk5aM/QdOFN4/8X6oaxgzFndWBhKTJew5Jir
ZRoTFONzdZRCK23YB7k4AncEYwy0fdsbNLuOJFHk3nHxmrTllpnXn1fcDL/H+vsF
3CGe7RBxRkzU06Sq4SlLBbqj5H4eeyyq8pP3kRF7y7KsI9G3GLeEW69LNkqYANxf
3tkC7MKt3qZp6UHx47gAqNaCS/cniF3rsLe7LgwTaxqg1+LNIbU=
=MNYe
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull NFD updates from Lee Jones:
"New Drivers:
- Add support for the Cirrus Logic CS42L43 Audio CODEC
Fix-ups:
- Make use of specific printk() format tags for various optimisations
- Kconfig / module modifications / tweaking
- Simplify obtaining resources (memory, device data) using unified
API helpers
- Bunch of Device Tree additions, conversions and adaptions
- Convert a bunch of Regmap configurations to use the Maple Tree
cache
- Ensure correct includes are present and remove some that are not
required
- Remove superfluous code
- Reduce amount of cycles spent in critical sections
- Omit the use of redundant casts and if relevant replace with better
ones
- Swap out raw_spin_{un}lock_irq{save,restore}() for
spin_{un}lock_irq{save,restore}()
Bug Fixes:
- Repair theoretical deadlock situation
- Fix some link-time dependencies
- Use more appropriate datatype when casting"
* tag 'mfd-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (70 commits)
mfd: mc13xxx: Simplify device data fetching in probe()
mfd: rz-mtu3: Replace raw_spin_lock->spin_lock()
mfd: rz-mtu3: Reduce critical sections
mfd: mxs-lradc: Fix Wvoid-pointer-to-enum-cast warning
mfd: wm31x: Fix Wvoid-pointer-to-enum-cast warning
mfd: wm8994: Fix Wvoid-pointer-to-enum-cast warning
mfd: tc3589: Fix Wvoid-pointer-to-enum-cast warning
mfd: lp87565: Fix Wvoid-pointer-to-enum-cast warning
mfd: hi6421-pmic: Fix Wvoid-pointer-to-enum-cast warning
mfd: max77541: Fix Wvoid-pointer-to-enum-cast warning
mfd: max14577: Fix Wvoid-pointer-to-enum-cast warning
mfd: stmpe: Fix Wvoid-pointer-to-enum-cast warning
mfd: rn5t618: Remove redundant of_match_ptr()
mfd: lochnagar-i2c: Remove redundant of_match_ptr()
mfd: stpmic1: Remove redundant of_match_ptr()
mfd: act8945a: Remove redundant of_match_ptr()
mfd: rsmu_spi: Remove redundant of_match_ptr()
mfd: altera-a10sr: Remove redundant of_match_ptr()
mfd: rsmu_i2c: Remove redundant of_match_ptr()
mfd: tc3589x: Remove redundant of_match_ptr()
...
