1. 07 Jul, 2024 2 commits
  2. 05 Jul, 2024 2 commits
  3. 02 Jul, 2024 5 commits
  4. 01 Jul, 2024 1 commit
  5. 30 Jun, 2024 3 commits
  6. 28 Jun, 2024 2 commits
  7. 21 Jun, 2024 1 commit
  8. 19 Jun, 2024 2 commits
    • Guenter Roeck's avatar
      hwmon: (spd5118) Add support for Renesas/ITD SPD5118 hub controllers · 1226a1b2
      Guenter Roeck authored
      The SPD5118 specification says, in its documentation of the page bits
      in the MR11 register:
      
      "
      This register only applies to non-volatile memory (1024) Bytes) access of
      SPD5 Hub device.
      For volatile memory access, this register must be programmed to '000'.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      "
      
      Renesas/ITD SPD5118 hub controllers take this literally and disable access
      to volatile memory if the page selected in MR11 is != 0. Since the BIOS or
      ROMMON will access the non-volatile memory and likely select a page != 0,
      this means that the driver will not instantiate since it can not identify
      the chip. Even if the driver instantiates, access to volatile registers
      is blocked after a nvram read operation which selects a page other than 0.
      
      To solve the problem, add initialization code to select page 0 during
      probe. Before doing that, use basic validation to ensure that this is
      really a SPD5118 device and not some random EEPROM.
      
      Cc: Sasha Kozachuk <skozachuk@google.com>
      Cc: John Hamrick <johnham@google.com>
      Cc: Chris Sarra <chrissarra@google.com>
      Tested-by: default avatarArmin Wolf <W_Armin@gmx.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      1226a1b2
    • Guenter Roeck's avatar
      hwmon: (spd5118) Use regmap to implement paging · 27972a41
      Guenter Roeck authored
      Using regmap for paging significantly improves caching since the regmap
      cache no longer needs to be cleared after changing the page, so let's
      use it.
      Suggested-by: default avatarArmin Wolf <W_Armin@gmx.de>
      Tested-by: default avatarArmin Wolf <W_Armin@gmx.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      27972a41
  9. 18 Jun, 2024 1 commit
  10. 14 Jun, 2024 2 commits
  11. 13 Jun, 2024 2 commits
  12. 12 Jun, 2024 5 commits
  13. 11 Jun, 2024 4 commits
    • Guenter Roeck's avatar
      hwmon: (pmbus/lm25066) Let enum chips start with index 0 · cbbb76e4
      Guenter Roeck authored
      Commit ac0c26ba ("hwmon: (lm25066) Use i2c_get_match_data()") changed
      enum chips to start with 1 instead of 0, under the assumption that
      the data pointer in of_device_id must not start with 0 (NULL) if
      i2c_get_match_data() is used. However, that is perfectly fine as long as
      there is also an i2c_device_id array with the same data which is used
      as fallback in that case.
      
      Let enum chips start with 0 to avoid confusion against other drivers
      where the enum starts with 0 and i2c_get_match_data() is used as well.
      
      Cc: Rob Herring <robh@kernel.org>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      cbbb76e4
    • Guenter Roeck's avatar
      hwmon: (nct6775) Let enum kinds start with index 0 · 22558934
      Guenter Roeck authored
      Commit 10a0575e ("hwmon: (nct6775-i2c) Use i2c_get_match_data()")
      introduced calling i2c_get_match_data() to the nct6775 driver. As part
      of that commit, enum kinds was changed to start with 1, based on
      
          Adjust the 'kinds' enum to not use 0, so that no match data can be
          distinguished from a valid enum value.
      
      The patch had to be fixed later with commit 2792fc8f ("hwmon:
      (nct6775-core) Explicitly initialize nct6775_device_names indexes") and
      commit efe86092 ("hwmon: (nct6775-platform) Explicitly initialize
      nct6775_sio_names indexes").
      
      Various patches submitted later show that the change from 0 to 1 is
      not really necessary. As it turns out, it is perfectly fine as long as
      there is an i2c_device_id array with the same data as in the of_device_id
      array. This data is used as fallback if the data pointer in struct
      of_device_id is NULL (0).
      
      Let enum chips start with 0 to avoid confusion against other drivers
      where the enum starts with 0 and i2c_get_match_data() is used as well.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      22558934
    • Guenter Roeck's avatar
      hwmon: (pmbus/mp2856) Let enum chips start with index 0 · e229c6e8
      Guenter Roeck authored
      Earlier it was assumed that the data pointer in of_device_id must not start
      with 0 (NULL) if i2c_get_match_data() is used. However, it turns out that
      this is perfectly fine as long as there is also an i2c_device_id array with
      the same data, which is used as fallback in that case.
      
      Let enum chips start with 0 to avoid confusion against other drivers
      where the enum starts with 0 and i2c_get_match_data() is used as well.
      
      While doing that, remove chip_id from struct mp2856_data since it is only
      used in the probe function, and typecast the result of i2c_get_match_data()
      to kernel_ulong_t to avoid the double typecast.
      
      Cc: Peter Yin <peteryin.openbmc@gmail.com>
      Cc: Potin Lai <potin.lai.pt@gmail.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      e229c6e8
    • Guenter Roeck's avatar
      hwmon: (pmbus/max31827) Explain why enum chips must not start with 0 · 138d45d9
      Guenter Roeck authored
      If a driver calls device_get_match_data(), the .data pointer in its id
      data structures must not be NULL/0 because device_get_match_data()
      returns NULL if an entry is not found. Explain that in a comment to avoid
      confusion why this is required in this driver but not in other drivers.
      
      Cc: Daniel Matyas <daniel.matyas@analog.com>
      Acked-by: default avatarNuno Sa <nuno.sa@analog.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      138d45d9
  14. 10 Jun, 2024 7 commits
  15. 08 Jun, 2024 1 commit