lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 6 Sep 2019 09:53:01 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tony Lindgren <tony@...mide.com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Benoît Cousson <bcousson@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Adam Ford <aford173@...il.com>,
        André Roth <neolynx@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-pm@...r.kernel.org,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com
Subject: Re: [RFC v2 3/3] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap36xx

Hi,
I am preparing the next PATCH version now. Incl. updating the commit
messages to carry more documentation about the opp-supported-hw bit
definitions.

So please do not merge yet.

> Am 05.09.2019 um 16:27 schrieb Tony Lindgren <tony@...mide.com>:
> 
> Hi,
> 
> * H. Nikolaus Schaller <hns@...delico.com> [190904 08:54]:
>> According to omap.txt bindings documentation, matching the ti-cpufreq driver needs
>> to specify explicitly if a board uses an omap3430 or omap36xx chip.
>> 
>> This needs to add ti,omap3430 to most omap34xx boards and replace ti,omap3630
>> by ti,omap36xx for some omap36xx boards (most others already have done it right).
>> 
>> We also clean up some instances of missing ti,am3517 so that we can rely on
>> seeing either one of:
>> 
>> ti,am3517
>> ti,omap34xx
>> ti,omap36xx
>> 
>> in addition to ti,omap3.
> 
> Please set up things to use ti,omap3630 in addition to ti,omap36xx
> for compatible to avoid churning the same files later.
> 
>> diff --git a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
>> --- a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
>> +++ b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
>> @@ -9,5 +9,5 @@
>> 
>> / {
>> 	model = "LogicPD Zoom DM3730 SOM-LV Development Kit";
>> -	compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3";
>> +	compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap36xx", "ti,omap3";
>> };
> 
> So just make this:
> 
> compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap36xx", "ti,omap3";

Do we really need both? The clock driver already checks for both variants and the
ti-cpufreq will as well. So it suffices to have either "ti,omap3630" or "ti,omap36xx".

But yes, there may be user-space code that reads sysfs. So we should keep the
"ti,omap3630" and add "ti,omap36xx".

> 
> And so on. It's fine to use ti,omap3630 for 37xx too as they're the same.
> 
>> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
>> index 9a5fde2d9bce..9947574bd0f8 100644
>> --- a/arch/arm/boot/dts/omap3-ldp.dts
>> +++ b/arch/arm/boot/dts/omap3-ldp.dts
>> @@ -10,7 +10,7 @@
>> 
>> / {
>> 	model = "TI OMAP3430 LDP (Zoom1 Labrador)";
>> -	compatible = "ti,omap3-ldp", "ti,omap3";
>> +	compatible = "ti,omap3-ldp", "ti,omap34xx, "ti,omap3";
> 
> This fails to compile, it's missing a '"' for ti,omap34xx. And here too,
> please update to use:

Ah yes. I missed that (and my build script did not build all DTB).

> 
> 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"

* 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?

> 
> And again it's fine to add "ti,omap3430" for 3530 variants.

Yes, sure.

BR,
Nikolaus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ