20 Jan, 2021
1 commit
-
This is the 5.10.6 stable release
* tag 'v5.10.6': (21 commits)
Linux 5.10.6
mwifiex: Fix possible buffer overflows in mwifiex_cmd_802_11_ad_hoc_start
exec: Transform exec_update_mutex into a rw_semaphore
...Signed-off-by: Jason Liu
Conflicts:
drivers/rtc/rtc-pcf2127.c
09 Jan, 2021
1 commit
-
This reverts stable commit baad618d078c857f99cc286ea249e9629159901f.
This commit is adding lines to spinand_write_to_cache_op, wheras the upstream
commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 that this was supposed to
backport was touching spinand_read_from_cache_op.
It causes a crash on writing OOB data by attempting to write to read-only
kernel memory.Cc: Miquel Raynal
Signed-off-by: Felix Fietkau
Signed-off-by: Greg Kroah-Hartman
04 Jan, 2021
1 commit
-
This is the 5.10.4 stable release
* tag 'v5.10.4': (717 commits)
Linux 5.10.4
x86/CPU/AMD: Save AMD NodeId as cpu_die_id
drm/edid: fix objtool warning in drm_cvt_modes()
...Signed-off-by: Jason Liu
Conflicts:
drivers/gpu/drm/imx/dcss/dcss-plane.c
drivers/media/i2c/ov5640.c
30 Dec, 2020
12 commits
-
commit c13d845e9a69580424d40b7b101c37d4f71bcd63 upstream.
Arguments 'infolen' and 'datalen' to meson_nfc_dma_buffer_release() were mixed up.
Fixes: 8fae856c53500 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
Cc: stable@vger.kernel.org
Signed-off-by: Sergei Antonov
Acked-by: Liang Yang
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201028094940.11765-1-saproj@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit bc3686021122de953858a5be4cbf6e3f1d821e79 upstream.
After each codeword NAND_FLASH_STATUS is read for possible operational
failures. But there is no DMA sync for CPU operation before reading it
and this leads to incorrect or older copy of DMA buffer in reg_read_buf.This patch adds the DMA sync on reg_read_buf for CPU before reading it.
Fixes: 5bc36b2bf6e2 ("mtd: rawnand: qcom: check for operation errors in case of raw read")
Cc: stable@vger.kernel.org
Signed-off-by: Praveenkumar I
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/1602230872-25616-1-git-send-email-ipkumar@codeaurora.org
Signed-off-by: Greg Kroah-Hartman -
commit 1ca71415f075353974524e96ed175306d8a937a8 upstream.
Apply changes to usecount also to the master partition.
Otherwise we have no refcounting at all if an MTD has no partitions.Cc: stable@vger.kernel.org
Fixes: 46b5889cc2c5 ("mtd: implement proper partition handling")
Signed-off-by: Richard Weinberger
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201206202220.27290-1-richard@nod.at
Signed-off-by: Greg Kroah-Hartman -
commit 639a82434f16a6df0ce0e7c8595976f1293940fd upstream.
Some devices (especially QCA ones) are already using hardcoded partition
names with colons in it. The OpenMesh A62 for example provides following
mtd relevant information via cmdline:root=31:11 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(custom),64k(0:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) rootfsname=rootfs rootwait
The change to split only on the last colon between mtd-id and partitions
will cause newpart to see following string for the first partition:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive)
Such a partition list cannot be parsed and thus the device fails to boot.
Avoid this behavior by making sure that the start of the first part-name
("(") will also be the last byte the mtd-id split algorithm is using for
its colon search.Fixes: eb13fa022741 ("mtd: parser: cmdline: Support MTD names containing one or more colons")
Cc: stable@vger.kernel.org
Cc: Ron Minnich
Signed-off-by: Sven Eckelmann
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201124062506.185392-1-sven@narfation.org
Signed-off-by: Greg Kroah-Hartman -
commit 868cbe2a6dcee451bd8f87cbbb2a73cf463b57e5 upstream.
So far OOB have never been used in SPI-NAND, add the missing memcpy to
make it work properly.Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-6-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 7671edeb193910482a9b0c22cd32176e7de7b2ed ]
To get better performance, current gpmi driver collected and chained all
small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and
wait for complete at the end.But some random DMA timeout found in this new driver, with the help of
ftrace, we found the root cause is as follows:Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6
DMA transfers and the DMA chain triggered at the end. It waits for bch
completion and check jiffies if it's timeout. The typical function graph
shown below,63.216351 | 1) | gpmi_ecc_read_page() {
63.216352 | 1) 0.750 us | gpmi_bch_layout_std();
63.216354 | 1) | gpmi_nfc_exec_op() {
63.216355 | 1) | gpmi_chain_command() {
63.216356 | 1) | mxs_dma_prep_slave_sg() {
63.216357 | 1) | /* mxs chan ccw idx: 0 */
63.216358 | 1) 1.750 us | }
63.216359 | 1) | mxs_dma_prep_slave_sg() {
63.216360 | 1) | /* mxs chan ccw idx: 1 */
63.216361 | 1) 2.000 us | }
63.216361 | 1) 6.500 us | }
63.216362 | 1) | gpmi_chain_command() {
63.216363 | 1) | mxs_dma_prep_slave_sg() {
63.216364 | 1) | /* mxs chan ccw idx: 2 */
63.216365 | 1) 1.750 us | }
63.216366 | 1) | mxs_dma_prep_slave_sg() {
63.216367 | 1) | /* mxs chan ccw idx: 3 */
63.216367 | 1) 1.750 us | }
63.216368 | 1) 5.875 us | }
63.216369 | 1) | /* gpmi_chain_wait_ready */
63.216370 | 1) | mxs_dma_prep_slave_sg() {
63.216372 | 1) | /* mxs chan ccw idx: 4 */
63.216373 | 1) 3.000 us | }
63.216374 | 1) | /* gpmi_chain_data_read */
63.216376 | 1) | mxs_dma_prep_slave_sg() {
63.216377 | 1) | /* mxs chan ccw idx: 5 */
63.216378 | 1) 2.000 us | }
63.216379 | 1) 1.125 us | mxs_dma_tx_submit();
63.216381 | 1) 1.000 us | mxs_dma_enable_chan();
63.216712 | 0) 2.625 us | mxs_dma_int_handler();
63.216717 | 0) 4.250 us | bch_irq();
63.216723 | 0) 1.250 us | mxs_dma_tasklet();
63.216723 | 1) | /* jiffies left 250 */
63.216725 | 1) ! 372.000 us | }
63.216726 | 1) 2.625 us | gpmi_count_bitflips();
63.216730 | 1) ! 379.125 us | }but it's not gurantee that bch irq handled always after dma irq handled,
sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore,
another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ
handled, this messed up the next DMA chain and causes DMA timeout. Check
the trace log when issue happened.63.218923 | 1) | gpmi_ecc_read_page() {
63.218924 | 1) 0.625 us | gpmi_bch_layout_std();
63.218926 | 1) | gpmi_nfc_exec_op() {
63.218927 | 1) | gpmi_chain_command() {
63.218928 | 1) | mxs_dma_prep_slave_sg() {
63.218929 | 1) | /* mxs chan ccw idx: 0 */
63.218929 | 1) 1.625 us | }
63.218931 | 1) | mxs_dma_prep_slave_sg() {
63.218931 | 1) | /* mxs chan ccw idx: 1 */
63.218932 | 1) 1.750 us | }
63.218933 | 1) 5.875 us | }
63.218934 | 1) | gpmi_chain_command() {
63.218934 | 1) | mxs_dma_prep_slave_sg() {
63.218935 | 1) | /* mxs chan ccw idx: 2 */
63.218936 | 1) 1.875 us | }
63.218937 | 1) | mxs_dma_prep_slave_sg() {
63.218938 | 1) | /* mxs chan ccw idx: 3 */
63.218939 | 1) 1.625 us | }
63.218939 | 1) 5.875 us | }
63.218940 | 1) | /* gpmi_chain_wait_ready */
63.218941 | 1) | mxs_dma_prep_slave_sg() {
63.218942 | 1) | /* mxs chan ccw idx: 4 */
63.218942 | 1) 1.625 us | }
63.218943 | 1) | /* gpmi_chain_data_read */
63.218944 | 1) | mxs_dma_prep_slave_sg() {
63.218945 | 1) | /* mxs chan ccw idx: 5 */
63.218947 | 1) 2.375 us | }
63.218948 | 1) 0.625 us | mxs_dma_tx_submit();
63.218949 | 1) 1.000 us | mxs_dma_enable_chan();
63.219276 | 0) 5.125 us | bch_irq();
Reviewed-by: Sascha Hauer
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201209035104.22679-3-han.xu@nxp.com
Signed-off-by: Sasha Levin -
[ Upstream commit ad8566d3555c4731e6b48823b92d3929b0394c14 ]
Call clk_disable_unprepare(nfc->phase_rx) if the clk_set_rate() function
fails to avoid a resource leak.Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
Signed-off-by: Dan Carpenter
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/X8ikVCnUsfTpffFB@mwanda
Signed-off-by: Sasha Levin -
[ Upstream commit 1b391c7f2e863985668d705f525af3ceb55bc800 ]
pm_runtime_get_sync() will increment pm usage at first and it
will resume the device later. If runtime of the device has
error or device is in inaccessible state(or other error state),
resume operation will fail. If we do not call put operation to
decrease the reference, it will result in reference leak in
the two functions(gpmi_init and gpmi_nfc_exec_op). Moreover,
this device cannot enter the idle state and always stay busy or
other non-idle state later. So we fixed it through adding
pm_runtime_put_noidle.Fixes: 5bc6bb603b4d0 ("mtd: rawnand: gpmi: Fix suspend/resume problem")
Signed-off-by: Zhang Qilong
Acked-by: Han Xu
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201107110552.1568742-1-zhangqilong3@huawei.com
Signed-off-by: Sasha Levin -
[ Upstream commit 8c174d1511d235ed6c049dcb2b704777ad0df7a5 ]
These flashes have some weird BP bits mapping which aren't supported in
the current locking code. Just add a simple unlock op to unprotect the
entire flash array which is needed for legacy behavior.Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection")
Signed-off-by: Michael Walle
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
Link: https://lore.kernel.org/r/20201203162959.29589-7-michael@walle.cc
Signed-off-by: Sasha Levin -
[ Upstream commit e6204d4620276398ed7317d64c369813a1f96615 ]
This is considered bad for the following reasons:
(1) We only support the block protection with BPn bits for write
protection. Not all Atmel parts support this.
(2) Newly added flash chip will automatically inherit the "has
locking" support and thus needs to explicitly tested. Better
be opt-in instead of opt-out.
(3) There are already supported flashes which doesn't support
the locking scheme. So I assume this wasn't properly tested
before adding that chip; which enforces my previous argument
that locking support should be an opt-in.Remove the global flag and add individual flags to all flashes which
supports BP locking. In particular the following flashes don't support
the BP scheme:
- AT26F004
- AT25SL321
- AT45DB081DPlease note, that some flashes which are marked as SPI_NOR_HAS_LOCK just
support Global Protection, i.e. not our supported block protection
locking scheme. This is to keep backwards compatibility with the
current "unlock all at boot" mechanism. In particular the following
flashes doesn't have BP bits:
- AT25DF041A
- AT25DF321
- AT25DF321A
- AT25DF641
- AT26DF081A
- AT26DF161A
- AT26DF321Signed-off-by: Michael Walle
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
Link: https://lore.kernel.org/r/20201203162959.29589-4-michael@walle.cc
Signed-off-by: Sasha Levin -
[ Upstream commit bdb1a75e4b9df6861ec6a6e3e3997820d3cebabe ]
Just try to unlock the whole SPI-NOR flash array. Don't abort the
probing in case of an error. Justifications:
(1) For some boards, this just works because
spi_nor_write_16bit_sr_and_check() is broken and just checks the
second half of the 16bit. Once that will be fixed, SPI probe will
fail for boards which has hardware-write protected SPI-NOR flashes.
(2) Until now, hardware write-protection was the only viable solution
to use the block protection bits. This is because this very
function spi_nor_unlock_all() will be called unconditionally on
every linux boot. Therefore, this bits only makes sense in
combination with the hardware write-protection. If we would fail
the SPI probe on an error in spi_nor_unlock_all() we'd break
virtually all users of the block protection bits.
(3) We should try hard to keep the MTD working even if the flash might
not be writable/erasable.Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection")
Signed-off-by: Michael Walle
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
Link: https://lore.kernel.org/r/20201203162959.29589-3-michael@walle.cc
Signed-off-by: Sasha Levin -
[ Upstream commit 989d4b72bae3b05c1564d38e71e18f65b12734fb ]
This flash part actually has 4 block protection bits.
Please note, that this patch is just based on information of the
datasheet of the datasheet and wasn't tested.Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write protection")
Reported-by: Tudor Ambarus
Signed-off-by: Michael Walle
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
Link: https://lore.kernel.org/r/20201203162959.29589-2-michael@walle.cc
Signed-off-by: Sasha Levin
18 Dec, 2020
2 commits
-
* spi/next: (8 commits)
LF-20-3 mtd: spi-nor: Use 1 bit mode of spansion(s25fs512s) flash
dt-bindings: spi: spi-fsl-qspi: Add bindings of ls1088a and ls1012a
MLK-24713 spi: lpspi: disable lpspi module irq in DMA mode
MLK-24870-1: spi: spi-nxp-fspi: Use IPS to read data on iMX8DXL
MLK-23644: spi: spi-nxp-fspi: enable runtime pm for fspi
... -
* nand/next: (17 commits)
LF-2439: mtd: nand: raw: gpmi: fix the build error due to upstream change
MLK-23693-3: mtd: rawnand: gpmi: add imx8dxl nand support
LF-1977: mtd: rawnand: gpmi: gpmi clock setting workaround for imx6sx
MLK-24007: mtd: rawnand: gpmi: fix the random DMA timeout issue
LF-993: mtd: rawnand: gpmi: remove unbalanced runtime pm ops
...
14 Dec, 2020
18 commits
-
This is a workaround patch which uses only single bit mode of s25fs512s
flashSigned-off-by: Han Xu
Signed-off-by: Kuldeep Singh -
The latest upstream nand frame uses the new ecc configuration structure,
fixs local changes accordingly to avoid build error.Signed-off-by: Han Xu
Reviewed-by: Frank Li -
imx8dxl ddr3 board doesn't have CS control connected by default, add new
device tree property to specify imx8dxl ddr3 evk supports only one cs.Signed-off-by: Han Xu
Reviewed-by: Frank Li -
on i.mx6sx, when changing the gpmi clock to 100MHz for EDO 5 mode, the
clock framework try to change the root clock and lead to system hang,
add this work around to limit the 6sx gpmi clock to 88MHz as a
workaround before clock framework fix the issue.Signed-off-by: Han Xu
-
To get better performance, current gpmi driver collected and chained all
small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and
wait for complete at the end.But some random DMA timeout found in this new driver, with the help of
ftrace, we found the root cause is as follows:Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6
DMA transfers and the DMA chain triggered at the end. It waits for bch
completion and check jiffies if it's timeout. The typical function graph
shown below,63.216351 | 1) | gpmi_ecc_read_page() {
63.216352 | 1) 0.750 us | gpmi_bch_layout_std();
63.216354 | 1) | gpmi_nfc_exec_op() {
63.216355 | 1) | gpmi_chain_command() {
63.216356 | 1) | mxs_dma_prep_slave_sg() {
63.216357 | 1) | /* mxs chan ccw idx: 0 */
63.216358 | 1) 1.750 us | }
63.216359 | 1) | mxs_dma_prep_slave_sg() {
63.216360 | 1) | /* mxs chan ccw idx: 1 */
63.216361 | 1) 2.000 us | }
63.216361 | 1) 6.500 us | }
63.216362 | 1) | gpmi_chain_command() {
63.216363 | 1) | mxs_dma_prep_slave_sg() {
63.216364 | 1) | /* mxs chan ccw idx: 2 */
63.216365 | 1) 1.750 us | }
63.216366 | 1) | mxs_dma_prep_slave_sg() {
63.216367 | 1) | /* mxs chan ccw idx: 3 */
63.216367 | 1) 1.750 us | }
63.216368 | 1) 5.875 us | }
63.216369 | 1) | /* gpmi_chain_wait_ready */
63.216370 | 1) | mxs_dma_prep_slave_sg() {
63.216372 | 1) | /* mxs chan ccw idx: 4 */
63.216373 | 1) 3.000 us | }
63.216374 | 1) | /* gpmi_chain_data_read */
63.216376 | 1) | mxs_dma_prep_slave_sg() {
63.216377 | 1) | /* mxs chan ccw idx: 5 */
63.216378 | 1) 2.000 us | }
63.216379 | 1) 1.125 us | mxs_dma_tx_submit();
63.216381 | 1) 1.000 us | mxs_dma_enable_chan();
63.216712 | 0) 2.625 us | mxs_dma_int_handler();
63.216717 | 0) 4.250 us | bch_irq();
63.216723 | 0) 1.250 us | mxs_dma_tasklet();
63.216723 | 1) | /* jiffies left 250 */
63.216725 | 1) ! 372.000 us | }
63.216726 | 1) 2.625 us | gpmi_count_bitflips();
63.216730 | 1) ! 379.125 us | }but it's not gurantee that bch irq handled always after dma irq handled,
sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore,
another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ
handled, this messed up the next DMA chain and causes DMA timeout. Check
the trace log when issue happened.63.218923 | 1) | gpmi_ecc_read_page() {
63.218924 | 1) 0.625 us | gpmi_bch_layout_std();
63.218926 | 1) | gpmi_nfc_exec_op() {
63.218927 | 1) | gpmi_chain_command() {
63.218928 | 1) | mxs_dma_prep_slave_sg() {
63.218929 | 1) | /* mxs chan ccw idx: 0 */
63.218929 | 1) 1.625 us | }
63.218931 | 1) | mxs_dma_prep_slave_sg() {
63.218931 | 1) | /* mxs chan ccw idx: 1 */
63.218932 | 1) 1.750 us | }
63.218933 | 1) 5.875 us | }
63.218934 | 1) | gpmi_chain_command() {
63.218934 | 1) | mxs_dma_prep_slave_sg() {
63.218935 | 1) | /* mxs chan ccw idx: 2 */
63.218936 | 1) 1.875 us | }
63.218937 | 1) | mxs_dma_prep_slave_sg() {
63.218938 | 1) | /* mxs chan ccw idx: 3 */
63.218939 | 1) 1.625 us | }
63.218939 | 1) 5.875 us | }
63.218940 | 1) | /* gpmi_chain_wait_ready */
63.218941 | 1) | mxs_dma_prep_slave_sg() {
63.218942 | 1) | /* mxs chan ccw idx: 4 */
63.218942 | 1) 1.625 us | }
63.218943 | 1) | /* gpmi_chain_data_read */
63.218944 | 1) | mxs_dma_prep_slave_sg() {
63.218945 | 1) | /* mxs chan ccw idx: 5 */
63.218947 | 1) 2.375 us | }
63.218948 | 1) 0.625 us | mxs_dma_tx_submit();
63.218949 | 1) 1.000 us | mxs_dma_enable_chan();
63.219276 | 0) 5.125 us | bch_irq(); -
Removed the unbalanced pm_runtime_mark_last_busy and
pm_runtime_put_autosuspend in gpmi_nand_probe function, which causes
system hang when dumping register, since clock is off.Reviewed-by: Aisheng Dong
Signed-off-by: Han Xu -
set the GPMI CTRL1 GANGED_RDYBUSY bit so dirver can sense the R/B signal
from all CS.Reviewed-by: Frank Li
Signed-off-by: Han Xu -
Macro GPMI_IS_MX6 is used in gpmi driver but iMX6QP was not included,
add iMX6QP to GPMI_IS_MX6 defination to configure GPMI registers
correctly.Signed-off-by: Han Xu
Reviewed-by: Frank Li
-
When we tested the NAND on kernel 5.4, found bad block scan was skipped
since BBM options was not correctly set, as a workaround, we set it in
gpmi controller code. But this change is arbitrary since it doesn't know
which nand chip mounted.The root cause was found and fixed by the following commit, which fixed
the issue in micron nand chip driver that deal with BBM for 2K page NAND
only, and change the nand_bbm_get_next_page not just skip the scan bad
block process when no BBM option found.commit a3c4c2339f8948b0f578e938970303a7372e60c0
Author: Piotr Sroka
Date: Tue Sep 24 06:54:31 2019 +0100With this fix, the previous BBM change in gpmi driver can be reverted.
Signed-off-by: Han Xu
-
use the nand chip required ecc settings when datermind the BCH ECC
layout settings.Signed-off-by: Han Xu
-
add the debugfs files in gpmi-nand driver for kobs-ng
Signed-off-by: Han Xu
-
The code change updated the NAND driver BCH ECC layout algorithm to
support large oob size NAND chips(oob > 1024 bytes) and proposed a new
way to set ECC layout.Current implementation requires each chunk size larger than oob size so
the bad block marker (BBM) can be guaranteed located in data chunk. The
ECC layout always using the unbalanced layout(Ecc for both meta and
Data0 chunk), but for the NAND chips with oob larger than 1k, the driver
cannot support because BCH doesn’t support GF 15 for 2K chunk.The change keeps the data chunk no larger than 1k and adjust the ECC
strength or ECC layout to locate the BBM in data chunk. General idea for
large oob NAND chips is1.Try all ECC strength from the minimum value required by NAND spec to
the maximum one that works, any ECC makes the BBM locate in data chunk
can be chosen.2.If none of them works, using separate ECC for meta, which will add one
extra ecc with the same ECC strength as other data chunks. This extra
ECC can guarantee BBM located in data chunk, of course, we need to check
if oob can afford it.Previous code has two methods for ECC layout setting, the
legacy_set_geometry and set_geometry_by_ecc_info, the difference between
these two methods is, legacy_set_geometry set the chunk size larger chan
oob size and then set the maximum ECC strength that oob can afford.
While the set_geometry_by_ecc_info set chunk size and ECC strength
according to NAND spec. It has been proved that the first method cannot
provide safe ECC strength for some modern NAND chips, so in current
code,1. Driver read NAND parameters first and then chose the proper ECC
layout setting method.2. If the oob is large or NAND required data chunk larger than oob
size, chose set_geometry_for_large_oob, otherwise use
set_geometry_by_ecc_info3. legacy_set_geometry only used for some NAND chips does not
contains necessary information. So this is only a backup plan, it is NOT
recommended to use these NAND chips.Signed-off-by: Han Xu
-
gpmi_init function may return without marking the last_busy status for
runtime, which causes gpmi doesn't go to auto suspend. Also fixed the
issue that pinctrl set to wrong state and re-apply timing after system
resume.Signed-off-by: Han Xu
-
add the bad block options for gpmi-nand driver
Signed-off-by: Han Xu
-
fix the qxp clk name and some runtime suspend/resume issue
Signed-off-by: Han Xu
-
add all supported platform info
Signed-off-by: Han Xu
-
leverage the runtime pm for system suspend/resume
Signed-off-by: Han Xu
-
If the master mtd does not have any slave mtd partitions,
and its numeraseregions is one(only has one erease block), and
we attach the master mtd with : ubiattach -m 0 -d 0We will meet the error:
-------------------------------------------------------
root@freescale ~$ ubiattach /dev/ubi_ctrl -m 0 -d 0
UBI: attaching mtd0 to ubi0
UBI error: io_init: multiple regions, not implemented
ubiattach: error!: cannot attach mtd0
error 22 (Invalid argument)
-------------------------------------------------------In fact, if there is only one "erase block", we should not
prevent the attach.This patch fixes it.
Signed-off-by: Huang Shijie
(cherry picked from commit 361cdc47fc4c4db31c5485560cdabd94f409bd81)
(cherry picked from commit ebee7d74914fad3cf7223af84496811c9d2488a1)Signed-off-by: Vipul Kumar
Signed-off-by: Han Xu
12 Dec, 2020
5 commits
-
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-10-miquel.raynal@bootlin.com -
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-9-miquel.raynal@bootlin.com -
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-8-miquel.raynal@bootlin.com -
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.Add the necessary logic to be sure Hamming keeps being only a default.
Fixes: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-7-miquel.raynal@bootlin.com -
Originally, commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework
user input parsing bits") kind of broke the logic around the
initialization of several ECC engines.Unfortunately, the fix (which indeed moved the ECC initialization to
the right place) did not take into account the fact that a different
ECC algorithm could have been used thanks to a DT property,
considering the "Hamming" algorithm entry a configuration while it was
only a default.Add the necessary logic to be sure Hamming keeps being only a default.
Reported-by: Chris Packham
Fixes: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()")
Signed-off-by: Miquel Raynal
Tested-by: Chris Packham
Link: https://lore.kernel.org/linux-mtd/20201203190340.15522-6-miquel.raynal@bootlin.com