On Thu, Mar 24, 2022 at 9:04 AM Tim Harvey <thar...@gateworks.com> wrote:
>
> On Thu, Mar 24, 2022 at 8:59 AM Fabio Estevam <feste...@gmail.com> wrote:
> >
> > Hi Tim,
> >
> > On Thu, Mar 24, 2022 at 12:32 PM Tim Harvey <thar...@gateworks.com> wrote:
> > >
> > > commit 7c84319af9c7 ("dm: gpio: Correct use of -ENODEV in drivers")
> > > changed the return code for an I2C NAK from -ENODEV to -EREMOTEIO.
> >
> > I think we should be consistent with Linux and return -ENXIO for the NACK
> > case:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/fault-codes.rst?h=v5.17#n88
> >
> > "ENXIO
> > Returned by I2C adapters to indicate that the address phase
> > of a transfer didn't get an ACK. While it might just mean
> > an I2C device was temporarily not responding, usually it
> > means there's nothing listening at that address."
>
> Fabio,
>
> I share your sentiment however if I go and change this in
> drivers/i2c/mxc_i2c.c (or others) how do I know I don't cause the same
> breakage that Simon's patch did? I can't easily tell if anyone is
> depending on EREMOTEIO (or ENODEV as it was) to mean NAK.
>
> For reference there are about 48 i2c drivers in drivers/i2c and only
> 3 currently return -ENXIO
> (designware_i2c.c,i2c-microchip.c,sun8i_rsb.c)
>
> Honestly I would love to just implement retries on NAK in mxc_i2c.c
> but that approach was not accepted in the Linux driver when I
> attempted to do it there.
>
Any other feedback on this? Regardless of if I2C drivers should return
the same error code as Linux on a NAK, I would like to get this patch
applied to fix the current regression for the upcoming v2022.04.
Best Regards,
Tim
