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 for Android: free password hash cracker in your pocket

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

Message-ID: <2e6f0437-0dca-41e9-ac80-f0843120cf52@roeck-us.net>
Date: Sun, 1 Feb 2026 07:21:22 -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 23:30, TINSAE TADESSE wrote:
> 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.

Looks good. I didn't know about the quirks, and that drivers are allowed to use them.
We live and learn. Go ahead, and please copy the hardware monitoring mailing list.
I'll hold off sending my patch upstream until we get a response; your solution is
much cleaner.

Thanks,
Guenter