Re: [PATCH 1/3] hwmon: spd5118: Do not fail resume on temporary I2C errors

[Guenter Roeck <linux@roeck-us.net>]

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