| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit 36a65982a98c4bc72fdcfef2c4aaf90193746631 ]
When the NV-DDR interface is not supported by the NAND chip,
the value of onfi->nvddr_timing_modes is 0. In this case,
the best_mode variable value in nand_choose_best_nvddr_timings()
is -1. The last for-loop is skipped and the function returns an
uninitialized value.
If this returned value is 0, the nand_choose_best_sdr_timings()
is not executed and no 'best timing' are set. This leads the host
controller and the NAND chip working at default mode 0 timing
even if a better timing can be used.
Fix this uninitialized returned value.
nand_choose_best_sdr_timings() is pretty similar to
nand_choose_best_nvddr_timings(). Even if onfi->sdr_timing_modes
should never be seen as 0, nand_choose_best_sdr_timings() returned
value is fixed.
Fixes: a9ecc8c814e9 ("mtd: rawnand: Choose the best timings, NV-DDR included")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-3-herve.codina@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 16d8b628a4152e8e8b01b6a1d82e30208ee2dd30 ]
NAND_OP_CMD() expects a delay parameter in nanoseconds.
The delay value is wrongly given in milliseconds.
Fix the conversion macro used in order to set this
delay in nanoseconds.
Fixes: d7a773e8812b ("mtd: rawnand: Access SDR and NV-DDR timings through a common macro")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-2-herve.codina@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 9472335eaa1452b51dc8e8edaa1a342997cb80c7 upstream.
Under certain circumstances, the timing settings calculated by
the FSMC NAND controller driver were inaccurate.
These settings led to incorrect data reads or fallback to
timing mode 0 depending on the NAND chip used.
The timing computation did not take into account the following
constraint given in SPEAr3xx reference manual:
twait >= tCEA - (tset * TCLK) + TOUTDEL + TINDEL
Enhance the timings calculation by taking into account this
additional constraint.
This change has no impact on slow timing modes such as mode 0.
Indeed, on mode 0, computed values are the same with and
without the patch.
NANDs which previously stayed in mode 0 because of fallback to
mode 0 can now work at higher speeds and NANDs which were not
working at all because of the corrupted data work at high
speeds without troubles.
Overall improvement on a Micron/MT29F1G08 (flash_speed tool):
mode0 mode3
eraseblock write speed 3220 KiB/s 4511 KiB/s
eraseblock read speed 4491 KiB/s 7529 KiB/s
Fixes: d9fb079571833 ("mtd: nand: fsmc: add support for SDR timings")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-5-herve.codina@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a4ca0c439f2d5ce9a3dc118d882f9f03449864c8 upstream.
The FSMC NAND controller should apply a delay after the
instruction has been issued on the bus.
The FSMC NAND controller driver did not handle this delay.
Add this waiting delay in the FSMC NAND controller driver.
Fixes: 4da712e70294 ("mtd: nand: fsmc: use ->exec_op()")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-4-herve.codina@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7e3cdba176ba59eaf4d463d273da0718e3626140 upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-3-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-8-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 194ac63de6ff56d30c48e3ac19c8a412f9c1408e upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-6-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f16b7d2a5e810fcf4b15d096246d0d445da9cc88 upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-4-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-5-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Cc: Jan Hoffmann <jan@3e8.eu>
Cc: Kestrel seventyfour <kestrelseventyfour@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Jan Hoffmann <jan@3e8.eu>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-2-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9be1446ece291a1f08164bd056bed3d698681f8b upstream.
The introduction of the generic ECC engine API lead to a number of
changes in various drivers which broke some of them. Here is a typical
example: I expected the SM_ORDER option to be handled by the Hamming ECC
engine internals. Problem: the fsmc driver does not instantiate (yet) a
real ECC engine object so we had to use a 'bare' ECC helper instead of
the shiny rawnand functions. However, when not intializing this engine
properly and using the bare helpers, we do not get the SM ORDER feature
handled automatically. It looks like this was lost in the process so
let's ensure we use the right SM ORDER now.
Fixes: ad9ffdce4539 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-2-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit fc9e18f9e987ad46722dad53adab1c12148c213c ]
Under the following conditions:
* after rounding up by 4 the number of bytes to transfer (this is
related to the controller's internal constraints),
* if this (rounded) amount of data is situated beyond the end of the
device,
* and only in NV-DDR mode,
the Arasan NAND controller timeouts.
This currently can happen in a particular helper used when picking
software ECC algorithms. Let's prevent this situation by refusing to use
the NV-DDR interface with software engines.
Fixes: 4edde6031458 ("mtd: rawnand: arasan: Support NV-DDR interface")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211008163640.1753821-1-miquel.raynal@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 46a0dc10fb32bec3e765e51bf71fbc070dc77ca3 ]
ebu_nand_probe() read the value of u32 variable "cs" from the device
firmware description and used it as the index for array ebu_host->cs
that can contain MAX_CS (2) elements at most. That could result in
a buffer overflow and various bad consequences later.
Fix the potential buffer overflow by restricting values of "cs" with
MAX_CS in probe.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC")
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Co-developed-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210903082653.16441-1-novikov@ispras.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit b4ebddd6540d78a7f977b3fea0261bd575c6ffe2 upstream.
Following the introduction of the generic ECC engine infrastructure, it
was necessary to reorganize the code and move the ECC configuration in
the ->attach_chip() hook. Failing to do that properly lead to a first
series of fixes supposed to stabilize the situation. Unfortunately, this
only fixed the use of software ECC engines, preventing any other kind of
engine to be used, including on-die ones.
It is now time to (finally) fix the situation by ensuring that we still
provide a default (eg. software ECC) but will still support different
ECC engines such as on-die ECC engines if properly described in the
device tree.
There are no changes needed on the core side in order to do this, but we
just need to leverage the logic there which allows:
1- a subsystem default (set to Host engines in the raw NAND world)
2- a driver specific default (here set to software ECC engines)
3- any type of engine requested by the user (ie. described in the DT)
As the raw NAND subsystem has not yet been fully converted to the ECC
engine infrastructure, in order to provide a default ECC engine for this
driver we need to set chip->ecc.engine_type *before* calling
nand_scan(). During the initialization step, the core will consider this
entry as the default engine for this driver. This value may of course
be overloaded by the user if the usual DT properties are provided.
Fixes: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-9-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
From QPIC V2 onwards there is a separate register to read
last code word "QPIC_NAND_READ_LOCATION_LAST_CW_n".
qcom_nandc_read_cw_raw() is used to read only one code word
at a time. If we will configure number of code words to 1 in
in QPIC_NAND_DEV0_CFG0 register then QPIC controller thinks
its reading the last code word, since from QPIC V2 onwards
we are having separate register to read the last code word,
we have to configure "QPIC_NAND_READ_LOCATION_LAST_CW_n"
register to fetch data from controller buffer to system
memory.
Fixes: 503ee5aad430 ("mtd: rawnand: qcom: update last code word register")
Cc: stable@kernel.org
Signed-off-by: Md Sadre Alam <mdalam@codeaurora.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/1630998357-1359-1-git-send-email-mdalam@codeaurora.org
|
|
Merge more updates from Andrew Morton:
"147 patches, based on 7d2a07b769330c34b4deabeed939325c77a7ec2f.
Subsystems affected by this patch series: mm (memory-hotplug, rmap,
ioremap, highmem, cleanups, secretmem, kfence, damon, and vmscan),
alpha, percpu, procfs, misc, core-kernel, MAINTAINERS, lib,
checkpatch, epoll, init, nilfs2, coredump, fork, pids, criu, kconfig,
selftests, ipc, and scripts"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (94 commits)
scripts: check_extable: fix typo in user error message
mm/workingset: correct kernel-doc notations
ipc: replace costly bailout check in sysvipc_find_ipc()
selftests/memfd: remove unused variable
Kconfig.debug: drop selecting non-existing HARDLOCKUP_DETECTOR_ARCH
configs: remove the obsolete CONFIG_INPUT_POLLDEV
prctl: allow to setup brk for et_dyn executables
pid: cleanup the stale comment mentioning pidmap_init().
kernel/fork.c: unexport get_{mm,task}_exe_file
coredump: fix memleak in dump_vma_snapshot()
fs/coredump.c: log if a core dump is aborted due to changed file permissions
nilfs2: use refcount_dec_and_lock() to fix potential UAF
nilfs2: fix memory leak in nilfs_sysfs_delete_snapshot_group
nilfs2: fix memory leak in nilfs_sysfs_create_snapshot_group
nilfs2: fix memory leak in nilfs_sysfs_delete_##name##_group
nilfs2: fix memory leak in nilfs_sysfs_create_##name##_group
nilfs2: fix NULL pointer in nilfs_##name##_attr_release
nilfs2: fix memory leak in nilfs_sysfs_create_device_group
trap: cleanup trap_init()
init: move usermodehelper_enable() to populate_rootfs()
...
|
|
HZ unit conversion macros are available in units.h, use them and remove
the duplicate definition.
Link: https://lkml.kernel.org/r/20210816114732.1834145-10-daniel.lezcano@linaro.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Christian Eggers <ceggers@arri.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Lukasz Luba <lukasz.luba@arm.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Miquel Raynal:
"MTD changes:
- blkdevs:
- Simplify the refcounting in blktrans_{open, release}
- Simplify blktrans_getgeo
- Remove blktrans_ref_mutex
- Simplify blktrans_dev_get
- Use lockdep_assert_held
- Don't hold del_mtd_blktrans_dev in blktrans_{open, release}
- ftl:
- Don't cast away the type when calling add_mtd_blktrans_dev
- Don't cast away the type when calling add_mtd_blktrans_dev
- Use container_of() rather than cast
- Fix use-after-free
- Add discard support
- Allow use of MTD_RAM for testing purposes
- concat:
- Check _read, _write callbacks existence before assignment
- Judge callback existence based on the master
- maps:
- Maps: remove dead MTD map driver for PMC-Sierra MSP boards
- mtdblock:
- Warn if added for a NAND device
- Add comment about UBI block devices
- Update old JFFS2 mention in Kconfig
- partitions:
- Redboot: convert to YAML
NAND core changes:
- Repair Miquel Raynal's email address in MAINTAINERS
- Fix a couple of spelling mistakes in Kconfig
- bbt: Skip bad blocks when searching for the BBT in NAND
- Remove never changed ret variable
Raw NAND changes:
- cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()'
- intel: Fix error handling in probe
- omap: Fix kernel doc warning on 'calcuate' typo
- gpmc: Fix the ECC bytes vs. OOB bytes equation
SPI-NAND core changes:
- Properly fill the OOB area.
- Fix comment
SPI-NAND drivers changes:
- macronix: Add Quad support for serial NAND flash"
* tag 'mtd/for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (30 commits)
mtd: rawnand: cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()'
mtd_blkdevs: simplify the refcounting in blktrans_{open, release}
mtd_blkdevs: simplify blktrans_getgeo
mtd_blkdevs: remove blktrans_ref_mutex
mtd_blkdevs: simplify blktrans_dev_get
mtd/rfd_ftl: don't cast away the type when calling add_mtd_blktrans_dev
mtd/ftl: don't cast away the type when calling add_mtd_blktrans_dev
mtd_blkdevs: use lockdep_assert_held
mtd_blkdevs: don't hold del_mtd_blktrans_dev in blktrans_{open, release}
mtd: rawnand: intel: Fix error handling in probe
mtd: mtdconcat: Check _read, _write callbacks existence before assignment
mtd: mtdconcat: Judge callback existence based on the master
mtd: maps: remove dead MTD map driver for PMC-Sierra MSP boards
mtd: rfd_ftl: use container_of() rather than cast
mtd: rfd_ftl: fix use-after-free
mtd: rfd_ftl: add discard support
mtd: rfd_ftl: allow use of MTD_RAM for testing purposes
mtdblock: Warn if added for a NAND device
mtd: spinand: macronix: Add Quad support for serial NAND flash
mtdblock: Add comment about UBI block devices
...
|
|
'cafe_nand_probe()'
A successful 'init_rs_non_canonical()' call should be balanced by a
corresponding 'free_rs()' call in the error handling path of the probe, as
already done in the remove function.
Update the error handling path accordingly.
Fixes: 8c61b7a7f4d4 ("[MTD] [NAND] Use rslib for CAFÉ ECC")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr
|
|
ebu_nand_probe() did not invoke ebu_dma_cleanup() and
clk_disable_unprepare() on some error handling paths. The patch fixes
that.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC")
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Co-developed-by: Anton Vasilyev <vasilyev@ispras.ru>
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210817092930.23040-1-novikov@ispras.ru
|
|
The ret variable used for returning value in the function
`meson_nfc_rw_cmd_prepare_and_execute` is never change after initialising.
Therefore, we can remove it safely and return 0 at the end of the function.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210803113300.24230-1-wangborong@cdjrlc.com
|
|
Fix a trivial typo which is reported after enabling W=1 level of warnings:
drivers/mtd/nand/raw/omap2.c:927: warning: expecting prototype
for omap_calcuate_ecc(). Prototype was for omap_calculate_ecc() instead
Signed-off-by: Vladimir Molokov <vladimir@molokov.se>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210801205909.7102-1-vladimir@molokov.se
|
|
Due to 14f97f0b8e2b, the rawnand platforms without "secure-regions"
property defined in DT fails to probe. The issue is,
of_get_nand_secure_regions() errors out if
of_property_count_elems_of_size() returns a negative error code.
If the "secure-regions" property is not present in DT, then also we'll
get -EINVAL from of_property_count_elems_of_size() but it should not
be treated as an error for platforms not declaring "secure-regions"
in DT.
So fix this behaviour by checking for the existence of that property in
DT and return 0 if it is not present.
Fixes: 14f97f0b8e2b ("mtd: rawnand: Add a check in of_get_nand_secure_regions()")
Reported-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Tested-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210727062813.32619-1-manivannan.sadhasivam@linaro.org
|
|
There are two spelling mistakes in the Kconfig text. Fix them.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210704094705.37175-1-colin.king@canonical.com
|
|
The blocks containing the bad block table can become bad as well. So
make sure to skip any blocks that are marked bad when searching for the
bad block table.
Otherwise in very rare cases where two BBT blocks wear out it might
happen that an obsolete BBT is used instead of a newer available
version.
This only applies to drivers which make use of a bad block marker in flash.
Other drivers won't be able to identify bad BBT blocks and thus can't skip
these.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210625123821.207458-1-s.riedmueller@phytec.de
|
|
Check for whether of_property_count_elems_of_size() returns a negative
error code.
Fixes: 13b89768275d ("mtd: rawnand: Add support for secure regions in NAND memory")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/YMtQFXE0F1w7mUh+@mwanda
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Richard Weinberger:
"MTD core changes:
- Convert list_for_each to entry variant
- Use MTD_DEVICE_ATTR_RO/RW() helper macros
- Remove unnecessary OOM messages
- Potential NULL dereference in mtd_otp_size()
- Fix freeing of otp_info buffer
- Create partname and partid debug files for child MTDs
- tests:
- Remove redundant assignment to err
- Fix error return code in mtd_oobtest_init()
- Add OTP NVMEM provider support
- Allow specifying of_node
- Convert sysfs sprintf/snprintf family to sysfs_emit
Bindings changes:
- Convert ti,am654-hbmc.txt to YAML schema
- spi-nor: add otp property
- Add OTP bindings
- add YAML schema for the generic MTD bindings
- Add brcm,trx-magic
MTD device drivers changes:
- Add support for microchip 48l640 EERAM
- Remove superfluous "break"
- sm_ftl:
- Fix alignment of block comment
- nftl:
- Return -ENOMEM when kmalloc failed
- nftlcore:
- Remove set but rewrite variables
- phram:
- Fix error return code in phram_setup()
- plat-ram:
- Remove redundant dev_err call in platram_probe()
MTD parsers changes:
- Qcom:
- Fix leaking of partition name
- Redboot:
- Fix style issues
- Seek fis-index-block in the right node
- trx:
- Allow to use TRX parser on Mediatek SoCs
- Allow to specify brcm, trx-magic in DT
Raw NAND core:
- Allow SDR timings to be nacked
- Bring support for NV-DDR timings which involved a number of small
preparation changes to bring new helpers, properly introduce NV-DDR
structures, fill them, differenciate them and pick the best timing
set.
- Add the necessary infrastructure to parse the new gpio-cs property
which aims at enlarging the number of available CS when a hardware
controller is too constrained.
- Update dead URL
- Silence static checker warning in nand_setup_interface()
- BBT:
- Fix corner case in bad block table handling
- onfi:
- Use more recent ONFI specification wording
- Use the BIT() macro when possible
Raw NAND controller drivers:
- Atmel:
- Ensure the data interface is supported.
- Arasan:
- Finer grain NV-DDR configuration
- Rename the data interface register
- Use the right DMA mask
- Leverage additional GPIO CS
- Ensure proper configuration for the asserted target
- Add support for the NV-DDR interface
- Fix a macro parameter
- brcmnand:
- Convert bindings to json-schema
- OMAP:
- Various fixes and style improvements
- Add larger page NAND chips support
- PL35X:
- New driver
- QCOM:
- Avoid writing to obsolete register
- Delete an unneeded bool conversion
- Allow override of partition parser
- Marvell:
- Minor documentation correction
- Add missing clk_disable_unprepare() on error in
marvell_nfc_resume()
- R852:
- Use DEVICE_ATTR_RO() helper macro
- MTK:
- Remove redundant dev_err call in mtk_ecc_probe()
- HISI504:
- Remove redundant dev_err call in probe
SPI-NAND core:
- Light reorganisation for the introduction of a core resume handler
- Fix double counting of ECC stats
SPI-NAND manufacturer drivers:
- Macronix:
- Add support for serial NAND flash
SPI NOR core changes:
- Ability to dump SFDP tables via sysfs
- Support for erasing OTP regions on Winbond and similar flashes
- Few API doc updates and fixes
- Locking support for MX25L12805D
SPI NOR controller drivers changes:
- Use SPI_MODE_X_MASK in nxp-spifi
- Intel Alder Lake-M SPI serial flash support"
* tag 'mtd/for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (125 commits)
mtd: spi-nor: remove redundant continue statement
mtd: rawnand: omap: Add larger page NAND chips support
mtd: rawnand: omap: Various style fixes
mtd: rawnand: omap: Check return values
mtd: rawnand: omap: Rename a macro
mtd: rawnand: omap: Aggregate the HW configuration of the ELM
mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller
dt-bindings: mtd: pl353-nand: Describe this hardware controller
MAINTAINERS: Add PL353 NAND controller entry
mtd: rawnand: qcom: avoid writing to obsolete register
mtd: rawnand: marvell: Minor documentation correction
mtd: rawnand: r852: use DEVICE_ATTR_RO() helper macro
mtd: spinand: add SPI-NAND MTD resume handler
mtd: spinand: Add spinand_init_flash() helper
mtd: spinand: add spinand_read_cfg() helper
mtd: rawnand: marvell: add missing clk_disable_unprepare() on error in marvell_nfc_resume()
mtd: rawnand: arasan: Finer grain NV-DDR configuration
mtd: rawnand: arasan: Rename the data interface register
mtd: rawnand: onfi: Fix endianness when reading NV-DDR values
mtd: rawnand: arasan: Use the right DMA mask
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/next
Raw NAND core:
* Allow SDR timings to be nacked
* Bring support for NV-DDR timings which involved a number of small
preparation changes to bring new helpers, properly introduce NV-DDR
structures, fill them, differenciate them and pick the best timing set.
* Add the necessary infrastructure to parse the new gpio-cs property
which aims at enlarging the number of available CS when a hardware
controller is too constrained.
* Update dead URL
* Silence static checker warning in nand_setup_interface()
* BBT:
- Fix corner case in bad block table handling
* onfi:
- Use more recent ONFI specification wording
- Use the BIT() macro when possible
Raw NAND controller drivers:
* Atmel:
- Ensure the data interface is supported.
* Arasan:
- Finer grain NV-DDR configuration
- Rename the data interface register
- Use the right DMA mask
- Leverage additional GPIO CS
- Ensure proper configuration for the asserted target
- Add support for the NV-DDR interface
- Fix a macro parameter
* brcmnand:
- Convert bindings to json-schema
* OMAP:
- Various fixes and style improvements
- Add larger page NAND chips support
* PL35X:
- New driver
* QCOM:
- Avoid writing to obsolete register
- Delete an unneeded bool conversion
- Allow override of partition parser
* Marvell:
- Minor documentation correction
- Add missing clk_disable_unprepare() on error in marvell_nfc_resume()
* R852:
- Use DEVICE_ATTR_RO() helper macro
* MTK:
- Remove redundant dev_err call in mtk_ecc_probe()
* HISI504:
- Remove redundant dev_err call in probe
SPI-NAND core:
* Light reorganisation for the introduction of a core resume handler
* Fix double counting of ECC stats
SPI-NAND manufacturer drivers:
* Macronix:
- Add support for serial NAND flash
|
|
There is no reason to be limited to 4kiB page NAND chips just because
this is the maximum length the ELM is able to handle in one go. Just
call the ELM several times and it will process as many data as needed.
Here we introduce the concept of ECC page (which is at most 4kiB). The
ELM will be sought as many times as there are ECC pages.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Ryan Barnett <ryan.barnett@collins.com>
Link: https://lore.kernel.org/linux-mtd/20210610134906.3503303-6-miquel.raynal@bootlin.com
|
|
Fix the comments style, declare the variables in a reverse Christmas
tree order, add an upper case character at the beginning of a sentence.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210610134906.3503303-5-miquel.raynal@bootlin.com
|
|
Check the return value of many helpers which might return error codes.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210610134906.3503303-4-miquel.raynal@bootlin.com
|
|
The macro BADBLOCK_MARKER_LENGTH is pretty long and could be reduced to
BBM_LEN which is more handy to use in the code.
This is a purely cosmetic change and is only done to avoid further
change to contain 100+ char lines just because of this definition.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210610134906.3503303-3-miquel.raynal@bootlin.com
|
|
Instead of calling elm_config() for each possible BCH configuration,
just save the BCH configuration that must be applied and use it in a
single call at the bottom.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210610134906.3503303-2-miquel.raynal@bootlin.com
|
|
This hardware controller is embedded in XilinX Zynq-7000 SoCs and has
partial support for Hamming ECC correction.
This work is inspired from the original contributions of Punnaiah
Choudary Kalluri and Naga Sureshkumar Relli.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Michael Walle <michael@walle.cc> [on zynq-7000]
Link: https://lore.kernel.org/linux-mtd/20210610082040.2075611-19-miquel.raynal@bootlin.com
|
|
QPIC_EBI2_ECC_BUF_CFG register got obsolete from QPIC V2.0 onwards.
Avoid writing this register if QPIC version is V2.0 or newer.
Signed-off-by: Md Sadre Alam <mdalam@codeaurora.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/1623134916-562-1-git-send-email-mdalam@codeaurora.org
|
|
Kernel test robot throws below warning ->
drivers/mtd/nand/raw/marvell_nand.c:454: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Minor documentation correction.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210607193736.4654-1-jrdr.linux@gmail.com
|
|
Use DEVICE_ATTR_RO() helper macro instead of plain DEVICE_ATTR(), which
makes the code a bit shorter and easier to read.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210603123339.12089-1-thunder.leizhen@huawei.com
|
|
marvell_nfc_resume()
Add clk_disable_unprepare() on error path in marvell_nfc_resume().
Fixes: bd9c3f9b3c00 ("mtd: rawnand: marvell: add suspend and resume hooks")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210601125814.3260364-1-yangyingliang@huawei.com
|
|
Add support for the timings register which may improve a bit the
overall throughput.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210527084959.208804-2-miquel.raynal@bootlin.com
|
|
There are 2 timing registers:
- "data interface"
- "timings"
So far, the "data interface" register was named "timings" which begins
misleading when bringing support for the "timings" register. Rename it
to "data_iface".
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210527084959.208804-1-miquel.raynal@bootlin.com
|
|
Without the use of le16_to_cpu(), these accesses would have been wrong
on a big-endian machine.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 45606518f961 ("mtd: rawnand: Add onfi_fill_nvddr_interface_config() helper")
Fixes: 9310668fb60a ("mtd: rawnand: Retrieve NV-DDR timing modes from the ONFI parameter page")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210527084913.208635-1-miquel.raynal@bootlin.com
|
|
Xilinx ZynqMP SoC and the Arasan controller support 64-bit DMA
addressing. Define the right mask otherwise the default is 32
and some accesses may overflow the default mask.
Reported-by: Jorge Courett <jorge.courett@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Jorge Courett <jorge.courett@gmail.com>
Link: https://lore.kernel.org/linux-mtd/20210527084548.208429-1-miquel.raynal@bootlin.com
|
|
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Remove it can help us save a bit of memory.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210610020958.15023-1-thunder.leizhen@huawei.com
|
|
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory' message
Remove it can help us save a bit of memory.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210610020620.14970-1-thunder.leizhen@huawei.com
|
|
The result of an expression consisting of a single relational operator is
already of the bool type and does not need to be evaluated explicitly.
No functional change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210510114944.3527-1-thunder.leizhen@huawei.com
|
|
Make use of the cs-gpios DT property as well as the core helper to parse
it so that the Arasan controller driver can now assert many more chips
than natively.
The Arasan controller has an internal limitation: RB0 is tied to CS0 and
RB1 is tied to CS1. Hence, it is possible to use external GPIOs as long
as one or the other native CS is not used (or configured to be driven as
a GPIO) and that all additional CS are physically wired on its
corresponding RB line. Eg. CS0 is used as a native CS, CS1 is not used
as native CS and may be used as a GPIO CS, CS2 is an additional GPIO
CS. Then the target asserted by CS0 should also be wired to RB0, while
the targets asserted by CS1 and CS2 should be wired to RB1.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210526093242.183847-5-miquel.raynal@bootlin.com
|
|
The controller being always asserting one CS or the other, there is no
need to actually select the right target before doing a page read/write.
However, the anfc_select_target() helper actually also changes the
timing configuration and clock in the case were two different NAND chips
with different timing requirements would be used. In this situation, we
must ensure proper configuration of the controller by calling it.
As a consequence of this change, the anfc_select_target() helper is
being moved earlier in the driver.
Fixes: 88ffef1b65cf ("mtd: rawnand: arasan: Support the hardware BCH ECC engine")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210526093242.183847-4-miquel.raynal@bootlin.com
|
|
New chips may feature a lot of CS because of their extended length. As
many controllers have been designed a decade ago, they usually only
feature just a couple. This does not mean that the entire range of
these chips cannot be accessed: it is just a matter of adding more
GPIO CS in the hardware design. A DT property has been added to
describe the CS array: cs-gpios.
Here is the code parsing it this new property, allocating what needs to
be, requesting the GPIOs and returning an array with the additional
available CS. The first entries of this array are left empty and are
reserved for native CS.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210526093242.183847-3-miquel.raynal@bootlin.com
|
