summaryrefslogtreecommitdiff
path: root/drivers/mtd
AgeCommit message (Collapse)Author
2020-11-20mtd: rawnand: sunxi: Document 'sunxi_nfc's 'caps' memberLee Jones
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/raw/sunxi_nand.c:250: warning: Function parameter or member 'caps' not described in 'sunxi_nfc' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Boris BREZILLON <b.brezillon.dev@gmail.com> Cc: Qiang Yu <yuq825@gmail.com> Cc: Dmitriy B <rzk333@gmail.com> Cc: Sergey Lapin <slapin@ossfans.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-21-lee.jones@linaro.org
2020-11-20mtd: rawnand: omap2: Fix a bunch of kernel-doc misdemeanoursLee Jones
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/raw/omap2.c:191: warning: Function parameter or member 'info' not described in 'omap_prefetch_enable' drivers/mtd/nand/raw/omap2.c:221: warning: Function parameter or member 'cs' not described in 'omap_prefetch_reset' drivers/mtd/nand/raw/omap2.c:221: warning: Function parameter or member 'info' not described in 'omap_prefetch_reset' drivers/mtd/nand/raw/omap2.c:946: warning: Function parameter or member 'chip' not described in 'omap_enable_hwecc' drivers/mtd/nand/raw/omap2.c:946: warning: Excess function parameter 'mtd' description in 'omap_enable_hwecc' drivers/mtd/nand/raw/omap2.c:1017: warning: Function parameter or member 'chip' not described in 'omap_dev_ready' drivers/mtd/nand/raw/omap2.c:1017: warning: Excess function parameter 'mtd' description in 'omap_dev_ready' drivers/mtd/nand/raw/omap2.c:1036: warning: Function parameter or member 'chip' not described in 'omap_enable_hwecc_bch' drivers/mtd/nand/raw/omap2.c:1036: warning: Excess function parameter 'mtd' description in 'omap_enable_hwecc_bch' drivers/mtd/nand/raw/omap2.c:1142: warning: Function parameter or member 'ecc_calc' not described in '_omap_calculate_ecc_bch' drivers/mtd/nand/raw/omap2.c:1142: warning: Excess function parameter 'ecc_code' description in '_omap_calculate_ecc_bch' drivers/mtd/nand/raw/omap2.c:1270: warning: Function parameter or member 'ecc_calc' not described in 'omap_calculate_ecc_bch_sw' drivers/mtd/nand/raw/omap2.c:1270: warning: Excess function parameter 'ecc_code' description in 'omap_calculate_ecc_bch_sw' drivers/mtd/nand/raw/omap2.c:1284: warning: Function parameter or member 'ecc_calc' not described in 'omap_calculate_ecc_bch_multi' drivers/mtd/nand/raw/omap2.c:1284: warning: Excess function parameter 'ecc_code' description in 'omap_calculate_ecc_bch_multi' drivers/mtd/nand/raw/omap2.c:1681: warning: Function parameter or member 'info' not described in 'is_elm_present' drivers/mtd/nand/raw/omap2.c:1681: warning: Function parameter or member 'elm_node' not described in 'is_elm_present' drivers/mtd/nand/raw/omap2.c:1681: warning: Excess function parameter 'omap_nand_info' description in 'is_elm_present' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Jian Zhang <jzhang@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-20-lee.jones@linaro.org
2020-11-20mtd: rawnand: omap_elm: Finish half populated function header, demote empty onesLee Jones
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/raw/omap_elm.c:102: warning: Function parameter or member 'ecc_steps' not described in 'elm_config' drivers/mtd/nand/raw/omap_elm.c:102: warning: Function parameter or member 'ecc_step_size' not described in 'elm_config' drivers/mtd/nand/raw/omap_elm.c:102: warning: Function parameter or member 'ecc_syndrome_size' not described in 'elm_config' drivers/mtd/nand/raw/omap_elm.c:440: warning: Function parameter or member 'info' not described in 'elm_context_save' drivers/mtd/nand/raw/omap_elm.c:488: warning: Function parameter or member 'info' not described in 'elm_context_restore' 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-19-lee.jones@linaro.org
2020-11-20mtd: rawnand: s3c2410: Add documentation for 2 missing struct membersLee Jones
Correct 'controller' typo while we're at it. Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/raw/s3c2410.c:172: warning: Function parameter or member 'controller' not described in 's3c2410_nand_info' drivers/mtd/nand/raw/s3c2410.c:172: warning: Function parameter or member 'freq_transition' not described in 's3c2410_nand_info' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Ben Dooks <ben@simtec.co.uk> Cc: linux-mtd@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-18-lee.jones@linaro.org
2020-11-20mtd: rawnand: cafe_nand: Remove superfluous param doc and add anotherLee Jones
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/raw/cafe_nand.c:372: warning: Function parameter or member 'page' not described in 'cafe_nand_read_page' drivers/mtd/nand/raw/cafe_nand.c:372: warning: Excess function parameter 'mtd' description in 'cafe_nand_read_page' Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> 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-17-lee.jones@linaro.org
2020-11-20mtd: rawnand: diskonchip: Marking unused variables as __always_unusedLee Jones
'dummy' is never checked (as per the nomenclature) and the use of 'emtpymatch' is currently #if 0'ed out. We could also #if 0 the declaration, but #ifery is pretty ugly, so I like to keep it to a minimum. Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/raw/diskonchip.c: In function ‘DoC_Delay’: drivers/mtd/nand/raw/diskonchip.c:219:16: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] drivers/mtd/nand/raw/diskonchip.c: In function ‘doc200x_calculate_ecc’: drivers/mtd/nand/raw/diskonchip.c:706:6: warning: variable ‘emptymatch’ set but not used [-Wunused-but-set-variable] Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Dan Brown <dan_brown@ieee.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.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-16-lee.jones@linaro.org
2020-11-20mtd: ubi: gluebi: Fix misnamed function parameter documentationLee Jones
Fixes the following W=1 kernel build warning(s): drivers/mtd/ubi/gluebi.c:446: warning: Function parameter or member 'ns_ptr' not described in 'gluebi_notify' drivers/mtd/ubi/gluebi.c:446: warning: Excess function parameter 'ptr' description in 'gluebi_notify' 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-15-lee.jones@linaro.org
2020-11-20mtd: rawnand: brcmnand: Demote non-conformant kernel-doc headersLee Jones
Fixes the following W=1 kernel build warning(s): drivers/mtd/nand/raw/brcmnand/brcmnand.c:1854: warning: Function parameter or member 'host' not described in 'brcmnand_edu_trans' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1854: warning: Function parameter or member 'addr' not described in 'brcmnand_edu_trans' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1854: warning: Function parameter or member 'buf' not described in 'brcmnand_edu_trans' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1854: warning: Function parameter or member 'len' not described in 'brcmnand_edu_trans' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1854: warning: Function parameter or member 'cmd' not described in 'brcmnand_edu_trans' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'host' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'desc' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'addr' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'buf' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'len' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'dma_cmd' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'begin' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'end' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1951: warning: Function parameter or member 'next_desc' not described in 'brcmnand_fill_dma_desc' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1977: warning: Function parameter or member 'host' not described in 'brcmnand_dma_run' drivers/mtd/nand/raw/brcmnand/brcmnand.c:1977: warning: Function parameter or member 'desc' not described in 'brcmnand_dma_run' Cc: Brian Norris <computersforpeace@gmail.com> Cc: Kamal Dasu <kdasu.kdev@gmail.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 Cc: bcm-kernel-feedback-list@broadcom.com Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-14-lee.jones@linaro.org
2020-11-20mtd: ubi: wl: Fix a couple of kernel-doc issuesLee Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Jones
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Raynal
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 Hellwig
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 Yadav
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 Yadav
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 Yadav
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 Yadav
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 Yadav
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 Yadav
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 Ambarus
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 Ambarus
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 Yadav
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 Yadav
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
generated by cgit (git 2.34.1) at 2025-09-24 09:24:42 +0000