summaryrefslogtreecommitdiff
path: root/drivers/mtd
AgeCommit message (Collapse)AuthorFilesLines
2020-11-20mtd: ubi: wl: Fix a couple of kernel-doc issuesLee Jones1-2/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/ubi/wl.c:584: warning: Function parameter or member 'nested' not described in 'schedule_erase' drivers/mtd/ubi/wl.c:1075: warning: Excess function parameter 'shutdown' description in '__erase_worker' Cc: Richard Weinberger <richard@nod.at> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-13-lee.jones@linaro.org
2020-11-20mtd: ubi: eba: Fix a couple of misdocumentation issuesLee Jones1-1/+2
Fixes the following W=1 kernel build warning(s): drivers/mtd/ubi/eba.c:1304: warning: Function parameter or member 'vidb' not described in 'ubi_eba_copy_leb' drivers/mtd/ubi/eba.c:1304: warning: Excess function parameter 'vid_hdr' description in 'ubi_eba_copy_leb' drivers/mtd/ubi/eba.c:1483: warning: Function parameter or member 'ai' not described in 'print_rsvd_warning' Cc: Richard Weinberger <richard@nod.at> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-12-lee.jones@linaro.org
2020-11-20mtd: ubi: kapi: Correct documentation for 'ubi_leb_read_sg's 'sgl' parameterLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/ubi/kapi.c:464: warning: Function parameter or member 'sgl' not described in 'ubi_leb_read_sg' drivers/mtd/ubi/kapi.c:464: warning: Excess function parameter 'buf' description in 'ubi_leb_read_sg' Cc: Richard Weinberger <richard@nod.at> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-11-lee.jones@linaro.org
2020-11-20mtd: spinand: toshiba: Demote non-conformant kernel-doc headerLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/spi/toshiba.c:36: warning: Function parameter or member 'write_cache_variants' not described in 'SPINAND_OP_VARIANTS' drivers/mtd/nand/spi/toshiba.c:36: warning: Function parameter or member '0' not described in 'SPINAND_OP_VARIANTS' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Yoshio Furuyama <ytc-mb-yfuruyama7@kioxia.com> Cc: Frieder Schrempf <frieder.schrempf@kontron.de> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-10-lee.jones@linaro.org
2020-11-20mtd: ubi: build: Document 'ubi_num' in struct mtd_dev_paramLee Jones1-0/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/ubi/build.c:61: warning: Function parameter or member 'ubi_num' not described in 'mtd_dev_param' Cc: Richard Weinberger <richard@nod.at> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-9-lee.jones@linaro.org
2020-11-20mtd: spi-nor: hisi-sfc: Demote non-conformant kernel-docLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or member 'np' not described in 'hisi_spi_nor_register' drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or member 'host' not described in 'hisi_spi_nor_register' Cc: Tudor Ambarus <tudor.ambarus@microchip.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-mtd@lists.infradead.org Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-8-lee.jones@linaro.org
2020-11-20mtd: onenand: onenand_bbt: Fix expected kernel-doc formattingLee Jones1-16/+16
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/onenand/onenand_bbt.c:33: warning: Function parameter or member 'buf' not described in 'check_short_pattern' drivers/mtd/nand/onenand/onenand_bbt.c:33: warning: Function parameter or member 'len' not described in 'check_short_pattern' drivers/mtd/nand/onenand/onenand_bbt.c:33: warning: Function parameter or member 'paglen' not described in 'check_short_pattern' drivers/mtd/nand/onenand/onenand_bbt.c:33: warning: Function parameter or member 'td' not described in 'check_short_pattern' drivers/mtd/nand/onenand/onenand_bbt.c:57: warning: Function parameter or member 'mtd' not described in 'create_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:57: warning: Function parameter or member 'buf' not described in 'create_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:57: warning: Function parameter or member 'bd' not described in 'create_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:57: warning: Function parameter or member 'chip' not described in 'create_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:132: warning: Function parameter or member 'mtd' not described in 'onenand_memory_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:132: warning: Function parameter or member 'bd' not described in 'onenand_memory_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:145: warning: Function parameter or member 'mtd' not described in 'onenand_isbad_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:145: warning: Function parameter or member 'offs' not described in 'onenand_isbad_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:145: warning: Function parameter or member 'allowbbt' not described in 'onenand_isbad_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:182: warning: Function parameter or member 'mtd' not described in 'onenand_scan_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:182: warning: Function parameter or member 'bd' not described in 'onenand_scan_bbt' drivers/mtd/nand/onenand/onenand_bbt.c:230: warning: Function parameter or member 'mtd' not described in 'onenand_default_bbt' Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-7-lee.jones@linaro.org
2020-11-20mtd: Fix misspelled function parameter 'section'Lee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/mtdcore.c:1592: warning: Function parameter or member 'section' not described in 'mtd_ooblayout_find_eccregion' drivers/mtd/mtdcore.c:1592: warning: Excess function parameter 'sectionp' description in 'mtd_ooblayout_find_eccregion' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-6-lee.jones@linaro.org
2020-11-20mtd: devices: docg3: Fix kernel-doc 'bad line' and 'excessive doc' issuesLee Jones1-3/+2
This patch also places the descriptions in the correct order. Fixes the following W=1 kernel build warning(s): drivers/mtd/devices/docg3.c:819: warning: bad line: drivers/mtd/devices/docg3.c:1799: warning: Excess function parameter 'base' description in 'doc_probe_device' Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-5-lee.jones@linaro.org
2020-11-20mtd: onenand: onenand_base: Fix expected kernel-doc formattingLee Jones1-219/+219
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/onenand/onenand_base.c:140: warning: Function parameter or member 'mtd' not described in 'onenand_ooblayout_32_64_ecc' drivers/mtd/nand/onenand/onenand_base.c:140: warning: Function parameter or member 'section' not described in 'onenand_ooblayout_32_64_ecc' drivers/mtd/nand/onenand/onenand_base.c:140: warning: Function parameter or member 'oobregion' not described in 'onenand_ooblayout_32_64_ecc' drivers/mtd/nand/onenand/onenand_base.c:200: warning: Function parameter or member 'addr' not described in 'onenand_readw' drivers/mtd/nand/onenand/onenand_base.c:212: warning: Function parameter or member 'value' not described in 'onenand_writew' drivers/mtd/nand/onenand/onenand_base.c:212: warning: Function parameter or member 'addr' not described in 'onenand_writew' drivers/mtd/nand/onenand/onenand_base.c:225: warning: Function parameter or member 'this' not described in 'onenand_block_address' drivers/mtd/nand/onenand/onenand_base.c:225: warning: Function parameter or member 'block' not described in 'onenand_block_address' drivers/mtd/nand/onenand/onenand_base.c:242: warning: Function parameter or member 'this' not described in 'onenand_bufferram_address' drivers/mtd/nand/onenand/onenand_base.c:242: warning: Function parameter or member 'block' not described in 'onenand_bufferram_address' NB: Snipped 200 lines for brevity. Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Adrian Hunter <ext-adrian.hunter@nokia.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-4-lee.jones@linaro.org
2020-11-20mtd: devices: phram: File headers are not good candidates for kernel-docLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/devices/phram.c:19: warning: Function parameter or member 'fmt' not described in 'pr_fmt' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: "Jochen Schäuble" <psionic@psionic.de> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-3-lee.jones@linaro.org
2020-11-20mtd: mtdpart: Fix misdocumented function parameter 'mtd'Lee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/mtd/mtdpart.c:300: warning: Function parameter or member 'mtd' not described in '__mtd_del_partition' drivers/mtd/mtdpart.c:300: warning: Excess function parameter 'priv' description in '__mtd_del_partition' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Thomas Gleixner <gleixner@linutronix.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: linux-mtd@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-2-lee.jones@linaro.org
2020-11-20mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()Miquel Raynal1-4/+17
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-20-miquel.raynal@bootlin.com
2020-11-20mtd: rawnand: sharpsl: Move the ECC initialization to ->attach_chip()Miquel Raynal1-8/+24
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2020-11-20mtd: rawnand: r852: Move the ECC initialization to ->attach_chip()Miquel Raynal2-13/+28
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-18-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()Miquel Raynal1-3/+17
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-17-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()Miquel Raynal1-2/+17
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-16-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: tmio: Move the ECC initialization to ->attach_chip()Miquel Raynal1-9/+24
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-15-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: txx9ndfmc: Move the ECC initialization to ->attach_chip()Miquel Raynal1-5/+9
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-14-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()Miquel Raynal1-2/+17
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-13-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()Miquel Raynal1-2/+17
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-12-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: lpc32xx_slc: Move the ECC initialization to ->attach_chip()Miquel Raynal1-12/+14
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com>
2020-11-19mtd: rawnand: lpc32xx_mlc: Move the ECC initialization to ->attach_chip()Miquel Raynal1-10/+13
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-10-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: fsmc: Move the ECC initialization to ->attach_chip()Miquel Raynal1-15/+15
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2020-11-19mtd: rawnand: diskonchip: Move the ECC initialization to ->attach_chip()Miquel Raynal1-10/+19
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-8-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: davinci: Move the ECC initialization to ->attach_chip()Miquel Raynal1-4/+4
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-7-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: cs553x: Move the ECC initialization to ->attach_chip()Miquel Raynal1-8/+16
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2020-11-19mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()Miquel Raynal1-2/+9
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-5-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()Miquel Raynal1-3/+9
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(). Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-4-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()Miquel Raynal1-2/+16
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(), a NAND controller hook. Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-3-miquel.raynal@bootlin.com
2020-11-19mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()Miquel Raynal1-2/+9
The probe function is only supposed to initialize the controller hardware but not the ECC engine. Indeed, we don't know anything about the NAND chip(s) at this stage. Let's move the logic initializing the ECC engine, even pretty simple, to the ->attach_chip() hook which gets called during nand_scan() routine, after the NAND chip discovery. As the previously mentioned logic is supposed to parse the DT for us, it is likely that the chip->ecc.* entries be overwritten. So let's avoid this by moving these lines to ->attach_chip(), a NAND controller hook. Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/linux-mtd/20201113123424.32233-2-miquel.raynal@bootlin.com
2020-11-16mtd_blkdevs: don't override BLKFLSBUFChristoph Hellwig1-28/+0
BLKFLSBUF is not supposed to actually send a flush command to the device, but to tear down buffer cache structures. Remove the mtd_blkdevs implementation and just use the default semantics instead. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-11-09mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR modePratyush Yadav1-1/+114
Since this flash doesn't have a Profile 1.0 table, the Octal DTR capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D fast read settings. Enable Octal DTR mode with 20 dummy cycles to allow running at the maximum supported frequency of 200Mhz. The flash supports the soft reset sequence. So, add the flag in the flash's info. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-16-p.yadav@ti.com
2020-11-09mtd: spi-nor: spansion: add support for Cypress Semper flashPratyush Yadav1-0/+171
The Cypress Semper flash is an xSPI compliant octal DTR flash. Add support for using it in octal DTR mode. The flash by default boots in a hybrid sector mode. But the sector map table on the part I had was programmed incorrectly and the SMPT values on the flash don't match the public datasheet. Specifically, in some places erase type 3 was used instead of 4. In addition, the region sizes were incorrect in some places. So, for testing I set CFR3N[3] to enable uniform sector sizes. Since the uniform sector mode bit is a non-volatile bit, this series does not change it to avoid making any permanent changes to the flash configuration. The correct data to implement a fixup is not available right now and will be done in a follow-up patch if needed. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> [vigneshr@ti.com: Drop unnecessary sleep in Octal DTR switch sequence] Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-15-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: disable Octal DTR mode on suspend.Pratyush Yadav1-0/+15
On resume, the init procedure will be run that will re-enable it. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-14-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: perform a Soft Reset on shutdownPratyush Yadav1-0/+45
Perform a Soft Reset on shutdown on flashes that support it so that the flash can be reset to its initial state and any configurations made by spi-nor (given that they're only done in volatile registers) will be reset. This will hand back the flash in pristine state for any further operations on it. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-13-p.yadav@ti.com
2020-11-09mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPTPratyush Yadav3-0/+7
A Soft Reset sequence will return the flash to Power-on-Reset (POR) state. It consists of two commands: Soft Reset Enable and Soft Reset. Find out if the sequence is supported from BFPT DWORD 16. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-12-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: enable octal DTR mode when possiblePratyush Yadav2-0/+40
Allow flashes to specify a hook to enable octal DTR mode. Use this hook whenever possible to get optimal transfer speeds. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-11-p.yadav@ti.com
2020-11-09mtd: spi-nor: Parse SFDP SCCR MapTudor Ambarus1-0/+48
Parse just the 22nd dword and look for the 'DTR Octal Mode Enable Volatile bit'. SPI_NOR_IO_MODE_EN_VOLATILE should be set just for the flashes that don't define the optional SFDP SCCR Map. For the others, let the SFDP do its job and fill the SNOR_F_IO_MODE_EN_VOLATILE flag. We avoid this way polluting the flash flags when declaring one. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20201005153138.6437-10-p.yadav@ti.com
2020-11-09mtd: spi-nor: Introduce SNOR_F_IO_MODE_EN_VOLATILETudor Ambarus2-0/+9
We don't want to enter a stateful mode, where a X-X-X I/O mode is entered by setting a non-volatile bit, because in case of a reset or a crash, once in the non-volatile mode, we may not be able to recover in bootloaders and we may break the SPI NOR boot. Forbid by default the I/O modes that are set via a non-volatile bit. SPI_NOR_IO_MODE_EN_VOLATILE should be set just for the flashes that don't define the optional SFDP SCCR Map, so that we don't pollute the flash info flags. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20201005153138.6437-9-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR modePratyush Yadav1-2/+13
Some controllers, like the cadence qspi controller, have trouble reading only 1 byte in DTR mode. So, do 2 byte reads for SR and FSR commands in DTR mode, and then discard the second byte. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-8-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: use dummy cycle and address width info from SFDPPratyush Yadav1-0/+10
The xSPI Profile 1.0 table specifies how many dummy cycles and address bytes are needed for the Read Status Register command in octal DTR mode. Use that information to send the correct Read SR command. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-7-p.yadav@ti.com
2020-11-09mtd: spi-nor: sfdp: parse xSPI Profile 1.0 tablePratyush Yadav3-1/+102
This table is indication that the flash is xSPI compliant and hence supports octal DTR mode. Extract information like the fast read opcode, dummy cycles, the number of dummy cycles needed for a Read Status Register command, and the number of address bytes needed for a Read Status Register command. We don't know what speed the controller is running at. Find the fast read dummy cycles for the fastest frequency the flash can run at to be sure we are never short of dummy cycles. If nothing is available, default to 20. Flashes that use a different value should update it in their fixup hooks. Since we want to set read settings, expose spi_nor_set_read_settings() in core.h. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-6-p.yadav@ti.com
2020-11-09mtd: spi-nor: sfdp: get command opcode extension type from BFPTPratyush Yadav2-0/+24
Some devices in DTR mode expect an extra command byte called the extension. The extension can either be same as the opcode, bitwise inverse of the opcode, or another additional byte forming a 16-byte opcode. Get the extension type from the BFPT. For now, only flashes with "repeat" and "inverse" extensions are supported. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-5-p.yadav@ti.com
2020-11-09mtd: spi-nor: add support for DTR protocolPratyush Yadav3-83/+252
Double Transfer Rate (DTR) is SPI protocol in which data is transferred on each clock edge as opposed to on each clock cycle. Make framework-level changes to allow supporting flashes in DTR mode. Right now, mixed DTR modes are not supported. So, for example a mode like 4S-4D-4D will not work. All phases need to be either DTR or STR. The xSPI spec says that "The program commands provide SPI backward compatible commands for programming data...". So 8D-8D-8D page program opcodes are populated with using 1S-1S-1S opcodes. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-4-p.yadav@ti.com
2020-11-09mtd: spi-nor: add spi_nor_controller_ops_{read_reg, write_reg, erase}()Pratyush Yadav1-34/+53
They are thin wrappers around nor->controller_ops->{read_reg,write_reg,erase}(). In a future commit DTR support will be added. These ops can not be supported by the controller_ops hooks and these helpers will make it easier to reject those calls. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-3-p.yadav@ti.com
2020-11-09mtd: spi-nor: core: use EOPNOTSUPP instead of ENOTSUPPPratyush Yadav1-5/+5
ENOTSUPP is not a SUSV4 error code. Using EOPNOTSUPP is preferred in its stead. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005153138.6437-2-p.yadav@ti.com
2020-10-30mtd: rawnand: stm32_fmc2: fix broken ECCChristophe Kerello1-7/+8
Since commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits"), ECC are broken in FMC2 driver in case of nand-ecc-step-size and nand-ecc-strength are not set in the device tree. To avoid this issue, the default settings are now set in stm32_fmc2_nfc_attach_chip function. Signed-off-by: Christophe Kerello <christophe.kerello@st.com> Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1604064819-26861-1-git-send-email-christophe.kerello@st.com
2020-10-28mtd: spi-nor: Fix address width on flash chips > 16MBBert Vermeulen1-3/+5
If a flash chip has more than 16MB capacity but its BFPT reports BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3. The check in spi_nor_set_addr_width() doesn't catch it because addr_width did get set. This fixes that check. Fixes: f9acd7fa80be ("mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths") Signed-off-by: Bert Vermeulen <bert@biot.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Joel Stanley <joel@jms.id.au> Tested-by: Cédric Le Goater <clg@kaod.org> Link: https://lore.kernel.org/r/20201006132346.12652-1-bert@biot.com
2020-10-28mtd: spi-nor: Don't copy self-pointing struct aroundAlexander Sverdlin1-3/+2
spi_nor_parse_sfdp() modifies the passed structure so that it points to itself (params.erase_map.regions to params.erase_map.uniform_region). This makes it impossible to copy the local struct anywhere else. Therefore only use memcpy() in backup-restore scenario. The bug may show up like below: BUG: unable to handle page fault for address: ffffc90000b377f8 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 3500 Comm: flashcp Tainted: G O 5.4.53-... #1 ... RIP: 0010:spi_nor_erase+0x8e/0x5c0 Code: 64 24 18 89 db 4d 8b b5 d0 04 00 00 4c 89 64 24 18 4c 89 64 24 20 eb 12 a8 10 0f 85 59 02 00 00 49 83 c6 10 0f 84 4f 02 00 00 <49> 8b 06 48 89 c2 48 83 e2 c0 48 89 d1 49 03 4e 08 48 39 cb 73 d8 RSP: 0018:ffffc9000217fc48 EFLAGS: 00010206 RAX: 0000000000740000 RBX: 0000000000000000 RCX: 0000000000740000 RDX: ffff8884550c9980 RSI: ffff88844f9c0bc0 RDI: ffff88844ede7bb8 RBP: 0000000000740000 R08: ffffffff815bfbe0 R09: ffff88844f9c0bc0 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000217fc60 R13: ffff88844ede7818 R14: ffffc90000b377f8 R15: 0000000000000000 FS: 00007f4699780500(0000) GS:ffff88846ff00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000b377f8 CR3: 00000004538ee000 CR4: 0000000000340fe0 Call Trace: part_erase+0x27/0x50 mtdchar_ioctl+0x831/0xba0 ? filemap_map_pages+0x186/0x3d0 ? do_filp_open+0xad/0x110 ? _copy_to_user+0x22/0x30 ? cp_new_stat+0x150/0x180 mtdchar_unlocked_ioctl+0x2a/0x40 do_vfs_ioctl+0xa0/0x630 ? __do_sys_newfstat+0x3c/0x60 ksys_ioctl+0x70/0x80 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x6a/0x200 ? prepare_exit_to_usermode+0x50/0xd0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f46996b6817 Cc: stable@vger.kernel.org Fixes: c46872170a54 ("mtd: spi-nor: Move erase_map to 'struct spi_nor_flash_parameter'") Co-developed-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Tested-by: Baurzhan Ismagulov <ibr@radix50.net> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201005084803.23460-1-alexander.sverdlin@nokia.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-28 01:53:44 +0300