Hi Andy, Thanks for the feedback. > Subject: Re: [PATCH v2 5/5] iio: magnetometer: ak8975: Sort OF table > > 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: > > > > > > > > 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. OK, will mention in the commit message about "soc_device_match". Cheers, Biju
