|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
| #
c2fc6b69 |
| 14-Jul-2023 |
Rob Herring <robh@kernel.org> |
mtd: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that me
mtd: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20230714174751.4060439-1-robh@kernel.org
show more ...
|
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9 |
|
| #
5145abeb |
| 16-Dec-2021 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
In a pipelined engine situation, we might either have the host which
internally has support for error correction, or have it us
mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device
In a pipelined engine situation, we might either have the host which
internally has support for error correction, or have it using an
external hardware block for this purpose. In the former case, the host
is also the ECC engine. In the latter case, it is not. In order to get
the right pointers on the right devices (for example: in order to devm_*
allocate variables), let's introduce this helper which can safely be
called by pipelined ECC engines in order to retrieve the right device
structure.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-16-miquel.raynal@bootlin.com
show more ...
|
| #
96489c1c |
| 16-Dec-2021 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: nand: ecc: Add infrastructure to support hardware engines
Add the necessary helpers to register/unregister hardware ECC engines
that will be called from ECC engine drivers.
Also add helpers to
mtd: nand: ecc: Add infrastructure to support hardware engines
Add the necessary helpers to register/unregister hardware ECC engines
that will be called from ECC engine drivers.
Also add helpers to get the right engine from the user
perspective. Keep a reference of the in use ECC engine in order to
prevent modules to be unloaded. Put the reference when the engine gets
retired.
A static list of hardware (only) ECC engines is setup to keep track of
the registered engines.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211216111654.238086-13-miquel.raynal@bootlin.com
show more ...
|
|
Revision tags: v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13 |
|
| #
00c15b78 |
| 01-Oct-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: spinand: Allow the case where there is no ECC engine
Even if this is not supposed to happen, there is no reason to fail the
probe if it was explicitly requested to use no ECC engine at all (for
mtd: spinand: Allow the case where there is no ECC engine
Even if this is not supposed to happen, there is no reason to fail the
probe if it was explicitly requested to use no ECC engine at all (for
instance, during development). This condition is met by just
commenting out the error on the OOB free bytes count after the
assignation of an ECC engine if none was provided (any other situation
would error out much earlier anyway).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20201001102014.20100-5-miquel.raynal@bootlin.com
show more ...
|
| #
da429b96 |
| 30-Sep-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: nand: Let on-die ECC engines be retrieved from the NAND core
Before making use of the ECC engines, we must retrieve them. Add the
necessary boilerplate.
Signed-off-by: Miquel Raynal <miquel.ra
mtd: nand: Let on-die ECC engines be retrieved from the NAND core
Before making use of the ECC engines, we must retrieve them. Add the
necessary boilerplate.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200930154109.3922-5-miquel.raynal@bootlin.com
show more ...
|
| #
53fbdeeb |
| 29-Sep-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: nand: Let software ECC engines be retrieved from the NAND core
Before making use of the ECC engines, we must retrieve them. Add the
boilerplate for the ones already available: software engines
mtd: nand: Let software ECC engines be retrieved from the NAND core
Before making use of the ECC engines, we must retrieve them. Add the
boilerplate for the ones already available: software engines (Hamming
and BCH).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-21-miquel.raynal@bootlin.com
show more ...
|
| #
51e7bf45 |
| 29-Sep-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: nand: ecc: Add an I/O request tweaking mechanism
Currently, BCH and Hamming engine are sharing the same
tweaking/restoring I/O mechanism: they need the I/O request to fully
cover the main/OOB a
mtd: nand: ecc: Add an I/O request tweaking mechanism
Currently, BCH and Hamming engine are sharing the same
tweaking/restoring I/O mechanism: they need the I/O request to fully
cover the main/OOB area. Let's make this code generic as sharing the
code between two drivers is already a win. Maybe other ECC engine
drivers will need it too.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-2-miquel.raynal@bootlin.com
show more ...
|
|
Revision tags: v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62 |
|
| #
a8c7ffdb |
| 27-Aug-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: nand: Introduce the ECC engine framework
Create a generic ECC engine framework. This is a base to instantiate ECC
engine objects.
If we really want to be generic, bindings must evolve, so here
mtd: nand: Introduce the ECC engine framework
Create a generic ECC engine framework. This is a base to instantiate ECC
engine objects.
If we really want to be generic, bindings must evolve, so here is the
new logic. The following three properties are mutually exclusive:
- The nand-no-ecc-engine boolean property is set and there is no
ECC engine to retrieve.
- The nand-use-soft-ecc-engine boolean property is set and the core
will force using the use of software correction.
- There is a nand-ecc-engine property pointing at a node which will
act as ECC engine.
It the later case, the property may reference:
- The NAND chip node itself (for the on-die ECC case).
- The parent node if the NAND controller embeds an ECC engine.
- Any other node being an external ECC controller as well.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-9-miquel.raynal@bootlin.com
show more ...
|
|
Revision tags: v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62 |
|
| #
a8c7ffdb |
| 27-Aug-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
mtd: nand: Introduce the ECC engine framework
Create a generic ECC engine framework. This is a base to instantiate ECC
engine objects.
If we really want to be generic, bindings
mtd: nand: Introduce the ECC engine framework
Create a generic ECC engine framework. This is a base to instantiate ECC
engine objects.
If we really want to be generic, bindings must evolve, so here is the
new logic. The following three properties are mutually exclusive:
- The nand-no-ecc-engine boolean property is set and there is no
ECC engine to retrieve.
- The nand-use-soft-ecc-engine boolean property is set and the core
will force using the use of software correction.
- There is a nand-ecc-engine property pointing at a node which will
act as ECC engine.
It the later case, the property may reference:
- The NAND chip node itself (for the on-die ECC case).
- The parent node if the NAND controller embeds an ECC engine.
- Any other node being an external ECC controller as well.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-9-miquel.raynal@bootlin.com
show more ...
|