linux-kernel - Re: [PATCH v3] hwmon: (pmbus): Introduce page_change

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAD_4BXjV7ob6SEcmo2z8QPcY0-GcgKg-X_Dr9NQbUu9q5svSfg@mail.gmail.com>
Date: Mon, 7 Apr 2025 13:03:21 -0700
From: William Kennington <william@...nnington.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] hwmon: (pmbus): Introduce page_change_delay

On Fri, Apr 4, 2025 at 4:46 PM Guenter Roeck <linux@...ck-us.net> wrote:
>
> On 4/4/25 12:31, William Kennington wrote:
> > On Thu, Apr 3, 2025 at 5:28 PM Guenter Roeck <linux@...ck-us.net> 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
>