[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0E2B2679F0650AE1+aQw0VgKNbcFqDH33@kernel.org>
Date: Thu, 6 Nov 2025 13:38:30 +0800
From: Troy Mitchell <troy.mitchell@...ux.spacemit.com>
To: Troy Mitchell <troy.mitchell@...ux.spacemit.com>,
Andi Shyti <andi.shyti@...nel.org>, Yixun Lan <dlan@...too.org>,
Alex Elder <elder@...cstar.com>,
Michael Opdenacker <michael.opdenacker@...tcommit.com>,
Troy Mitchell <troymitchell988@...il.com>,
linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev
Subject: Re: [PATCH] i2c: spacemit: fix detect issue
On Thu, Nov 06, 2025 at 06:34:26AM +0100, Aurelien Jarno wrote:
> Hi,
>
> On 2025-11-06 09:05, Troy Mitchell wrote:
> > On Wed, Nov 05, 2025 at 11:44:00PM +0100, Aurelien Jarno wrote:
> > > Hi,
> > >
> > > On 2025-11-03 15:06, Troy Mitchell wrote:
> > [...]
> > > > if (i2c->status & (SPACEMIT_SR_BED | SPACEMIT_SR_ALD)) {
> > > > spacemit_i2c_reset(i2c);
> > > > - return -EAGAIN;
> > > > + if (i2c->status & SPACEMIT_SR_ALD)
> > > > + return -EAGAIN;
> > > > }
> > >
> > > This makes the resulting code, while correct, complex to understand as
> > > it is now two really different errors, as you explained well in the
> > > commit message.
> > >
> > > I therefore suggest to organize the code as:
> > >
> > > /* Arbitration Loss Detected */
> > > if (i2c->status & SPACEMIT_SR_ALD) {
> > > spacemit_i2c_reset(i2c);
> > > return -EAGAIN;
> > > }
> > >
> > > /* Bus Error No ACK/NAK */
> > > if (i2c->status & SPACEMIT_SR_BED) {
> > > spacemit_i2c_reset(i2c);
> > > }
> > Thanks. I'll fix it in the next version.
> > >
> > >
> > > > return i2c->status & SPACEMIT_SR_ACKNAK ? -ENXIO : -EIO;
> > > > @@ -491,6 +492,8 @@ static int spacemit_i2c_xfer(struct i2c_adapter *adapt, struct i2c_msg *msgs, in
> > > >
> > > > spacemit_i2c_init(i2c);
> > > >
> > > > + spacemit_i2c_clear_int_status(i2c, SPACEMIT_I2C_INT_STATUS_MASK);
> > > > +
> > >
> > > This sounds good to start the transfer with a clean interrupt state. I
> > > just wonder if it should be moved to spacemit_i2c_init(), ie where the
> > > corresponding interrupts are enabled.
> > Uh, We can move it actually. But is it essentail?
>
> For me ensuring that the interrupt status is in a clean state after
> enabling the interrupt is part of the initialization.
Yes, I agree that.
> Furthermore if
> spacemit_i2c_init() has to be called from another place, it's very
> likely that it's also needed to get interrupt status in a clean state.
Why we need to call init() in other place?
Could you give me a cese?
- Troy
>
> Regards
> Aurelien
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurelien@...el32.net http://aurel32.net
>
Powered by blists - more mailing lists