linux.git/drivers/misc/eeprom, branch v6.12.80

misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66

2026-03-04T12:21:24+00:00

[ Upstream commit b54c82d6cbfc76647ba558e8e3647eb2b0ba0e2b ]

commit 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66
compatible strings") added support for 93xx56 and 93xx66 eeproms, but
didn't take into account that the write enable/disable + erase all
commands are hardcoded for the 6-bit address of the 93xx46.

This commit fixes the command word generation by increasing the number
of shifts as the address field grows, keeping the command intact.

Also, the check for 8-bit or 16-bit mode is no longer required as this
is already taken into account in the edev->addrlen field.

Signed-off-by: Markus Perkins 
Link: https://patch.msgid.link/20251202104823.429869-3-markus@notsyncing.net
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

eeprom: ee1004: Check chip before probing

2025-05-29T09:02:43+00:00

[ Upstream commit d9406677428e9234ea62bb2d2f5e996d1b777760 ]

Like other eeprom drivers, check if the device is really there and
functional before probing.

Signed-off-by: Eddie James 
Link: https://lore.kernel.org/r/20250218220959.721698-1-eajames@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

eeprom: digsy_mtc: Make GPIO lookup table match the device

2025-03-13T12:02:16+00:00

commit 038ef0754aae76f79b147b8867f9250e6a976872 upstream.

The dev_id value in the GPIO lookup table must match to
the device instance name, which in this case is combined
of name and platform device ID, i.e. "spi_gpio.1". But
the table assumed that there was no platform device ID
defined, which is wrong. Fix the dev_id value accordingly.

Fixes: 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO descriptors")
Cc: stable 
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20250206220311.1554075-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle

2024-12-14T19:04:09+00:00

[ Upstream commit 7738a7ab9d12c5371ed97114ee2132d4512e9fd5 ]

Add a quirk similar to eeprom_93xx46 to add an extra clock cycle before
reading data from the EEPROM.

The 93Cx6 family of EEPROMs output a "dummy 0 bit" between the writing
of the op-code/address from the host to the EEPROM and the reading of
the actual data from the EEPROM.

More info can be found on page 6 of the AT93C46 datasheet (linked below).
Similar notes are found in other 93xx6 datasheets.

In summary the read operation for a 93Cx6 EEPROM is:
Write to EEPROM:	110[A5-A0]	(9 bits)
Read from EEPROM:	0[D15-D0]	(17 bits)

Where:
	110 is the start bit and READ OpCode
	[A5-A0] is the address to read from
	0 is a "dummy bit" preceding the actual data
	[D15-D0] is the actual data.

Looking at the READ timing diagrams in the 93Cx6 datasheets the dummy
bit should be clocked out on the last address bit clock cycle meaning it
should be discarded naturally.

However, depending on the hardware configuration sometimes this dummy
bit is not discarded. This is the case with Exar PCI UARTs which require
an extra clock cycle between sending the address and reading the data.

Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-5193-SEEPROM-AT93C46D-Datasheet.pdf
Reviewed-by: Andy Shevchenko 
Signed-off-by: Parker Newman 
Link: https://lore.kernel.org/r/0f23973efefccd2544705a0480b4ad4c2353e407.1727880931.git.pnewman@connecttech.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

eeprom: ee1004: Fix locking issues in ee1004_probe()

2024-07-31T11:41:42+00:00

Currently, the devres-based management of ee1004_bus_data has
several issues when it comes to locking:

1. It does not call mutex_unlock() before returning an error.

2. When encountering an error, it deadlocks when trying to recursively
   lock a mutex.

Fix this by moving the mutex-protected bus data initialization into
a separate function so that devm_add_action_or_reset() is called
without the mutex being held.

Reported-by: Dan Carpenter 
Fixes: 55d57ef6fa97 ("eeprom: ee1004: Use devres for bus data cleanup")
Signed-off-by: Armin Wolf 
Reviewed-by: Dan Carpenter 
Link: https://lore.kernel.org/r/20240713234813.21746-1-W_Armin@gmx.de
Signed-off-by: Greg Kroah-Hartman

Merge tag 'i2c-for-6.11-rc1-try2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2024-07-19T23:46:26+00:00

Pull i2c fixes from Wolfram Sang:
 "The I2C core gains documentation updates for the testunit, a cleanup
  regarding unneeded 'driver_data' and more sanity checks in the char
  device.

  For the host drivers, this release includes significant updates, with
  the primary change being the renaming from "master/slave" to
  "controller/target" to adhere to I2C v7 and SMBus 3.2 standards.

  New Support:

   - Added support for Intel Arrow Lake-H
   - Added I2C support in the Arioha SoC by linking the Mediatek I2C
     controller

  Cleanups:

   - Added the MODULE_DESCRIPTION() macro, resolving a modpost warning
     in the ALi 1563 Southbridge driver.
   - Constified the regmap_config declaration in the i2c-designware
     driver.
   - Improved the coding style in the Renesas R-Car driver by removing
     unnecessary semicolons after brackets.

  General improvements:

   - In the OMAP device, replaced NOIRQ_SYSTEM_SLEEP_PM_OPS with
     RUNTIME_PM_OPS to enable waking up the controller during suspend()
     before suspend_noirq() kicks in.
   - Improved logging in the Xilinx driver.
   - Added a warning (WARN()) in the Renesas R-Car driver for spurious
     interrupts.

  DTS Changes:

   - Removed address-cell and size-cell from the Atmel at91sam, nVidia
     Tegra 20, and Samsung S3c2410 devices.
   - Fixed Texas Instruments OMAP4 I2C controller to comply with the
     i2c-controller.yaml schema.
   - Improved indentation in DTS examples for several I2C devices.
   - Converted the NXP LPC1788 binding to the dt-schema.
   - Added documentation for the compatible string thead,th1520-i2c.
   - Added the "power-domains" property for the Meson I2C driver.

  AT24 EEPROM driver changes:

   - add support for two new Microchip models
   - document even more new models in DT bindings (those use fallback
     compatibles so no code changes)"

* tag 'i2c-for-6.11-rc1-try2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (87 commits)
  i2c: document new callbacks in i2c_algorithm
  dt-bindings: i2c: amlogic,meson6-i2c: add optional power-domains
  dt-bindings: i2c: at91: Add sama7d65 compatible string
  i2c: st: reword according to newest specification
  i2c: cpm: reword according to newest specification
  i2c: virtio: reword according to newest specification
  i2c: nvidia-gpu: reword according to newest specification
  i2c: viai2c: reword according to newest specification
  i2c: viperboard: reword according to newest specification
  i2c: uniphier: reword according to newest specification
  i2c: uniphier-f: reword according to newest specification
  i2c: tiny-usb: reword according to newest specification
  i2c: thunderx-pcidrv: reword according to newest specification
  i2c: tegra-bpmp: reword according to newest specification
  i2c: taos-evm: reword according to newest specification
  i2c: sun6i-p2wi: reword according to newest specification
  i2c: stm32f4: reword according to newest specification
  i2c: sprd: reword according to newest specification
  i2c: sis5595: reword according to newest specification
  i2c: rzv2m: reword according to newest specification
  ...

eeprom: ee1004: Instantiate jc42 devices for DIMMS implementing Rev.1 SPD

2024-07-04T10:03:01+00:00

DDR4 DIMMS implementing SPD Annex L, Revision 1 do not implement SPD byte
14 (Module Temperature Sensor); this byte was only added in revision 2 of
the standard. This only applies to DDR4, not DDR4E or LPDDR4, since those
DDR types were only introduced in revision 3 of the standard.

Use this information to instantiate the jc42 device if the module is a DDR4
following SPD revision 1.0 and a device is detected at the expected thermal
sensor address, even if the Module Temperature Sensor byte suggests that
the thermal sensor is not supported.

Cc: Heiner Kallweit 
Cc: Thomas Weißschuh 
Signed-off-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20240629173716.20389-2-linux@roeck-us.net
Signed-off-by: Greg Kroah-Hartman

eeprom: ee1004: Call i2c_new_scanned_device to instantiate thermal sensor

2024-07-04T10:03:01+00:00

Instantiating a device by calling i2c_new_client_device() assumes that the
device is not already instantiated. If that is not the case, it will return
an error and generate a misleading kernel log message.

i2c i2c-0: Failed to register i2c client jc42 at 0x18 (-16)

This can be reproduced by unloading the ee1004 driver and loading it again.

Avoid this by calling i2c_new_scanned_device() instead, which returns
silently if a device is already instantiated or does not exist.

Fixes: 393bd1000f81 ("eeprom: ee1004: add support for temperature sensor")
Cc: Heiner Kallweit 
Cc: Thomas Weißschuh 
Signed-off-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20240629173716.20389-1-linux@roeck-us.net
Signed-off-by: Greg Kroah-Hartman

eeprom: ee1004: Add nvmem support

2024-07-04T10:02:56+00:00

Currently the driver does not register a nvmem provider, which means
that userspace programs cannot access the ee1004 EEPROM through the
standard nvmem sysfs API.
Fix this by replacing the custom sysfs attribute with a standard nvmem
interface, which also takes care of backwards compatibility.

Tested on a Dell Inspiron 3505.

Signed-off-by: Armin Wolf 
Link: https://lore.kernel.org/r/20240625063459.429953-2-W_Armin@gmx.de
Signed-off-by: Greg Kroah-Hartman

eeprom: ee1004: Use devres for bus data cleanup

2024-07-04T10:02:56+00:00

Use devm_add_action_or_reset() to clean up the bus data at
driver removal or when an error occurs during probe.
This will allow us to use other devres-based APIs later.

Tested on a Dell Inspiron 3505.

Signed-off-by: Armin Wolf 
Link: https://lore.kernel.org/r/20240625063459.429953-1-W_Armin@gmx.de
Signed-off-by: Greg Kroah-Hartman