Re: [PATCH v3] hwmon: (pmbus): Introduce page_change_delay

[William Kennington]

On Fri, Apr 4, 2025 at 4:46 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> On 4/4/25 12:31, William Kennington wrote:
> > On Thu, Apr 3, 2025 at 5:28 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> >>> @@ -2530,7 +2527,7 @@ static int pmbus_read_coefficients(struct i2c_client *client,
> >>>        rv = i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> >>>                            I2C_SMBUS_WRITE, PMBUS_COEFFICIENTS,
> >>>                            I2C_SMBUS_BLOCK_PROC_CALL, &data);
> >>> -     pmbus_update_ts(client, true);
> >>> +     pmbus_update_ts(client, PMBUS_OP_READ | PMBUS_OP_WRITE);
> >>
> >> I'd argue that this does not warrant a PMBUS_OP_WRITE in the first place.
> >>  From the chip's perspective, the operation is complete after the data
> >> is returned. This is just as much a write as any other SMBus read operation
> >> (a write of an address followed by a read). If you think otherwise, please
> >> explain.
> >>
> >> Either case, the change warrants an explanation in the patch description.
> >
> > The previous behavior was to treat this as a write though? I updated
>
> That dpesn't mean that the previous code was correct.

Yeah i 100% agree, I just didn't think this is the place to be
figuring out if the old decisions were accurate or not. I was keeping
the behavior the same (respecting write_delay) for this operation
because it's unclear to me what the purpose of the delay is for. It
seems like it's actually meant to delay around the concepts of smbus
read / write, not PMBUS logical reads / writes. Anyway, I left this
the same for now.

>
> > the description about picking the maximum delay in the code change
> > above, but this specific instance is still classified the same.
> >
> > I think technically we shouldn't do a single smbus transfer, but do
> > the write followed by read with a write delay injected between them. I
> > don't want to make that change here but it doesn't make sense to
> > ignore the write delay IMHO.
> >
>
> Every single SMBus read transfer is a write (chip address plus register address)
> followed by a read. Following your logic, every read should be treated as a write,
> followed by the write delay, followed by the read.

Understood, but I think that was the purpose of the delays when
originally contributed. It's about SMBUS related issues in specific
device implementations and not PMBUS logical operations.

>
> Guenter
>