user/sven/linux.git/include/linux/mtd, branch v6.15.7

mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants

2025-06-27T10:13:43Z

[ Upstream commit dba90f5a79c13936de4273a19e67908a0c296afe ] Dual and quad capable chips natively support dual and quad I/O variants at up to 104MHz (1-2-2 and 1-4-4 operations). Reaching the maximum speed of 166MHz is theoretically possible (while still unsupported in the field) by adding a few more dummy cycles. Let's be accurate and clearly state this limit. Setting a maximum frequency implies adding the frequency parameter to the macro, which is done using a variadic argument to avoid impacting all the other drivers which already make use of this macro. Fixes: 1ea808b4d15b ("mtd: spinand: winbond: Update the *JW chip definitions") Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (quad IO) read from cache ops

2025-06-27T10:13:42Z

[ Upstream commit 9c6911072c6e8b128ccdb7dd00efa13c47513074 ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (quad IO) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (quad output) read from cache ops

2025-06-27T10:13:42Z

[ Upstream commit 1deae734cc1c7e976d588e7d8f46af2bb9ef5656 ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (quad output) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (dual IO) read from cache ops

2025-06-27T10:13:42Z

[ Upstream commit d9de177996d74c0cc44220003953ba2d2bece0ac ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (dual IO) read from cache macro names. While at modifying them, better reordering the macros to group them all by bus topology which now feels more intuitive. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (dual output) read from cache ops

2025-06-27T10:13:42Z

[ Upstream commit 684f7105e8534f6500de389c089ba204cb1c8058 ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (dual output) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin

mtd: spinand: Use more specific naming for the (single) read from cache ops

2025-06-27T10:13:42Z

[ Upstream commit ea2087d4e66d0b927918cc9048576aca6a0446ad ] SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (single) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants") Signed-off-by: Sasha Levin

mtd: rawnand: qcom: Pass 18 bit offset from NANDc base to BAM base

2025-06-27T10:13:06Z

commit ee000969f28bf579d3772bf7c0ae8aff86586e20 upstream. The BAM command descriptor provides only 18 bits to specify the BAM register offset. Additionally, in the BAM command descriptor, the BAM register offset is supposed to be specified as "(NANDc base - BAM base) + reg_off". Since, the BAM controller expecting the value in the form of "NANDc base - BAM base", so that added a new field 'bam_offset' in the NAND properties structure and use it while preparing the command descriptor. Previously, the driver was specifying the NANDc base address in the BAM command descriptor. Cc: stable@vger.kernel.org Fixes: 8d6b6d7e135e ("mtd: nand: qcom: support for command descriptor formation") Tested-by: Lakshmi Sowjanya D Signed-off-by: Md Sadre Alam Acked-by: Mark Brown Tested-by: Gabor Juhos # on IPQ9574 Reviewed-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: spinand: Fix build with gcc < 7.5

2025-04-07T07:05:31Z

__VA_OPT__ is a macro that is useful when some arguments can be present or not to entirely skip some part of a definition. Unfortunately, it is a too recent addition that some of the still supported old GCC versions do not know about, and is anyway not part of C11 that is the version used in the kernel. Find a trick to remove this macro, typically '__VA_ARGS__ + 0' is a workaround used in netlink.h which works very well here, as we either expect: - 0 - A positive value - No value, which means the field should be 0. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503181330.YcDXGy7F-lkp@intel.com/ Fixes: 7ce0d16d5802 ("mtd: spinand: Add an optional frequency to read from cache macros") Cc: stable@vger.kernel.org Tested-by: Jean Delvare Signed-off-by: Miquel Raynal

Merge tag 'mtd/for-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux

2025-03-26T17:28:36Z

Pull mtd updates from Miquel Raynal: "MTD changes: - The atmel,dataflash binding has been converted to yaml and the physmap one constrained. Some logs are improved, error path are getting reworked a bit, few patches target the use of str_enabled_disabled(). Raw NAND changes: - i.MX8 and i.MX31 now have their own compatible, the Qcom driver got cleaned, the Broadcom driver got fixed. SPI NAND changes: - OTP support has been brought, and ESMT and Micron manufacturer drivers implement it. - Read retry, and Macronix manufacturer driver implement it. SPI NOR changes: - Adding support for few flashes. Few cleanup patches for the core driver, where we touched the headers inclusion list and we start using the scope based mutex cleanup helpers. There is also a bunch of minor improvements and fixes in drivers and bindings" * tag 'mtd/for-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (34 commits) dt-bindings: mtd: atmel,dataflash: convert txt to yaml mtd: mchp48l640: Use str_enable_disable() in mchp48l640_write_prepare() mtd: rawnand: gpmi: Use str_enabled_disabled() in gpmi_nand_attach_chip() mtd: mtdpart: Do not supply NULL to printf() dt-bindings: mtd: gpmi-nand: Add compatible string for i.MX8 chips mtd: nand: Fix a kdoc comment mtd: spinand: Improve spinand_info macros style mtd: spi-nor: drop unused mtd: spi-nor: explicitly include mtd: spi-nor: explicitly include mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program mtd: Fix error handling in mtd_device_parse_register() error path mtd: capture device name setting failure when adding mtd mtd: Add check for devm_kcalloc() mtd: Replace kcalloc() with devm_kcalloc() dt-bindings: mtd: physmap: Ensure all properties are defined mtd: rawnand: brcmnand: fix PM resume warning dt-bindings: mtd: mxc-nand: Document fsl,imx31-nand mtd: spinand: macronix: Add support for read retry ...

mtd: nand: Fix a kdoc comment

2025-03-18T16:15:39Z

The max_bad_eraseblocks_per_lun member of nand_device obviously describes a number of *maximum* number of bad eraseblocks per LUN. Fix this obvious typo. Fixes: 377e517b5fa5 ("mtd: nand: Add max_bad_eraseblocks_per_lun info to memorg") Cc: # fix kdoc comment Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal