summaryrefslogtreecommitdiff
path: root/include/linux/mtd/rawnand.h
AgeCommit message (Collapse)AuthorFilesLines
2023-12-22Merge tag 'nand/for-6.8' into mtd/nextMiquel Raynal1-0/+13
* Raw NAND The most meaningful change being the conversion of the brcmnand driver to the ->exec_op() API, this series brought additional changes to the core in order to help controller drivers to handle themselves the WP pin during destructive operations when relevant. As always, there is as well a whole bunch of miscellaneous W=1 fixes, together with a few runtime fixes (double free, timeout value, OOB layout, missing register initialization) and the usual load of remove callbacks turned into void (which led to switch the txx9ndfmc driver to use module_platform_driver()).
2023-12-22mtd: rawnand: Prevent crossing LUN boundaries during sequential readsMiquel Raynal1-0/+2
The ONFI specification states that devices do not need to support sequential reads across LUN boundaries. In order to prevent such event from happening and possibly failing, let's introduce the concept of "pause" in the sequential read to handle these cases. The first/last pages remain the same but any time we cross a LUN boundary we will end and restart (if relevant) the sequential read operation. Cc: stable@vger.kernel.org Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Martin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/linux-mtd/20231215123208.516590-2-miquel.raynal@bootlin.com
2023-12-04mtd: rawnand: NAND controller write protectDavid Regan1-0/+2
Allow NAND controller to be responsible for write protect pin handling during fast path and exec_op destructive operation when controller_wp flag is set. Signed-off-by: David Regan <dregan@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231125012438.15191-2-dregan@broadcom.com
2023-12-04mtd: rawnand: Add destructive operationBoris Brezillon1-0/+11
Erase and program operations need the write protect (wp) pin to be de-asserted to take effect. Add the concept of destructive operation and pass the information to exec_op() so controllers know when they should de-assert this pin without having to decode the command opcode. Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: David Regan <dregan@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231125012438.15191-1-dregan@broadcom.com
2023-10-16mtd: rawnand: Ensure the nand chip supports cached readsRouven Czerwinski1-0/+2
Both the JEDEC and ONFI specification say that read cache sequential support is an optional command. This means that we not only need to check whether the individual controller supports the command, we also need to check the parameter pages for both ONFI and JEDEC NAND flashes before enabling sequential cache reads. This fixes support for NAND flashes which don't support enabling cache reads, i.e. Samsung K9F4G08U0F or Toshiba TC58NVG0S3HTA00. Sequential cache reads are now only available for ONFI and JEDEC devices, if individual vendors implement this, it needs to be enabled per vendor. Tested on i.MX6Q with a Samsung NAND flash chip that doesn't support sequential reads. Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Cc: stable@vger.kernel.org Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20230922141717.35977-1-r.czerwinski@pengutronix.de
2023-07-12mtd: rawnand: export 'nand_exit_status_op()'Arseniy Krasnov1-0/+1
Export this function to work in pair with 'nand_status_op()' which is already exported. Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20230705104403.696680-2-AVKrasnov@sberdevices.ru
2023-03-07mtd: rawnand: Fix spelling mistake waifunc() -> waitfunc()Md Sadre Alam1-1/+1
There is a spelling mistake in a chip->legacy.waifunc(). Fix it. Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20230306144810.22078-1-quic_mdalam@quicinc.com
2023-01-23mtd: rawnand: Fix nand_chip kdocMiquel Raynal1-0/+4
Describe the continuous read nand_chip fields to avoid the following htmldocs warning: include/linux/mtd/rawnand.h:1325: warning: Function parameter or member 'cont_read' not described in 'nand_chip' Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20230116094735.11483-1-miquel.raynal@bootlin.com
2023-01-13mtd: rawnand: Support for sequential cache readsJaimeLiao1-0/+9
Add support for sequential cache reads for controllers using the generic core helpers for their fast read/write helpers. Sequential reads may reduce the overhead when accessing physically continuous data by loading in cache the next page while the previous page gets sent out on the NAND bus. The ONFI specification provides the following additional commands to handle sequential cached reads: * 0x31 - READ CACHE SEQUENTIAL: Requires the NAND chip to load the next page into cache while keeping the current cache available for host reads. * 0x3F - READ CACHE END: Tells the NAND chip this is the end of the sequential cache read, the current cache shall remain accessible for the host but no more internal cache loading operation is required. On the bus, a multi page read operation is currently handled like this: 00 -- ADDR1 -- 30 -- WAIT_RDY (tR+tRR) -- DATA1_IN 00 -- ADDR2 -- 30 -- WAIT_RDY (tR+tRR) -- DATA2_IN 00 -- ADDR3 -- 30 -- WAIT_RDY (tR+tRR) -- DATA3_IN Sequential cached reads may instead be achieved with: 00 -- ADDR1 -- 30 -- WAIT_RDY (tR) -- \ 31 -- WAIT_RDY (tRCBSY+tRR) -- DATA1_IN \ 31 -- WAIT_RDY (tRCBSY+tRR) -- DATA2_IN \ 3F -- WAIT_RDY (tRCBSY+tRR) -- DATA3_IN Below are the read speed test results with regular reads and sequential cached reads, on NXP i.MX6 VAR-SOM-SOLO in mapping mode with a NAND chip characterized with the following timings: * tR: 20 µs * tRCBSY: 5 µs * tRR: 20 ns and the following geometry: * device size: 2 MiB * eraseblock size: 128 kiB * page size: 2 kiB ============= Normal read @ 33MHz ================= mtd_speedtest: eraseblock read speed is 15633 KiB/s mtd_speedtest: page read speed is 15515 KiB/s mtd_speedtest: 2 page read speed is 15398 KiB/s =================================================== ========= Sequential cache read @ 33MHz =========== mtd_speedtest: eraseblock read speed is 18285 KiB/s mtd_speedtest: page read speed is 15875 KiB/s mtd_speedtest: 2 page read speed is 16253 KiB/s =================================================== We observe an overall speed improvement of about 5% when reading 2 pages, up to 15% when reading an entire block. This is due to the ~14us gain on each additional page read (tR - (tRCBSY + tRR)). Co-developed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> Tested-by: Liao Jaime <jaimeliao.tw@gmail.com> Link: https://lore.kernel.org/linux-mtd/20230112093637.987838-4-miquel.raynal@bootlin.com
2023-01-13mtd: rawnand: Check the data only read pattern only onceMiquel Raynal1-0/+8
Instead of checking if a pattern is supported each time we need it, let's create a bitfield that only the core would be allowed to fill at startup time. The core and the individual drivers may then use it in order to check what operation they should use. This bitfield is supposed to grow over time. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Liao Jaime <jaimeliao.tw@gmail.com> Link: https://lore.kernel.org/linux-mtd/20230112093637.987838-2-miquel.raynal@bootlin.com
2022-02-09mtd: rawnand: protect access to rawnand devices while in suspendSean Nyekjaer1-0/+2
Prevent rawnand access while in a suspended state. Commit 013e6292aaf5 ("mtd: rawnand: Simplify the locking") allows the rawnand layer to return errors rather than waiting in a blocking wait. Tested on a iMX6ULL. Fixes: 013e6292aaf5 ("mtd: rawnand: Simplify the locking") Signed-off-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220208085213.1838273-1-sean@geanix.com
2021-11-19mtd: rawnand: Export nand_read_page_hwecc_oob_first()Paul Cercueil1-0/+2
Move the function nand_read_page_hwecc_oob_first() (previously nand_davinci_read_page_hwecc_oob_first()) to nand_base.c, and export it as a GPL symbol, so that it can be used by more modules. Cc: <stable@vger.kernel.org> # v5.2 Fixes: a0ac778eb82c ("mtd: rawnand: ingenic: Add support for the JZ4740") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211016132228.40254-4-paul@crapouillou.net
2021-05-26mtd: rawnand: Add a helper to parse the gpio-cs DT propertyMiquel Raynal1-0/+4
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
2021-05-26mtd: rawnand: Move struct gpio_desc declaration to the topMiquel Raynal1-1/+1
The struct gpio_desc is declared in the middle of the rawnand.h header, right before the first function using it (nand_gpio_waitrdy). Before adding a new function and to make it clear: move the declaration to the top of the file. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210526093242.183847-2-miquel.raynal@bootlin.com
2021-05-26mtd: rawnand: Access SDR and NV-DDR timings through a common macroMiquel Raynal1-0/+28
Most timings related to the bus timings are different between SDR and NV-DDR. However, we identified 9 individual timings which are more related to the NAND chip internals. These are common between the two interface types. Fortunately, only these common timings are being shared through the NAND core and its ->exec_op() interface, which allows the writing of a simple macro checking the interface type and depending on it, returning either the relevant SDR timing or the NV-DDR timing. This is the purpose of the NAND_COMMON_TIMING_PS() macro. As all this is evaluated at build time, one will immediately be notified in case a non common timing is being accessed through this macro. Two handy macros are also inserted at the same time, which use PSEC_TO_NSEC or PSEC_TO_MSEC so that it is very easy to return timings in milli-, nano- or pico-seconds, as usually requested by the internal API. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210505213750.257417-14-miquel.raynal@bootlin.com
2021-05-26mtd: rawnand: Add NV-DDR timingsMiquel Raynal1-0/+112
Create the relevant ONFI NV-DDR timings structure and fill it with default values from the ONFI specification. Add the relevant structure entries and helpers. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210505213750.257417-9-miquel.raynal@bootlin.com
2021-05-26mtd: rawnand: Update dead URLMiquel Raynal1-2/+2
The current link to the ONFI specification is broken, the onfi.org website now points to materials on Micron's website. Update the URL accordingly. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210505213750.257417-6-miquel.raynal@bootlin.com
2021-05-26mtd: rawnand: Add a helper to clarify the interface configurationMiquel Raynal1-1/+10
Name it nand_interface_is_sdr() which will make even more sense when nand_interface_is_nvddr() will be introduced. Use it when relevant. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210505213750.257417-2-miquel.raynal@bootlin.com
2021-04-07mtd: rawnand: Add support for secure regions in NAND memoryManivannan Sadhasivam1-0/+14
On a typical end product, a vendor may choose to secure some regions in the NAND memory which are supposed to stay intact between FW upgrades. The access to those regions will be blocked by a secure element like Trustzone. So the normal world software like Linux kernel should not touch these regions (including reading). The regions are declared using a NAND chip DT property, "secure-regions". So let's make use of this property in the raw NAND core and skip access to the secure regions present in a system. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210402150128.29128-4-manivannan.sadhasivam@linaro.org
2021-03-28mtd: rawnand: remove duplicate include in rawnand.hZhang Yunkai1-1/+0
'linux/mtd/nand.h' included in 'rawnand.h' is duplicated. It is also included in the 17th line. Signed-off-by: Zhang Yunkai <zhang.yunkai@zte.com.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210313105702.365878-1-zhang.yunkai@zte.com.cn
2020-12-11mtd: rawnand: fix a kernel-doc markupMauro Carvalho Chehab1-1/+2
Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/9ed47a57d12c40e73a9b01612ee119d39baa6236.1603469755.git.mchehab+huawei@kernel.org
2020-12-11mtd: nand: ecc-hamming: Stop using raw NAND structuresMiquel Raynal1-0/+2
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 <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-17-miquel.raynal@bootlin.com
2020-12-11mtd: nand: ecc-hamming: Rename the exported functionsMiquel Raynal1-0/+7
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 <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-16-miquel.raynal@bootlin.com
2020-12-11mtd: rawnand: Get rid of chip->ecc.privMiquel Raynal1-2/+0
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 <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-11-miquel.raynal@bootlin.com
2020-11-30mtd: nand: ecc-bch: Update the prototypes to be more genericMiquel Raynal1-0/+5
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 <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200929230124.31491-8-miquel.raynal@bootlin.com
2020-09-30mtd: rawnand: Use the NAND framework user_conf object for ECC flagsMiquel Raynal1-1/+0
Instead of storing the ECC flags in chip->ecc.options, use nanddev->ecc.user_conf.flags. There is currently only one to save: NAND_ECC_MAXIMIZE. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-21-miquel.raynal@bootlin.com
2020-09-30mtd: rawnand: Use the ECC framework user input parsing bitsMiquel Raynal1-12/+0
Many helpers are generic to all NAND chips, they should not be raw-NAND specific, so use the generic ones. To avoid moving all the raw NAND core "history" into the generic NAND layer, we keep a part of this parsing in the raw NAND core to ensure backward compatibility. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-20-miquel.raynal@bootlin.com
2020-09-30mtd: rawnand: Use the ECC framework OOB layoutsMiquel Raynal1-3/+1
No need to have our own in the raw NAND core. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-18-miquel.raynal@bootlin.com
2020-09-28mtd: rawnand: Use the new ECC engine type enumerationMiquel Raynal1-2/+2
Mechanical switch from the legacy "mode" enumeration to the new "engine type" enumeration in drivers and board files. The device tree parsing is also updated to return the new enumeration from the old strings. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-11-miquel.raynal@bootlin.com
2020-09-28mtd: rawnand: Separate the ECC engine type and the ECC byte placementMiquel Raynal1-2/+4
The use of "syndrome" placement should not be encoded in the ECC engine mode/type. Create a "placement" field in NAND chip and change all occurrences of the NAND_ECC_HW_SYNDROME enumeration to be just NAND_ECC_HW and possibly a placement entry like NAND_ECC_PLACEMENT_INTERLEAVED. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-10-miquel.raynal@bootlin.com
2020-08-27mtd: rawnand: Move the nand_ecc_algo enum to the generic NAND layerMiquel Raynal1-14/+0
This enumeration is generic and will be reused NAND-wide. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-4-miquel.raynal@bootlin.com
2020-08-27mtd: rawnand: Rename the ECC algorithm enumeration itemsMiquel Raynal1-8/+8
NAND_ECC_ is not a meaningful prefix, use NAND_ECC_ALGO_ instead. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-3-miquel.raynal@bootlin.com
2020-08-27mtd: rawnand: Add a kernel doc to the ECC algorithm enumerationMiquel Raynal1-0/+7
Before moving it to the generic raw NAND core, ensure the enumeration is properly described. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200827085208.16276-2-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Allocate the interface configurations dynamicallyMiquel Raynal1-3/+8
Instead of manipulating the statically allocated structure and copy timings around, allocate one at identification time and save it in the nand_chip structure once it has been initialized. All NAND chips using the same interface configuration during reset and startup, we define a helper to retrieve a single reset interface configuration object, shared across all NAND chips. We use a second pointer to always have a reference on the currently applied interface configuration, which may either point to the "best interface configuration" or to the "default reset interface configuration". Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-29-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Get rid of the default ONFI timing modeMiquel Raynal1-9/+0
The ->choose_interface() hook is here for manufacturer drivers to provide a better timing interface than the default one, this field is not needed anymore. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-28-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Add the ->choose_interface_config() hookMiquel Raynal1-0/+3
This hook can be overloaded by NAND manufacturer drivers to propose alternative timings when not following the main standards. In this case, the manufacturer drivers is responsible for choosing the best interface configuration that fits both the controller and chip capabilities. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-23-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: s/data_interface/interface_config/Miquel Raynal1-17/+16
The name/suffix data_interface is a bit misleading in that the field or functions actually represent a configuration that can be applied by the controller/chip. Let's rename all fields/functions/hooks that are worth renaming. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2020-06-26mtd: rawnand: Hide the chip->data_interface indirectionMiquel Raynal1-0/+11
As a preparation for allocating the data interface structure dynamically (and rename it), let's avoid accessing chip->data_interface directly. Instead, we introduce a helper, nand_get_interface_config(), and use it to retrieve the current data interface configuration out of a nand_chip object. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-19-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Reorganize the nand_chip structureMiquel Raynal1-90/+76
Reorder fields in this structure and pack entries by theme: * The main descriptive structures * The data interface details * Bad block information * The device layout * Extra buffers matching the device layout * Internal values * External objects like the ECC controller, the ECC engine and a private data pointer. While at it, adapt the documentation style. I changed on purpose the description of @oob_poi which was weird. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-7-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Declare the nand_manufacturer structure out of nand_chipMiquel Raynal1-8/+12
Now that struct nand_manufacturer type is free, use it to store the nand_manufacturer_desc and the manufacturer's private data. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-6-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Rename the manufacturer structureMiquel Raynal1-1/+1
It is currently called nand_manufacturer but could actually be called nand_manufacturer_desc, like its instances, so that the former name is left unused for now. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-5-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Create a nand_chip operations structureMiquel Raynal1-14/+18
And move nand_chip hooks there. While moving entries from one structure to the other, adapt the documentation style. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-4-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Only use u8 instead of uint8_t in nand_chip structureMiquel Raynal1-2/+2
Mechanical change to avoid using old types. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-3-miquel.raynal@bootlin.com
2020-06-26mtd: rawnand: Use unsigned types for nand_chip unsigned valuesMiquel Raynal1-7/+7
page_shift, phys_erase_shift, bbt_erase_shift, chip_shift, pagemask, subpagesize and badblockbits are all positive values, so declare them as unsigned. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200529111322.7184-2-miquel.raynal@bootlin.com
2020-05-31mtd: rawnand: Add an invalid ECC mode to discriminate with valid onesMiquel Raynal1-0/+1
NAND ECC modes (or providers) have their own enumeration but, unlike their algorithms counterpart, there is no invalid or uninitialized value to discriminate between an error and having chosen a no-ECC situation. Add an "invalid" entry for this purpose. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200526195633.11543-7-miquel.raynal@bootlin.com
2020-05-31mtd: rawnand: Drop OOB_FIRST placement schemeMiquel Raynal1-1/+0
This scheme has been introduced for the Davinci controller and means that the OOB area must be read *before* the rest of the data. This has nothing to do with the ECC in OOB placement as it could be understood and most importantly, there is no point in having this function out of the Davinci NAND controller driver. A DT property for this scheme has been added but never used, even by the Davinci driver which only uses this scheme to change the default nand_read_page(). Move the main read_page() helper into the Davinci driver and remove the remaining boilerplate. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200526195633.11543-4-miquel.raynal@bootlin.com
2020-05-31mtd: rawnand: Avoid a typedefMiquel Raynal1-3/+3
In new code, the use of typedef is discouraged. Turn this one in the raw NAND core into a regular enumeration. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200526195633.11543-3-miquel.raynal@bootlin.com
2020-05-31mtd: rawnand: Stop using nand_release()Miquel Raynal1-2/+0
This helper is not very useful and very often people get confused: they use nand_release() instead of nand_cleanup(). Now that all drivers have been converted to do not use nand_release() anymore, let's remove this helper. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-63-miquel.raynal@bootlin.com
2020-05-24mtd: rawnand: Add nand_extract_bits()Miquel Raynal1-0/+4
There are cases where ECC bytes are not byte-aligned. Indeed, BCH implies using a number of ECC bits, which are not always a multiple of 8. We then need a helper like nand_extract_bits() to extract these syndromes from a buffer. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20200519074549.23673-5-miquel.raynal@bootlin.com
2020-05-24mtd: rawnand: Propage CS selection to sub operationsBoris Brezillon1-0/+2
Some controller using the instruction parse infrastructure might need to know which CS a specific sub-operation is targeting. Let's propagate this information. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200505101353.1776394-2-boris.brezillon@collabora.com