kernel/linux.git/drivers/mtd/devices/phram.c, branch linux-7.0.y

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

mtd: phram: Add the kernel lock down check

2024-12-05T10:11:44+00:00

The phram MTD driver may map any memory pages no matter whether it's reserved or whatever used for systems, which basically allows user bypassing the lock down. Add the check and abort the probe if the kernel is locked down for LOCKDOWN_DEV_MEM. Reported-by: Fabian Vogt Suggested-by: Fabian Vogt Signed-off-by: Takashi Iwai Acked-by: Richard Weinberger Signed-off-by: Miquel Raynal

mtd: phram: only call platform_driver_unregister if phram_setup fails

2024-12-05T10:09:53+00:00

The check on ret and call to platform_driver_unregister is only required in the code path where MODULE is not defined. Fix this by moving this code into the relevant place after the call to phram_setup. Signed-off-by: Colin Ian King Signed-off-by: Miquel Raynal

mtd: Switch back to struct platform_driver::remove()

2024-10-21T09:58:07+00:00

After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/mtd to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20241007205803.444994-10-u.kleine-koenig@baylibre.com

mtd: phram: Convert to platform remove callback returning void

2023-10-16T08:56:47+00:00

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 Signed-off-by: Miquel Raynal Acked-by: Tudor Ambarus Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-6-u.kleine-koenig@pengutronix.de

mtd: phram: Allow cached mappings

2022-05-16T16:37:48+00:00

Currently phram always uses ioremap(), but this is unnecessary when normal memory is used. If the reserved-memory node does not specify the no-map property, indicating it should be mapped as system RAM and ioremap() cannot be used on it, use a cached mapping using memremap(MEMREMAP_WB) instead. On one of my systems this improves read performance by ~70%. (Note that this driver has always used normal memcpy/memset functions on memory obtained from ioremap(), which sparse doesn't like. There is no memremap() variant which maps exactly to ioremap() on all architectures, so that behaviour of the driver is not changed to avoid affecting existing users, but the sparse warnings are suppressed in the moved code with __force.) Signed-off-by: Vincent Whitchurch Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220510151822.1809278-1-vincent.whitchurch@axis.com

mtd: phram: Allow probing via reserved-memory

2022-04-25T08:37:49+00:00

Allow phram to be probed from the devicetree. It expects to be in a reserved-memory node as documented by the bindings. This allows things like partitioning to be specified via the devicetree. Signed-off-by: Vincent Whitchurch Acked-by: Rob Herring Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220412135302.1682890-4-vincent.whitchurch@axis.com

mtd: phram: Prevent divide by zero bug in phram_setup()

2022-01-25T09:32:07+00:00

The problem is that "erasesize" is a uint64_t type so it might be non-zero but the lower 32 bits are zero so when it's truncated, "(uint32_t)erasesize", then that value is zero. This leads to a divide by zero bug. Avoid the bug by delaying the divide until after we have validated that "erasesize" is non-zero and within the uint32_t range. Fixes: dc2b3e5cbc80 ("mtd: phram: use div_u64_rem to stop overwrite len in phram_setup") Signed-off-by: Dan Carpenter Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220121115505.GI1978@kadam

mtd: phram: Fix error return code in phram_setup()

2021-05-10T08:44:34+00:00

Return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Reported-by: Hulk Robot Signed-off-by: Yu Kuai Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210408133812.1209798-1-yukuai3@huawei.com