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:   Tue, 3 Sep 2019 08:23:51 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Benoît Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.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@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        letux-kernel@...nphoenux.org, kernel@...a-handheld.com
Subject: Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table


> Am 03.09.2019 um 08:14 schrieb Viresh Kumar <viresh.kumar@...aro.org>:
> 
> On 03-09-19, 08:01, H. Nikolaus Schaller wrote:
>> 
>>> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@...aro.org>:
>>> 
>>> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
>>>> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
>>>> 1GHz capability is automatically detected.
>>>> 
>>>> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
>>>> ---
>>>> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
>>>> 1 file changed, 7 deletions(-)
>>>> 
>>>> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>> index 5441e9ffdbb4..e98b0c615f19 100644
>>>> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>> @@ -11,13 +11,6 @@
>>>> 	cpus {
>>>> 		cpu@0 {
>>>> 			cpu0-supply = <&vcc>;
>>>> -			operating-points = <
>>>> -				/* kHz    uV */
>>>> -				300000  1012500
>>>> -				600000  1200000
>>>> -				800000  1325000
>>>> -				1000000	1375000
>>>> -			>;
>>>> 		};
>>>> 	};
>>> 
>>> This should be merged with 2/5 ?
>> 
>> Well, it bloats 2/5.
> 
> It is logically the right place to do this as that's where we are
> adding opp-v2.

Well, sometimes the philosophy of patches is to add something new
first and remove the old in a second separate patch if the system
can live with both. This makes it easier to digest single patches
(because they are smaller) and might also better pinpoint an issue
by bisect.

> 
>> What I hope (I can't test) is that this opp-v1 table
>> is ignored if an opp-v2 table exists. So that it can be
>> removed by a separate follow-up patch.
> 
> It should work as that's what we are doing in OPP core, but I still
> feel this better get merged with 2/5.

Ok, I see. Noted for RFCv2.

There will also be a big batch of changes for the compatible record
(omap3530->omap35xx, add omap34xx where needed) of ca. 10 board definition
DTS files. Should this then also become part of the new 2/5?

BR and thanks,
Nikolaus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ