linux-kernel - Re: [PATCH 1/3] hwmon: spd5118: Do not fail resume on temporary I2C errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a43a785a-2b43-4588-8fbf-5eaec398acb9@gmx.de>
Date: Mon, 12 Jan 2026 18:46:26 +0100
From: Armin Wolf <W_Armin@....de>
To: Guenter Roeck <linux@...ck-us.net>,
 Tinsae Tadesse <tinsaetadesse2015@...il.com>
Cc: linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] hwmon: spd5118: Do not fail resume on temporary I2C
 errors

Am 12.01.26 um 17:36 schrieb Guenter Roeck:

> On 1/10/26 14:27, Armin Wolf wrote:
>> Am 10.01.26 um 18:19 schrieb Tinsae Tadesse:
>>
>>> SPD5118 DDR5 temperature sensors may be temporarily unavailable
>>> during s2idle resume. Ignore temporary -ENXIO and -EIO errors during 
>>> resume and allow
>>> register synchronization to be retried later.
>>
>> Hi,
>>
>> do you know if the error is caused by the SPD5118 device itself or by 
>> the underlying
>> i2c controller? Please also share the output of "acpidump" and the 
>> name of the i2c
>> controller used to communicate with the SPD5118.
>>
>>> Signed-off-by: Tinsae Tadesse <tinsaetadesse2015@...il.com>
>>> ---
>>>   drivers/hwmon/spd5118.c | 8 +++++++-
>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/hwmon/spd5118.c b/drivers/hwmon/spd5118.c
>>> index 5da44571b6a0..ec9f14f6e0df 100644
>>> --- a/drivers/hwmon/spd5118.c
>>> +++ b/drivers/hwmon/spd5118.c
>>> @@ -512,9 +512,15 @@ static int spd5118_resume(struct device *dev)
>>>   {
>>>       struct spd5118_data *data = dev_get_drvdata(dev);
>>>       struct regmap *regmap = data->regmap;
>>> +    int ret;
>>>       regcache_cache_only(regmap, false);
>>> -    return regcache_sync(regmap);
>>> +    ret = regcache_sync(regmap);
>>> +    if(ret == -ENXIO || ret == -EIO) {
>>> +        dev_warn(dev, "SPD hub not responding on resume (%d), 
>>> deferring init\n", ret);
>>> +        return 0;
>>> +    }
>>
>> The specification says that the SPD5118 might take up to 10ms to 
>> initialize its i2c interface
>> after power on. Can you test if simply waiting for 10ms before 
>> syncing the regcache solves this
>> issue?
>>
>
> It seems to be highly unlikely that this code executes within 10ms of 
> powering on the memory.
>
> Guenter
>
AFAIK the 10ms are associated with the VDDIO supply, the VDDSPD main supply is different from that.
I just want to test if this device disables VDDIO during suspend-to-idle.

I have another theory: if the SPD5118 somehow looses power, we might still need to manually put the
device into 16-bit address mode using standard 8-bit i2c commands.

Thanks,
Armin Wolf

>> Thanks,
>> Armin Wolf
>>
>>> +    return ret;
>>>   }
>>>   static DEFINE_SIMPLE_DEV_PM_OPS(spd5118_pm_ops, spd5118_suspend, 
>>> spd5118_resume);
>>
>