Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp190230ybm; Wed, 27 May 2020 23:45:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAnRnGV0m+QC8bFaxCdoGSE7Q/lbOB9wC417od4CiQlIkmiPYKEQ7Nfu8zVZ1Ys0iqnfgB X-Received: by 2002:a50:d1d3:: with SMTP id i19mr1523156edg.35.1590648345990; Wed, 27 May 2020 23:45:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590648345; cv=none; d=google.com; s=arc-20160816; b=VfB3KG7/BSIOeHDA8l3w41JVGyp4tKqf5IN/AxjOgdgMk1mALEgnMNNSVtrlltAjDv aOFjTAaVx3C6UESx2m+xZkg0+dGSCkeEUMBh/vyxaTJ+bIuNp/rD3yV/hqeuh0NQxeBI vkQiGMpQDUcpKsxt1EWT9MM8XuIuDUfWNrKLBda2G1I6CtI+yA0VDJmLb3JD1GA342sP 8B/bt4QXyEi0qKBeI/ByEomRyJqatCi32uUY3ErFInxYwbw4Sc2u6JMVpLlVDv/nQW43 zoQYDUCdkoGlJpXGFVBwEK1iX0prUjGWpT1V+rZ/6Nok6008K8AFfrkL8uP62nsmBMDV +XDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=LW1slht9bE0E5/uM4NqU8lPmoftsRq+K40XaJW5OCX8=; b=qY3qrogC2Kt7In/5o8ohrD7n4aExJQ54N6hv6kOYUp0K7ELLkRHbPPndNHWNvDEBHT GOcaYZX+JyFyUEl1uYF1lpv7MQ0DzMZK/ZQTGXWeVSaDMPHK9IaQHRcqeZ34gFeYzsrp u/tMffbGftwLeJlN/otvqc9VpG45mnVdWfr8K1dOSBRLJvt9ievSVxJmKcvxFyNZv0zb 8AUpp0JEvnQQqP71gQ9oKErp94J0fWnOGJdadeIN4OpPWI9cSMv03kS06bjrt68cPVzj RZ9WTjAAuV/zyePejODGdhniicqfxmohXTYyoszZCVqcqFf/Y5zqh+IKLMm9/rZgsNpF nMPg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o3si3357310ejg.491.2020.05.27.23.45.23; Wed, 27 May 2020 23:45:45 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726394AbgE1GmU (ORCPT + 99 others); Thu, 28 May 2020 02:42:20 -0400 Received: from 8bytes.org ([81.169.241.247]:45136 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725836AbgE1GmU (ORCPT ); Thu, 28 May 2020 02:42:20 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 2194526B; Thu, 28 May 2020 08:42:18 +0200 (CEST) Date: Thu, 28 May 2020 08:42:16 +0200 From: Joerg Roedel To: Christoph Hellwig Cc: iommu@lists.linux-foundation.org, jroedel@suse.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH 02/10] iommu/amd: Unexport get_dev_data() Message-ID: <20200528064216.GN5221@8bytes.org> References: <20200527115313.7426-1-joro@8bytes.org> <20200527115313.7426-3-joro@8bytes.org> <20200528061353.GA17035@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200528061353.GA17035@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 27, 2020 at 11:13:53PM -0700, Christoph Hellwig wrote: > On Wed, May 27, 2020 at 01:53:05PM +0200, Joerg Roedel wrote: > > From: Joerg Roedel > > > > This function is internal to the AMD IOMMU driver and only exported > > because the amd_iommu_v2 modules calls it. But the reason it is called > > from there could better be handled by amd_iommu_is_attach_deferred(). > > So unexport get_dev_data() and use amd_iommu_is_attach_deferred() > > instead. > > Btw, what is the reason amd_iommu_v2 is a separate module? It is > very little code, and other drivers seem to just integrate such > functionality. The module contains optional functionality that is only needed by the amd_kfd driver, which itself only does something useful on (newer) AMD GPUs. So I made it a separate module back in the days to save the memory when it is not needed. But this caused other problems with the amd_kfd module, when they got loaded in the wrong order. And the module is often loaded by distros anyway, as it successfully loads even when no AMD IOMMU is in the system. The reason for that was to have the symbols available for drivers which can optionally use AMD IOMMUv2 functionality. In fact I have already thought about making it built-in, just havn't done so yet. Regards, Joerg