Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753890AbcD1Ur6 (ORCPT ); Thu, 28 Apr 2016 16:47:58 -0400 Received: from mail.kernel.org ([198.145.29.136]:56620 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753743AbcD1Urz (ORCPT ); Thu, 28 Apr 2016 16:47:55 -0400 Date: Thu, 28 Apr 2016 15:47:49 -0500 From: Rob Herring To: Andy Gross Cc: Stephen Boyd , linux-arm-msm , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, jilai wang Subject: Re: [Patch v2 1/8] dt/bindings: firmware: Add Qualcomm SCM binding Message-ID: <20160428204749.GA12941@rob-hp-laptop> References: <1461625725-32425-1-git-send-email-andy.gross@linaro.org> <1461625725-32425-2-git-send-email-andy.gross@linaro.org> <20160426014906.GH29990@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2621 Lines: 66 On Mon, Apr 25, 2016 at 09:14:59PM -0500, Andy Gross wrote: > On 25 April 2016 at 20:49, Stephen Boyd wrote: > > On 04/25, Andy Gross wrote: > >> This patch adds the device tree support for the Qualcomm SCM firmware. > >> > >> Signed-off-by: Andy Gross > >> --- > >> .../devicetree/bindings/firmware/qcom,scm.txt | 28 ++++++++++++++++++++++ > >> 1 file changed, 28 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt > >> > >> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt > >> new file mode 100644 > >> index 0000000..a679a87 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt > >> @@ -0,0 +1,28 @@ > >> +QCOM Secure Channel Manager (SCM) > >> + > >> +Qualcomm processors include an interface to communicate to the secure firmware. > >> +This interface allows for clients to request different types of actions. These > >> +can include CPU power up/down, HDCP requests, loading of firmware, and other > >> +assorted actions. > >> + > >> +Required properties: > >> +- compatible: must contain one of the following: > >> + * "qcom,scm-apq8064" for APQ8064 > >> + * "qcom,scm-apq8084" for APQ8084 > >> + * "qcom,scm-msm8916" for MSM8916 > >> + * "qcom,scm-msm8974" for MSM8974 > > > > Do we need to keep adding these into the driver for every SoC > > that we support? My understanding is apq8064 can be the one that > > requires one clk, and msm8974 can be the one that requires three. > > The driver can just have those two compatibles for now, and we > > can keep adding compatibles here for the different SoCs, but > > really we don't care, that's just to save ourselves if something > > pops up and needs a workaround. > > > > It will certainly look weird if it's firmware that's compatible > > with qcom,scm-msm8974 but on an apq8084, so perhaps something Not if the first string has apq8084. > > more generic like, qcom-scm-v1 and qcom,scm-v2 can be used as the > > generic compatible in the driver: > > > > compatible = "qcom,scm-apq8064", "qcom,scm-v1"; > > > > vs. > > > > compatible = "qcom,scm-apq8084", "qcom,scm-v2"; > > > > ? > > > > I just want to avoid the constant SoC churn update here if we can. > > Right. We can certainly do it that way. Its just that the v1/v2 > aren't the real versions. What if we did qcom,scm vs > qcom,scm-apq8064? I'd prefer this over fake version numbers. Is there any sane versioning of the firmware itself that could be used? Rob