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: <fb688a65-b2cd-4223-ae04-130b5657712d@roeck-us.net>
Date: Sat, 31 Jan 2026 17:25:00 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: TINSAE TADESSE <tinsaetadesse2015@...il.com>
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 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