kernel/drivers/misc/eeprom/at25.c, branch linux-rolling-stable

eeprom: at25: fram: Fix chip range in comment

2025-10-22T05:59:57Z

The first chip supported by the commented code is CY15B102QN, fix the copy-paste error. Signed-off-by: Alexander Sverdlin Link: https://patch.msgid.link/20251020145858.1598599-1-alexander.sverdlin@siemens.com Signed-off-by: Greg Kroah-Hartman

eeprom: at25: make FRAM device ID error message more precise

2025-09-06T13:58:23Z

The error description would be wrong in case the "size" Devicetree property is missing for an FRAM without device ID. Signed-off-by: Markus Heidelberg Reviewed-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250815095839.4219-4-m.heidelberg@cab.de Signed-off-by: Greg Kroah-Hartman

eeprom: at25: support Cypress FRAMs without device ID

2025-09-06T13:58:23Z

Not all FRAM chips have a device ID and implement the corresponding read command. For such chips this led to the following error on module loading: at25 spi2.0: Error: no Cypress FRAM (id 00) The device ID contains the memory size, so devices without this ID are supported now by setting the size manually in Devicetree using the "size" property. Tested with FM25L16B and "size = <2048>;": at25 spi2.0: 2 KByte fm25 fram, pagesize 4096 According to Infineon/Cypress datasheets, these FRAMs have a device ID: FM25V01A FM25V02A FM25V05 FM25V10 FM25V20A FM25VN10 but these do not: FM25040B FM25640B FM25C160B FM25CL64B FM25L04B FM25L16B FM25W256 So all "FM25V*" FRAMs and only these have a device ID. The letter after "FM25" (V/C/L/W) only describes the voltage range, though. Link: https://lore.kernel.org/all/20250401133148.38330-1-m.heidelberg@cab.de/ Signed-off-by: Markus Heidelberg Reviewed-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250815095839.4219-3-m.heidelberg@cab.de Signed-off-by: Greg Kroah-Hartman

eeprom: at25: convert to spi-mem API

2025-07-16T12:24:52Z

Replace the RAW SPI accesses with spi-mem API. The latter will fall back to RAW SPI accesses if spi-mem callbacks are not implemented by a controller driver. Notable advantages: - read function now allocates a bounce buffer for SPI DMA compatibility, similar to write function; - the driver can now be used in conjunction with SPI controller drivers providing spi-mem API only, e.g. spi-nxp-fspi. - during the initial probe the driver polls busy/ready status bit for 25ms instead of giving up instantly and hoping that the FW didn't write the EEPROM Notes: - mutex_lock() has been dropped from fm25_aux_read() because the latter is only being called in probe phase and therefore cannot race with at25_ee_read() or at25_ee_write() Quick 4KB block size test with CY15B102Q 256KB F-RAM over spi_omap2_mcspi driver (no spi-mem ops provided, fallback to raw SPI inside spi-mem): OP | throughput, KB/s | change --------+-----------------------+------- write | 1717.847 -> 1656.684 | -3.6% read | 1115.868 -> 1059.367 | -5.1% The lower throughtput probably comes from the 3 messages per SPI transfer inside spi-mem instead of hand-crafted 2 messages per transfer in the former at25 code. However, if the raw SPI access is not preserved, then the driver doesn't grow from the lines-of-code perspective and subjectively could be considered even a bit simpler. Higher performance impact on the read operation could be explained by the newly introduced bounce buffer in read operation. I didn't find any explanation or guarantee, why would a bounce buffer be not needed on the read side, so I assume it's a pure luck that nobody read EEPROM into some variable on stack on an architecture where kernel stack would be not DMA-able. Cc: Michael Walle Cc: Hui Wang Link: https://lore.kernel.org/all/28ab8b72afee1af59b628f7389f0d7f5@kernel.org/ Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250702222823.864803-1-alexander.sverdlin@siemens.com Signed-off-by: Greg Kroah-Hartman

eeprom: at25: fram: Detect and support inside-out chip variants

2025-07-16T12:17:57Z

Infineon seems to be confused with the order ID bytes should be presented by the FRAM chips and to be on the safe side they offer chips which are either JEDEC conform or the full opposite of the latter. Examples of the chips which present ID bytes in the reversed order are: CY15B102QN CY15B204QSN Let's support them nevertheless. Except reversing the ID bytes, they also have quite different density encoding even across EXCELON(tm) family. The patch has been tested with the above two chips. Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250702222927.864875-1-alexander.sverdlin@siemens.com Signed-off-by: Greg Kroah-Hartman

eeprom: at25: drop unneeded MODULE_ALIAS

2024-04-29T09:14:00Z

The ID table already has respective entry and MODULE_DEVICE_TABLE and creates proper alias for SPI driver. Having another MODULE_ALIAS causes the alias to be duplicated. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240414154957.127113-1-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman

eeprom: at25: Convert to use fwnode_device_is_compatible()

2023-01-20T11:05:01Z

Replace open coded fwnode_device_is_compatible() in the driver. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230119175742.77723-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

eeprom: at25: Rework buggy read splitting

2022-06-27T14:21:05Z

The recent change to split reads into chunks has several problems: 1. If an SPI controller has no transfer size limit, max_chunk is SIZE_MAX, and num_msgs becomes zero, causing no data to be read into the buffer, and exposing the original contents of the buffer to userspace, 2. If the requested read size is not a multiple of the maximum transfer size, the last transfer reads too much data, overflowing the buffer, 3. The loop logic differs from the write case. Fix the above by: 1. Keeping track of the number of bytes that are still to be transferred, instead of precalculating the number of messages and keeping track of the number of bytes tranfered, 2. Calculating the transfer size of each individual message, taking into account the number of bytes left, 3. Switching from a "while"-loop to a "do-while"-loop, and renaming "msg_count" to "segment". While at it, drop the superfluous cast from "unsigned int" to "unsigned int", also from at25_ee_write(), where it was probably copied from. Fixes: 0a35780c755ccec0 ("eeprom: at25: Split reads into chunks and cap write size") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/7ae260778d2c08986348ea48ce02ef148100e088.1655817534.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman

eeprom: at25: Split reads into chunks and cap write size

2022-06-10T14:42:48Z

Make use of spi_max_transfer_size to avoid requesting transfers that are too large for some spi controllers. Signed-off-by: Brad Bishop Signed-off-by: Eddie James Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20220524215142.60047-1-eajames@linux.ibm.com Signed-off-by: Greg Kroah-Hartman

eeprom: at25: Use DMA safe buffers

2022-04-24T15:25:10Z

Reading EEPROM fails with following warning: [ 16.357496] ------------[ cut here ]------------ [ 16.357529] fsl_spi b01004c0.spi: rejecting DMA map of vmalloc memory [ 16.357698] WARNING: CPU: 0 PID: 371 at include/linux/dma-mapping.h:326 fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.357775] CPU: 0 PID: 371 Comm: od Not tainted 5.16.11-s3k-dev-01743-g19beecbfe9d6-dirty #109 [ 16.357806] NIP: c03fbc9c LR: c03fbc9c CTR: 00000000 [ 16.357825] REGS: e68d9b20 TRAP: 0700 Not tainted (5.16.11-s3k-dev-01743-g19beecbfe9d6-dirty) [ 16.357849] MSR: 00029032 CR: 24002282 XER: 00000000 [ 16.357931] [ 16.357931] GPR00: c03fbc9c e68d9be0 c26d06a0 00000039 00000001 c0d36364 c0e96428 00000027 [ 16.357931] GPR08: 00000001 00000000 00000023 3fffc000 24002282 100d3dd6 100a2ffc 00000000 [ 16.357931] GPR16: 100cd280 100b0000 00000000 aff54f7e 100d0000 100d0000 00000001 100cf328 [ 16.357931] GPR24: 100cf328 00000000 00000003 e68d9e30 c156b410 e67ab4c0 e68d9d38 c24ab278 [ 16.358253] NIP [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.358292] LR [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.358325] Call Trace: [ 16.358336] [e68d9be0] [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 (unreliable) [ 16.358388] [e68d9c00] [c03fcb44] fsl_spi_bufs.isra.0+0x94/0x1a0 [ 16.358436] [e68d9c20] [c03fd970] fsl_spi_do_one_msg+0x254/0x3dc [ 16.358483] [e68d9cb0] [c03f7e50] __spi_pump_messages+0x274/0x8a4 [ 16.358529] [e68d9ce0] [c03f9d30] __spi_sync+0x344/0x378 [ 16.358573] [e68d9d20] [c03fb52c] spi_sync+0x34/0x60 [ 16.358616] [e68d9d30] [c03b4dec] at25_ee_read+0x138/0x1a8 [ 16.358667] [e68d9e50] [c04a8fb8] bin_attr_nvmem_read+0x98/0x110 [ 16.358725] [e68d9e60] [c0204b14] kernfs_fop_read_iter+0xc0/0x1fc [ 16.358774] [e68d9e80] [c0168660] vfs_read+0x284/0x410 [ 16.358821] [e68d9f00] [c016925c] ksys_read+0x6c/0x11c [ 16.358863] [e68d9f30] [c00160e0] ret_from_syscall+0x0/0x28 ... [ 16.359608] ---[ end trace a4ce3e34afef0cb5 ]--- [ 16.359638] fsl_spi b01004c0.spi: unable to map tx dma This is due to the AT25 driver using buffers on stack, which is not possible with CONFIG_VMAP_STACK. As mentionned in kernel Documentation (Documentation/spi/spi-summary.rst): - Follow standard kernel rules, and provide DMA-safe buffers in your messages. That way controller drivers using DMA aren't forced to make extra copies unless the hardware requires it (e.g. working around hardware errata that force the use of bounce buffering). Modify the driver to use a buffer located in the at25 device structure which is allocated via kmalloc during probe. Protect writes in this new buffer with the driver's mutex. Fixes: b587b13a4f67 ("[PATCH] SPI eeprom driver") Cc: stable Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/230a9486fc68ea0182df46255e42a51099403642.1648032613.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman