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: <CAJ12PfOvDe5-tsuZGeGpOZh61MztorK08NFfDMV3mkP8dNpDfA@mail.gmail.com>
Date: Sun, 1 Feb 2026 10:30:29 +0300
From: TINSAE TADESSE <tinsaetadesse2015@...il.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Armin Wolf <W_Armin@....de>, 
	"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 Sun, Feb 1, 2026 at 4:25 AM Guenter Roeck <linux@...ck-us.net> wrote:
>
> On 1/31/26 11:50, TINSAE TADESSE wrote:
> ...
> >
> > Hi Guenter,
> >
> > While investigating this issue, I previously mentioned
> > about a flow where SPD write disabled state can be
> > exported as a capability from the i801 controller, so
> > that the SPD5118 hwmon driver consumes it.
> >
> > The SPD write disabled state is known to the controller
> > driver (i2c-i801), but this information is not
> > propagated to client drivers. As a result, auto-detected
> > devices may be instantiated and probed even though the
> > controller cannot support the required access model.
> >
> > This raises a major architectural question:
> >
> > Should SMBus / I2C controller drivers be able to
> > advertise bus-level capability constraints (such as SPD
> > write disabled state) to client drivers, so that clients can
> > make an informed decision during probe?
> >
> > A capability-based approach would allow:
> > * controller drivers to expose what is possible on a given bus
> > * client drivers to decide whether they can operate correctly
> > * avoidance of device-specific policy in controller drivers
> > * consistent handling across different SPD-capable devices
> >
> > I actually tested the possibility of detecting, propagating,
> > and consuming the SPD write disabled state using an I2C
> > adapter capability flag. Using this approach, I was able to
> > fix the issue even with the CONFIG_SENSORS_SPD5118_DETECT
> > kernel configuration enabled.
> >
> > At this stage, I am not proposing a specific implementation.
> > The goal of this RFC is to get agreement on whether this type
> > of problem should be solved through capability propagation,
> > and if so, what mechanism would be preferred.
> >
> > Any feedback on design direction, or existing infrastructure
> > that could be reused would be very welcome.
> >
>
> I think it is a good idea, but how would the flag look like ?
> The i801 controller only write protects a range of addresses;
> I think it is 0x50..0x57. So any I2C_FUNC flag would presumably
> have to be address range specific. You could try adding
> something like I2C_FUNC_SPD_WRITE_PROTECTED. Either case,
> you'll have to ask the I2C subsystem maintainers for advice.
> I would suggest to give it a try.
>
> Thanks,
> Guenter
>

Hello Guenter,

Thanks for the feedback.
I have attached one implementation that I tested and confirmed to
resolve the issue.
I will forward an RFC to the i2c maintainers, and if you don't mind,
I will also add you to the email list.

Thanks again for the guidance.

View attachment "0002-PATCH-2-2-hwmon-spd5118-Fail-probe-if-SPD-writes-are.patch" of type "text/x-patch" (1908 bytes)

View attachment "0001-PATCH-1-2-i2c-i801-Detect-SPD-Write-Disable-and-expo.patch" of type "text/x-patch" (2474 bytes)