Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp945304pxu; Thu, 15 Oct 2020 22:48:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz49A2xat/AAYtSIwRyR0cQlpLZmAQSlXTg0caDa15bfYS+HEnW/IV7s9IqsJVOuO+XFBQQ X-Received: by 2002:a50:aa84:: with SMTP id q4mr2002173edc.331.1602827315597; Thu, 15 Oct 2020 22:48:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602827315; cv=none; d=google.com; s=arc-20160816; b=GEZfnLixINqPiPc4180AbmTMmHT1jvYMNfugXBDe3cDubmeZrT1TKyWyHtOaLSpLTO ktxfWK/3xTXdfXffxLloxKjMl+2exgcizCEHBJteQ1pM4sZXHxE/woh/BXn7WG4fZE5n Ol/8y3Ud+mRcJP8RCLd+hX7Z11Df0yDMlU8JoXrO4ruTN2jOCiU0VkgIHCThkUlMv7+Q 18HiQ8HXoH815UxZwR4DxEZ1vP2EdXsS5VTo7VeaV+4BDhsZYFlyz+WkKH1Sk98H22X4 6OJ4U2XhGoGJo+xVBbFWsPdYI0FFwr8USne8eo72CNpcmQFQ84yxzawpZck5UBYdGMYl RVAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=C9/au9NmuAjbAcpNdJ/iNR3JJfxaIrQJHGtDNhivldY=; b=aDHOKJG5dI3g9yy2gSvmGRIFMgm1efprqjR9O42jxfMYKBP5KY6WB7jvqRQXVoomGX UBSrZjKuuB1PPC4sdTDREDth+bbHsLyWBBCB7y346wafCmEHFelaOFN2L+1bVT87W1uR RGMTTF5KO+rgdHC+qDY/HqCI8dkfxpL0Ljkbh/sDZPra6yjUaILi+iIsjmRWW4yZiuDZ BUm/BDe8GYXEel9hDBHbZJjmb4xoiAqupebaGOn7eJdWqQTmj68E2g1M60WJmaYlA1yc YKVynrOlxZASLaaYTduk4fPSPUwetRa3UpLUhRZJfy8fGrY+uVU2b+uL5lE96kxDgfTc Z+Aw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fUnr49tv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o13si1160216ejb.365.2020.10.15.22.48.13; Thu, 15 Oct 2020 22:48:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fUnr49tv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726310AbgJPECL (ORCPT + 99 others); Fri, 16 Oct 2020 00:02:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725298AbgJPECL (ORCPT ); Fri, 16 Oct 2020 00:02:11 -0400 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4AFBC061755; Thu, 15 Oct 2020 21:02:09 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id h6so625333pgk.4; Thu, 15 Oct 2020 21:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=C9/au9NmuAjbAcpNdJ/iNR3JJfxaIrQJHGtDNhivldY=; b=fUnr49tvI2n8Bt8NbcB9EuFZXeZSkEm0m3HKZpMJQNWe1MqKl04RBFrb2f1epAFdf+ la4hswFSfMQ+QyQ3YcImGcU1wpeC3mZh/5Pk7kSDKWmg7hz3aR2Jkj6hXGUr/lvBOolV vQCAO05qsArss6AZMqm1OJzYrp2WsasKMfy4DuDRcZxo7KuQAfeLczazVfX0zpyWLtVh mhbDAz4bd8OPnx9fQMJ+H7lz+F51UfQZDiE6F5Ry4Ya/clJd8EfIzGRbPa2kgxe5gy8n P2LLP/iSGXrLTqUn2MF7rmekQd88zpnFoLmFIYaLcsZuJGzn8AnjDPgP7uC5SgIJC50d Jx7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=C9/au9NmuAjbAcpNdJ/iNR3JJfxaIrQJHGtDNhivldY=; b=SPiXOul7m3wdU8hgrFeCjx1s6PSmql9ee799wkmJajm7JgJPCRQnabGTvRmz7r6l6u ckxOFM9111dvQFEXv0LMNj2xRtSSuxaX4c+30NuBzMiXGp2jKvP9oHXMPj4T/FKpCPfX bjZhqVNiBPfkbRKBy569grYvFR4KVFAaxC6bJ86VrmilDDVOKFbyA68DtjYf9B15fj5I 2byUHy95wfHNSgLW838Yue5+9gWZQQLMIi5uKcfSkd9XP+oLNK3vA5TC25RYp8R6zqfx ydsdeFuIVHp4f1h4X9/7EQO2Ol5Xa2RUmDRGP5PTRQaBQ0uuN7vkJ8LXzg9qO0NCpiu9 1Vqg== X-Gm-Message-State: AOAM533FMQq/yfdlgYmKYGWVUaK7Kf4TZ6ZnlZeR0AbKquJPUt8XL3Ya CDXODsZP5/jWS9d2lCQo3ECUVzsj1Ns= X-Received: by 2002:a05:6a00:150a:b029:159:53cd:86db with SMTP id q10-20020a056a00150ab029015953cd86dbmr1667035pfu.11.1602820928943; Thu, 15 Oct 2020 21:02:08 -0700 (PDT) Received: from Asurada-Nvidia (thunderhill.nvidia.com. [216.228.112.22]) by smtp.gmail.com with ESMTPSA id b6sm943638pjq.42.2020.10.15.21.02.08 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 15 Oct 2020 21:02:08 -0700 (PDT) Date: Thu, 15 Oct 2020 20:53:47 -0700 From: Nicolin Chen To: Robin Murphy Cc: thierry.reding@gmail.com, joro@8bytes.org, digetx@gmail.com, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, jonathanh@nvidia.com Subject: Re: [PATCH v7 3/3] iommu/tegra-smmu: Add PCI support Message-ID: <20201016035347.GA28140@Asurada-Nvidia> References: <20201009161936.23122-1-nicoleotsuka@gmail.com> <20201009161936.23122-4-nicoleotsuka@gmail.com> <20201015041346.GA13936@Asurada-Nvidia> <340afbc0-5513-0742-d2d2-1ab908248af3@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <340afbc0-5513-0742-d2d2-1ab908248af3@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 15, 2020 at 10:55:52AM +0100, Robin Murphy wrote: > On 2020-10-15 05:13, Nicolin Chen wrote: > > On Wed, Oct 14, 2020 at 06:42:36PM +0100, Robin Murphy wrote: > > > On 2020-10-09 17:19, Nicolin Chen wrote: > > > > This patch simply adds support for PCI devices. > > > > > > > > Reviewed-by: Dmitry Osipenko > > > > Tested-by: Dmitry Osipenko > > > > Signed-off-by: Nicolin Chen > > > > --- > > > > > > > > Changelog > > > > v6->v7 > > > > * Renamed goto labels, suggested by Thierry. > > > > v5->v6 > > > > * Added Dmitry's Reviewed-by and Tested-by. > > > > v4->v5 > > > > * Added Dmitry's Reviewed-by > > > > v3->v4 > > > > * Dropped !iommu_present() check > > > > * Added CONFIG_PCI check in the exit path > > > > v2->v3 > > > > * Replaced ternary conditional operator with if-else in .device_group() > > > > * Dropped change in tegra_smmu_remove() > > > > v1->v2 > > > > * Added error-out labels in tegra_smmu_probe() > > > > * Dropped pci_request_acs() since IOMMU core would call it. > > > > > > > > drivers/iommu/tegra-smmu.c | 35 +++++++++++++++++++++++++---------- > > > > 1 file changed, 25 insertions(+), 10 deletions(-) > > > > > > > > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c > > > > index be29f5977145..2941d6459076 100644 > > > > --- a/drivers/iommu/tegra-smmu.c > > > > +++ b/drivers/iommu/tegra-smmu.c > > > > @@ -10,6 +10,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > #include > > > > @@ -865,7 +866,11 @@ static struct iommu_group *tegra_smmu_device_group(struct device *dev) > > > > group->smmu = smmu; > > > > group->soc = soc; > > > > - group->group = iommu_group_alloc(); > > > > + if (dev_is_pci(dev)) > > > > + group->group = pci_device_group(dev); > > > > > > Just to check, is it OK to have two or more swgroups "owning" the same > > > iommu_group if an existing one gets returned here? It looks like that might > > > not play nice with the use of iommu_group_set_iommudata(). > > > > Do you mean by "gets returned here" the "IS_ERR" check below? > > I mean that unlike iommu_group_alloc()/generic_device_group(), > pci_device_group() may give you back a group that already contains another > device and has already been set up from that device's perspective. This can > happen for topological reasons like requester ID aliasing through a PCI-PCIe > bridge or lack of isolation between functions. Okay..but we don't really have two swgroups owning the same groups in case of PCI devices. For Tegra210, all PCI devices inherit the same swgroup from the PCI controller. And I'd think previous chips do the same. The only use case currently of 2+ swgroups owning the same iommu_group is for display controller. Or do you suggest we need an additional check for pci_device_group?