<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/mtd, branch v5.4.276</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.276</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.276'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-05-02T14:18:36Z</updated>
<entry>
<title>mtd: diskonchip: work around ubsan link failure</title>
<updated>2024-05-02T14:18:36Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-04-05T14:30:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=672c5715b640fcb06a25a8f6857787c6f17df5bf'/>
<id>urn:sha1:672c5715b640fcb06a25a8f6857787c6f17df5bf</id>
<content type='text'>
commit 21c9fb611c25d5cd038f6fe485232e7884bb0b3d upstream.

I ran into a randconfig build failure with UBSAN using gcc-13.2:

arm-linux-gnueabi-ld: error: unplaced orphan section `.bss..Lubsan_data31' from `drivers/mtd/nand/raw/diskonchip.o'

I'm not entirely sure what is going on here, but I suspect this has something
to do with the check for the end of the doc_locations[] array that contains
an (unsigned long)0xffffffff element, which is compared against the signed
(int)0xffffffff. If this is the case, we should get a runtime check for
undefined behavior, but we instead get an unexpected build-time error.

I would have expected this to work fine on 32-bit architectures despite the
signed integer overflow, though on 64-bit architectures this likely won't
ever work.

Changing the contition to instead check for the size of the array makes the
code safe everywhere and avoids the ubsan check that leads to the link
error. The loop code goes back to before 2.6.12.

Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20240405143015.717429-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: meson: fix scrambling mode value in command macro</title>
<updated>2024-04-13T10:51:23Z</updated>
<author>
<name>Arseniy Krasnov</name>
<email>avkrasnov@salutedevices.com</email>
</author>
<published>2024-02-10T21:45:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=64a1ccfa9ae5a10670dcd1e19faa37e615bc54e9'/>
<id>urn:sha1:64a1ccfa9ae5a10670dcd1e19faa37e615bc54e9</id>
<content type='text'>
[ Upstream commit ef6f463599e16924cdd02ce5056ab52879dc008c ]

Scrambling mode is enabled by value (1 &lt;&lt; 19). NFC_CMD_SCRAMBLER_ENABLE
is already (1 &lt;&lt; 19), so there is no need to shift it again in CMDRWGEN
macro.

Signed-off-by: Arseniy Krasnov &lt;avkrasnov@salutedevices.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20240210214551.441610-1-avkrasnov@salutedevices.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ubi: correct the calculation of fastmap size</title>
<updated>2024-04-13T10:51:23Z</updated>
<author>
<name>Zhang Yi</name>
<email>yi.zhang@huawei.com</email>
</author>
<published>2024-02-20T02:49:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a1d549aec8539dce80075b9c31ed875a0d415b68'/>
<id>urn:sha1:a1d549aec8539dce80075b9c31ed875a0d415b68</id>
<content type='text'>
[ 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 &lt;yi.zhang@huawei.com&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ubi: Check for too small LEB size in VTBL code</title>
<updated>2024-04-13T10:51:23Z</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2024-01-24T06:37:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4e09d5210ba481dd04ccc6e7d1b3b019d8bc3ddc'/>
<id>urn:sha1:4e09d5210ba481dd04ccc6e7d1b3b019d8bc3ddc</id>
<content type='text'>
[ 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 &lt;cy54@illinois.edu&gt;
Cc: stable@vger.kernel.org
Fixes: 801c135ce73d ("UBI: Unsorted Block Images")
Reported-by: Chenyuan Yang &lt;cy54@illinois.edu&gt;
Closes: https://lore.kernel.org/linux-mtd/1433EB7A-FC89-47D6-8F47-23BE41B263B3@illinois.edu/
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: lpc32xx_mlc: fix irq handler prototype</title>
<updated>2024-03-26T22:22:22Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-02-13T10:00:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8df143c608fc2aa6d3be60eed76824d1e26b2a73'/>
<id>urn:sha1:8df143c608fc2aa6d3be60eed76824d1e26b2a73</id>
<content type='text'>
[ 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 &lt;arnd@arndb.de&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20240213100146.455811-1-arnd@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mtd: maps: physmap-core: fix flash size larger than 32-bit</title>
<updated>2024-03-26T22:22:21Z</updated>
<author>
<name>Baruch Siach</name>
<email>baruch@tkos.co.il</email>
</author>
<published>2024-02-08T10:34:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d9d4d1363bb147e6581e53667b1d704eeb6161e1'/>
<id>urn:sha1:d9d4d1363bb147e6581e53667b1d704eeb6161e1</id>
<content type='text'>
[ 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 &lt;baruch@tkos.co.il&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/9fbf3664ce00f8b07867f1011834015f21d162a5.1707388458.git.baruch@tkos.co.il
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "Revert "mtd: rawnand: gpmi: Fix setting busy timeout setting""</title>
<updated>2024-02-23T07:25:15Z</updated>
<author>
<name>Max Krummenacher</name>
<email>max.krummenacher@toradex.com</email>
</author>
<published>2024-02-07T17:49:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=10c586da9f17a11de8fe835b099c081741afabb6'/>
<id>urn:sha1:10c586da9f17a11de8fe835b099c081741afabb6</id>
<content type='text'>
This reverts commit 15a3adfe75937c9e4e0e48f0ed40dd39a0e526e2.

The backport of [1] relies on having [2] also backported. Having only
one of the two results in a bogus hw-&gt;timing1 setting.

If only [2] is backportet the 16 bit register value likely underflows
resulting in a busy_wait_timeout of 0.
Or if only [1] is applied the value likely overflows with chances of
having last 16 LSBs all 0 which would then result in a
busy_wait_timeout of 0 too.

Both cases may lead to NAND data corruption, e.g. on a Colibri iMX7
setup this has been seen.

[1] commit 0fddf9ad06fd ("mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times")
[2] commit 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy timeout setting")

Signed-off-by: Max Krummenacher &lt;max.krummenacher@toradex.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mtd: spinand: macronix: Fix MX35LFxGE4AD page size</title>
<updated>2024-02-23T07:24:49Z</updated>
<author>
<name>JaimeLiao</name>
<email>jaimeliao@mxic.com.tw</email>
</author>
<published>2024-01-25T02:48:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=635a0039e87e6d674cec9f7341a70d4ae6be4560'/>
<id>urn:sha1:635a0039e87e6d674cec9f7341a70d4ae6be4560</id>
<content type='text'>
Support for MX35LF{2,4}GE4AD chips was added in mainline through
upstream commit 5ece78de88739b4c68263e9f2582380c1fd8314f.

The patch was later adapted to 5.4.y and backported through
stable commit 85258ae3070848d9d0f6fbee385be2db80e8cf26.

Fix the backport mentioned right above as it is wrong: the bigger chip
features 4kiB pages and not 2kiB pages.

Fixes: 85258ae30708 ("mtd: spinand: macronix: Add support for MX35LFxGE4AD")
Cc: stable@vger.kernel.org # v5.4.y
Cc: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: JaimeLiao &lt;jaimeliao@mxic.com.tw&gt;
Acked-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mtd: Fix gluebi NULL pointer dereference caused by ftl notifier</title>
<updated>2024-01-25T22:34:23Z</updated>
<author>
<name>ZhaoLong Wang</name>
<email>wangzhaolong1@huawei.com</email>
</author>
<published>2023-12-20T02:46:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1bf4fe14e97cda621522eb2f28b0a4e87c5b0745'/>
<id>urn:sha1:1bf4fe14e97cda621522eb2f28b0a4e87c5b0745</id>
<content type='text'>
[ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ]

If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
‘gluebi-&gt;desc’ in gluebi_read().

ubi_gluebi_init
  ubi_register_volume_notifier
    ubi_enumerate_volumes
      ubi_notify_all
        gluebi_notify    nb-&gt;notifier_call()
          gluebi_create
            mtd_device_register
              mtd_device_parse_register
                add_mtd_device
                  blktrans_notify_add   not-&gt;add()
                    ftl_add_mtd         tr-&gt;add_mtd()
                      scan_header
                        mtd_read
                          mtd_read_oob
                            mtd_read_oob_std
                              gluebi_read   mtd-&gt;read()
                                gluebi-&gt;desc - NULL

Detailed reproduction information available at the Link [1],

In the normal case, obtain gluebi-&gt;desc in the gluebi_get_device(),
and access gluebi-&gt;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: 2ba3d76a1e29 ("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 &lt;wangzhaolong1@huawei.com&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Acked-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response</title>
<updated>2024-01-25T22:34:22Z</updated>
<author>
<name>Ronald Monthero</name>
<email>debug.penguin32@gmail.com</email>
</author>
<published>2023-11-18T08:31:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f5ea2cf3bbb1741a3bcc314698de87ae0f3a39cf'/>
<id>urn:sha1:f5ea2cf3bbb1741a3bcc314698de87ae0f3a39cf</id>
<content type='text'>
[ Upstream commit 923fb6238cb3ac529aa2bf13b3b1e53762186a8b ]

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

[&lt;804b2047&gt;] (nand_get_device) from [&lt;804b5335&gt;] (nand_write_oob+0x1b/0x4a)
[&lt;804b5335&gt;] (nand_write_oob) from [&lt;804a3585&gt;] (mtd_write+0x41/0x5c)
[&lt;804a3585&gt;] (mtd_write) from [&lt;804c1d47&gt;] (ubi_io_write+0x17f/0x22c)
[&lt;804c1d47&gt;] (ubi_io_write) from [&lt;804c047b&gt;] (ubi_eba_write_leb+0x5b/0x1d0)

Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller")
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Ronald Monthero &lt;debug.penguin32@gmail.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/linux-mtd/20231118083156.776887-1-debug.penguin32@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
