linux-kernel - Re: [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies

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]

Message-ID: <b5a03fc2848b21fcac0f88436a4f7c87@agner.ch>
Date:	Wed, 02 Dec 2015 12:51:04 -0800
From:	Stefan Agner <stefan@...er.ch>
To:	Shawn Guo <shawnguo@...nel.org>
Cc:	kernel@...gutronix.de, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, linux@....linux.org.uk,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies

On 2015-12-02 00:13, Shawn Guo wrote:
> On Mon, Nov 30, 2015 at 05:59:26PM -0800, Stefan Agner wrote:
>> Linux on Vybrid used several different L2 latencies so far, none
>> of them seem to be the right ones. According to the application note
>> AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
>> on CPU clock and is inside the L2 cache controller, whereas the data
>> portion is stored in the external SRAM running on platform clock.
>> Hence it is likely that the correct value requires a higher data
>> latency then tag latency.
>> 
>> These are the values which have been used so far:
>> - The mainline values:
>>   arm,data-latency = <1 1 1>;
>>   arm,tag-latency = <2 2 2>;
>>   Those values have lead to problems on higher clocks. They look
>>   like a poor translation from the reset values (missing +1 offset
>>   and a mix up between tag/latency values).
>> - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
>>   arm,data-latency = <4 2 3>
>>   arm,tag-latency = <4 2 3>
>>   The cache initialization function along with the value matches the
>>   i.MX6 code from the same kernel, so it seems that those values have
>>   just been copied.
>> - The Colibri values:
>>   arm,data-latency = <2 1 2>;
>>   arm,tag-latency = <3 2 3>;
>>   Those were a mix between the values of the Linux 3.0 based BSP and
>>   the mainline values above.
>> - The SoC Reset values (converted to DT notation):
>>   arm,data-latency = <3 3 3>;
>>   arm,tag-latency = <2 2 2>;
>> 
>> So far there is no official statement on what the correct values are.
>> See also the related Freescale community thread:
>> https://community.freescale.com/message/579785#579785
>> 
>> For now, the reset values seem to be the best bet. Remove all other
>> "bogus" values and use the reset value on vf610.dtsi level.
>> 
>> Signed-off-by: Stefan Agner <stefan@...er.ch>
>> ---
>> Hi Shawn,
>> 
>> Any chance to get this into 4.4?
> 
> I can try.  Generally, upstream maintainers are becoming more strict for
> -rc inclusion after -rc3 phase.  Do you have any user stories about why
> this is a critical/urgent fix?  If we send this a critical fix for 4.4-rc
> inclusion, do we need to Cc stable?

It came up a while ago on Freescale community, but I think that user
used downstream BSP's:
https://community.freescale.com/thread/332326

The Colibri VF61 board overwrites the latency, so it is not really
critical for this board.

The Freescale Tower runs at 400MHz by default, but has a CPU which would
support up to 500MHz. I am pretty sure with 500MHz CPU clock, things
will go south with current settings.

Regarding stable: Would probably be consistent...

--
Stefan


> 
> Shawn
> 
>> 
>> --
>> Stefan
>> 
>>  arch/arm/boot/dts/vf610-colibri.dtsi | 5 -----
>>  arch/arm/boot/dts/vf610.dtsi         | 2 +-
>>  2 files changed, 1 insertion(+), 6 deletions(-)
>> 
>> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi b/arch/arm/boot/dts/vf610-colibri.dtsi
>> index 19fe045..2d7eab7 100644
>> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
>> @@ -18,8 +18,3 @@
>>  		reg = <0x80000000 0x10000000>;
>>  	};
>>  };
>> -
>> -&L2 {
>> -	arm,data-latency = <2 1 2>;
>> -	arm,tag-latency = <3 2 3>;
>> -};
>> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
>> index 5f8eb1b..58bc6e4 100644
>> --- a/arch/arm/boot/dts/vf610.dtsi
>> +++ b/arch/arm/boot/dts/vf610.dtsi
>> @@ -19,7 +19,7 @@
>>  		reg = <0x40006000 0x1000>;
>>  		cache-unified;
>>  		cache-level = <2>;
>> -		arm,data-latency = <1 1 1>;
>> +		arm,data-latency = <3 3 3>;
>>  		arm,tag-latency = <2 2 2>;
>>  	};
>>  };
>> --
>> 2.6.2
>> 
>> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/