Re: [PATCH 2/3] iio: accel: kxcjk-1013: Add support for KX022-1020

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 24, 2024 at 7:34 PM Jonathan Cameron
<Jonathan.Cameron@xxxxxxxxxx> wrote:
> On Thu, 24 Oct 2024 17:28:14 +0300
> Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > On Mon, Jul 15, 2024 at 10:30:46AM +0200, Hans de Goede wrote:
> > > On 7/14/24 7:33 PM, Rayyan Ansari wrote:
> > > > Add compatible for the KX022-1020 accelerometer [1] using the
> > > > KX022-1023 [2] register map as both have an identical i2c interface.
> > > >
> > > > [1]: https://kionixfs.azureedge.net/en/datasheet/KX022-1020%20Specifications%20Rev%2012.0.pdf
> > > > [2]: https://kionixfs.azureedge.net/en/datasheet/KX023-1025%20Specifications%20Rev%2012.0.pdf
> > > >
> > > > Signed-off-by: Rayyan Ansari <rayyan@xxxxxxxxx>
> > >
> > > Thanks, patch looks good to me:
> > >
> > > Reviewed-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> >
> > Note, this patch broke kx231025 case...
> >
> > > >   KXCJ91008,
> > > >   KXTJ21009,
> > > >   KXTF9,
> > > > + KX0221020,
> > > >   KX0231025,
> > > >   KX_MAX_CHIPS /* this must be last */
> > > >  };
> >
> > ...because this enum is used of ODR startup timeout settings which
> > are all moved now to be 0 and new ID inherited the timeouts from
> > the KX0231025 case.
> >
> > Since I have been looking into the driver, and I have a few patches
> > coming, I propose to do the following (as it's still ODR data being
> > missed) to:
> > 1) revert this one
> > 2) apply my set;
> > 3) re-apply this with the fixed data.
>
> > Another approach can be done (but probably not by me) is to move the ID
> > to the proper location, add ODR startup timeouts or explain why it's not
> > needed and then apply my patch.
> >
> > But, taking into account that we are almost at -rc5 and I want my stuff
> > not to be postponed, I tend to follow the first approach.
> >
> > Opinions, comments?
> >
> > P.S. FWIW, my set will include switching this driver to use chip_info
> > structure so the similar mistakes won't happen again, that's also why
> > I prefer the first approach I listed above.
>
> Hmm. Either I want the revert in before the release, or your series
> to make the merge window (and hence probably hit in first couple of stable
> releases).

I have sent the v3 (out of 24 patches) that includes revert and a fix
in the I2C ID table. Those two can be backported.

> Ideal would be revert very soon and chase it in to togreg so your series
> can go on top, but that would rely on some lucky timing of pull requests
> and merges that is probably too optimistic.

Up to you how to proceed, the patches are available in the mailing list :-)

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux