Message ID | 20221128064648.1934720-7-baolu.lu@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp5475215wrr; Sun, 27 Nov 2022 22:57:21 -0800 (PST) X-Google-Smtp-Source: AA0mqf4AJeFz6QzX06CVkfuLYEPE9Q+K2g+WfERkCzEr9R/oy+c6JUbXpbpKex0EuD8Cev/0jHZG X-Received: by 2002:aa7:c04f:0:b0:45c:f13b:4b96 with SMTP id k15-20020aa7c04f000000b0045cf13b4b96mr11490606edo.129.1669618641163; Sun, 27 Nov 2022 22:57:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669618641; cv=none; d=google.com; s=arc-20160816; b=yxyMTtMGv4nr2TnO5w9wWw707lxq6kSglkQBVFWSFWhYbeAMRtxowBwUN6cD+szpL8 NY9RLal5HPUhBVoQYz0ekZUyU6BN9G5guXqcSNq2f0pqrk2hqhKgftNeqR/D+J3CwF55 4AW6qDDl/JmVJHuvl1Pz0GhrARDFReVNrEhrjennlw4P/UUMBFcsqYl/xrB0Xa8KlZLo V8YId/o+B2V4RzgksDtQFuZmYVWcIKi6mFgFNVpSj+O0QChHvhrA/d3Hycyru5MrnJRI LjLomZXjPvW9bqaB5iWvcFYh/EuJsC3A46eb1VPkYErJ6tIxxQT3CrPuj44+BbHghGM9 6sEQ== 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=Nl1Eg7WlXcYUFENHrSYfkoqG86BhOKphGyh+uhgDNhs=; b=p7mbx1eRL8DoVoe9BEKfsytzNgMwz7gNEJ+0tDpsuvNzvoTwzs5LbTp8X8dYYPo6Z2 hJw6oaUW/AV9MvmMzwfCg+bwRr7M74V6BHKLb5K5+0G1oGjk+1F9h8yvCiaLml7/+HDq MDLdZQuVadd4zCHoGmY4a1LpqGddIVCsgm1/0LnZ2Dr9H4zeOyejD+AmAIrwOiaPcXVW wgFjkXfFyM5PLlX5Oj5I0d+RDOJpnar0Td5t7oQ0RBU5RbuYwRdGHy0UFBhWPUrP4QnM ziO+D49F6rEr6bTthknYXEbHZeXAwquZ9+0QHI88iNBuMOjXWiccWgdTY7uzqFsr9UCB 8nOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gLeFmrBe; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gt32-20020a1709072da000b007bd8ac3aebbsi6814533ejc.812.2022.11.27.22.56.58; Sun, 27 Nov 2022 22:57:21 -0800 (PST) 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=@intel.com header.s=Intel header.b=gLeFmrBe; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229834AbiK1GzQ (ORCPT <rfc822;gah0developer@gmail.com> + 99 others); Mon, 28 Nov 2022 01:55:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229956AbiK1Gy5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 28 Nov 2022 01:54:57 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD3F615812 for <linux-kernel@vger.kernel.org>; Sun, 27 Nov 2022 22:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669618488; x=1701154488; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=foe9CYLv4t/yayK/wv2PdURR8PHQrrf3ntMgKPrhGNg=; b=gLeFmrBeTkpXk8YOmIFZC9MJxb8vI7zaZI48wUBR8C0OXgvXALY0ImoI R9zSM7XPMjfld+AVYEuvHCI6z+kHlVvXa2+mRjlOTjUXa/7c7wiXskqhd M6OzRYzL9WDZGr77PvfMWSb0oOez0lse8a7Q1gOHFgpx+LFPCotrKkWPu +lHxwmvxvpA1zjjT4QMvYYmb46xYThuZxfMfXV5ESOKf0JV85a4Ex4fhv fqrFezyGCBDs7ZLzG9qYQwEqMB5YhX/xmt2AZqWtfmVZNyzP/rb8cs/qV 7QBLbdBZZG+f4NlzKc92GFv1lclZGGP3Lrs+Bz4m/i/kDgWWM6VGKhyUc w==; X-IronPort-AV: E=McAfee;i="6500,9779,10544"; a="312395009" X-IronPort-AV: E=Sophos;i="5.96,199,1665471600"; d="scan'208";a="312395009" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2022 22:54:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10544"; a="674120803" X-IronPort-AV: E=Sophos;i="5.96,199,1665471600"; d="scan'208";a="674120803" Received: from allen-box.sh.intel.com ([10.239.159.48]) by orsmga008.jf.intel.com with ESMTP; 27 Nov 2022 22:54:41 -0800 From: Lu Baolu <baolu.lu@linux.intel.com> To: Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@nvidia.com>, Christoph Hellwig <hch@infradead.org>, Kevin Tian <kevin.tian@intel.com>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Jean-Philippe Brucker <jean-philippe@linaro.org> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>, Rob Clark <robdclark@gmail.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Yong Wu <yong.wu@mediatek.com>, Matthias Brugger <matthias.bgg@gmail.com>, Heiko Stuebner <heiko@sntech.de>, Matthew Rosato <mjrosato@linux.ibm.com>, Orson Zhai <orsonzhai@gmail.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, Chunyan Zhang <zhang.lyra@gmail.com>, Chen-Yu Tsai <wens@csie.org>, Thierry Reding <thierry.reding@gmail.com>, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com> Subject: [PATCH v3 06/20] iommu/mtk: Remove detach_dev callback Date: Mon, 28 Nov 2022 14:46:34 +0800 Message-Id: <20221128064648.1934720-7-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221128064648.1934720-1-baolu.lu@linux.intel.com> References: <20221128064648.1934720-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_NONE autolearn=ham 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?1750722036165805683?= X-GMAIL-MSGID: =?utf-8?q?1750722036165805683?= |
Series |
iommu: Retire detach_dev callback
|
|
Commit Message
Baolu Lu
Nov. 28, 2022, 6:46 a.m. UTC
The IOMMU driver supports default domain, so the detach_dev op will never
be called. Remove it to avoid dead code.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
drivers/iommu/mtk_iommu.c | 9 ---------
1 file changed, 9 deletions(-)
Comments
On Mon, Nov 28, 2022 at 02:46:34PM +0800, Lu Baolu wrote: > The IOMMU driver supports default domain, so the detach_dev op will never > be called. Remove it to avoid dead code. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/iommu/mtk_iommu.c | 9 --------- > 1 file changed, 9 deletions(-) I listed this driver as not supporting default domains: https://lore.kernel.org/linux-iommu/20220516135741.GV1343366@nvidia.com/ ? Has something changed? Did I get it wrong? Jason
On 2022-11-28 13:49, Jason Gunthorpe wrote: > On Mon, Nov 28, 2022 at 02:46:34PM +0800, Lu Baolu wrote: >> The IOMMU driver supports default domain, so the detach_dev op will never >> be called. Remove it to avoid dead code. >> >> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >> --- >> drivers/iommu/mtk_iommu.c | 9 --------- >> 1 file changed, 9 deletions(-) > > I listed this driver as not supporting default domains: > > https://lore.kernel.org/linux-iommu/20220516135741.GV1343366@nvidia.com/ > > ? > > Has something changed? Did I get it wrong? static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type) { struct mtk_iommu_domain *dom; if (type != IOMMU_DOMAIN_DMA && type != IOMMU_DOMAIN_UNMANAGED) return NULL; ... This one runs on arm64, so has always supported default domains for iommu-dma to work. Cheers, Robin.
On 11/28/22 9:59 PM, Robin Murphy wrote: > On 2022-11-28 13:49, Jason Gunthorpe wrote: >> On Mon, Nov 28, 2022 at 02:46:34PM +0800, Lu Baolu wrote: >>> The IOMMU driver supports default domain, so the detach_dev op will >>> never >>> be called. Remove it to avoid dead code. >>> >>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >>> --- >>> drivers/iommu/mtk_iommu.c | 9 --------- >>> 1 file changed, 9 deletions(-) >> >> I listed this driver as not supporting default domains: >> >> https://lore.kernel.org/linux-iommu/20220516135741.GV1343366@nvidia.com/ >> >> ? >> >> Has something changed? Did I get it wrong? > > static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type) > { > struct mtk_iommu_domain *dom; > > if (type != IOMMU_DOMAIN_DMA && type != IOMMU_DOMAIN_UNMANAGED) > return NULL; > ... > > > This one runs on arm64, so has always supported default domains for > iommu-dma to work. This, together with several other ones, only support IOMMU_DOMAIN_DMA type of default domain. The iommu core handle this by falling back to IOMMU_DOMAIN_DMA if other types fail. dom = __iommu_domain_alloc(bus, type); if (!dom && type != IOMMU_DOMAIN_DMA) { dom = __iommu_domain_alloc(bus, IOMMU_DOMAIN_DMA); if (dom) pr_warn("Failed to allocate default IOMMU domain of type %u for group %s - Falling back to IOMMU_DOMAIN_DMA", type, group->name); } I have another cleanup series: https://github.com/LuBaolu/intel-iommu/commits/iommu-use-def_default_type-wip which adds IOMMU_DOMAIN_DMA default domain type requirement in the def_domain_type callback. I planed to bring that to discussion after this one. Best regards, baolu
On 2022-11-29 02:07, Baolu Lu wrote: > On 11/28/22 9:59 PM, Robin Murphy wrote: >> On 2022-11-28 13:49, Jason Gunthorpe wrote: >>> On Mon, Nov 28, 2022 at 02:46:34PM +0800, Lu Baolu wrote: >>>> The IOMMU driver supports default domain, so the detach_dev op will >>>> never >>>> be called. Remove it to avoid dead code. >>>> >>>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >>>> --- >>>> drivers/iommu/mtk_iommu.c | 9 --------- >>>> 1 file changed, 9 deletions(-) >>> >>> I listed this driver as not supporting default domains: >>> >>> https://lore.kernel.org/linux-iommu/20220516135741.GV1343366@nvidia.com/ >>> >>> ? >>> >>> Has something changed? Did I get it wrong? >> >> static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type) >> { >> struct mtk_iommu_domain *dom; >> >> if (type != IOMMU_DOMAIN_DMA && type != IOMMU_DOMAIN_UNMANAGED) >> return NULL; >> ... >> >> >> This one runs on arm64, so has always supported default domains for >> iommu-dma to work. > > This, together with several other ones, only support IOMMU_DOMAIN_DMA > type of default domain. The iommu core handle this by falling back to > IOMMU_DOMAIN_DMA if other types fail. > > dom = __iommu_domain_alloc(bus, type); > if (!dom && type != IOMMU_DOMAIN_DMA) { > dom = __iommu_domain_alloc(bus, IOMMU_DOMAIN_DMA); > if (dom) > pr_warn("Failed to allocate default IOMMU > domain of type %u for group %s - Falling back to IOMMU_DOMAIN_DMA", > type, group->name); > } > > I have another cleanup series: > > https://github.com/LuBaolu/intel-iommu/commits/iommu-use-def_default_type-wip > > which adds IOMMU_DOMAIN_DMA default domain type requirement in the > def_domain_type callback. I planed to bring that to discussion after > this one. Per the discussion over on the s390 thread, I think that would be a step in the wrong direction. I'd prefer to keep .def_domain_type for device-specific requirements and express general driver domain support a different way. If the IOMMU_DOMAIN_DMA fallback is worth removing then the one for IOMMU_DOMAIN_BLOCKED is as well - no point doing half the job ;) Thanks, Robin.
On 2022/11/29 19:45, Robin Murphy wrote: > On 2022-11-29 02:07, Baolu Lu wrote: >> On 11/28/22 9:59 PM, Robin Murphy wrote: >>> On 2022-11-28 13:49, Jason Gunthorpe wrote: >>>> On Mon, Nov 28, 2022 at 02:46:34PM +0800, Lu Baolu wrote: >>>>> The IOMMU driver supports default domain, so the detach_dev op will >>>>> never >>>>> be called. Remove it to avoid dead code. >>>>> >>>>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >>>>> --- >>>>> drivers/iommu/mtk_iommu.c | 9 --------- >>>>> 1 file changed, 9 deletions(-) >>>> >>>> I listed this driver as not supporting default domains: >>>> >>>> https://lore.kernel.org/linux-iommu/20220516135741.GV1343366@nvidia.com/ >>>> >>>> ? >>>> >>>> Has something changed? Did I get it wrong? >>> >>> static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type) >>> { >>> struct mtk_iommu_domain *dom; >>> >>> if (type != IOMMU_DOMAIN_DMA && type != IOMMU_DOMAIN_UNMANAGED) >>> return NULL; >>> ... >>> >>> >>> This one runs on arm64, so has always supported default domains for >>> iommu-dma to work. >> >> This, together with several other ones, only support IOMMU_DOMAIN_DMA >> type of default domain. The iommu core handle this by falling back to >> IOMMU_DOMAIN_DMA if other types fail. >> >> dom = __iommu_domain_alloc(bus, type); >> if (!dom && type != IOMMU_DOMAIN_DMA) { >> dom = __iommu_domain_alloc(bus, IOMMU_DOMAIN_DMA); >> if (dom) >> pr_warn("Failed to allocate default IOMMU >> domain of type %u for group %s - Falling back to IOMMU_DOMAIN_DMA", >> type, group->name); >> } >> >> I have another cleanup series: >> >> https://github.com/LuBaolu/intel-iommu/commits/iommu-use-def_default_type-wip >> >> which adds IOMMU_DOMAIN_DMA default domain type requirement in the >> def_domain_type callback. I planed to bring that to discussion after >> this one. > > Per the discussion over on the s390 thread, I think that would be a step > in the wrong direction. I'd prefer to keep .def_domain_type for > device-specific requirements and express general driver domain support a > different way. If the IOMMU_DOMAIN_DMA fallback is worth removing then > the one for IOMMU_DOMAIN_BLOCKED is as well - no point doing half the > job ;) Get you. Thanks for pointing this out. Sure, let's keep the code. Best regards, baolu
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index 5dc1009a19ed..2022f47529c1 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -713,14 +713,6 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain, return ret; } -static void mtk_iommu_detach_device(struct iommu_domain *domain, - struct device *dev) -{ - struct mtk_iommu_data *data = dev_iommu_priv_get(dev); - - mtk_iommu_config(data, dev, false, 0); -} - static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova, phys_addr_t paddr, size_t pgsize, size_t pgcount, int prot, gfp_t gfp, size_t *mapped) @@ -949,7 +941,6 @@ static const struct iommu_ops mtk_iommu_ops = { .owner = THIS_MODULE, .default_domain_ops = &(const struct iommu_domain_ops) { .attach_dev = mtk_iommu_attach_device, - .detach_dev = mtk_iommu_detach_device, .map_pages = mtk_iommu_map, .unmap_pages = mtk_iommu_unmap, .flush_iotlb_all = mtk_iommu_flush_iotlb_all,