Message ID | 20230403200530.2103099-3-abel.vesa@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2561625vqo; Mon, 3 Apr 2023 13:19:37 -0700 (PDT) X-Google-Smtp-Source: AKy350YwY6toNbzZTFA0phGr+ZHgmvy+3rTzRQlkrYzKfsb0urVC6maQOiQ0HXBBlEnnY/Uds60e X-Received: by 2002:a05:6a20:3b89:b0:d9:2827:b65a with SMTP id b9-20020a056a203b8900b000d92827b65amr107821pzh.5.1680553177493; Mon, 03 Apr 2023 13:19:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680553177; cv=none; d=google.com; s=arc-20160816; b=g+Ugjti6v6u7K0T4oAZI+TZeplgvyjgg16IeqoW9VP4gjZp7hmOGBbz3x/QhYwOtOC EMZD+WLF3urQytrx356vqBcM9G0N9Wmo1+mix2gjnQXUtPyez3g/sF2uDrRinKq7Z/dU eXks+AihtyyTZ45ifFJARmAEMy9JPWU90StVaK4D8vSwu2VJSFEewVJPQBKb1JsrtLus tkm1RUoGbkQ55/piPOurV5TVRtUEYuysI2QSjg5Qa8bugLzyAH74teMezWRWq8NKrSK1 yDEAQf4QODT1O1PqzMeEnhFtJMbtTzYNYFp8Ar8K1bUeePcTH3ODOTs5ngYEo+wUkpuX GN+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LtkVbXjOkWE1mDRtDA64NnPbwftHZmH0QT3gMjYI38Y=; b=a3s6CKoJhkPVOJlwc1fqLgsx4VnAo2J+iDx+64FuyHqHDFarD+3zZPc84eOEHNmC0X eIEoHy277dw4iIlqcYvCzOmMxwZEDwK3EinEim6TFE3HzFeSawnh3Per4NfyhDVcz8s5 2Ucn8QJJ9OutWEuPPlB2AJ5dOBkKz2pBtSqda0PCvkKimM9dCf+ZrlLz/llL4gqTvzRE P03ZqwR3T2onT7iKSYrmMPH7PozWQJqmx8/aJYQxViG7El805Pc+FDu6v/g093B2+Vsg /+3jgthZGHmI17Sk7mWv6qnGDchvtZtaP9JpSH1N+ThYSgLm4RtW6bmZjR85/kwI1Rvc IKyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=anUhkD13; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j6-20020a625506000000b0059d1764718dsi8854327pfb.133.2023.04.03.13.19.25; Mon, 03 Apr 2023 13:19:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=anUhkD13; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233000AbjDCUFu (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Mon, 3 Apr 2023 16:05:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232831AbjDCUFn (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 3 Apr 2023 16:05:43 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 941223AA9 for <linux-kernel@vger.kernel.org>; Mon, 3 Apr 2023 13:05:41 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id l15-20020a05600c4f0f00b003ef6d684102so15255317wmq.3 for <linux-kernel@vger.kernel.org>; Mon, 03 Apr 2023 13:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680552340; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=LtkVbXjOkWE1mDRtDA64NnPbwftHZmH0QT3gMjYI38Y=; b=anUhkD130aHAwvsiiZmvlUZHWOZZqMhnR0U+GdzME761AblPsoBRbfBX9SUdODa9dW AAL/ZnWQadaW2iESlmdRhpFwYsXxLxd0hB0srtAtHNfzRygDunJrMlyfVsYUd+8b7IE1 w0ItXIzjJsH5rm/6X1LQSH5EYPvHwFetKWtqdoQjD2fzZfU/QBjs7WsW5w3tHnHnij4o 11h+C7VTBMHu3qAHrTgY2HE7f+v6BQf3bWAGNVlX31ceSZv0t9xcNxNIFFmRkeFQRfIL VryBsthFzMWOAb0ymNzg01I+d37TH4F6SiDaJGnSS7jgmwCsQIjv95Gli3sjBPD5v/6H hmDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680552340; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LtkVbXjOkWE1mDRtDA64NnPbwftHZmH0QT3gMjYI38Y=; b=UkFg7CbqmC9fzamtN3s7cgsVEvmuROZRpJMzt5f1XtifuyiQjRzoBA6rsAE4k4eWYU twLECTQBrJgGB8cWUeIHV6lbVPTxdlnHoapQIFq/GEfIK3Nms/zCqGaQzBEeBLVKpHCt gzgweVdEzRxLGl4jz/leCJfYK4aAfSjHV+N9V02XC3dkdiwF7JuR1oCALpJaS7DrMPCO i6sZFXZx6H3yP+3DLRINR5C5p1cbnMH5XzqvoWB9t3fSSzgnVMQA+iswL/Lb6EV9e/6p vr6FuppprKcGxVmtbDlXGkoEbxK8c28gtaUh41ZhWqLQSlx8BUNb6Mx0dsaYUlRHEdfp Y/dQ== X-Gm-Message-State: AAQBX9cTU9o4O4dA1XbrdZTf5mVD2qHYG0oIBjNHgiQMPHmmI7ltq9cD TC7jGVxFjg63Yi1Fof6FEMazrw== X-Received: by 2002:a1c:f70d:0:b0:3ee:814b:9c39 with SMTP id v13-20020a1cf70d000000b003ee814b9c39mr468393wmh.18.1680552339953; Mon, 03 Apr 2023 13:05:39 -0700 (PDT) Received: from localhost.localdomain ([94.52.112.99]) by smtp.gmail.com with ESMTPSA id iv19-20020a05600c549300b003ef69873cf1sm20798037wmb.40.2023.04.03.13.05.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Apr 2023 13:05:39 -0700 (PDT) From: Abel Vesa <abel.vesa@linaro.org> To: Ulf Hansson <ulf.hansson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Manivannan Sadhasivam <mani@kernel.org>, Alim Akhtar <alim.akhtar@samsung.com>, Avri Altman <avri.altman@wdc.com>, Bart Van Assche <bvanassche@acm.org>, Adrian Hunter <adrian.hunter@intel.com>, "James E . J . Bottomley" <jejb@linux.ibm.com>, "Martin K . Petersen" <martin.petersen@oracle.com>, Herbert Xu <herbert@gondor.apana.org.au>, "David S . Miller" <davem@davemloft.net>, Eric Biggers <ebiggers@kernel.org> Cc: linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arm-msm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-scsi@vger.kernel.org Subject: [PATCH v5 2/6] dt-bindings: ufs: qcom: Add ICE phandle Date: Mon, 3 Apr 2023 23:05:26 +0300 Message-Id: <20230403200530.2103099-3-abel.vesa@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230403200530.2103099-1-abel.vesa@linaro.org> References: <20230403200530.2103099-1-abel.vesa@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762187728466764990?= X-GMAIL-MSGID: =?utf-8?q?1762187728466764990?= |
Series |
Add dedicated Qcom ICE driver
|
|
Commit Message
Abel Vesa
April 3, 2023, 8:05 p.m. UTC
Starting with SM8550, the ICE will have its own devicetree node
so add the qcom,ice property to reference it.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
The v4 is here:
https://lore.kernel.org/all/20230327134734.3256974-4-abel.vesa@linaro.org/
Changes since v4:
* Added check for sm8550 compatible w.r.t. qcom,ice in order to enforce
it while making sure none of the other platforms are allowed to use it
Changes since v3:
* dropped the "and drop core clock" part from subject line
Changes since v2:
* dropped all changes except the qcom,ice property
.../devicetree/bindings/ufs/qcom,ufs.yaml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Comments
On 03/04/2023 22:05, Abel Vesa wrote: > Starting with SM8550, the ICE will have its own devicetree node > so add the qcom,ice property to reference it. > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > --- > > The v4 is here: > https://lore.kernel.org/all/20230327134734.3256974-4-abel.vesa@linaro.org/ > > Changes since v4: > * Added check for sm8550 compatible w.r.t. qcom,ice in order to enforce > it while making sure none of the other platforms are allowed to use it Why? Also, this does not solve my previous question still. Best regards, Krzysztof
On 23-04-04 07:41:55, Krzysztof Kozlowski wrote: > On 03/04/2023 22:05, Abel Vesa wrote: > > Starting with SM8550, the ICE will have its own devicetree node > > so add the qcom,ice property to reference it. > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > --- > > > > The v4 is here: > > https://lore.kernel.org/all/20230327134734.3256974-4-abel.vesa@linaro.org/ > > > > Changes since v4: > > * Added check for sm8550 compatible w.r.t. qcom,ice in order to enforce > > it while making sure none of the other platforms are allowed to use it > > Why? SM8550 will be the first platform to use the new DT bindings w.r.t ICE. > > Also, this does not solve my previous question still. Well, the clocks are not added for the a few platforms (which include SM8550). Same for 'ice' reg range.. So the only thing left is to enforce the qcom,ice property availability only for SM8550. I believe it solves the mutual exclusiveness of the "ice" reg range along with the clocks versus the qcom,ice property, by enforcing at compatible level. Is this not enough? > > Best regards, > Krzysztof >
On 04/04/2023 10:59, Abel Vesa wrote: > On 23-04-04 07:41:55, Krzysztof Kozlowski wrote: >> On 03/04/2023 22:05, Abel Vesa wrote: >>> Starting with SM8550, the ICE will have its own devicetree node >>> so add the qcom,ice property to reference it. >>> >>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> >>> --- >>> >>> The v4 is here: >>> https://lore.kernel.org/all/20230327134734.3256974-4-abel.vesa@linaro.org/ >>> >>> Changes since v4: >>> * Added check for sm8550 compatible w.r.t. qcom,ice in order to enforce >>> it while making sure none of the other platforms are allowed to use it >> >> Why? > > SM8550 will be the first platform to use the new DT bindings w.r.t ICE. This I understand, but why other platforms cannot use it? > >> >> Also, this does not solve my previous question still. > > Well, the clocks are not added for the a few platforms (which include > SM8550). Same for 'ice' reg range.. So the only thing left is to > enforce the qcom,ice property availability only for SM8550. I believe > it solves the mutual exclusiveness of the "ice" reg range along with the > clocks versus the qcom,ice property, by enforcing at compatible level. Ah, I think I understand. That would work except I don't understand why enforcing qcom,qce only for specific, new SoCs. Assuming it is a correct hardware representation, we want it for everyone, don't we? Best regards, Krzysztof
On 23-04-04 12:12:06, Krzysztof Kozlowski wrote: > On 04/04/2023 10:59, Abel Vesa wrote: > > On 23-04-04 07:41:55, Krzysztof Kozlowski wrote: > >> On 03/04/2023 22:05, Abel Vesa wrote: > >>> Starting with SM8550, the ICE will have its own devicetree node > >>> so add the qcom,ice property to reference it. > >>> > >>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > >>> --- > >>> > >>> The v4 is here: > >>> https://lore.kernel.org/all/20230327134734.3256974-4-abel.vesa@linaro.org/ > >>> > >>> Changes since v4: > >>> * Added check for sm8550 compatible w.r.t. qcom,ice in order to enforce > >>> it while making sure none of the other platforms are allowed to use it > >> > >> Why? > > > > SM8550 will be the first platform to use the new DT bindings w.r.t ICE. > > This I understand, but why other platforms cannot use it? The platforms that do not have ICE support yet will be added in the same subschema along with SM8550 when the ICE DT node will be added in their dtsi. > > > > >> > >> Also, this does not solve my previous question still. > > > > Well, the clocks are not added for the a few platforms (which include > > SM8550). Same for 'ice' reg range.. So the only thing left is to > > enforce the qcom,ice property availability only for SM8550. I believe > > it solves the mutual exclusiveness of the "ice" reg range along with the > > clocks versus the qcom,ice property, by enforcing at compatible level. > > Ah, I think I understand. That would work except I don't understand why > enforcing qcom,qce only for specific, new SoCs. Assuming it is a correct > hardware representation, we want it for everyone, don't we? Yes, but they will be added to the subschema (qcom,ice one) when their their ICE support (ICE DT) will be added. This way, we keep the bindings check without failures (for now). > > Best regards, > Krzysztof >
On 04/04/2023 12:41, Abel Vesa wrote: >>>> >>>> Also, this does not solve my previous question still. >>> >>> Well, the clocks are not added for the a few platforms (which include >>> SM8550). Same for 'ice' reg range.. So the only thing left is to >>> enforce the qcom,ice property availability only for SM8550. I believe >>> it solves the mutual exclusiveness of the "ice" reg range along with the >>> clocks versus the qcom,ice property, by enforcing at compatible level. >> >> Ah, I think I understand. That would work except I don't understand why >> enforcing qcom,qce only for specific, new SoCs. Assuming it is a correct >> hardware representation, we want it for everyone, don't we? > > Yes, but they will be added to the subschema (qcom,ice one) when their > their ICE support (ICE DT) will be added. This way, we keep the bindings > check without failures (for now). I understand that then you will rework this if:then case, so I think it is just easier to make it correct from the first place. If there is qcom,qce, then reg is maxItems:1. Otherwise - maxItems can be 2. You achieve the same result, all DTS validate, without any need of further changes later. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml index c5a06c048389..874de31d2c41 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -70,6 +70,10 @@ properties: power-domains: maxItems: 1 + qcom,ice: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the Inline Crypto Engine node + reg: minItems: 1 maxItems: 2 @@ -187,6 +191,21 @@ allOf: # TODO: define clock bindings for qcom,msm8994-ufshc + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8550-ufshc + then: + properties: + qcom,ice: + maxItems: 1 + else: + properties: + qcom,ice: false + + unevaluatedProperties: false examples: