[PATCH v1] i2c: lpi2c: implement master_xfer_atomic callback

[Carlos Song]

> -----Original Message-----
> From: Andi Shyti <andi.shyti at kernel.org>
> Sent: Tuesday, May 6, 2025 7:02 AM
> To: Francesco Dolcini <francesco at dolcini.it>
> Cc: Aisheng Dong <aisheng.dong at nxp.com>; Shawn Guo
> <shawnguo at kernel.org>; Sascha Hauer <s.hauer at pengutronix.de>;
> Pengutronix Kernel Team <kernel at pengutronix.de>; Fabio Estevam
> <festevam at gmail.com>; Emanuele Ghidoli <emanuele.ghidoli at toradex.com>;
> linux-i2c at vger.kernel.org; imx at lists.linux.dev;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Francesco
> Dolcini <francesco.dolcini at toradex.com>
> Subject: [EXT] Re: [PATCH v1] i2c: lpi2c: implement master_xfer_atomic callback
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
> 
> 
> Hi Francesco,
> 
> I'm sorry for the late reply on this.
> 
> Can someone from NXP help with the review? Carlos? Dong?
> 

Hi, 

Yes. I reviewed this. It is ok for me! Thank you. 
Reviewed-by: Carlos Song <carlos.song at nxp.com>

> On Wed, Mar 19, 2025 at 03:51:14PM +0100, Francesco Dolcini wrote:
> > From: Emanuele Ghidoli <emanuele.ghidoli at toradex.com>
> >
> > Rework the read and write code paths in the driver to support
> > operation in atomic contexts. To achieve this, the driver must not
> > rely on IRQs or perform any scheduling, e.g., via a sleep or schedule
> > routine. Even jiffies do not advance in atomic contexts, so timeouts
> > based on them are substituted with delays.
> >
> > Implement atomic, sleep-free, and IRQ-less operation. This increases
> > complexity but is necessary for atomic I2C transfers required by some
> > hardware configurations, e.g., to trigger reboots on an external PMIC chip.
> >
> > Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli at toradex.com>
> > Signed-off-by: Francesco Dolcini <francesco.dolcini at toradex.com>
> > ---
> >  drivers/i2c/busses/i2c-imx-lpi2c.c | 258
> > +++++++++++++++++++----------
> >  1 file changed, 173 insertions(+), 85 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > index 0d4b3935e687..f34b6f07e9a4 100644
> > --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/init.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/io.h>
> > +#include <linux/iopoll.h>
> >  #include <linux/kernel.h>
> >  #include <linux/module.h>
> >  #include <linux/of.h>
> > @@ -187,36 +188,35 @@ struct lpi2c_imx_struct {
> >       struct i2c_client       *target;
> >  };
> >
> > +#define READL_POLL_TIMEOUT(atomic, addr, val, cond, delay_us,
> > +timeout_us) \
> 
> READ_POLL_TIMEOUT is not really a name that belongs to this driver. Could we
> name it something like lpi2c_imx_read_poll_timeout()? I'd prefer lowercase, but
> I won't object to capital letters.
> 
> Additionally, the timeout_us value is always 500000, could we just drop it from
> the parameter list? Same goes for LPI2C_MSR.
> 
> Thanks,
> Andi