[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b7303424-d63f-5ea7-866a-bda6d1f93ff2@arm.com>
Date: Tue, 5 Sep 2017 17:54:43 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Julien Thierry <julien.thierry@....com>,
ALKML <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
DTML <devicetree@...r.kernel.org>
Cc: Sudeep Holla <sudeep.holla@....com>, Nishanth Menon <nm@...com>,
Harb Abdulhamid <harba@...eaurora.org>,
Arnd Bergmann <arnd@...db.de>,
Jassi Brar <jassisinghbrar@...il.com>,
Ryan Harkin <Ryan.Harkin@....com>,
Roy Franz <roy.franz@...ium.com>, Loc Ho <lho@....com>,
Alexey Klimov <alexey.klimov@....com>
Subject: Re: [PATCH v2 05/18] firmware: arm_scmi: add initial support for
performance protocol
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
Powered by blists - more mailing lists