From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Martin Subject: Re: [PATCH] ARM: trusted_foundations: Maintain CPU endianness Date: Fri, 20 Mar 2015 16:20:59 +0000 Message-ID: <20150320162059.GD4725@e103592.cambridge.arm.com> References: <1426865807-22981-1-git-send-email-digetx@gmail.com> <550C4106.4090801@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <550C4106.4090801-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Content-Disposition: inline Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dmitry Osipenko Cc: Stephen Warren , Thierry Reding , Alexandre Courbot , linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-tegra@vger.kernel.org On Fri, Mar 20, 2015 at 06:47:18PM +0300, Dmitry Osipenko wrote: > This patch not tested. I assume that firmware save/restore cp15 > context, i.e. it doesn't require switching to LE before smc call and > restore endianness after. That assumption should be valid. However, I think this patch must be tested before assuming it is correct. If the arguments were passed in memory then there might force LE order for that data block, but there should not be a need for this if the values are in registers. Cheers ---Dave From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave.Martin@arm.com (Dave Martin) Date: Fri, 20 Mar 2015 16:20:59 +0000 Subject: [PATCH] ARM: trusted_foundations: Maintain CPU endianness In-Reply-To: <550C4106.4090801@gmail.com> References: <1426865807-22981-1-git-send-email-digetx@gmail.com> <550C4106.4090801@gmail.com> Message-ID: <20150320162059.GD4725@e103592.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Mar 20, 2015 at 06:47:18PM +0300, Dmitry Osipenko wrote: > This patch not tested. I assume that firmware save/restore cp15 > context, i.e. it doesn't require switching to LE before smc call and > restore endianness after. That assumption should be valid. However, I think this patch must be tested before assuming it is correct. If the arguments were passed in memory then there might force LE order for that data block, but there should not be a need for this if the values are in registers. Cheers ---Dave From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751777AbbCTQVF (ORCPT ); Fri, 20 Mar 2015 12:21:05 -0400 Received: from service87.mimecast.com ([91.220.42.44]:48540 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbbCTQVD convert rfc822-to-8bit (ORCPT ); Fri, 20 Mar 2015 12:21:03 -0400 Date: Fri, 20 Mar 2015 16:20:59 +0000 From: Dave Martin To: Dmitry Osipenko Cc: Stephen Warren , Thierry Reding , Alexandre Courbot , linux-tegra@vger.kernel.org, Russell King , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: trusted_foundations: Maintain CPU endianness Message-ID: <20150320162059.GD4725@e103592.cambridge.arm.com> References: <1426865807-22981-1-git-send-email-digetx@gmail.com> <550C4106.4090801@gmail.com> MIME-Version: 1.0 In-Reply-To: <550C4106.4090801@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-OriginalArrivalTime: 20 Mar 2015 16:20:59.0662 (UTC) FILETIME=[DA09AAE0:01D06329] X-MC-Unique: 115032016210101501 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 20, 2015 at 06:47:18PM +0300, Dmitry Osipenko wrote: > This patch not tested. I assume that firmware save/restore cp15 > context, i.e. it doesn't require switching to LE before smc call and > restore endianness after. That assumption should be valid. However, I think this patch must be tested before assuming it is correct. If the arguments were passed in memory then there might force LE order for that data block, but there should not be a need for this if the values are in registers. Cheers ---Dave