Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Jul 01, 2021
  2. May 14, 2021
  3. Dec 04, 2020
  4. Sep 25, 2020
  5. Sep 24, 2020
    • Jon Hunter's avatar
      eeprom: at24: Initialise AT24 NVMEM ID field · f434f9b7
      Jon Hunter authored
      
      The AT24 EEPROM driver does not initialise the 'id' field of the
      nvmem_config structure and because the entire structure is not
      initialised, it ends up with a random value. This causes the NVMEM
      driver to append the device 'devid' value to name of the NVMEM
      device. Ideally for I2C devices such as the AT24 that already have a
      unique name, we would not bother to append the 'devid'. However, given
      that this has always been done for AT24 devices, we cannot remove the
      'devid' as this will change the name of the userspace sysfs node for
      the NVMEM device. Nonetheless we should ensure that the 'id' field of
      the nvmem_config structure is initialised so that there is no chance of
      a random value causes problems in the future. Therefore, set the NVMEM
      config.id to NVMEM_DEVID_AUTO for AT24 EEPROMs so that the 'devid' is
      always appended.
      
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      f434f9b7
  6. Sep 17, 2020
  7. Sep 01, 2020
  8. Aug 25, 2020
    • Jean Delvare's avatar
      eeprom: at24: Tidy at24_read() · 99363d1c
      Jean Delvare authored
      
      The elegant code in at24_read() has the drawback that we now need
      to make a copy of all parameters to pass them to the post-processing
      callback function if there is one. Rewrite the loop in such a way that
      the parameters are not modified, so saving them is no longer needed.
      
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      99363d1c
  9. Aug 18, 2020
    • Jean Delvare's avatar
      eeprom: at24: Add support for the Sony VAIO EEPROMs · a4423ced
      Jean Delvare authored
      
      Special handling of the Sony VAIO EEPROMs is the last feature of the
      legacy eeprom driver that the at24 driver does not support. Adding
      this would let us deprecate and eventually remove the legacy eeprom
      driver.
      
      So add the option to specify a post-processing callback function that
      is called after reading data from the EEPROM, before it is returned
      to the user. The 24c02-vaio type is the first use case of that option:
      the callback function will mask the sensitive data for non-root users
      exactly as the legacy eeprom driver was doing.
      
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      [Bartosz: removed a stray newline]
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      a4423ced
  10. Jul 10, 2020
  11. Mar 12, 2020
    • Michael Auchter's avatar
      misc: eeprom: at24: fix regulator underflow · 58d6fee5
      Michael Auchter authored
      The at24 driver attempts to read a byte from the device to validate that
      it's actually present, and if not, disables the vcc regulator and
      returns -ENODEV. However, between the read and the error handling path,
      pm_runtime_idle() is called and invokes the driver's suspend callback,
      which also disables the vcc regulator. This leads to an underflow of the
      regulator enable count if the EEPROM is not present.
      
      Move the pm_runtime_suspend() call to be after the error handling path
      to resolve this.
      
      Fixes: cd5676db
      
       ("misc: eeprom: at24: support pm_runtime control")
      Signed-off-by: default avatarMichael Auchter <michael.auchter@ni.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      58d6fee5
  12. Feb 10, 2020
  13. Jan 23, 2020
  14. Jan 09, 2020
  15. Jan 02, 2020
  16. Oct 04, 2019
  17. Jul 28, 2019
  18. Jul 22, 2019
  19. Jun 27, 2019
  20. May 31, 2019
  21. May 28, 2019
  22. Feb 14, 2019
  23. Dec 10, 2018
  24. Oct 02, 2018
    • Wang Xin's avatar
      eeprom: at24: fix unexpected timeout under high load · 9a9e295e
      Wang Xin authored
      
      Within at24_loop_until_timeout the timestamp used for timeout checking
      is recorded after the I2C transfer and sleep_range(). Under high CPU
      load either the execution time for I2C transfer or sleep_range() could
      actually be larger than the timeout value. Worst case the I2C transfer
      is only tried once because the loop will exit due to the timeout
      although the EEPROM is now ready.
      
      To fix this issue the timestamp is recorded at the beginning of each
      iteration. That is, before I2C transfer and sleep. Then the timeout
      is actually checked against the timestamp of the previous iteration.
      This makes sure that even if the timeout is reached, there is still one
      more chance to try the I2C transfer in case the EEPROM is ready.
      
      Example:
      
      If you have a system which combines high CPU load with repeated EEPROM
      writes you will run into the following scenario.
      
       - System makes a successful regmap_bulk_write() to EEPROM.
       - System wants to perform another write to EEPROM but EEPROM is still
         busy with the last write.
       - Because of high CPU load the usleep_range() will sleep more than
         25 ms (at24_write_timeout).
       - Within the over-long sleeping the EEPROM finished the previous write
         operation and is ready again.
       - at24_loop_until_timeout() will detect timeout and won't try to write.
      
      Signed-off-by: default avatarWang Xin <xin.wang7@cn.bosch.com>
      Signed-off-by: default avatarMark Jonas <mark.jonas@de.bosch.com>
      Signed-off-by: default avatarBartosz Golaszewski <brgl@bgdev.pl>
      9a9e295e
  25. Jul 25, 2018
  26. May 16, 2018
  27. May 09, 2018
  28. Mar 23, 2018