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: <CAJ12PfNFWt==4yYJRV_YGwz7eSam1gvNE6xbADxYqa=tiMuEqA@mail.gmail.com>
Date: Mon, 12 Jan 2026 17:37:50 +0300
From: TINSAE TADESSE <tinsaetadesse2015@...il.com>
To: Armin Wolf <W_Armin@....de>
Cc: linux@...ck-us.net, 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

Hi Armin,

> Do you know if the error is caused by the SPD5118 device itself or by the underlying i2c controller?

The error appears to be caused by the underlying I2C controller and platform
power sequencing rather than by the SPD5118 device itself.

The failure manifests as a temporary -ENXIO occurring only during s2idle
resume. The SPD5118 temperature sensor works correctly before suspend and
after resume once the bus becomes available again. This indicates that the
driver’s resume callback may be invoked before the I2C controller or firmware
has fully re-enabled access to the SPD hub.

> Please also share the output of "acpidump" and the name of the i2c
controller used to communicate with the SPD5118.

I have attached the output of acpidump as requested.
The SPD5118 is connected via I2C bus 14 and accessed through the Intel
I801 SMBus controller (0000:00:1f.4), which is ACPI-managed.

> Can you test if simply waiting for 10ms before syncing the regcache solves this
issue?

I tested adding an explicit msleep(10) in spd5118_resume() before calling
regcache_sync(), for the I2C interface to become ready after power-on.
With this delay in place, the resume failures (-ENXIO during regcache sync)
no longer occur, and repeated suspend/resume cycles are completed successfully.

However, relying on a fixed delay in the resume path is not robust and would
not be suitable across platforms with different firmware and power sequencing.
It also still performs hardware I/O during PM resume.

Additional evidence comes from running sensors, where all the temperature
limit and alarm attributes fail with “Can’t read” and temp1 reports N/A,
after adding msleep(10). All hwmon attributes (temperature input,
limits, and alarms) fail uniformly, which points to a bus-level access
failure rather than an issue with specific SPD5118 registers.
This supports deferring regcache synchronization and avoiding I2C transactions
in the resume callback, since userspace may attempt to access hwmon
attributes before the
bus or device is ready.

On Sun, Jan 11, 2026 at 1:27 AM Armin Wolf <W_Armin@....de> 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?
>
> Thanks,
> Armin Wolf
>
> > +     return ret;
> >   }
> >
> >   static DEFINE_SIMPLE_DEV_PM_OPS(spd5118_pm_ops, spd5118_suspend, spd5118_resume);

Download attachment "acpidump.txt.gz" of type "application/gzip" (697411 bytes)