Received: by 2002:a05:7412:3b8b:b0:fc:a2b0:25d7 with SMTP id nd11csp2453178rdb; Mon, 12 Feb 2024 05:37:09 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWfpCi4tl9USJZV4RH2+7n4vfhLlU3O+j7GBNvNsSpNVZGwvuTnXt+z0lwdiQ3JVepw9h8SaqOvfgM9hXI1wIHFtcb7PKrM3FfDqvVEXA== X-Google-Smtp-Source: AGHT+IGpOIXfAkA/bTAzDAdRzV7J4pLOcJV1vE878NidIDZiUjv+f01R+acFmjJPlS5fD0ICDKty X-Received: by 2002:ac8:5a16:0:b0:42c:75f8:2247 with SMTP id n22-20020ac85a16000000b0042c75f82247mr4075416qta.20.1707745028436; Mon, 12 Feb 2024 05:37:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707745028; cv=pass; d=google.com; s=arc-20160816; b=rF9QPd7fKYH3Cc+347z1gfK2567CaI8cfYx+nCn0uwnNnreaqx0yrbWTSxT0/8blOw wJnKm6ytliZKnK8yl/Eu3x0ugurnd5DMJ4yNY5q/7wnWUWlgu8+ldXM1panStmwvpZq3 koJ5zkTtZxNU/LVCvdDvkIsJwgN9v+Wugamz7mXTfhUoGI2oaRmpfQR56I7Uu86x75Sf /k35ObzWBDUDVQuxVHqw91t9Vwdws5hzg3cfL0E7EZGCN0EoMDEyXs/gkQSrSWOkSA4j JFs2Q6IF/0ElCth6SWCV2f514D/zBZ6w/lmyZUMGrV5W5EkZx7Tzc8ZA7eJSEs9uOMCX p95w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :dkim-signature; bh=voyZqJo/cIne41l5d+IDZJTmO0BrPsamqEotiqg3SZ4=; fh=/xqRJdUMA+gBc4kZwRIH+xHdmcI2evK0xpVyQy2yw/I=; b=zMkbfQTzchd9dsL8wDyX6g+JQKZ1kSioC5fR2d3c4TRufhI7vWcQiKE5yezay7XOak Tqgc3Vti9ZN96YAGUxhSOxJkPNpIWg590zS4LJxvMvHawloU0oOLVnvEq2APXOfRLkwk QZvp4nv/CjG6bkU0CSQcjf52+MEYUuOEWgjDEpYBi/t5mU3iGTtrp7IP8Uhq1bOLAsGm qV13iamN5gL2Xe+0lkQqpLeIhv6p+efF8nD9ZqRDDyYmZhvdpERNSMBiGu1RVw3gF5eK mvwhSZHF2h83M6vm7CAwuseh0MBuJmpSoNh6Oam9msFgL3L8Ll7Y71P6gDp8hVEk7ZlF 6Y5Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nGoFUZMZ; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-61688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61688-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org X-Forwarded-Encrypted: i=2; AJvYcCWCvvX4K0Ime36D31n+FdJMEK02FLUG7QoZMTalEnVj0WKtcd3Uap2uvehFa7A7YvyulllJAGWTwBbwn48ssUPLHWTVpCSSonCLKaaZzQ== Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id v15-20020ac8728f000000b0042c01ce9059si340968qto.430.2024.02.12.05.37.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 05:37:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-61688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nGoFUZMZ; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-61688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61688-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org 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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 246EE1C2214A for ; Mon, 12 Feb 2024 13:37:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4CDF847A5D; Mon, 12 Feb 2024 13:27:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="nGoFUZMZ" Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (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 342B245BE8 for ; Mon, 12 Feb 2024 13:27:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707744433; cv=none; b=E0fSgCQIqd2TDhi/1EonwB08XJmzr/tkVyhy7HBfiUn5UMC9EKvZ5BNIheuVnGqs/Xo5sR2w7ZqAswpJBfj9buskJ7dBCYROfHnNMjKY8yDvwE6QC5xHMGYa1i3fe6k6246r7tvBuEafqsRSvwdrE0BjtBsS/i6gq6rVTZezCn8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707744433; c=relaxed/simple; bh=UgJE8QN26wTVcYTwslTRxKcPKfKIluHtkCRbsH9i8HU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ICwOzGhzF6v9wsgSCSqRU3vsZX2b/1b1MxWAqooR8e0eorsN4d5Vl/eA53EFiaSuWyG6C0+97m4g1ejHQtlutNPyl8hehIr56dfrQgXlmia88oe13TK0MwN62if7Bsbeu2LTc3Foy88y+J2D2rK67JFPy/yLqZ8/hv1DI84vs4o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=nGoFUZMZ; arc=none smtp.client-ip=209.85.219.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-dc745927098so2616568276.3 for ; Mon, 12 Feb 2024 05:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1707744430; x=1708349230; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=voyZqJo/cIne41l5d+IDZJTmO0BrPsamqEotiqg3SZ4=; b=nGoFUZMZjXBY1U0CR9u5EV/I7+w50xRnP2TGdlY8u+rN+EW1dn41R6dVDZwwKFFe2w bcrSTwDuMhhOZm6MqEf6Pn4Ze+iggGnGTlBW7eJTK/U7XegVi9xt5/H/EgdzAYEeBKv5 2TUNrf+CJoAnfNLZbE0x1hKE5DYF4W95sbJwBeCezzKcAAbMx03mt6d7YpTnhp6o2QOT B+eO6uqvL2imvfm5mOZ27Jwr6b4bBsfl6Opl2RPEcsq7VzQoLo8WtKek/EOXZsxPOkVH zUdfguGe088cj2rYTpEmvb/ON1NqMoPNXSMyjZoVYLRv9vMnFEztQlcm8aZ5Ou/AcTlB XKYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707744430; x=1708349230; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=voyZqJo/cIne41l5d+IDZJTmO0BrPsamqEotiqg3SZ4=; b=dIGf+YBXKOlamslNi643O0GZPDcxHekg901BIlxa7rAzr25DBMnVI7Um1aOODFjPcV /wKq9+4LyMRlEOJrgOyhiWiiZ6Lt2ph3H70k3D56oZvBKewZNlPsqpqN7oguLcLGebet yVdUEuMSaKDWRsZhD+wtiVU+MfVmZ4pfVMav1IkJxol3Uo2zLpq4egFCit25OEJFuclQ Cm4GbFesQzPb9WoWNe2Ca0zepmL9HuHjUvlUf0YxXYZHXmYCcxXVVYGkmdPimPr3WVVT YrZmlX7I2v8I1sBCyFLwOnyZt0/Gxd0QhhT6MdOY5DEQdY294Cl3PrYlYvOlCtoXhUEG 2fIQ== X-Forwarded-Encrypted: i=1; AJvYcCWRKINwHjWyuEmBk0NDSZKCVDorMoVX0IjhMTAXOS5QmXT5MW+MhHH1DKRLt/f3toKzZ1dYfzmN8PX8BFeJqP82xdPK7f5fBprwukUF X-Gm-Message-State: AOJu0YxxmLE4ydpzcY9xP0YmQ9eiIgfioU8W4JC2hG89GMbUUVhOVqwx NWwpjg54Rqzge5+PJS7DPsamvqyxOYuBkK1wwI3NmsQR6Ny9AieEqDJwrunNV0YMY5be3QWg9h2 O+TP7+Voq1/tw9XJxAy1Tx89hrASrWBBdwZjCwQ== X-Received: by 2002:a05:6902:2604:b0:dc7:4fbd:2b55 with SMTP id dw4-20020a056902260400b00dc74fbd2b55mr6374378ybb.45.1707744430126; Mon, 12 Feb 2024 05:27:10 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240207-enable_pcie-v1-1-b684afa6371c@quicinc.com> <3ad77846-b4a8-80ee-e9e1-d5cbf4add6d8@quicinc.com> <20240209075716.GA12035@thinkpad> <20240212131551.GA74465@thinkpad> In-Reply-To: <20240212131551.GA74465@thinkpad> From: Dmitry Baryshkov Date: Mon, 12 Feb 2024 15:26:59 +0200 Message-ID: Subject: Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Add PCIe nodes To: Manivannan Sadhasivam Cc: Krishna Chaitanya Chundru , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, quic_vbadigan@quicinc.com, quic_ramkri@quicinc.com, quic_nitegupt@quicinc.com, quic_skananth@quicinc.com, quic_parass@quicinc.com Content-Type: text/plain; charset="UTF-8" On Mon, 12 Feb 2024 at 15:16, Manivannan Sadhasivam wrote: > > On Fri, Feb 09, 2024 at 12:56:18PM +0200, Dmitry Baryshkov wrote: > > On Fri, 9 Feb 2024 at 09:57, Manivannan Sadhasivam > > wrote: > > > > > > On Fri, Feb 09, 2024 at 12:58:15PM +0530, Krishna Chaitanya Chundru wrote: > > > > > > > > > > > > On 2/8/2024 8:49 PM, Dmitry Baryshkov wrote: > > > > > On Thu, 8 Feb 2024 at 16:58, Krishna Chaitanya Chundru > > > > > wrote: > > > > > > On 2/8/2024 12:21 PM, Dmitry Baryshkov wrote: > > > > > > > On Thu, 8 Feb 2024 at 08:14, Krishna Chaitanya Chundru > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/7/2024 5:17 PM, Dmitry Baryshkov wrote: > > > > > > > > > On Wed, 7 Feb 2024 at 12:42, Krishna chaitanya chundru > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Enable PCIe1 controller and its corresponding PHY nodes on > > > > > > > > > > qcs6490-rb3g2 platform. > > > > > > > > > > > > > > > > > > > > PCIe switch is connected to PCIe1, PCIe switch has multiple endpoints > > > > > > > > > > connected. For each endpoint a unique BDF will be assigned and should > > > > > > > > > > assign unique smmu id. So for each BDF add smmu id. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Krishna chaitanya chundru > > > > > > > > > > --- > > > > > > > > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 42 ++++++++++++++++++++++++++++ > > > > > > > > > > 1 file changed, 42 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > > > > > > > > > > index 8bb7d13d85f6..0082a3399453 100644 > > > > > > > > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > > > > > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > > > > > > > > > > @@ -413,6 +413,32 @@ vreg_bob_3p296: bob { > > > > > > > > > > }; > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > +&pcie1 { > > > > > > > > > > + perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>; > > > > > > > > > > + > > > > > > > > > > + pinctrl-0 = <&pcie1_reset_n>, <&pcie1_wake_n>; > > > > > > > > > > + pinctrl-names = "default"; > > > > > > > > > > + > > > > > > > > > > + iommu-map = <0x0 &apps_smmu 0x1c80 0x1>, > > > > > > > > > > + <0x100 &apps_smmu 0x1c81 0x1>, > > > > > > > > > > + <0x208 &apps_smmu 0x1c84 0x1>, > > > > > > > > > > + <0x210 &apps_smmu 0x1c85 0x1>, > > > > > > > > > > + <0x218 &apps_smmu 0x1c86 0x1>, > > > > > > > > > > + <0x300 &apps_smmu 0x1c87 0x1>, > > > > > > > > > > + <0x400 &apps_smmu 0x1c88 0x1>, > > > > > > > > > > + <0x500 &apps_smmu 0x1c89 0x1>, > > > > > > > > > > + <0x501 &apps_smmu 0x1c90 0x1>; > > > > > > > > > > > > > > > > > > Is the iommu-map really board specific? > > > > > > > > > > > > > > > > > The iommu-map for PCIe varies if PCIe switch is connected. > > > > > > > > For this platform a PCIe switch is connected and for that reason > > > > > > > > we need to define additional smmu ID's for each BDF. > > > > > > > > > > > > > > > > For that reason we defined here as these ID's are applicable only > > > > > > > > for this board. > > > > > > > > > > > > > > So, these IDs are the same for all boards, just being unused on > > > > > > > devices which have no bridges / switches connected to this PCIe host. > > > > > > > If this is correct, please move them to sc7280.dtsi. > > > > > > > > > > > > > Yes ID's will be same for all boards. we can move them sc7280.dtsi > > > > > > but the BDF to smmu mapping will be specific to this board only. > > > > > > if there is some other PCIe switch with different configuration is > > > > > > connected to different board of same variant in future again these > > > > > > mapping needs to updated. > > > > > > > > > > Could you possibly clarify this? Are they assigned one at a time > > > > > manually? Or is it somehow handled by the board's TZ code, which > > > > > assigns them sequentially to the known endpoints? And is it done via > > > > > probing the link or via some static configuration? > > > > > > > > There is no assignment of SID's in TZ for PCIe. > > > > PCIe controller has BDF to SID mapping table which we need to > > > > program with the iommu map table. > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-qcom.c?h=v6.8-rc3#n997 > > > > > > > > Based upon switch the BDF to SID table will change for example I had two > > > > switches with one switch has 2 PCIe ports and other has 3 ports one > > > > embedded port which supports multiple functions. > > > > > > > > For the first switch the BDF's are > > > > - 0x000(root complex), > > > > - 0x100(USP), > > > > - 0x208(DSP 0), > > > > - 0x210(DSP 1), > > > > - 0x300(endpoint connected to DSP 0), > > > > - 0x400( endpoint connected to DSP 1). > > > > > > > > For 2nd switch the BDF's are > > > > - 0x000(root complex), > > > > - 0x100(USP), > > > > - 0x208(embeeded DSP 0), > > > > - 0x210(DSP 1), > > > > - 0x218 (DSP 2), > > > > - 0x300(embedded endpoint function 0), > > > > - 0x301 (embedded endpoint function 1) > > > > - 0x400( endpoint connected to DSP 1) > > > > - 0x500(endpoint connected to DSP2). > > > > > > > > For these two switches we need different BDF to SID table so for that > > > > reason we are keeping iommu map here as this is specific to this board. > > > > > > > > > > I don't understand why the SID table has to change between PCIe devices. The SID > > > mapping should be part of the SoC dtsi, where a single SID would be defined for > > > the devices under a bus. And all the devices under the bus have to use the same > > > SID. > > > > This sounds like a sane default, indeed. Nevertheless, I see a point > > in having per-device-SID assignment. This increases isolation and can > > potentially prevent security issues. However in such case SID > > assignment should be handled in some automagic way. In other words, > > there must be no need to duplicate the topology of the PCIe bus in the > > iommu-maps property. > > > > Yes, address space isolation is the primary motive behind this patch. But as > you said, we should not do it by hardcoding the SIDs in the board DTS. It won't > scale and is not a proper solution. > > Instead, the issue should be addressed in the IOMMU layer by working with the > IOMMU folks. > > It should be noted that we _cannot_ use any arbitrary SID for PCIe bus. HYP/TZ > will fault the transactions coming with different SIDs than the ones assigned > to them. So we still need to pass that info from DT to IOMMU layer. Yes, passing a range or a masked value sounds logical. Passing 1:1 mapping for a dynamic bus doesn't. -- With best wishes Dmitry