Re: [BUG] hwmon: (spd5118) resume fails -ENXIO on write protected hubs

On 8/17/26 16:02, Armin Wolf wrote:
> Am 17.08.26 um 19:03 schrieb GG:
> 
>> Understood - thanks for explaining the page selection part, that makes sense. I'll blacklist it for now.
>>
>> Appreciate you taking the time to get back to me on this!
>>
>> Gabriel G
>>
>> On Monday, August 17th, 2026 at 12:58 PM, Guenter Roeck <[email protected]> wrote:
>>
>>> On 8/17/26 09:42, GG wrote:
>>>> Sorry - I should have searched the archives before sending my last email. I've since
>>>> found this from February, which is the same problem:
>>>>
>>>>     https://lore.kernel.org/linux-hwmon/[email protected]/
>>>>
>>>> And I missed the obvious clue sitting in my own boot log:
>>>>
>>>>     i801_smbus 0000:00:1f.4: SPD Write Disable is set
>>>>
>>>> So my kernel already knew. Apologies for the noise.
>>>>
>>> Unfortunately that knowledge is not passed on to the spd5118 driver.
> 
> Yes, sadly the patch series adding support for this was abandoned :/
> 

If I recall correctly, the important part (a I2C_AQ_SPD_WRITE_DISABLED flag
or similar provided by the I2C controller) was rejected.

>>>> One thing I'll mention in case it's useful: that series above has spd5118 refuse to
>>>> probe when writes are disabled. On my machine that would lose me two working
>>>> temperature sensors. Reads are completely fine here, I get correct temps,
>>>> and my temperature limits read back properly. It's only writing that fails.
>>>>
>>>> Happy to test anything on my hardware if it would help.
>>>>
>>> That can not be done, as I mentioned in my other e-mail.
>>>
>>> Problem is that accessing temperature sensor data on spd5118 compatible chips
>>> requires a write to select the correct chip page. If writes are disabled, and
>>> the BIOS selected a page other than page 0, temperature sensor data is not
>>> accessible. Since the BIOS can do whatever it wants and may have selected a
>>> different page after a suspend/resume sequence, one simply can not trust
>>> the status when the driver is loaded initially.
>>>
>>> Guenter
> 
> Would it be enough if we always select page 0 inside spd5118_i2c_init(), thereby
> preventing the driver from probing on hardware that does not allow us to write
> the page select register?
> 

Looking into the code, it seems like the device may have been instantiated
through the detect path. That makes me wonder which distribution enables
CONFIG_SENSORS_SPD5118_DETECT because it should _not_ be enabled by default.

Anyway, I guess I'll have to implement a dummy write operation in
spd5118_i2c_init() to check if writes are possible and bail out on error.
That is less than perfect but the best we can do without a flag from the
I2C controller.

I'll look into that after the commit window closes.

Thanks,
Guenter