These are just two left-overs from times when this driver was bigger.

They are not really useful anymore. Remove them.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Tested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Arrange declarations of local variables by line length as visually
it's easier to read.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Tested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This structure only needs to exist during the call to nvmem_register().
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Tested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We use our own mutex for locking. Disable the regmap-specific locking.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Tested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add all supported at24 variants to the of_match table.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>

AT24 EEPROMs have a write-protect pin, which - when pulled high -
inhibits writes to the upper quadrant of memory (although it has been
observed that on some chips it disables writing to the entire memory
range).

On some boards, this pin is connected to a GPIO and pulled high by
default, which forces the user to manually change its state before
writing. On linux this means that we either need to hog the line all
the time, or set the GPIO value before writing from outside of the
at24 driver.

Make the driver check if the write-protect GPIO was defined in the
device tree and pull it low whenever writing to the EEPROM.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

The chip size passed via devicetree, i2c, or acpi device ids is now no
longer limited to a power of two. So the temporary fix can be removed.
Signed-off-by: NSven Van Asbroeck <svendev@arcx.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Fundamental properties such as capacity and page size differ among
at24-type chips. But these chips do not have an id register, so this
can't be discovered at runtime.

Traditionally, at24-type eeprom properties were determined in two ways:
- by passing a 'struct at24_platform_data' via platform_data, or
- by naming the chip type in the devicetree, which passes a 'magic
  number' to probe(), which is then converted to a 'struct
  at24_platform_data'.

Recently a bug was discovered because the magic number rounds down all
chip sizes to the lowest power of two. This was addressed by
a work-around commit 5478e478 ("eeprom: at24: correctly set the
size for at24mac402"), with the wish that magic numbers should over
time be converted to structs.

This patch replaces the magic numbers with 'struct at24_chip_data'.
Signed-off-by: NSven Van Asbroeck <svendev@arcx.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

A regmap_config struct is pretty big and declaring two of them
statically just to tweak the reg_bits value adds unnecessary bloat.

Declare the regmap config locally in at24_probe() instead.

Bloat-o-meter output for ARM:

add/remove: 0/2 grow/shrink: 1/0 up/down: 4/-272 (-268)
Function                                     old     new   delta
at24_probe                                  1560    1564      +4
regmap_config_8                              136       -    -136
regmap_config_16                             136       -    -136
Total: Before=7012, After=6744, chg -3.82%
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

There are a couple symbols defined in the driver source file which are
missing the at24_ prefix. This patch fixes that.

For module params: use module_param_named() in order to not break
userspace.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Fix issues reported by checkpatch for at24.c.
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Some multi-address eeproms in the at24 family may not automatically
roll-over reads to the next slave address. On those eeproms, reads
that straddle slave boundaries will not work correctly.

Solution:
Mark such eeproms with a flag that prevents reads straddling
slave boundaries. Add the AT24_FLAG_NO_RDROL flag to the eeprom
entry in the device_id table, or add 'no-read-rollover' to the
eeprom devicetree entry.

Note that I have not personally enountered an at24 chip that
does not support read rollovers. They may or may not exist.
However, my hardware requires this functionality because of
a quirk.
Signed-off-by: NSven Van Asbroeck <svendev@arcx.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Remove remaining now unneeded code dealing with SMBUS details.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Remove the old and now unused read functions.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Add regmap-based read function and instead of using three different
read functions (standard, mac, serial) use just one and factor out the
read offset adjustment for mac and serial to at24_adjust_read_offset.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Remove the old and now unused write functions.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Add a regmap-based write function.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Change return type of at24_translate_offset to *at24_client to make
member regmap accessible for subsequent patches of this series.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

This patch adds basic regmap support to be used by subsequent
patches of this series.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Trying to read the MAC address from an eeprom that has an offset that
is not a multiple of 4 causes an error currently.

Fix it by changing the nvmem stride to 1.

Cc: stable@vger.kernel.org
Signed-off-by: NDavid Lechner <david@lechnology.com>
[Bartosz: tweaked the commit message]
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

The at24 driver creates dummy I2C devices to access offsets in the chip
that are outside the area supported using a single I2C address. It is not
meaningful to use runtime PM to such devices; the system firmware (ACPI)
does not know about these devices nor runtime PM was enabled for them.
Always use the real device instead of the dummy ones.

Fixes: 98e82010 ("eeprom: at24: enable runtime pm support")
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: NSven Van Asbroeck on a 24AA16/24LC16B <svendev@arcx.com>
[Bartosz: rebased on top of previous fixes for 4.15, tweaked the
          commit message]
[Sven: fixed Bartosz's rebase]
Signed-off-by: NSven Van Asbroeck <svendev@arcx.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

So far we completely rely on the caller to provide valid arguments.
To be on the safe side perform an own sanity check.

Cc: stable@vger.kernel.org
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Chip datasheet mentions that word addresses other than the actual
start position of the MAC delivers undefined results. So fix this.
Current implementation doesn't work due to this wrong offset.

Cc: stable@vger.kernel.org
Fixes: 0b813658 ("eeprom: at24: add support for at24mac series")
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down
the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6,
making it impossible to read it all.

Fix it by manually adjusting the value in probe().

This patch contains a temporary fix that is suitable for stable
branches. Eventually we'll probably remove the call to ilog2() while
converting the magic values to actual structs.

Cc: stable@vger.kernel.org
Fixes: 0b813658 ("eeprom: at24: add support for at24mac series")
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

To maintain backward compatibility with old Device Trees, only use the OF
device ID table .data if the device was registered via OF and the OF node
compatible matches an entry in the OF device ID table.
Suggested-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Currently the device is kept in D0, there is an opportunity
to save power by enabling runtime pm.

Device can be daisy chained from PMIC and we can't rely on I2C core
for auto resume/suspend. Driver will decide when to resume/suspend.
Reviewed-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NDivagar Mohandass <divagar.mohandass@intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Obtain the size of the EEPROM chip from DT if the "size" property is
specified for the device.
Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NDivagar Mohandass <divagar.mohandass@intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Allow the at24 driver to get configuration information from both OF and
ACPI by using the more generic device_property functions.
This change was inspired by the at25.c driver.

I have a custom board with a ST M24C02 EEPROM attached to an I2C bus.
With the following ACPI construct, this patch instantiates a working
instance of the driver.

Device (EEP0) {
 Name (_HID, "PRP0001")
 Name (_DSD, Package () {
  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
  Package () {
   Package () {"compatible", Package () {"st,24c02"}},
   Package () {"pagesize", 16},
  },
 })
 Name (_CRS, ResourceTemplate () {
  I2cSerialBus (
   0x0057, ControllerInitiated, 400000,
   AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00,
   ResourceConsumer,,)
 })
}
Signed-off-by: NBen Gardner <gardner.ben@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The at24 driver doesn't check if the chip is functional in its probe
function. This leads to instantiating devices that are not physically
present. For example the cape EEPROMs for BeagleBone Black are defined
in the device tree at four addresses on i2c2, but normally only one of
them is present.

If the userspace doesn't know the location in advance, it will need to
check if reading the nvmem attributes fails to determine which EEPROM
is actually there.

Try to read a single byte in probe() and bail-out with -ENODEV if the
read fails.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

loop_until_timeout() replaced a do {} while loop in the at24 driver
with a for loop which, under certain circumstances (such as heavy load
or low value of the write_timeout argument), can lead to the code in
the loop never being executed.

Make sure that at least one iteration of the code enclosed within
loop_until_timeout() is always executed.
Suggested-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add a new read function to the at24 driver allowing to retrieve the
factory-programmed mac address embedded in chips from the at24mac
family.

These chips can be instantiated similarily to the at24cs family,
except that there's no way of having access to both the serial number
and the mac address at the same time - the user must instantiate
either an at24cs or at24mac device as both special memory areas are
accessible on the same slave address.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The chips from the at24cs family have two memory areas - a regular
read-write block and a read-only area containing the serial number.

The latter is visible on a different slave address (the address of the
rw memory block + 0x08). In order to access both blocks the user needs
to instantiate a regular at24c device for the rw block address and a
corresponding at24cs device on the serial number block address.

Add a function that allows to access the serial number and assign it
to at24->read_func if the chip allows serial number read operations
and the driver was passed the relevant flag for this device.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Split at24_eeprom_write() into three smaller functions - one for the
i2c operations and two for the smbus extensions (separate routines for
block and byte transfers). Assign them in at24_probe() depending on
the bus capabilities.

Also: in order to avoid duplications move code adjusting the count
argument into a separate function and use it for i2c and smbus block
writes (no need for a roll-over for byte writes as we're always
writing one byte).
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Split at24_eeprom_read() into two smaller functions - one for the
i2c operations and one for the smbus extensions. Assign them in
at24_probe() depending on the bus capabilities.

Also: in order to avoid duplications move the comments related to
offset calculations above the at24_translate_offset() routine.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Before splitting the read/write routines into smaller, more
specialized functions, unduplicate some code in advance.

Use a 'for' loop instead of 'do while' when waiting for the previous
write to complete and hide it behind a macro.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The first step in simplifying the read and write functions is to call
them via function pointers stored in at24_data. When we eventually
split the routines into smaller ones (depending on whether they use
smbus or i2c operations) we'll simply assign them to said pointers
instead of checking the flags at runtime every time we read/write.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Align the arguments in broken lines with the arguments list's opening
brackets and make checkpatch.pl happy by converting 'unsigned' into
'unsigned int'.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In preparation for splitting at24_eeprom_write() & at24_eeprom_read()
into smaller, specialized routines move at24_read() below, so that it
won't be intertwined with the low-level EEPROM accessors.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As part of the preparation for introducing support for more chips,
improve the readability of the device table by separating columns
with tabs.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch moves to nvmem support in the driver to use callback instead
of regmap.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>