From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752295AbdIEQyL (ORCPT <rfc822;w@1wt.eu>);
        Tue, 5 Sep 2017 12:54:11 -0400
Received: from foss.arm.com ([217.140.101.70]:42854 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751480AbdIEQyJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 5 Sep 2017 12:54:09 -0400
Cc: Sudeep Holla <sudeep.holla@arm.com>, Nishanth Menon <nm@ti.com>,
        Harb Abdulhamid <harba@codeaurora.org>, Arnd Bergmann <arnd@arndb.de>,
        Jassi Brar <jassisinghbrar@gmail.com>,
        Ryan Harkin <Ryan.Harkin@arm.com>, Roy Franz <roy.franz@cavium.com>,
        Loc Ho <lho@apm.com>, Alexey Klimov <alexey.klimov@arm.com>
Subject: Re: [PATCH v2 05/18] firmware: arm_scmi: add initial support for
 performance protocol
To: Julien Thierry <julien.thierry@arm.com>,
        ALKML <linux-arm-kernel@lists.infradead.org>,
        LKML <linux-kernel@vger.kernel.org>, DTML <devicetree@vger.kernel.org>
References: <1501857104-11279-1-git-send-email-sudeep.holla@arm.com>
 <1501857104-11279-6-git-send-email-sudeep.holla@arm.com>
 <2690239b-27a7-dce3-88a6-d53808e8e93c@arm.com>
 <534bae20-9f80-e79b-42a5-93d838732720@arm.com>
From: Sudeep Holla <sudeep.holla@arm.com>
Organization: ARM
Message-ID: <b7303424-d63f-5ea7-866a-bda6d1f93ff2@arm.com>
Date: Tue, 5 Sep 2017 17:54:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <534bae20-9f80-e79b-42a5-93d838732720@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Julien,

On 05/09/17 16:56, Julien Thierry wrote:
> 
> 
> On 05/09/17 16:04, Julien Thierry wrote:

[...]


>>
>> This seems odd, shouldn't it be the following?
>> le64_to_cpu(attr->stats_addr_low | (__le64)attr->stats_addr_high << 32)
>>
> 
> After further reflexion, I think you are right. If I understood the
> specification, the address seems to be split into upper and lower 32bits
> and each one is stored as a uint32, which fits what you are doing to
> obtain the address.
> 
> You can ignore my previous comment.
> 

Sorry I am checking this bit late, you have figured out yourself
already. All the 64 bit values need to be dealt similarly as SCMI
specification restricts so. It's basically done so as the firmware
running is mostly 32-bit little endian system.

-- 
Regards,
Sudeep