linux-stable.git/drivers/mtd, branch linux-6.7.y Linux kernel stable tree mtd: rawnand: Constrain even more when continuous reads are enabled 2024-04-03T13:11:28+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-03-07T11:53:14+00:00 1a7d50630ac9557edf9cd50cf5570d7027c9662f [ Upstream commit 78ffbefba8d7822b232585570b293de5bc397da6 ] As a matter of fact, continuous reads require additional handling at the operation level in order for them to work properly. The core helpers do have this additional logic now, but any time a controller implements its own page helper, this extra logic is "lost". This means we need another level of per-controller driver checks to ensure they can leverage continuous reads. This is for now unsupported, so in order to ensure continuous reads are enabled only when fully using the core page helpers, we need to add more initial checks. Also, as performance is not relevant during raw accesses, we also prevent these from enabling the feature. This should solve the issue seen with controllers such as the STM32 FMC2 when in sequencer mode. In this case, the continuous read feature would be enabled but not leveraged, and most importantly not disabled, leading to further operations to fail. Reported-by: Christophe Kerello <christophe.kerello@foss.st.com> Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Christophe Kerello <christophe.kerello@foss.st.com> Link: https://lore.kernel.org/linux-mtd/20240307115315.1942678-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 78ffbefba8d7822b232585570b293de5bc397da6 ]

As a matter of fact, continuous reads require additional handling at the
operation level in order for them to work properly. The core helpers do
have this additional logic now, but any time a controller implements its
own page helper, this extra logic is "lost". This means we need another
level of per-controller driver checks to ensure they can leverage
continuous reads. This is for now unsupported, so in order to ensure
continuous reads are enabled only when fully using the core page
helpers, we need to add more initial checks.

Also, as performance is not relevant during raw accesses, we also
prevent these from enabling the feature.

This should solve the issue seen with controllers such as the STM32 FMC2
when in sequencer mode. In this case, the continuous read feature would
be enabled but not leveraged, and most importantly not disabled, leading
to further operations to fail.

Reported-by: Christophe Kerello <christophe.kerello@foss.st.com>
Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Christophe Kerello <christophe.kerello@foss.st.com>
Link: https://lore.kernel.org/linux-mtd/20240307115315.1942678-1-miquel.raynal@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: rawnand: Ensure all continuous terms are always in sync 2024-04-03T13:11:28+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-02-23T11:55:45+00:00 6e3b9c4698f888ce1fc247fd6e3192ebaab7181e [ Upstream commit 6fb075fca63c3486612986eeff84ed4179644038 ] While crossing a LUN boundary, it is probably safer (and clearer) to keep all members of the continuous read structure aligned, including the pause page (which is the last page of the lun or the last page of the continuous read). Once these members properly in sync, we can use the rawnand_cap_cont_reads() helper everywhere to "prepare" the next continuous read if there is one. Fixes: bbcd80f53a5e ("mtd: rawnand: Prevent crossing LUN boundaries during sequential reads") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20240223115545.354541-4-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6fb075fca63c3486612986eeff84ed4179644038 ]

While crossing a LUN boundary, it is probably safer (and clearer) to
keep all members of the continuous read structure aligned, including the
pause page (which is the last page of the lun or the last page of the
continuous read). Once these members properly in sync, we can use the
rawnand_cap_cont_reads() helper everywhere to "prepare" the next
continuous read if there is one.

Fixes: bbcd80f53a5e ("mtd: rawnand: Prevent crossing LUN boundaries during sequential reads")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240223115545.354541-4-miquel.raynal@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: rawnand: Add a helper for calculating a page index 2024-04-03T13:11:28+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-02-23T11:55:44+00:00 a37370f25de41f02cc8c2b18cdb75142486f568f [ Upstream commit df9803bf5a91e3599f12b53c94722f2c4e144a86 ] For LUN crossing boundaries, it is handy to know what is the index of the last page in a LUN. This helper will soon be reused. At the same time I rename page_per_lun to ppl in the calling function to clarify the lines. Cc: stable@vger.kernel.org # v6.7 Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20240223115545.354541-3-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit df9803bf5a91e3599f12b53c94722f2c4e144a86 ]

For LUN crossing boundaries, it is handy to know what is the index of
the last page in a LUN. This helper will soon be reused. At the same
time I rename page_per_lun to ppl in the calling function to clarify the
lines.

Cc: stable@vger.kernel.org # v6.7
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240223115545.354541-3-miquel.raynal@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: rawnand: Fix and simplify again the continuous read derivations 2024-04-03T13:11:28+00:00 Miquel Raynal miquel.raynal@bootlin.com 2024-02-23T11:55:43+00:00 967a949a22a1330bb209077ff0f9e80bd579e654 [ Upstream commit c7ee7c8d4b60fe46d4861b1200bc1c7ab657960a ] We need to avoid the first page if we don't read it entirely. We need to avoid the last page if we don't read it entirely. While rather simple, this logic has been failed in the previous fix. This time I wrote about 30 unit tests locally to check each possible condition, hopefully I covered them all. Reported-by: Christophe Kerello <christophe.kerello@foss.st.com> Closes: https://lore.kernel.org/linux-mtd/20240221175327.42f7076d@xps-13/T/#m399bacb10db8f58f6b1f0149a1df867ec086bb0a Suggested-by: Christophe Kerello <christophe.kerello@foss.st.com> Fixes: 828f6df1bcba ("mtd: rawnand: Clarify conditions to enable continuous reads") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Christophe Kerello <christophe.kerello@foss.st.com> Link: https://lore.kernel.org/linux-mtd/20240223115545.354541-2-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c7ee7c8d4b60fe46d4861b1200bc1c7ab657960a ]

We need to avoid the first page if we don't read it entirely.
We need to avoid the last page if we don't read it entirely.
While rather simple, this logic has been failed in the previous
fix. This time I wrote about 30 unit tests locally to check each
possible condition, hopefully I covered them all.

Reported-by: Christophe Kerello <christophe.kerello@foss.st.com>
Closes: https://lore.kernel.org/linux-mtd/20240221175327.42f7076d@xps-13/T/#m399bacb10db8f58f6b1f0149a1df867ec086bb0a
Suggested-by: Christophe Kerello <christophe.kerello@foss.st.com>
Fixes: 828f6df1bcba ("mtd: rawnand: Clarify conditions to enable continuous reads")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Christophe Kerello <christophe.kerello@foss.st.com>
Link: https://lore.kernel.org/linux-mtd/20240223115545.354541-2-miquel.raynal@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: rawnand: meson: fix scrambling mode value in command macro 2024-04-03T13:11:12+00:00 Arseniy Krasnov avkrasnov@salutedevices.com 2024-02-10T21:45:51+00:00 e9db9e57919910d96e9042d3ba8741beb9d580f4 [ Upstream commit ef6f463599e16924cdd02ce5056ab52879dc008c ] 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: 8fae856c5350 ("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 Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ef6f463599e16924cdd02ce5056ab52879dc008c ]

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: 8fae856c5350 ("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
Signed-off-by: Sasha Levin <sashal@kernel.org>
ubi: correct the calculation of fastmap size 2024-04-03T13:11:12+00:00 Zhang Yi yi.zhang@huawei.com 2024-02-20T02:49:03+00:00 342fad916456299f69f97f0a6bc12fa03037a07e [ Upstream commit 7f174ae4f39e8475adcc09d26c5a43394689ad6c ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7f174ae4f39e8475adcc09d26c5a43394689ad6c ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ubi: Check for too small LEB size in VTBL code 2024-04-03T13:11:11+00:00 Richard Weinberger richard@nod.at 2024-01-24T06:37:02+00:00 f9fbbc86f849e0b333fb6a257c86f53850699997 [ Upstream commit 68a24aba7c593eafa8fd00f2f76407b9b32b47a9 ] 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: 801c135ce73d ("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> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 68a24aba7c593eafa8fd00f2f76407b9b32b47a9 ]

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: 801c135ce73d ("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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: rawnand: lpc32xx_mlc: fix irq handler prototype 2024-03-26T22:18:39+00:00 Arnd Bergmann arnd@arndb.de 2024-02-13T10:00:09+00:00 7d5347622926c9e3d28e31c49e6ec698cc641e52 [ Upstream commit 347b828882e6334690e7003ce5e2fe5f233dc508 ] clang-16 warns about mismatched function prototypes: drivers/mtd/nand/raw/lpc32xx_mlc.c:783:29: error: cast from 'irqreturn_t (*)(int, struct lpc32xx_nand_host *)' (aka 'enum irqreturn (*)(int, struct lpc32xx_nand_host *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] Change the interrupt handler to the normal way of just passing a void* pointer and converting it inside the function.. Fixes: 70f7cb78ec53 ("mtd: add LPC32xx MLC NAND driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20240213100146.455811-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 347b828882e6334690e7003ce5e2fe5f233dc508 ]

clang-16 warns about mismatched function prototypes:

drivers/mtd/nand/raw/lpc32xx_mlc.c:783:29: error: cast from 'irqreturn_t (*)(int, struct lpc32xx_nand_host *)' (aka 'enum irqreturn (*)(int, struct lpc32xx_nand_host *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]

Change the interrupt handler to the normal way of just passing
a void* pointer and converting it inside the function..

Fixes: 70f7cb78ec53 ("mtd: add LPC32xx MLC NAND driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240213100146.455811-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: maps: physmap-core: fix flash size larger than 32-bit 2024-03-26T22:18:39+00:00 Baruch Siach baruch@tkos.co.il 2024-02-08T10:34:18+00:00 0e42e330409628f3d67773efdf4fb73955a3eec6 [ Upstream commit 3884f03edd34887514a0865a80769cd5362d5c3b ] 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: ba32ce95cbd987 ("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 Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3884f03edd34887514a0865a80769cd5362d5c3b ]

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: ba32ce95cbd987 ("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
Signed-off-by: Sasha Levin <sashal@kernel.org>
mtd: spinand: esmt: Extend IDs to 5 bytes 2024-03-26T22:18:31+00:00 Ezra Buehler ezra.buehler@husqvarnagroup.com 2024-01-25T20:01:08+00:00 18e1162623fdf60f7157a0bdb90fd7d3669859c3 [ Upstream commit 4bd14b2fd8a83a2f5220ba4ef323f741e11bfdfd ] 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: aa08bf187f32 ("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 Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4bd14b2fd8a83a2f5220ba4ef323f741e11bfdfd ]

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: aa08bf187f32 ("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
Signed-off-by: Sasha Levin <sashal@kernel.org>