| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
While working a bit on this driver I dropped the platform includes and
commented a few lines just to verify the correctness of my changes. It
appeared the following:
drivers/mtd/nand/raw/au1550nd.c: In function ‘au1550nd_waitrdy’:
drivers/mtd/nand/raw/au1550nd.c:130:3: error: implicit declaration of function ‘usleep_range’ [-Werror=implicit-function-declaration]
usleep_range(10, 100);
^~~~~~~~~~~~
drivers/mtd/nand/raw/au1550nd.c: In function ‘au1550nd_exec_instr’:
drivers/mtd/nand/raw/au1550nd.c:188:3: error: implicit declaration of function ‘ndelay’ [-Werror=implicit-function-declaration]
ndelay(instr->delay_ns);
^~~~~~
I think the delay.h header should be included in this file and not
come from one of its platform includes, so let's add it here.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
The NAND ECC core is included in the generic NAND core when it is
compiled in.
Different software ECC engines drivers will select the NAND ECC core
and thus also have a dependency on the NAND core. Using a "depends on"
between the two leads to possible cases (not real cases, but created
by robots) where one is still unselected because of the "select does
not verifies depends on" game:
WARNING: unmet direct dependencies detected for MTD_NAND_ECC
Depends on [n]: MTD [=m] && MTD_NAND_CORE [=n]
Selected by [m]:
- MTD_NAND_ECC_SW_HAMMING [=y] && MTD [=m]
- MTD_NAND_ECC_SW_BCH [=y] && MTD [=m]
Fix this by using a select instead.
Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Acked-by: Randy Dunlap <[email protected]> # build-tested
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Moving files around produced the following warnings:
Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c
Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c
Fix one by just dropping the reference because it is not relevant, the
other by using a better noun instead of a file name.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
i.MX is a devicetree-only platform now and the existing platform data
support in this driver was only useful for old non-devicetree platforms.
Get rid of the platform data support since it is no longer used.
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Sascha Hauer <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
of_find_device_by_node() already takes a reference to the device, and
ingenic_ecc_release() will drop the reference. So, the get_device() in
ingenic_ecc_get() is redundand.
Fixes: 15de8c6efd0e("mtd: rawnand: ingenic: Separate top-level and SoC specific code")
Signed-off-by: Yu Kuai <[email protected]>
Acked-by: Paul Cercueil <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This code has been written in 2008 and is fine, but in order to keep
robots happy, I think it's time to change a little bit this code just
to clarify the different possible values of eccsize_mult. Indeed, this
variable may only take the value 1 or 2 because step_size, in the case
of the software Hamming ECC engine may only be 256 or 512. Depending
on the value of eccsize_mult, an extra rp17 variable is set, or not
and triggers the following warning:
smatch warnings:
ecc_sw_hamming_calculate() error: uninitialized symbol 'rp17'.
As highlighted by Dan Carpenter, if the only possible values for
eccsize_mult are 1 and 2, then the code is fine, but "it's hard to
tell just from looking".
So instead of shifting step_size, let's use a ternary condition to
assign to eccsize_mult the only two possible values and clarify the
driver's logic.
Now that the situation is clarified for humans, ensure rp17 is
initialized to 0 to keep compilers and robots silent as well.
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This patch enables NAND MDMA (MBUS DMA) mode for
the Allwinner SoCs A23/A33/H3.
The DMA transfer method gets sets now to MBUS DMA as default for
the sun8i-a23-nand-controller (till now DMA transfer was executed
via the shared DMA engine).
The main advantage is more bandwidth for the users of the shared DMA
engine and also that the MBUS DMA setup requires less configuration
effort. For example you don't need to define a dedicated DMA channel
in the device-tree any more.
Reviewed-by: Boris Brezillon <[email protected]>
Signed-off-by: Manuel Dipolt <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
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: [email protected]
Signed-off-by: Sergei Antonov <[email protected]>
Acked-by: Liang Yang <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Some identifiers have different names between their prototypes
and the kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/9ed47a57d12c40e73a9b01612ee119d39baa6236.1603469755.git.mchehab+huawei@kernel.org
|
|
Add the compatible string for IPQ6018 QPIC NAND controller
version 1.5.0. It's properties are same as IPQ8074, so reuse
the same.
Signed-off-by: Kathiravan T <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Add the binding for the QPIC NAND used on IPQ6018 SoC.
Signed-off-by: Kathiravan T <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
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: [email protected]
Signed-off-by: Praveenkumar I <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
The extra gpmi_nand.o object is not needed anymore since
commit 3045f8e36963 ("mtd: rawnand: gpmi: move all driver
code into single file").
Signed-off-by: Marco Felsch <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This comment is no longer true so drop it.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
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: [email protected]
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Now that all the logic is available in the NAND core, let's use it
from the SPI-NAND core. Right now there is no functional change as the
default ECC engine for SPI-NANDs is set to 'on-die', but user can now
use software correction if they want to by just setting the right
properties in the DT.
Also note that the OOB layout handling is removed from the SPI-NAND
core as each ECC engine is supposed to handle it by it's own; users
should not be aware of that.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This property does not describe very well its purpose: it describes
the ECC engine type. Deprecate it in favor of nand-ecc-engine which
points to either the NAND part itself in case of on-die ECC, or to the
parent node in case of an integrated ECC engine in the NAND controller
(previously referred as "hardware") or to another node in case of an
external controller. Other "modes" (none/software) are achieved with
the new nand-use-soft-ecc-engine and nand-no-ecc-engine properties.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Add the logic in the NAND core to find the right ECC engine depending
on the NAND chip requirements and the user desires. Right now, the
choice may be made between (more will come):
* software Hamming
* software BCH
* on-die (SPI-NAND devices only)
Once the ECC engine has been found, the ECC engine must be
configured.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
The SPI-NAND layer default is on-die ECC because until now it was the
only one supported. New SPI-NAND chip flavors might use something else
as ECC engine provider but this will always be the default if the user
does not choose explicitly something else.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Before making use of the ECC engines, we must retrieve them. Add the
necessary boilerplate.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Make use of the existing functions taken from the SPI-NAND core to
instantiate an on-die ECC engine specific to the SPI-NAND core. The
next step will be to tweak the core to use this object instead of
calling the helpers directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Prepare the creation of a SPI-NAND on-die ECC engine by gathering the
ECC-related code earlier enough in the core to avoid the need for
forward declarations.
The next step is to actually create that engine by implementing the
generic ECC interface.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
One comment in the SPI-NAND core is not very clear, fix it to ease the
understanding of what the block does.
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Let's continue introducing the generic ECC engine abstraction in the
NAND subsystem by instantiating a second ECC engine: software
Hamming.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
There is no reason to always embed the software Hamming ECC engine
implementation. By default it is (with raw NAND), but we can let the
user decide.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Most of the includes are simply useless, drop them.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This code is meant to be reused by the SPI-NAND core. Now that the
driver has been cleaned and reorganized, use a generic ECC engine
object to store the driver's data instead of accessing members of the
nand_chip structure. This means adding proper init/cleanup helpers.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Prefix by ecc_sw_hamming_ the functions which should be internal only
but are exported for "raw" operations.
Prefix by nand_ecc_sw_hamming_ the other functions which will be used
in the context of the declaration of an Hamming proper ECC engine
object.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Various style fixes.
There is not functional change.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Some functions should never have been exported (the ones prefixed by
__*), in this case simply drop the documentation, we never want
anybody to use this function from the outside.
For the other functions, enhance the style.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
The include file pretends being the header for "ECC algorithm", while
it is just the header for the Hamming implementation. Make this clear
by rewording the sentence.
Do the same with the module description.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Hamming ECC code might be later re-used by the SPI NAND layer.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
nand_ecc_ctrl embeds a private pointer which only has a meaning in the
sunxi driver. This structure will soon be deprecated, but as this
field is actually not needed, let's just drop it.
Cc: Maxime Ripard <[email protected]>
Cc: Chen-Yu Tsai <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Let's continue introducing the generic ECC engine abstraction in the
NAND subsystem by instantiating a first ECC engine: the software
BCH one.
While at it, make a very tidy ecc_sw_bch_init() function and move all
the sanity checks and user input management in
nand_ecc_sw_bch_init_ctx(). This second helper will be called from the
raw RAND core.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This code is meant to be reused by the SPI-NAND core. Now that the
driver has been cleaned and reorganized, use a generic ECC engine
object to store the driver's data instead of accessing members of the
nand_chip structure.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
These functions must be usable by the main NAND core, so their names
must be technology-agnostic as well as the parameters. Hence, we pass
a generic nand_device instead of a raw nand_chip structure.
As it seems that changing the raw NAND functions to always pass a
generic NAND device is a lost of time, we prefer to create dedicated
raw NAND wrappers that will be useful in the near future to do the
translation.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Like for any other compilation option, use the IS_ENABLED() macro
instead of hardcoding it.
By droping this helper we can get rid of the BCH header in nandsim.c.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
When a function is not available, returning -ENOTSUPP makes much more
sense than returning -1.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
The NAND BCH control structure has nothing to do outside of this
driver, all users of the nand_bch_init/free() functions just save it
to chip->ecc.priv so do it in this driver directly and return a
regular error code instead.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Fix function headers, capitals and reword a little bit the comments
to make this driver more readable.
There is not functional change.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
BCH ECC code might be later re-used by the SPI NAND layer.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fixes from Thomas Gleixner:
"Two more places which invoke tracing from RCU disabled regions in the
idle path.
Similar to the entry path the low level idle functions have to be
non-instrumentable"
* tag 'locking-urgent-2020-11-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
intel_idle: Fix intel_idle() vs tracing
sched/idle: Fix arch_cpu_idle() vs tracing
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Thomas Gleixner:
"Two fixes for irqchip drivers:
- Save and restore the GICV3 ITS state unconditionally on
suspend/resume to handle firmware which fails to do so.
- Use the correct index into the fwspec parameters to read the irq
trigger type in the EXIU chip driver"
* tag 'irq-urgent-2020-11-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/gic-v3-its: Unconditionally save/restore the ITS state on suspend
irqchip/exiu: Fix the index of fwspec for IRQ type
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull EFI fixes from Borislav Petkov:
"More EFI fixes forwarded from Ard Biesheuvel:
- revert efivarfs kmemleak fix again - it was a false positive
- make CONFIG_EFI_EARLYCON depend on CONFIG_EFI explicitly so it does
not pull in other dependencies unnecessarily if CONFIG_EFI is not
set
- defer attempts to load SSDT overrides from EFI vars until after the
efivar layer is up"
* tag 'efi-urgent-for-v5.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi: EFI_EARLYCON should depend on EFI
efivarfs: revert "fix memory leak in efivarfs_create()"
efi/efivars: Set generic ops before loading SSDT
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Borislav Petkov:
"A couple of urgent fixes which accumulated this last week:
- Two resctrl fixes to prevent refcount leaks when manipulating the
resctrl fs (Xiaochen Shen)
- Correct prctl(PR_GET_SPECULATION_CTRL) reporting (Anand K Mistry)
- A fix to not lose already seen MCE severity which determines
whether the machine can recover (Gabriele Paoloni)"
* tag 'x86_urgent_for_v5.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Do not overwrite no_way_out if mce_end() fails
x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
x86/resctrl: Add necessary kernfs_put() calls to prevent refcount leak
x86/resctrl: Remove superfluous kernfs_get() calls to prevent refcount leak
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Palmer Dabbelt:
"I've collected a handful of fixes over the past few weeks:
- A fix to un-break the build-id argument to the vDSO build, which is
necessary for the LLVM linker.
- A fix to initialize the jump label subsystem, without which it (and
all the stuff that uses it) doesn't actually function.
- A fix to include <asm/barrier.h> from <vdso/processor.h>, without
which some drivers won't compile"
* tag 'riscv-for-linus-5.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
RISC-V: fix barrier() use in <vdso/processor.h>
RISC-V: Add missing jump label initialization
riscv: Explicitly specify the build id style in vDSO Makefile again
|