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] [day] [month] [year] [list]

Message-ID: <CAJ12PfMC_Potx9aNxaJJ3y=sX=rzyhm-6LJ8Z8OjUyDxiDUNsA@mail.gmail.com>
Date: Thu, 15 Jan 2026 16:50:03 +0300
From: TINSAE TADESSE <tinsaetadesse2015@...il.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: "linux-hwmon@...r.kernel.org" <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

On Wed, Jan 14, 2026 at 5:23 PM Guenter Roeck <linux@...ck-us.net> wrote:
>
> On 1/14/26 05:07, TINSAE TADESSE wrote:
> ...
> >>> Hi Guenter,
> >>>
> >>> I tested changing the i801 SMBus controller to use
> >>> SET_LATE_SYSTEM_SLEEP_PM_OPS() instead of
> >>> DEFINE_SIMPLE_DEV_PM_OPS() as a diagnostic experiment. With this
> >>> change, spd5118 resume failures (-ENXIO)
> >>> still persist, suggesting PM ordering alone is insufficient and other
> >>> firmware interactions are involved.
> >>
> >> How about the problem in the suspend function ? Is that also still seen ?
> >>
> >> Also, the subject talks about -EIO. Is that still seen ?
> >>
> >> Either case, can you enable debug logs for the i801 driver ?
> >> It should generate log entries when it reports errors.
> >>
> >> Thanks,
> >> Guenter
> >>
> >
> > Hi Guenter,
> >
> > Thank you for the questions. To clarify:
> >
> Please do not drop mailing lists from replies.
>
> > 1) I have not observed any failures in the suspend path. The suspend
> > callback completes successfully, and
> > I have not seen I2C errors or warnings during suspend at any point.
>
> Sorry, I seem to be missing something.
>
> In that case, what is the point of patch 3/3 of your series which
> removes hardware accesses from the suspend function ?
>
> > 2) I have also not observed -EIO in my testing. The error consistently
> > reported on resume and subsequent hwmon access is -ENXIO.
> > Earlier references to -EIO were based on assumptions rather than
> > observed logs, and I should have been clearer about that.
> >
>
> Thanks for the clarification.
>
> Guenter
>
> > I am enabling debug logging for the i801 driver to collect more
> > concrete evidence of controller state during resume.
>

Hi Guenter,

> Sorry, I seem to be missing something.
>
> In that case, what is the point of patch 3/3 of your series which
> removes hardware accesses from the suspend function ?

You are right to question this, and I agree that it needs clarification.

Patch 3/3 was originally proposed under the assumption that the resume failures
were caused by spd5118 performing I2C transactions while the
controller was not yet available,
and that removing hardware accesses from the suspend path might
mitigate the issue.
At that point, I assumed the problem was limited to the resume callback.

After enabling detailed i801 debug logging and testing with
SET_LATE_SYSTEM_SLEEP_PM_OPS() in the i801 driver,
it became clear that this assumption was incorrect. The controller
itself reports "i801_smbus: No response"
both during suspend and immediately after resume, and spd5118 merely
propagates the resulting -ENXIO.
This indicates that the issue is not caused by spd5118 suspend/resume
behavior, but by the unavailability of the
SMBus controller due to platform or firmware interactions during
s2idle transitions.

Given this, I agree that patch 3/3 does not address the root cause and
does not provide a justified improvement.
I am therefore fine with dropping it.

Thank you for pointing this out.