Skip to content

L
linux
Switch branch/tag
  1. 28 Jun, 2024 2 commits
  3. 21 Jun, 2024 1 commit
  5. 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
  7. 18 Jun, 2024 1 commit
  9. 14 Jun, 2024 2 commits
  11. 13 Jun, 2024 2 commits
  13. 12 Jun, 2024 5 commits
  15. 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
  17. 10 Jun, 2024 7 commits
  19. 08 Jun, 2024 14 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7