lkml.org 
[lkml]   [2019]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v2 3/3] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap36xx
* H. Nikolaus Schaller <hns@goldelico.com> [190906 07:53]:
> > Am 05.09.2019 um 16:27 schrieb Tony Lindgren <tony@atomide.com>:
> > compatible = "ti,omap3-ldp", "ti,omap3430", "ti,omap34xx", "ti,omap3";
>
> After thinking a little about the whole topic the main rule of this change must be:
>
> * do not break any existing in-tree DTS
> => only *add* to compatible what we need to distinguish between omap34 and omap36
>
> * additions shall only follow new scheme
> => we only add "ti,omap34xx" or "ti,omap36xx"
> but neither "ti,omap3630" nor "ti,omap3430"

Sorry I don't follow you on this one.. We should always add "ti,omap3630"
where "ti,omap36xx" is currently used so we can eventually get rid of
"ti,omap36xx". And the same for 34xx.

> * cover some out-of-tree DTS
> => make the ti-cpufreq driver still match "ti,omap3430" or "ti,omap3630"
> even if this duplicates compatibility
>
> This would mean that the logicpd-som-lv-37xx-devkit.dts gets the additional "ti,omap36xx"
> while the omap3-ldp.dts would only get an "ti,omap34xx" but no "ti,omap3430" (since we
> do not use it anywhere).
>
> Could you agree on this approach?

Yeah sounds like logicpd-som-lv-37xx-devkit.dts currently still needs
"ti,omap36xx" for now.

If modifying omap3-ldp.dts, also add "ti,omap3430" in additon to
"ti,omap34xx" that it already has.

So basically let's assume the following:

"ti,omap3430" == "ti,omap34xx"
"ti,omap3630" == "ti,omap36xx"

This means code needs to parse both.

And eventually we just drop the "xx" variants.

So while patching compatibles, let's also update for this to
avoid multiple patches churning the same compatibles over and
over.

Regards,

Tony

\
 
 \ /
  Last update: 2019-09-06 17:48    [W:0.076 / U:2.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site