IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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 (mostly) ignored
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.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # atmel
Reviewed-by: Paul Cercueil <paul@crapouillou.net> # ingenic
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> # ingenic
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # intel
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # meson
Acked-by: Roger Quadros <rogerq@kernel.org> # omap_elm
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
Reviewed-by: Heiko Stuebner <heiko@sntech.de> # rockchip
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> # sunxi
Acked-by: Thierry Reding <treding@nvidia.com> # tegra
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/20230411113816.3472237-1-u.kleine-koenig@pengutronix.de
struct mtd_info has a flag oops_panic_write which is set when the write
operation is issued via the panic_write() callback. That allows controller
drivers to distinguish the panic write from a regular write.
Replace the open coded 'in_interrupt() | oops_in_progress' checks with a
check for that flag. in_interrupt() is an unrealiable indicator anyway as
it covers all sorts of atomic contexts not only hard and soft interrupt
service routines.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: linux-mtd@lists.infradead.org
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201113141422.2214771-1-bigeasy@linutronix.de
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200901142535.12819-1-krzk@kernel.org
As previously reported by Sudip Mukherjee for the Samsung driver, the
omap2 onenand driver is called omap2.c in our directory and omap2.c in
the tty/serial/ directory. If both drivers are compiled as modules, it
would produce the following warning:
warning: same module names found:
drivers/tty/serial/omap2.ko
drivers/mtd/nand/onenand/omap2.ko
Rename the onenand omap2 driver so that it fits the folder's
convention: onenand_omap2.c.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
