Re: [PATCH 1/2] i2c: i801: Detect SPD Write Disable and expose as adapter quirk

[TINSAE TADESSE]

On Mon, Jun 8, 2026 at 3:28 PM Andi Shyti <andi.shyti@xxxxxxxxxx> wrote:
>
> Hi Tinsae,
>
> sorry for the very late reply.
>
> > +/* SPD writes are blocked by host controller */
> > +#define I2C_AQ_SPD_WRITE_DISABLED    BIT(8)
> > +
>
> We don't need this extra flag, we already do this statement in
> i2c_register_spd().
>
> Can't we just assume that for spd5118 spd write is always
> disabled? That's what happens in i2c_register_spd.
>
> Check:
>
> 84d477354b0a ("i2c: smbus: Support DDR5 and LPDDR5 SPD EEPROMs")
> 4d6d35d3417d ("i2c: smbus: introduce Write Disable-aware SPD instantiating functions")
>
> Thanks,
> Andi


Hi Andi,

Thanks for reviewing this patch series.

> We don't need this extra flag, we already do this statement in
> i2c_register_spd().

Based on my testing, the issue does not appear to be in the SPD
registration path
handled by 'i2c_register_spd()'.

I verified that:

* The i801 driver correctly detects SPD Write Disable.
* Disabling 'CONFIG_SENSORS_SPD5118_DETECT' completely eliminates the problem.
* The suspend/resume failures only occur when 'CONFIG_SENSORS_SPD5118_DETECT=y'.

Based on these observations, it appears that the SPD5118 detect path
may instantiate
the device independently of the SPD registration logic and therefore
may bypass the
SPD Write Disable handling added by commit 4d6d35d3417d ("i2c: smbus:
introduce Write
Disable-aware SPD instantiating functions").

This would explain why SPD5118 is still instantiated on systems where SPD Write
Disable is active, even though the SPD registration helpers are
already SPD WD aware.

The above observations are what motivated this patch series. Am I correct in
suspecting that the SPD5118 detect path is separate from the SPD
registration path, or
is there another instantiation path that I should investigate?

Best,
Tinsae Tadesse