[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6ECB2C39812D3E23+aT-jFKR-o5RsJxD9@kernel.org>
Date: Mon, 15 Dec 2025 13:59:17 +0800
From: Troy Mitchell <troy.mitchell@...ux.spacemit.com>
To: Alex Elder <elder@...cstar.com>,
Troy Mitchell <troy.mitchell@...ux.spacemit.com>,
Andi Shyti <andi.shyti@...nel.org>, Yixun Lan <dlan@...too.org>,
Troy Mitchell <troymitchell988@...il.com>
Cc: linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev
Subject: Re: [PATCH v4] i2c: spacemit: introduce pio for k1
On Fri, Nov 07, 2025 at 09:50:26AM -0600, Alex Elder wrote:
> On 10/9/25 4:59 AM, Troy Mitchell wrote:
> > This patch introduces I2C PIO functionality for the Spacemit K1 SoC,
> > enabling the use of I2C in atomic context.
[...]
> > @@ -125,10 +127,14 @@ struct spacemit_i2c_dev {
> > enum spacemit_i2c_state state;
> > bool read;
> > + bool use_pio;
>
> This is fine, but you could maybe call it atomic (to match
> the callback funtion name).
>
> Actually, almost all uses of this field are negated, i.e.:
> if (!i2c->use_pio)
>
> Maybe you could use a name that doesn't require negation,
> like "can_block" for example.
Most of the negation is unnecessary; it's my code's behavior. I'll
modify the code behavior, not this variable. I believe this variable
directly reflects the hardware behavior. Therefore, I won't modify it
here.
- Troy
Powered by blists - more mailing lists