kernel/drivers/mtd/devices/phram.c, branch linux-rolling-stable

mtd: phram: Add the kernel lock down check

2024-12-05T10:11:44Z

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:53Z

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:07Z

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:47Z

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:48Z

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:49Z

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:07Z

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:34Z

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

mtd: phram: use div_u64_rem to stop overwrite len in phram_setup

2021-01-27T12:45:51Z

We now support user to set erase page size, and use do_div between len and erase size to determine the reasonableness for the erase size. However, do_div is a macro and will overwrite the value of len. Which results a mtd device with unexcepted size. Fix it by use div_u64_rem. Fixes: ffad560394de ("mtd: phram: Allow the user to set the erase page size.") Signed-off-by: yangerkun Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210125124936.651812-1-yangerkun@huawei.com

mtd: phram: Allow the user to set the erase page size.

2020-12-07T11:29:19Z

Permit the user to specify the erase page size as a parameter. This solves two problems: - phram can access images made by mkfs.jffs2. mkfs.jffs2 won't create images with erase sizes less than 8KiB; many architectures define PAGE_SIZE as 4KiB. - Allows more effective use of small capacity devices. JFFS2 needs somewhere between 2 and 5 empty pages for garbage collection; and for an NVRAM part with only 32KiB of space, a smaller erase page allows much better utilization in applications where garbage collection is important. Signed-off-by: Patrick O'Grady Reviewed-by: Joern Engel Link: https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=A@mail.gmail.com/ [Guohua Zhong: fix token array index out of bounds and update patch for kernel master branch] Signed-off-by: Guohua Zhong Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20201207095529.20896-1-zhongguohua1@huawei.com