| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Miquel Raynal:
"Core MTD:
- Fixes to the virt-concat driver
- Added INT0800 firmware-flash map driver
- mtdblock: prevent reclaim I/O during request processing
- cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an x8 device
Raw NAND:
- Clean up the Qualcomm controller driver again
- Improve / create Arasan and IBM
- Reflect that ESMT and GigaDevice share ID 0xc8, and disable broken
timings feature on GD9FU2G8F3A
- Drop platform data support from the lpc32xx drivers
SPI NAND:
- Heyangtek uses two bytes for the BBM like every other device
- Winbond: Add support for W25N04LW and W25N08LW
- Support for ISSI SPI NAND flashes
SPI NOR:
- Support for new Macronix and (lots of) Winbond flash devices
- Rewrite the status register handling. There were many small helper
functions to enable quad I/O mode in many different ways. That's
now consolidated in one generic function.
- Rework the SFPD handling. It used to be only parsed for flashes
present in the in-kernel database which had any of the multi-I/O
bit set - or with the addition of generic flash driver for any
unknown flashes. This left a gap where SFDP wasn't handled and it
turns out newer flashes (with SFDP support) will reused IDs of just
these old flashed. With the rework, SFDP is tried to be parsed for
any flashes and will amend the information which is already present
in the in-kernel database.
- Increase SFDP size limit to 16KiB. There are flashes which have
some larger gaps between tables and thus exceeds the former 4KiB
limit.
- Flash fixups are getting more and more common. Due to this, the
fixups are now a separate list (per manufacturer) instead of being
attached to a specific flash. A new .match() callback makes them
more flexible, when one is applied.
- Support 1-1-8 and 1-8-8 modes with larger flashes which need 4byte
addresses
Then there is the load of API updates and misc AI fixes"
* tag 'mtd/for-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (155 commits)
mtd: spi-nor: sfdp: reduce stack usage in spi_nor_parse_sfdp()
mtd: spi-nor: sfdp: fix missing kernel-doc
mtd: parsers: qcom: fix offset/size overflow on large partitions
mtd: spinand: heyangtek: Reserve both bad block marker bytes
mtd: rawnand: pl353: fix clk reference leak in pl35x_nfc_setup_interface()
mtd: nand: use dmaengine_submit() instead of ->tx_submit()
dt-bindings: mtd: convert IBM NDFC binding to YAML
mtd: rawnand: fsl_ifc: allocate shared ctrl with devm_kzalloc
mtd: rawnand: qcom: fix read location register usage in config_nand_cw_read()
mtd: rawnand: qcom: move common code to the 'qpic_common' module
mtd: rawnand: qcom: rename 'nand_stats' structure
mtd: rawnand: qcom: make nandc_set_read_loc_last() more generic
mtd: rawnand: qcom: make nandc_set_read_loc_first() more generic
mtd: rawnand: qcom: make config_nand_cw_write() more generic
mtd: rawnand: qcom: make config_nand_page_write() more generic
mtd: rawnand: qcom: make config_nand_page_read() more generic
mtd: rawnand: qcom: make check_flash_errors() more generic
dt-bindings: mtd: arasan: Add "power-domains" for ZynqMP
mtd: virt-concat: unlink discarded items before freeing
mtd: virt-concat: unlink concat node before freeing it
...
|
|
SPI NOR changes for 7.4
- Support for new Macronix and (lots of) Winbond flash devices
- The addition of the Winbond flashes was accompanied by a big rewrite of the
status register handling. There were many small helper functions to enable
quad I/O mode in many different ways. That's now consolidated in one generic
function.
- The SFPD handling was reworked. It used to be only parsed for flashes present
in the in-kernel database which had any of the multi-I/O bit set - or with the
addition of generic flash driver for any unknown flashes. This left a gap
where SFDP wasn't handled and it turns out newer flashes (with SFDP support)
will reused IDs of just these old flashed. With the rework, SFDP is tried to
be parsed for any flashes and will amend the information which is already
present in the in-kernel database.
- SFDP size limit was increased to 16KiB. There are flashes which have some
larger gaps between tables and thus exceeds the former 4KiB limit.
- Flash fixups are getting more and more common. Due to this, the fixups are now
a separate list (per manufacturer) instead of being attached to a specific
flash. A new .match() callback makes them more flexible, when one is applied.
- 1-1-8 and 1-8-8 modes are now supported with larger flashes which needs 4byte
addresses.
|
|
Raw NAND:
- The Qualcomm controller driver has been cleaned up again.
- Arasan and IBM have been improved/created.
- Reflect that ESMT and GigaDevice share ID 0xc8, and disable broken
timings feature on GD9FU2G8F3A.
- Platform data support has been dropped from the lpc32xx drivers.
SPI NAND:
- Heyangtek uses two bytes for the BBM like every other device.
- Winbond: Add support for W25N04LW and W25N08LW.
- Support for ISSI SPI NAND flashes.
Then there is the load of API updates and misc AI fixes.
|
|
The 'qpic_common' module provides some generic functions which are
usable by both the 'qcom_nandc' and by the 'spi-qpic-snand' driver.
Move more code from the 'qcom_nandc' driver to there in order to
allow using those also from the 'spi-qpic-snand' driver.
No functional changes.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Drop a superfluous empty line from the end of the 'bam_positions'
structure group within the 'bam_transaction' structure.
No functional changes.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The kernel-doc heading for struct spinand_manufacturer_ops misspells
and truncates its name as manufacurer_ops. As a result, kernel-doc cannot
match the comment to the structure declaration.
Use the structure's actual name.
Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
We currently print through sysfs and debugfs the name of the part if the
.name field, which is legacy, has been filled in the ID table (otherwise
"(null)" is printed). These IDs had an interest until manufacturers
started re-using more and more extensively the so called unique JEDEC
IDs. At this stage, a name that was tailored for a chip sold in 2016 may
no longer be relevant for a chip sold in 2026. Still showing this name
through the various filesystems may confuse people, removing these names
cannot be done since they are now part of the user ABI (because of
sysfs).
In order to allow overwriting the .name field (which is part of a
read-only structure), let's create a spi-nor pointer which will by
default point to that .name, but which can be cleared in fixup hooks to
make sure the name is hidden on newer parts.
Reviewed-by: Takahiro Kuwano <takahiro.kuwano@infineon.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
|
|
Revision F of the JEDEC JESD216 standard includes yet another
supported setting in the QER 3-bit bitfield: 110b.
This setting implies that the QE bit is bit 1 of SR2 (which is an
already supported case) but this time it makes it very clear that both
reading and writing to SR2 is supported, but not with the usual
opcodes. The write operation uses an alternate WRSR2 opcode:
0x31 (instead of 0x3E) and both the reads and writes manipulate a single
register at a time.
Reviewed-by: Takahiro Kuwano <takahiro.kuwano@infineon.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
|
|
SPI NOR has a lot of history. Additions over additions, the subtleties
of the JESD216 specification, their implementations by the manufacturers
and the hardware mistakes have generated a gigantic maze, let's try to
understand what is really needed.
The specification explains the QE (Quad Enable) bitfield as describing
where the bit to enable the Quad capability is, but also how to set
it. Unfortunately, the specification is not precise about what opcodes
are supported exactly in all the cases. There is an introduction that
basically states:
- Opcode 0x05 reads SR1
- Opcode 0x35 reads SR2
- Opcode 0x01 writes SR1, and then SR2 if another byte is written
Then the bitfield, among indicating the location of the QE bit, may
indicate:
- Reading SR1 and SR2 in one operation is not possible (loops over the
content of SR1)
- Reading SR2 directly is possible
- Only writing SR1 zeroes SR2.
One problem with the current implementation, is that it only focuses on
the QE bit. A quad_enable function was created for each case, even
though in practice, the logic was always the same: read, modify, write,
read back and verify. One problem comes when other features need to play
with the status registers, like software block protection or OTP: you
never know how to properly handle the QE bit, nor where it is, nor how
to read/write the Status registers. This lead to
approximations/guessing (in swp.c, otp.c and obviously in legacy
controller drivers like atmel.c) but also to the implementation of a
gazillon of helpers for reading/writing/checking the status registers.
In addition, I believe some design decisions had a negative impact over
the years.
- All possible situations had to be flagged by the core. This is likely
wrong, because we no longer know why we need specific quirks. It was
ineherent to the state of the SPI NOR core before the great cleanup
that had happened the past few years. I believe this creates confusion
in the core today, and we should push this to vendor fixups
instead. As an example, in 2023 Hsin-Yi was facing an issue because
his chip was setting the wrong QER value, leading to RDCR being
prevented, thus falling into a condition blindly setting a random QE
bit (I strongy believe it is done like that for wrong reasons). His
chip actually had RDCR support! The correct fix should have been to
mark the capability in a device fixup instead of handling this in the
core.
Link: https://lore.kernel.org/lkml/CAJMQK-hR0eaO0b4Vd0U8_KAndLyZapqdHjVLAoe42rWi9rdLkA@mail.gmail.com/
- SFDP parsing is over cautious. I believe
BFPT_DWORD15_QER_SR2_BIT1_NO_RD is abusive (nothing states that RDCR is
not supported), and BFPT_DWORD15_QER_SR2_BIT1 is also out of
specification when forcing 16-bit Status writes.
- SNOR_F_HAS_16BIT_SR is only imposing 16bit Status writes, whereas
reads can still be 8-bit wide.
- The usage of helpers verifying the writes was also spread for IMHO no
really good reason. Why shouldn't we trust spi operations when it
comes to Status Registers? We do not read back our page reads, so why
status registers should be treated with so much care, if it's not
because we are unsure of what is being done? My proposal includes a
check when it comes to the QE bit (done once) but we don't need these
checks otherwise. If the QE bit was written properly, there are high
chances that the other register accesses will just be fine, no?
Asde from my main quest, I also observed no good reason to ask the
read/write status register callers to use nor->bouncebuf while the
low-level helpers could do it themselves (we are talking about one or
two bytes being copied).
So after these observations, my proposal is the following:
- Create private low level helpers that just read or write a status
register. They are flexible, we can give the opcode (which varies
based on the SFDP QER field) and the length (1 or 2).
- Create public generic accessors which will be used to read/write sr1
and/or sr2. This is where all the cleverness shall be. The helpers use
the available opcodes for a given chip in order to fullfill the
request.
- Provide a single generic ->quad_enable() hook which generically does
all the steps mentioned above (read, modify, write, read back and
verify).
- Create a list of opcodes for all 6 possible situations:
{read, write} {sr1, sr2, sr1 and sr2}. These opcodes are
filled/cleared based on the QER field. An opcode set to 0 indicates
the absence of support (there is no 0x00 opcode in SPI NOR).
I tried my best to analyze the current behavior and to mimic it as much
as possible, but this is a risky cleanup. However, if we go for this, it
will be *much* easier in the future to handle all kind of chip
variations. We won't be limited to a couple of flags anymore, but rather
we'll be able to just disable a read or write capability using a single
line.
Known deviations:
- The Atmel manufacturer driver drives non SFDP chips which by default
were receiving the HAS_16B_WR flag, forcing SR2 writes all the times,
but it was deliberately making single bytes writes to SR1 for its
locking operations. The flag is likely wrong for them, so I removed
it.
- I am proposing on purpose a single quad_enable helper. It should match
all the cases, with 1 identified difference which I believe is
harmless: in the SR2_BIT7 case, the helper would make an extra SR1
read/write which was not done before. This entry explicitly supports
reading and writing the two registers. Note: no manufacturer has been
identified to actually use that entry yet.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
|
|
When "nand-no-ecc-engine" is set in DT, nanddev_get_ecc_engine() takes
the NAND_ECC_ENGINE_TYPE_NONE path and returns success while leaving
nand->ecc.engine NULL. The SPI-NAND code nevertheless dereferences it
unconditionally to test for a pipelined engine, so probing such a
device oopses immediately.
Rather than open-coding the test three times, add a
nand_ecc_is_pipelined() helper to the NAND core that folds the NULL
check into the integration comparison, and use it everywhere. Future
callers then cannot reintroduce the problem.
Fixes: f9d7c7265bcf ("mtd: spinand: Create direct mapping descriptors for ECC operations")
Cc: stable@vger.kernel.org
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Since NXP LPC32xx SoC support in the Linux kernel strictly depends on
device tree support, the unused platform data support can be removed
from the NAND MLC driver.
Signed-off-by: Vladimir Zapolskiy <vz@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Since NXP LPC32xx SoC support in the Linux kernel strictly depends on
device tree support, the unused platform data support can be removed
from the NAND SLC driver.
Signed-off-by: Vladimir Zapolskiy <vz@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Add a new manufacturer driver for ISSI SPI NAND devices (manufacturer
ID 0x9d). The following devices are supported:
- IS37/IS38SMW01G8B: 1Gb, 1.8V
- IS37/IS38SMW02G8B: 2Gb, 1.8V
- IS37/IS38SML04G8B: 4Gb, 3.3V, 2-die stacked
- IS37/IS38SMW04G8B: 4Gb, 1.8V, 2-die stacked
Signed-off-by: Bill Lee <blee@issi.com>
Signed-off-by: Jeff Kim <jekim@issi.com>
Signed-off-by: Han Xu <han.xu@nxp.com>
Link: https://patch.msgid.link/20260825-spinand_issi-v1-1-d81bdd7c212d@nxp.com
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Right now the SFDP parsing code is modifying both members of
struct spi_nor_flash_parameter and struct spi_nor. This may lead to
inconsistencies if the parsing fails because only the flash parameters
are rolled back.
To fix this, move the flags into the struct spi_nor_flash_parameter.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260601125438.3481722-1-mwalle%40kernel.org?part=3
Signed-off-by: Michael Walle <mwalle@kernel.org>
|
|
Right now the SFDP parsing code is modifying both members of
struct spi_nor_flash_parameter and struct spi_nor. This may lead to
inconsistencies if the parsing fails because only the flash parameters
are rolled back.
To fix this, move cmd_ext_type into the struct spi_nor_flash_parameter.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260601125438.3481722-1-mwalle%40kernel.org?part=3
Signed-off-by: Michael Walle <mwalle@kernel.org>
|
|
QPIC v1.5 requires using the OP_PAGE_READ_ONFI_READ command, but is missing
the rest of the hardware changes that are currently covered by the QPIC v2
(qpic_version2) check in the driver. Split that into an extra
has_onfi_read_op feature flag so it can be separately enabled.
No functional change.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The HeYangTek HYF1GQ4UDACAE is a 1 Gbit (128 MiB) SLC SPI-NAND with
2048 + 64 byte pages and on-die 4-bit / 512-byte ECC; its JEDEC
manufacturer ID is 0xc9. The die is GD5F1GQ4-compatible, so the OOB
layout is taken from the in-tree gd5fxgq4xa. The die exposes only a
coarse 2-bit ECC status with no fine-grained bitflip-count register, so
the status is decoded into a representative number of corrected bitflips.
It is found, among others, on some Keenetic KN-3411 (Buddy 6) units.
Datasheet:
https://www.heyangtek.cn/previewfile.jsp?file=ABUIABA9GAAgwsvRnwYo-eDpsgc
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
* Extend SPI NAND continuous read to Winbond devices, which requires
numerous changes in the spi-{mem,nand} layers such as the need for a
secondary read operation template.
* Continuous reads in general have also been enhanced/fixed for avoiding
potential issues at probe time and at block boundaries.
Plus, there is the usual load of misc fixes and improvements.
|
|
The current locking implementation allows to select a power of two
number of blocks, which is going to be the protected amount, as well as
telling whether this is the data at the top (end of the device) or the
bottom (beginning of the device). This means at most we can cover half
of the device or the entire device, but nothing in between.
The complement feature allows a much finer grain of configuration, by
allowing to invert what is considered locked and unlocked.
Add support for this feature. The only known position for the CMP bit is
bit 6 of the configuration register.
The locking and unlocking logics are kept unchanged if the CMP bit is
unavailable. Otherwise, once the regular logic has been applied, we
check if we already found an optimal configuration. If not, we try with
the CMP bit set. If the coverage is closer to the request, we use it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
The qcom_nand_controller had a struct nand_controller *controller
pointer that was assigned to (struct nand_controller *)&nandc[1],
with the allocation oversized by sizeof(*controller) to make room.
get_qcom_nand_controller() then walked backwards from chip->controller
using sizeof()-based arithmetic to recover the enclosing nandc.
Embed the nand_controller directly into qcom_nand_controller and use
container_of() in get_qcom_nand_controller(). The header now needs
the full rawnand.h definition rather than a forward declaration.
Assisted-by: Claude:Opus-4.7
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
This patch adds support for the randomizer feature.
It introduces a 'set_randomizer' callback in 'struct spinand_info' and
'struct spinand_device'.
If a driver implements this callback, the core will invoke it during
device initialization (spinand_init) to enable or disable the randomizer
feature based on the device tree configuration.
Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
In order to be able to generate debugfs output without having to
actually reach the flash, create a SPI NOR local cache of the status
registers. What matters in our case are all the bits related to sector
locking. As such, in order to make it clear that this cache is not
intended to be used anywhere else, we zero the irrelevant bits.
The cache is initialized once during the early init, and then maintained
every time the write protection scheme is updated.
Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
There are two status registers, named 1 and 2. The current wording is
misleading as "1" may refer to the status register ID as well as the
number of bytes required (which, in this case can be 1 or 2).
Clarify the comments by aligning them on the same pattern:
"{read,write} status {1,2} register"
Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
|
|
In case a chip supports continuous reads, but uses a slightly different
cache operation for these, it may provide a secondary operation template
which will be used only during continuous cache read operations.
From a vendor driver point of view, enabling this feature implies
providing a new set of templates for these continuous read
operations. The core will automatically pick the fastest variant,
depending on the hardware capabilities.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Aside from preparation changes in the SPI NAND core, the changes carried
here focus on the shared spi-mem layer which is enhanced in order to
bring two new features:
- The possibility to fill a primary and a secondary operation template
in the direct mapping structure in order to support continuous reads
in SPI NAND, which may require two different read operations.
- SPI controllers may indicate possible CS instabilities over long
transfers by setting a boolean. This capability is related to the
previous one, the need for it has arised while testing SPI NAND
continuous reads with the Cadence QSPI controller which cannot, under
certain conditions, keep the CS asserted for the length of
an eraseblock-large transfer.
|
|
Direct mappings are very static concepts, which allow us to reuse a
template to perform reads or writes in a very efficient manner after a
single initialization. With the introduction of pipelined ECC engines
for SPI controllers, the need to differentiate between an operation with
and without correction has arised. The chosen solution at that time has
been to create new direct mappings for these operations, jumping from 2
to 4 dirmaps per target. Enabling ECC was done by choosing the correct
dirmap.
Today, we need to further parametrize dirmaps. With the goal to enable
continuous reads on a wider range of devices, we will need more
flexibility regarding the read from cache operation template to pick at
run time, for instance to use shorter "continuous read from cache"
variants.
We could create other direct mappings, but it would increase the matrix
by a power of two, bringing the theoretical number of dirmaps to
8 (read/write, ecc, shorter read variants) per target. This grow is not
sustainable, so let's change how dirmaps work - a little bit.
Operations already carry an ECC parameter, use it to indicate whether
error correction is required or not. In practice this change happens
only at the core level, SPI controller drivers do not care about the
direct mapping structure in this case, they just pick whatever is in the
template as a base. As a result, we allow the core to dynamically change
the content of the templates.
He who can do more can do less, so during the checking steps, make sure
to enable the ECC requirement just for the time of the checks.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
This helper is going to be needed in a vendor driver, so expose it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Some devices stuff address bits in the double byte opcode (in place of
the repeated byte) in order to be able to increase the size of the
devices, without adding extra address bytes.
Create a flag to identify those devices. When the flag is set, use the
"packed" variant for the read data operation.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The main changes happened in the SunXi driver in order to
support new versions of the Allwinner NAND controller.
There are also some DT-binding improvements and cleanups.
Finally a couple of actual fixes (Realtek ECC and Winbond SPI NAND),
aside with the usual load of misc changes.
|
|
A flex array can be used to reduce the allocation to 1.
And actually mtdconcat was using the pointer + 1 trick to point to the
overallocated area. Better alternatives exist.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Mention that we are declaring the main SPI NAND flags with a comment.
Align the values with tabs.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Introducing CONFIG_MTD_VIRT_CONCAT to separate the legacy flow from the new
approach, where only the concatenated partition is registered as an MTD
device, while the individual partitions that form it are not registered
independently, as they are typically not required by the user.
CONFIG_MTD_VIRT_CONCAT is a boolean configuration option that depends on
CONFIG_MTD_PARTITIONED_MASTER. When enabled, it allows flash nodes to be
exposed as individual MTD devices along with the other partitions.
The solution focuses on fixed-partitions description only as it depends on
device boundaries. It supports multiple sets of concatenated devices, each
comprising two or more partitions.
flash@0 {
reg = <0>;
partitions {
compatible = "fixed-partitions";
part0@0 {
part-concat-next = <&flash0_part1>;
label = "part0_0";
reg = <0x0 0x800000>;
};
flash0_part1: part1@800000 {
label = "part0_1";
reg = <800000 0x800000>;
};
part2@1000000 {
part-concat-next = <&flash1_part0>;
label = "part0_2";
reg = <0x800000 0x800000>;
};
};
};
flash@1 {
reg = <1>;
partitions {
compatible = "fixed-partitions";
flash1_part0: part1@0 {
label = "part1_0";
reg = <0x0 0x800000>;
};
part1@800000 {
label = "part1_1";
reg = <0x800000 0x800000>;
};
};
};
The partitions that gets created are
flash@0
part0_0-part0_1-concat
flash@1
part1_1
part0_2-part1_0-concat
Suggested-by: Bernhard Frauendienst <kernel@nospam.obeliks.de>
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
To enable a more generic approach for concatenating MTD devices,
struct mtd_concat should be accessible beyond the mtdconcat driver.
Therefore, the definition is being moved to a header file.
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Create a new bus interface named ODTR for "octal DTR", which matches the
following pattern: 8D-8D-8D.
Add octal DTR support for all the existing core operations. Add a second
set of templates for this bus interface.
Give the possibility for drivers to register their read, write and
update cache variants as well as their vendor specific operations.
Check the SPI controller driver supports all the octal DTR commands that
we might need before switching to the ODTR bus interface.
Make the switch by calling ->configure_chip() with the ODTR
parameter. Fallback in case this step fails.
If someone ever attempts to suspend a chip in octal DTR mode, there are
changes that it will loose its configuration at resume. Prevent any
problem by explicitly switching back to SSDR while suspending. Note:
there is a limitation in the current approach, page I/Os are not
available as the dirmaps will be created for the ODTR bus interface if
that option is supported and not switched back to SSDR during
suspend. Switching them is possible but would be costly and would not
bring anything as right after resuming we will switch again to ODTR. In
case this capability is used for debug, developpers should mind to
destroy and recreate suitable direct mappings.
Finally, as a side effect, we increase the buffer for reading IDs to
6. No device at this point returns 6 bytes, but we support 5 bytes IDs,
which means in octal DTR mode we have no other choice than reading an
even number of bytes, hence 6.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The chip configuration hook is the one responsible to actually switch
the switch between bus interfaces. It is natural to give it the bus
interface we expect with a new parameter. For now the only value we can
give is SSDR, but this is subject to change in the future, so add a bit
of extra logic in the implementations of this callback to make sure
both the core and the chip driver are aligned on the request.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Create a bus interface enumeration, currently only containing the
one we support: SSDR, for single SDR, so any operation whose command is
sent over a single data line in SDR mode, ie. any operation matching
1S-XX-XX.
The main spinand_device structure gets a new parameter to store this
enumeration, for now unused. Of course it is set to SSDR during the SSDR
templates initialization to further clarify the state we are in at the
moment.
This member is subject to be used to know in which bus configuration we
and be updated by the core when we switch to faster mode(s).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
It is probably safe to expect that all SPI controller drivers will ever
support all the most basic SPI NAND operations, such as write enable,
register reads, page program, block erases, etc. However, what about
vendor specific operations? So far nobody complained about it, but as we
are about to introduce octal DTR support, and as none of the SPI NAND
instruction set is defined in any standard, we must remain careful about
these extra operations.
One way to make sure we do not blindly get ourselves in strange
situations with vendor commands failing silently is to make the check
once for all, while probing the chip. However at this stage we have no
such list, so let's add the necessary infrastructure to allow:
- registering vendor operations,
- checking they are actually supported when appropriate.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Create a SPINAND_OP() macro to which we give the name of the operation
we want. This macro retrieves the correct operation template based on
the current bus interface (currently only single SDR, will soon be
extended to octal DTR) and fills it with the usual parameters.
This macro makes the transition from calling directly the low-level
macros into using the (bus interface dependent) templates very smooth.
Use it in all places that can be trivially converted. At this stage
there is no functional change expected, until octal DTR support gets
added.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Currently, the SPI NAND core implementation directly calls macros to get
the various operations in shape. These macros are specific to the bus
interface, currently only supporting the single SDR interface (any
command following the 1S-XX-XX pattern).
Introducing support for other bus interfaces (such as octal DTR) would
mean that every user of these macros should become aware of the current
bus interface and act accordingly, picking up and adapting to the
current configuration. This would add quite a bit of boilerplate, be
repetitive as well as error prone in case we miss one occurrence.
Instead, let's create a table with all SPI NAND memory operations that
are currently supported. We initialize them with the same single SDR _OP
macros as before. This opens the possibility for users of the individual
macros to make use of these templates instead. This way, when we will add
another bus interface, we can just switch to another set of templates
and all users will magically fill in their spi_mem_op structures with
the correct ops.
The existing read, write and update cache variants are also moved in
this template array, which is barely noticeable by callers as we also
add a structure member pointing to it.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
In order to introduce templates for all operations and not only for page
helpers (in order to introduce octal DDR support), decouple the WR_EN
and WR_DIS operations into two separate macros.
Adapt the callers accordingly.
There is no functional change.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
SPI NAND command values are directly included in the macros defining the
ops. These are stale definitions, they are unused so drop them.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
The @data buffer is 5 bytes, not 4, it has been extended for the need of
devices with an extra ID bytes.
Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs")
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
spi: Octal DTR support
This series adds support for 8D-8D-8D in SPI NAND, which can already be
leveraged without any SPI changes as controllers already have this
support for some SPI NOR devices.
Among the few spi-mem patches, they are needed for building the SPI NAND
changes (especially the ODTR introduction at the end) and therefore an
immutable tag will be needed for merging in the MTD tree (unless all the
series goes through MTD directly ofc).
|
|
In a vain attempt to consolidate the email zoo switch everything to the
kernel.org account.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Add support for Dosilicon DS35Q1GA (3.3V) and DS35M1GA (1.8V) SPI NAND.
These are 1Gbit (128MB) devices with:
- 2048 byte pages + 64 byte OOB
- 64 pages per block, 1024 blocks
- On-die 4-bit ECC per 512 byte sector
The 64-byte OOB area is divided into 4 segments of 16 bytes, with each
segment containing 8 bytes of user data (M2+M1) and 8 bytes of ECC
parity (R1). This provides 30 bytes of usable OOB space after reserving
2 bytes for the bad block marker.
Tested on Genexis Platinum 4410 (EcoNet EN751221) by writing known
patterns to OOB and verifying ECC parity placement in R1 regions.
Datasheet:
https://www.dosilicon.com/resources/SPI%20NAND/DS35X1GAXXX_rev08.pdf
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Raw NAND changes:
* The major change in this MR will be the support for the Allwinner H616
NAND controller, which lead to numerous changes and cleanups in the
driver.
* Another notable change on this driver is the use of
field_get()/field_prep(), but since the global support for this
helpers is going to be merged in the same release as we start using
these helpers, it implies undefining them in the first place to avoid
warnings. Depending on the merging order (Yuri's bitmap branch or
mtd/next), a temporary warning may arise.
* Marvell drivers layout handling changes have also landed, they fix
previous definitions and abuses that have been made previously, which
implied to relax the ECC parameters validation in the core a bit.
* The Cadence NAND controller driver gets NV-DDR interface support.
SPI NAND changes:
* Support for FudanMicro FM25S01BI3 and ESMT F50L1G41LC is added.
Aside from these main changes, there is the usual load of fixes and API
updates.
|
|
This adds support for ESMT F50L1G41LC, which appears to be an updated
version of the already supported F50L1G41LB.
Add esmt_8c SPI_NAND manufacturer to account for the newly used vendor
ID with support for the ESMT F50L1G41LC chip.
Link: https://github.com/openwrt/openwrt/pull/15214#issuecomment-3514824435
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Correct most kernel-doc warnings in include/linux/mtd/spear_smi.h
by adding a leading '@' to the description of struct members.
Add a new description for the missing @np member.
Warning: spear_smi.h:48 struct member 'name' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'mem_base' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'size' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'partitions' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'nr_partitions' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'fast_mode' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:62 struct member 'clk_rate' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'num_flashes' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'board_flash_info' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'np' not described
in 'spear_smi_plat_data'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
* Raw NAND:
- Add support for Loongson-2K1000 and Loongson-2K0500 NAND controllers,
including extra features, such as chip select and 6-byte NAND ID
reading support.
- Drop the s3c2410 driver.
* SPI NAND:
- Important SPI NAND continuous read improvements and fixes.
- Add support for FudanMicro FM25S01A.
- Add support for continuous reads in Gigadevice vendor driver.
* ECC:
- Add support for the Realtek ECC engine.
This PR comes with the usual amount of various miscellaneous fixes.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
