diff mbox series

i2c: ocores: set IACK bit after core is enabled

Message ID 20240517191000.11390-1-grygorii.tertychnyi@leica-geosystems.com
State Superseded
Headers show
Series i2c: ocores: set IACK bit after core is enabled | expand

Commit Message

grygorii tertychnyi May 17, 2024, 7:10 p.m. UTC 
Setting IACK bit when core is disabled does not clear the "Interrupt Flag"
bit in the status register, and the interrupt remains pending.

Sometimes it causes failure for the very first message transfer, that is
usually a device probe.

Hence, set IACK bit after core is enabled to clear pending interrupt.

Signed-off-by: Grygorii Tertychnyi <grygorii.tertychnyi@leica-geosystems.com>
---
 drivers/i2c/busses/i2c-ocores.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
2.43.0

Comments

Peter Korsgaard May 18, 2024, 6:46 p.m. UTC | #1 
>>>>> "Grygorii" == Grygorii Tertychnyi <grembeter@gmail.com> writes:

 > Setting IACK bit when core is disabled does not clear the "Interrupt Flag"
 > bit in the status register, and the interrupt remains pending.

 > Sometimes it causes failure for the very first message transfer, that is
 > usually a device probe.

 > Hence, set IACK bit after core is enabled to clear pending interrupt.

 > Signed-off-by: Grygorii Tertychnyi <grygorii.tertychnyi@leica-geosystems.com>

I no longer have access to a device with i2c-ocores, but it sounds
sensible so:

Acked-by: Peter Korsgaard <peter@korsgaard.com>


> ---
 >  drivers/i2c/busses/i2c-ocores.c | 2 +-
 >  1 file changed, 1 insertion(+), 1 deletion(-)

 > diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
 > index a0af027db04c..a52f8fd4e2fe 100644
 > --- a/drivers/i2c/busses/i2c-ocores.c
 > +++ b/drivers/i2c/busses/i2c-ocores.c
 > @@ -439,8 +439,8 @@ static int ocores_init(struct device *dev, struct ocores_i2c *i2c)
 >  	oc_setreg(i2c, OCI2C_PREHIGH, prescale >> 8);

 >  	/* Init the device */
 > -	oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
 >  	oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN);
 > +	oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);

 >  	return 0;
 >  }
 > --
 > 2.43.0
Markus Elfring May 19, 2024, 5:25 a.m. UTC | #2 
…
> Sometimes it causes failure for the very first message transfer, …

Does such an information indicate the need for the tag “Fixes”?

Regards,
Markus
grygorii tertychnyi May 20, 2024, 1:30 p.m. UTC | #3 
On Sun, May 19, 2024 at 7:25 AM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> …
> > Sometimes it causes failure for the very first message transfer, …
>
> Does such an information indicate the need for the tag “Fixes”?

I'm not sure: the original initialization order was introduced by the
very first commit
18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller").

Regards,
Grygorii
Andrew Lunn May 20, 2024, 1:41 p.m. UTC | #4 
On Mon, May 20, 2024 at 03:30:43PM +0200, grygorii tertychnyi wrote:
> On Sun, May 19, 2024 at 7:25 AM Markus Elfring <Markus.Elfring@web.de> wrote:
> >
> > …
> > > Sometimes it causes failure for the very first message transfer, …
> >
> > Does such an information indicate the need for the tag “Fixes”?
> 
> I'm not sure: the original initialization order was introduced by the
> very first commit
> 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller").

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

  It fixes a problem like an oops, a hang, data corruption, a real
  security issue, a hardware quirk, a build error (but not for things
  marked CONFIG_BROKEN), or some “oh, that’s not good” issue.

Your description of the very first message transfer failing sounds
like a data corruption? Using the commit which adds the driver is also
fine, some bugs have been there all the time.

Remember to add a

Cc: stable@vger.kernel.org

    Andrew
grygorii tertychnyi May 20, 2024, 3:01 p.m. UTC | #5 
On Mon, May 20, 2024 at 3:41 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, May 20, 2024 at 03:30:43PM +0200, grygorii tertychnyi wrote:
> > On Sun, May 19, 2024 at 7:25 AM Markus Elfring <Markus.Elfring@web.de> wrote:
> > >
> > > …
> > > > Sometimes it causes failure for the very first message transfer, …
> > >
> > > Does such an information indicate the need for the tag “Fixes”?
> >
> > I'm not sure: the original initialization order was introduced by the
> > very first commit
> > 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller").
>
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>
>   It fixes a problem like an oops, a hang, data corruption, a real
>   security issue, a hardware quirk, a build error (but not for things
>   marked CONFIG_BROKEN), or some “oh, that’s not good” issue.
>
> Your description of the very first message transfer failing sounds
> like a data corruption? Using the commit which adds the driver is also
> fine, some bugs have been there all the time.

Thanks! Yes, it is a data corruption.

> Remember to add a
>
> Cc: stable@vger.kernel.org

I will send v2.

Regards,
Grygorii
diff mbox series

Patch

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index a0af027db04c..a52f8fd4e2fe 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -439,8 +439,8 @@  static int ocores_init(struct device *dev, struct ocores_i2c *i2c)
 	oc_setreg(i2c, OCI2C_PREHIGH, prescale >> 8);

 	/* Init the device */
-	oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
 	oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN);
+	oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);

 	return 0;
 }