@@ -182,6 +182,22 @@ static struct bin_attribute *ee1004_attrs[] = {
BIN_ATTRIBUTE_GROUPS(ee1004);
+static void ee1004_probe_temp_sensor(struct i2c_client *client)
+{
+ struct i2c_board_info info = { .type = "jc42" };
+ u8 byte14;
+ int ret;
+
+ /* byte 14, bit 7 is set if temp sensor is present */
+ ret = ee1004_eeprom_read(client, &byte14, 14, 1);
+ if (ret != 1 || !(byte14 & BIT(7)))
+ return;
+
+ info.addr = 0x18 | (client->addr & 7);
+
+ i2c_new_client_device(client->adapter, &info);
+}
+
static void ee1004_cleanup(int idx, struct ee1004_bus_data *bd)
{
if (--bd->dev_count == 0) {
@@ -234,6 +250,9 @@ static int ee1004_probe(struct i2c_client *client)
dev_dbg(&client->dev, "Currently selected page: %d\n", err);
bd->current_page = err;
}
+
+ ee1004_probe_temp_sensor(client);
+
mutex_unlock(&ee1004_bus_lock);
dev_info(&client->dev,
The EE1004 SPD data structure advertises the presence of a thermal sensor on a DDR4 module in byte 14, bit 7. Let's use this information to explicitly instantiate the thermal sensor I2C client instead of having to rely on class-based I2C probing. The temp sensor i2c address can be derived from the SPD i2c address, so we can directly instantiate the device and don't have to probe for it. If the temp sensor has been instantiated already by other means (e.g. class-based auto-detection), then the busy-check in i2c_new_client_device will detect this. Patch was successfully tested with a Corsair Vengeance RGB PRO DDR4 module which comes with a thermal sensor. Link: https://www.spinics.net/lists/linux-i2c/msg65963.html Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> --- Patch is the same as the RFC version, it's just re-based. --- drivers/misc/eeprom/ee1004.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)