kernel/linux.git/drivers/misc/eeprom/at25.c, branch linux-7.1.y

eeprom: at25: expose JEDEC ID via sysfs

2026-01-27T14:55:45+00:00

Return the raw JEDEC ID bytes as returned by the RDID command, even for variations that have the bytes in reverse order. This way we can avoid ambiguity if the manufacturer ever releases a new chip that returns them according to standard. Signed-off-by: Patrick Wicki Reviewed-by: Alexander Sverdlin Tested-by: Alexander Sverdlin Link: https://patch.msgid.link/20260120130603.1066559-2-patrick@subset.ch Signed-off-by: Greg Kroah-Hartman

eeprom: at25: add support for Infineon Cypress QSN FRAMs

2026-01-27T14:55:45+00:00

Add support for Infineon Cypress CY15****QSN FRAM chips. Unlike the QN variants these chips have an 8 byte JEDEC ID. The layout of the serial number matches that of already supported chips like the CY15B204QN, so make the read-out unconditional. Tested with the CY15B204QSN. According to Infineon datasheets, all QSN variants appear to share a consistent pattern so the size should be correctly detected based on the density bits in the ID: CY15B201QSN: 0x00 00 00 00 06 82 54 40, density_id: 8: 1Mb CY15B102QSN: 0x00 00 00 00 06 82 51 48, density_id: 9: 2Mb CY15B204QSN: 0x00 00 00 00 06 82 54 50, density_id: 10: 4Mb CY15V108QSN: 0x00 00 00 00 06 82 52 58, density_id: 11: 8Mb Signed-off-by: Patrick Wicki Reviewed-by: Alexander Sverdlin Tested-by: Alexander Sverdlin Link: https://patch.msgid.link/20260120130603.1066559-1-patrick@subset.ch Signed-off-by: Greg Kroah-Hartman

eeprom: at25: fram: Fix chip range in comment

2025-10-22T05:59:57+00:00

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:23+00:00

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:23+00:00

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:52+00:00

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:57+00:00

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:00+00:00

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:01+00:00

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:05+00:00

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