From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751815AbdFHJ2W (ORCPT ); Thu, 8 Jun 2017 05:28:22 -0400 Received: from foss.arm.com ([217.140.101.70]:44714 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822AbdFHJ2V (ORCPT ); Thu, 8 Jun 2017 05:28:21 -0400 Cc: Sudeep Holla , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Roy Franz , Harb Abdulhamid , Nishanth Menon , Arnd Bergmann Subject: Re: [RFC PATCH 2/8] firmware: arm_scmi: add basic driver infrastructure for SCMI To: Roy Franz References: <1496851812-19623-1-git-send-email-sudeep.holla@arm.com> <1496851812-19623-3-git-send-email-sudeep.holla@arm.com> From: Sudeep Holla Organization: ARM Message-ID: <5310ae30-72b8-1dee-2b20-4759fad8b636@arm.com> Date: Thu, 8 Jun 2017 10:28:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roy, On 07/06/17 20:18, Roy Franz wrote: > On Wed, Jun 7, 2017 at 9:10 AM, Sudeep Holla wrote: >> The SCMI is intended to allow OSPM to manage various functions that are >> provided by the hardware platform it is running on, including power and >> performance functions. SCMI provides two levels of abstraction, protocols >> and transports. Protocols define individual groups of system control and >> management messages. A protocol specification describes the messages >> that it supports. Transports describe the method by which protocol >> messages are communicated between agents and the platform. >> >> This patch adds basic infrastructure to manage the message allocation, >> initialisation, packing/unpacking and shared memory management. >> >> Signed-off-by: Sudeep Holla >> --- >> drivers/firmware/Kconfig | 21 ++ >> drivers/firmware/Makefile | 1 + >> drivers/firmware/arm_scmi/Makefile | 2 + >> drivers/firmware/arm_scmi/common.h | 74 ++++ >> drivers/firmware/arm_scmi/driver.c | 737 +++++++++++++++++++++++++++++++++++++ >> include/linux/scmi_protocol.h | 48 +++ >> 6 files changed, 883 insertions(+) >> create mode 100644 drivers/firmware/arm_scmi/Makefile >> create mode 100644 drivers/firmware/arm_scmi/common.h >> create mode 100644 drivers/firmware/arm_scmi/driver.c >> create mode 100644 include/linux/scmi_protocol.h >> [...] >> + >> +#define client_to_scmi_info(c) container_of(c, struct scmi_info, cl) >> +#define handle_to_scmi_info(h) container_of(h, struct scmi_info, handle) >> + >> +/* >> + * The SCP firmware only executes in little-endian mode, so any buffers >> + * shared through SCMI should have their contents converted to little-endian >> + */ > > nit: > This really has more to do with the SCMI protocol defining everything > as little endian, rather the endian-ness of the SCP, right? There could be SCP > implementations that are not Cortex M3s or little endian. > Thanks for taking time to review this RFC, much appreciated. All valid points(on this and other patches) and fixed locally now. Also thanks for saving time in debugging these issues. I should be able to do some testing next week. -- Regards, Sudeep