Message ID | 20240105-sm6350-qce-v1-2-416e5c7319ac@fairphone.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-18053-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp6320474dyb; Fri, 5 Jan 2024 08:16:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IHUS+M0q6E+dO4mTjYpWIHw2fBFFf5Hkt4CScVKw8uPsFk4iMpD2Nhw4Ijfej+oESQrkxTk X-Received: by 2002:aa7:8512:0:b0:6d9:beca:3a40 with SMTP id v18-20020aa78512000000b006d9beca3a40mr1937910pfn.56.1704471408238; Fri, 05 Jan 2024 08:16:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704471408; cv=none; d=google.com; s=arc-20160816; b=Xv7FtsIBKEBGka8VlW+yjZrvWxSR5vIf+vzKvrpekPtdF3NJl2gU73UY+dAyfZr5v9 yk5Sto21YduTtZ8MgPIglVv/kLvYa5GScp4guIVpqCBazwKBdTAkUs8NL7k9mLz//nJZ KUwyBJHhYuZn4A+mMKDkmn7HEbMBPRYYrUd0xqwWw8VTQ9kxkxTTHLfVruB5dO2fZxAE IggJDqMeG0NPG0/q1poZD49HnPZWiKTfCRO/oJzYDmTzEUH3m62Stw1JkdrvwdEHQBOJ L12eciwq+/GWDjwthZekua+9YN2r5Rkso5ZtE3MKiz3YacqbwZ3e6FBV/jdILp5y46c4 pYiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=2EkrLPpfX68IA8d/5CPpZuMAmVCLu73Yzxl8t1E6w2M=; fh=Axo/juG94L2E/g4LgObE98QoVKnVnygKXzAdhjykaAA=; b=RDU9pA+6Nr/vH5ActnfkHTcAEXNDe7bD1Zo5xRU/J3AHy1jo7Z9+n5AUcF4RU2FRcU C8YVHFYhLoRikH0isIVcX2dTLwinLqxT1pcSQ2H/ii5RWL4nPuuarteESMJN1wAGC1sF GbMQE1COL/OBg4UO+YYMdue9MY74JVBxqoqs5roORw/v6OpfW1gZyO0LysSTRlGcbKxE pWHbCzhlu5nG/RT6PgnlmGTC/cB74tW7WhUQ9qCvhj7S7xFPgk14Uh5RxdYJpym9GCN5 H5SqxGo5YXis/nJ3UmXKn/mp3pHX8BKUnbC9ckYNKgTU0XRF1GYbOG47gVLdgl8FRipE Lfdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fairphone.com header.s=fair header.b=U0SY9mNR; spf=pass (google.com: domain of linux-kernel+bounces-18053-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18053-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=fairphone.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id q24-20020a638c58000000b005cde435ff91si1484740pgn.878.2024.01.05.08.16.48 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 08:16:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-18053-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@fairphone.com header.s=fair header.b=U0SY9mNR; spf=pass (google.com: domain of linux-kernel+bounces-18053-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18053-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=fairphone.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 0A50128376C for <ouuuleilei@gmail.com>; Fri, 5 Jan 2024 16:16:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2F1FD34540; Fri, 5 Jan 2024 16:15:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fairphone.com header.i=@fairphone.com header.b="U0SY9mNR" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1622A2E85F for <linux-kernel@vger.kernel.org>; Fri, 5 Jan 2024 16:15:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fairphone.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fairphone.com Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-55719cdc0e1so1425945a12.1 for <linux-kernel@vger.kernel.org>; Fri, 05 Jan 2024 08:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; t=1704471348; x=1705076148; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=2EkrLPpfX68IA8d/5CPpZuMAmVCLu73Yzxl8t1E6w2M=; b=U0SY9mNRzOHLg2oAJuki4XzHlnHxFPPVkogg4Bsg9gAjcixsZ7XWE9nydc3ZOuiHsT Wl9VlAwNnK/OWl7qMZjd+yvuhS2ocl+0uMDZNcEUzlpXGhJqIXLqeyKlO2HHJFxH3Jvz 77AacKA9ADY95/ZLd/pWxo6ykcbUfYNIcs4aoRfNLXlQ6RLfYH0K6QSMP7GHRGac2F3R zfL5LlJoZvzwwzSTDfsW9ZH5UPidQ1miL0/CKzbsLHItD4HBf6+ztuMFZBGpd2HaNXbG ZFGykocPpCUUM4yo+esWqko0/GuA+BGj3SJpgSEbFWRtAXryW6aVv2bC3g/bQRDhfCcp rnOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704471348; x=1705076148; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2EkrLPpfX68IA8d/5CPpZuMAmVCLu73Yzxl8t1E6w2M=; b=LBIzj6SNzK69zaZgdmKdlA57IgVxBHvevjCT+2+wK+PtcGr9NvCT4G4bIZ8qJxvahh 9xXwUyvbv7+oioJ8Tlo0DJEAdPb+MOkAyEHt6hlirMpPgDHkayTJYfeZsycaUT+f9hHN 0COCMK4ZXZvfsAfhkpm7y2XM1sZwk7eD9DQf0TkiIdtM/OHi1nsMICnsRiv1gB8u2cJ9 iT52QU4PsXWELl19e9ytpC1mzLu8gqzme27VuKOnNDMNsSC2/eYrYb9ovKjXuvaeLaLz DdCUf6RfasNGQpr7oG6v+MZYVY4xw0/Oz5JnFwSW1MGjOsaV9NSXuaaNSLlp+XyU+9l2 agQQ== X-Gm-Message-State: AOJu0YyD/4FKr06qsrUAY1yTM/kR4p3ldggwpQRxddxHzs8mEVefr5Wu 5cHbSUHo5dz1yVmOCjdf/WOy/OWlTohRhw== X-Received: by 2002:a17:906:261a:b0:a26:d20e:35a7 with SMTP id h26-20020a170906261a00b00a26d20e35a7mr1259647ejc.127.1704471348452; Fri, 05 Jan 2024 08:15:48 -0800 (PST) Received: from otso.luca.vpn.lucaweiss.eu (144-178-202-138.static.ef-service.nl. [144.178.202.138]) by smtp.gmail.com with ESMTPSA id ft33-20020a170907802100b00a26a5632d8fsm1031726ejc.13.2024.01.05.08.15.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 08:15:47 -0800 (PST) From: Luca Weiss <luca.weiss@fairphone.com> Date: Fri, 05 Jan 2024 17:15:44 +0100 Subject: [PATCH 2/2] arm64: dts: qcom: sm6350: Add Crypto Engine Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240105-sm6350-qce-v1-2-416e5c7319ac@fairphone.com> References: <20240105-sm6350-qce-v1-0-416e5c7319ac@fairphone.com> In-Reply-To: <20240105-sm6350-qce-v1-0-416e5c7319ac@fairphone.com> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Thara Gopinath <thara.gopinath@gmail.com>, Herbert Xu <herbert@gondor.apana.org.au>, "David S. Miller" <davem@davemloft.net>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Bhupesh Sharma <bhupesh.sharma@linaro.org> Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Luca Weiss <luca.weiss@fairphone.com> X-Mailer: b4 0.12.4 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787267811273250556 X-GMAIL-MSGID: 1787267811273250556 |
Series |
Add Crypto Engine support for SM6350
|
|
Commit Message
Luca Weiss
Jan. 5, 2024, 4:15 p.m. UTC
Add crypto engine (CE) and CE BAM related nodes and definitions for this
SoC.
For reference:
[ 2.297419] qcrypto 1dfa000.crypto: Crypto device found, version 5.5.1
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
Comments
On Fri, Jan 05, 2024 at 05:15:44PM +0100, Luca Weiss wrote: > Add crypto engine (CE) and CE BAM related nodes and definitions for this > SoC. > > For reference: > > [ 2.297419] qcrypto 1dfa000.crypto: Crypto device found, version 5.5.1 > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > arch/arm64/boot/dts/qcom/sm6350.dtsi | 31 +++++++++++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi > index 8fd6f4d03490..516aadbb16bb 100644 > --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi > +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi > @@ -1212,6 +1212,37 @@ ufs_mem_phy_lanes: phy@1d87400 { > }; > }; > > + cryptobam: dma-controller@1dc4000 { > + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0"; > + reg = <0 0x01dc4000 0 0x24000>; > + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>; > + #dma-cells = <1>; > + qcom,ee = <0>; > + qcom,controlled-remotely; > + num-channels = <16>; > + qcom,num-ees = <4>; > + iommus = <&apps_smmu 0x432 0x0000>, > + <&apps_smmu 0x438 0x0001>, > + <&apps_smmu 0x43f 0x0000>, > + <&apps_smmu 0x426 0x0011>, > + <&apps_smmu 0x436 0x0011>; The last two lines look equivalent to me: 0x436 & ~0x0011 = 0x426. It's also a bit weird that the mask has one more digit than the stream ID. And ordered numerically (by stream ID, first number) it would be a bit easier to read. :-) Thanks, Stephan
On Fri Jan 5, 2024 at 5:30 PM CET, Stephan Gerhold wrote: > On Fri, Jan 05, 2024 at 05:15:44PM +0100, Luca Weiss wrote: > > Add crypto engine (CE) and CE BAM related nodes and definitions for this > > SoC. > > > > For reference: > > > > [ 2.297419] qcrypto 1dfa000.crypto: Crypto device found, version 55.1 > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > --- > > arch/arm64/boot/dts/qcom/sm6350.dtsi | 31 +++++++++++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > index 8fd6f4d03490..516aadbb16bb 100644 > > --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > @@ -1212,6 +1212,37 @@ ufs_mem_phy_lanes: phy@1d87400 { > > }; > > }; > > > > + cryptobam: dma-controller@1dc4000 { > > + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0"; > > + reg = <0 0x01dc4000 0 0x24000>; > > + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>; > > + #dma-cells = <1>; > > + qcom,ee = <0>; > > + qcom,controlled-remotely; > > + num-channels = <16>; > > + qcom,num-ees = <4>; > > + iommus = <&apps_smmu 0x432 0x0000>, > > + <&apps_smmu 0x438 0x0001>, > > + <&apps_smmu 0x43f 0x0000>, > > + <&apps_smmu 0x426 0x0011>, > > + <&apps_smmu 0x436 0x0011>; > > The last two lines look equivalent to me: 0x436 & ~0x0011 = 0x426. I don't understand the IOMMU SID + mask really, but I think I've seen somewhere before like here that TZ can be a bit picky with the SIDs? https://lore.kernel.org/linux-arm-msm/opqdrmyj3y64nqqqmakjydn5rkspizufyeavm7ec7c7ufqz4wk@ey2a7bq3shfj/ https://lore.kernel.org/linux-arm-msm/11b5db69-49f5-4d7b-81c9-687d66a5cb0d@linaro.org/ I don't quite want to risk having some obscure use case breaking because we cleaned up the dts ;) But if you're more sure than me that it won't break, let me know! > > It's also a bit weird that the mask has one more digit than the stream > ID. And ordered numerically (by stream ID, first number) it would be a > bit easier to read. :-) Sorting them is no problem, can do that for v2. > > Thanks, > Stephan
On Fri, Feb 16, 2024 at 11:46:49AM +0100, Luca Weiss wrote: > On Fri Jan 5, 2024 at 5:30 PM CET, Stephan Gerhold wrote: > > On Fri, Jan 05, 2024 at 05:15:44PM +0100, Luca Weiss wrote: > > > Add crypto engine (CE) and CE BAM related nodes and definitions for this > > > SoC. > > > > > > For reference: > > > > > > [ 2.297419] qcrypto 1dfa000.crypto: Crypto device found, version 5.5.1 > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > --- > > > arch/arm64/boot/dts/qcom/sm6350.dtsi | 31 +++++++++++++++++++++++++++++++ > > > 1 file changed, 31 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > index 8fd6f4d03490..516aadbb16bb 100644 > > > --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > @@ -1212,6 +1212,37 @@ ufs_mem_phy_lanes: phy@1d87400 { > > > }; > > > }; > > > > > > + cryptobam: dma-controller@1dc4000 { > > > + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0"; > > > + reg = <0 0x01dc4000 0 0x24000>; > > > + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>; > > > + #dma-cells = <1>; > > > + qcom,ee = <0>; > > > + qcom,controlled-remotely; > > > + num-channels = <16>; > > > + qcom,num-ees = <4>; > > > + iommus = <&apps_smmu 0x432 0x0000>, > > > + <&apps_smmu 0x438 0x0001>, > > > + <&apps_smmu 0x43f 0x0000>, > > > + <&apps_smmu 0x426 0x0011>, > > > + <&apps_smmu 0x436 0x0011>; > > > > The last two lines look equivalent to me: 0x436 & ~0x0011 = 0x426. > > I don't understand the IOMMU SID + mask really, but I think I've seen > somewhere before like here that TZ can be a bit picky with the SIDs? > > https://lore.kernel.org/linux-arm-msm/opqdrmyj3y64nqqqmakjydn5rkspizufyeavm7ec7c7ufqz4wk@ey2a7bq3shfj/ > https://lore.kernel.org/linux-arm-msm/11b5db69-49f5-4d7b-81c9-687d66a5cb0d@linaro.org/ > > I don't quite want to risk having some obscure use case breaking because > we cleaned up the dts ;) > > But if you're more sure than me that it won't break, let me know! > I'm afraid I can't really help with this kind of certainty. My knowledge about proprietary Qualcomm firmware is probably even more limited than yours. However, my personal feeling is that the "TZ wants X" arguments are most often just as badly based on superficial knowledge. In simplified terms, the SMMU has a number of components connected to it (the crypto BAM, USB controller, UFS, ...). When the components make memory requests they are identified by a number of Stream IDs (SIDs). The purpose of "iommus" in the device tree is to describe all SIDs that belong to a particular device. These SIDs are then all assigned to a context bank that allows the device to access selected regions in RAM. It shouldn't matter *how* the SIDs are matched inside the SMMU, as long as they end up at the correct context bank. The SMMU will look through the configured Stream Match Registers (SMRs = SID + Mask) to find the context bank that is assigned to the SID. The docs say "If MASK[i]==1, ID[i] is ignored.". This means a SMR with ID=0x426 MASK=0x0011 is definitely identical to ID=0x436 MASK=0x0011. Having the extra entry will make absolutely no difference to the SMMU aside from wasting a pointless SMR. The links you posted suggest "TZ" looks at the SMRs allocated by Linux. If that is really the case then I would expect that to be fundamentally broken. In my opinion there is absolutely no guarantee how or in which order Linux allocates the SMRs. Such functionality would either be extremely complex or broken in tons of edge cases. TL;DR: I cannot provide proof that removing this entry makes a difference. I can just say that I doubt it does, and if it does, then we have far more serious problems. The device tree is supposed to describe the hardware ("This device makes memory requests with the following SIDs") and not fundamentally broken peculiarities of the proprietary TZ firmware ("registers must be programmed exactly with these values"). Thanks, Stephan
On Fri, Feb 16, 2024 at 11:46:49AM +0100, Luca Weiss wrote: > On Fri Jan 5, 2024 at 5:30 PM CET, Stephan Gerhold wrote: > > On Fri, Jan 05, 2024 at 05:15:44PM +0100, Luca Weiss wrote: > > > Add crypto engine (CE) and CE BAM related nodes and definitions for this > > > SoC. > > > > > > For reference: > > > > > > [ 2.297419] qcrypto 1dfa000.crypto: Crypto device found, version 5.5.1 > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > --- > > > arch/arm64/boot/dts/qcom/sm6350.dtsi | 31 +++++++++++++++++++++++++++++++ > > > 1 file changed, 31 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > index 8fd6f4d03490..516aadbb16bb 100644 > > > --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > @@ -1212,6 +1212,37 @@ ufs_mem_phy_lanes: phy@1d87400 { > > > }; > > > }; > > > > > > + cryptobam: dma-controller@1dc4000 { > > > + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0"; > > > + reg = <0 0x01dc4000 0 0x24000>; > > > + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>; > > > + #dma-cells = <1>; > > > + qcom,ee = <0>; > > > + qcom,controlled-remotely; > > > + num-channels = <16>; > > > + qcom,num-ees = <4>; > > > + iommus = <&apps_smmu 0x432 0x0000>, > > > + <&apps_smmu 0x438 0x0001>, > > > + <&apps_smmu 0x43f 0x0000>, > > > + <&apps_smmu 0x426 0x0011>, > > > + <&apps_smmu 0x436 0x0011>; > > > > The last two lines look equivalent to me: 0x436 & ~0x0011 = 0x426. > > I don't understand the IOMMU SID + mask really, but I think I've seen > somewhere before like here that TZ can be a bit picky with the SIDs? > > https://lore.kernel.org/linux-arm-msm/opqdrmyj3y64nqqqmakjydn5rkspizufyeavm7ec7c7ufqz4wk@ey2a7bq3shfj/ > https://lore.kernel.org/linux-arm-msm/11b5db69-49f5-4d7b-81c9-687d66a5cb0d@linaro.org/ > > I don't quite want to risk having some obscure use case breaking because > we cleaned up the dts ;) > > But if you're more sure than me that it won't break, let me know! > > > > > It's also a bit weird that the mask has one more digit than the stream > > ID. And ordered numerically (by stream ID, first number) it would be a > > bit easier to read. :-) > > Sorting them is no problem, can do that for v2. > Where you able to do this? I don't see a v2 in my inbox, am I just searching poorly? Regards, Bjorn > > > > Thanks, > > Stephan >
On Fri Feb 16, 2024 at 7:09 PM CET, Bjorn Andersson wrote: > On Fri, Feb 16, 2024 at 11:46:49AM +0100, Luca Weiss wrote: > > On Fri Jan 5, 2024 at 5:30 PM CET, Stephan Gerhold wrote: > > > On Fri, Jan 05, 2024 at 05:15:44PM +0100, Luca Weiss wrote: > > > > Add crypto engine (CE) and CE BAM related nodes and definitions for this > > > > SoC. > > > > > > > > For reference: > > > > > > > > [ 2.297419] qcrypto 1dfa000.crypto: Crypto device found, version 5.5.1 > > > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > > --- > > > > arch/arm64/boot/dts/qcom/sm6350.dtsi | 31 +++++++++++++++++++++++++++++++ > > > > 1 file changed, 31 insertions(+) > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > > index 8fd6f4d03490..516aadbb16bb 100644 > > > > --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > > +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi > > > > @@ -1212,6 +1212,37 @@ ufs_mem_phy_lanes: phy@1d87400 { > > > > }; > > > > }; > > > > > > > > + cryptobam: dma-controller@1dc4000 { > > > > + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0"; > > > > + reg = <0 0x01dc4000 0 0x24000>; > > > > + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>; > > > > + #dma-cells = <1>; > > > > + qcom,ee = <0>; > > > > + qcom,controlled-remotely; > > > > + num-channels = <16>; > > > > + qcom,num-ees = <4>; > > > > + iommus = <&apps_smmu 0x432 0x0000>, > > > > + <&apps_smmu 0x438 0x0001>, > > > > + <&apps_smmu 0x43f 0x0000>, > > > > + <&apps_smmu 0x426 0x0011>, > > > > + <&apps_smmu 0x436 0x0011>; > > > > > > The last two lines look equivalent to me: 0x436 & ~0x0011 = 0x426. > > > > I don't understand the IOMMU SID + mask really, but I think I've seen > > somewhere before like here that TZ can be a bit picky with the SIDs? > > > > https://lore.kernel.org/linux-arm-msm/opqdrmyj3y64nqqqmakjydn5rkspizufyeavm7ec7c7ufqz4wk@ey2a7bq3shfj/ > > https://lore.kernel.org/linux-arm-msm/11b5db69-49f5-4d7b-81c9-687d66a5cb0d@linaro.org/ > > > > I don't quite want to risk having some obscure use case breaking because > > we cleaned up the dts ;) > > > > But if you're more sure than me that it won't break, let me know! > > > > > > > > It's also a bit weird that the mask has one more digit than the stream > > > ID. And ordered numerically (by stream ID, first number) it would be a > > > bit easier to read. :-) > > > > Sorting them is no problem, can do that for v2. > > > > Where you able to do this? I don't see a v2 in my inbox, am I just > searching poorly? Only sent v2 some minutes ago, didn't have any more time on Friday. Regards Luca > > Regards, > Bjorn > > > > > > > Thanks, > > > Stephan > >
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi index 8fd6f4d03490..516aadbb16bb 100644 --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi @@ -1212,6 +1212,37 @@ ufs_mem_phy_lanes: phy@1d87400 { }; }; + cryptobam: dma-controller@1dc4000 { + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0"; + reg = <0 0x01dc4000 0 0x24000>; + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>; + #dma-cells = <1>; + qcom,ee = <0>; + qcom,controlled-remotely; + num-channels = <16>; + qcom,num-ees = <4>; + iommus = <&apps_smmu 0x432 0x0000>, + <&apps_smmu 0x438 0x0001>, + <&apps_smmu 0x43f 0x0000>, + <&apps_smmu 0x426 0x0011>, + <&apps_smmu 0x436 0x0011>; + }; + + crypto: crypto@1dfa000 { + compatible = "qcom,sm6350-qce", "qcom,sm8150-qce", "qcom,qce"; + reg = <0 0x01dfa000 0 0x6000>; + dmas = <&cryptobam 4>, <&cryptobam 5>; + dma-names = "rx", "tx"; + iommus = <&apps_smmu 0x432 0x0000>, + <&apps_smmu 0x438 0x0001>, + <&apps_smmu 0x43f 0x0000>, + <&apps_smmu 0x426 0x0011>, + <&apps_smmu 0x436 0x0011>; + interconnects = <&aggre2_noc MASTER_CRYPTO_CORE_0 QCOM_ICC_TAG_ALWAYS + &clk_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>; + interconnect-names = "memory"; + }; + ipa: ipa@1e40000 { compatible = "qcom,sm6350-ipa";