Re: [PATCH v2 5/5] iio: magnetometer: ak8975: Sort OF table

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

 



On Fri, Aug 18, 2023 at 05:43:15PM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 18, 2023 at 5:35 PM Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > On Fri, Aug 18, 2023 at 04:55:18PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Aug 18, 2023 at 1:30 PM Andy Shevchenko
> > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > > On Fri, Aug 18, 2023 at 08:56:00AM +0100, Biju Das wrote:
> > > > > Sort OF table alphabetically by compatibles.
> > > >
> > > > > Suggested-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > > >
> > > > Wrong, I haven't suggested that. See comment to the previous patch.
> > > >
> > > > And this is definitely wrong as Geert explained already why.
> > > > You need to fix the code that handles the ID table first.
> > >
> > > I retracted my own comment:
> > > https://lore.kernel.org/r/CAMuHMdUVCS_D0SBtDBrLQbAkdt0ZUbMOca+ukdwUtnGqzUr+cA@xxxxxxxxxxxxxx
> > >
> > > Upon a second read, I agree my reply
> > >
> > >     Seems like it is, cfr. the scoring system in drivers/of/base.c
> > >
> > > was confusing, as it was not super clear if it was a response to the
> > > first or the second line of your comment:
> > >
> > >     You mean the OF ID list must be specifically ordered?! What a nice
> > > minefield!
> > >     This has to be fixed somewhere else, surely.
> > >
> > > Conclusion: there is no issue, the scoring system handles primary
> > > vs. fallback compatible values, irrespective of ordering.
> >
> > Now I'm totally confused. Previously you mentioned a couple of
> > different APIs — one in OF, one in SoC. AFAIU the second one
> > still needs to be fixed to follow the logic that OF does.
> >
> > My previous understanding was that
> >   OF code — no issue
> >   SoC code — the ordering is required to be correct
> 
> Correct.
> 
> > Can you confirm that there is no issue in that second case?
> > And if there is none, why did you mention it?
> 
> There is still an issue (read: you have to be careful) in the second
> case, which does not matter here, as this driver does not use
> soc_device_match().
> I mentioned soc_device_match() because it is the second popular way
> to match on OF platforms, but behaves slightly different than
> of_match_node().

Now it's clear, thanks.
Biju, please add that to the commit message.

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux