Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2742936pxb; Mon, 31 Jan 2022 03:24:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNnszHXaJkY4ppq/yI8iI66v9yZDIZf8Jzs2tKCz+UUwPZU4SD284FuOF2uqr2jECGPymt X-Received: by 2002:a17:902:bf02:: with SMTP id bi2mr20384716plb.139.1643628257888; Mon, 31 Jan 2022 03:24:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643628257; cv=none; d=google.com; s=arc-20160816; b=vNSSN4YS05nlb6Ky56B7MjBZVz62lw1fN/eP6iwyvhpUT6KWeuij3E0oTGztuM6fxg S7Os04iQzOH5NcSRGlZag5mpxFIOPAfTF65L4DgeC/NDaCjXQui6seXcg68adFrClKng wDCzG0ouBsCMhaT2iPwTfkzE+KITZ3jKaTx4+SOCwhZENRrAvCkumS+ZTDKHN50waBjj U1AQh93eQw9eukP6xUiMiJqXYRajIHS5vHgUNGSM+dMV16DxZ4QEs+8ubpXxNEWISgUk bW7gpJPIW9Ts4N2XgUNKKrrKgQGoZGkKNzuWEHdflistgR4l0KsmQHrYL3OHS4y23p/r 3VGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=N7lJSE7BiZSWYVPO93vOi5RKNGbcMvU1Q/8GP6EjOMk=; b=Rj51b2mrgdPFtpOW3lChVEv5BK/QxWHhnV10GBiRRrbU56E6K3qxNQTw4Shw7DwGZQ aZDV9NIaVaQKw/V95iEyYZ9KzekjDpMWstv1WIZQnow/Q+Y27pj5M215w2xD2H1fDzQZ 4A2rk724JO9n/JJYyOY+BFZYZBAHLLrdZJrrRPpICdvmwKqUjqu3jL595OAGrQ4ClpNA 0MvGGMqB58v62HNlEdj5mvXOVbuimKcROjxKzyUqgt/vXaTmAuTO94Xj5eKJX11H1YFN QvH0thRsGP1M7JpDD2wXt3JPZrZgOBrGPvYMfQlcSV1DOpBsLQsvY6mV3qrICKldUCUi 8GEQ== 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=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y143si12428863pfb.63.2022.01.31.03.24.06; Mon, 31 Jan 2022 03:24:17 -0800 (PST) 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=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350348AbiA1QyN (ORCPT + 99 others); Fri, 28 Jan 2022 11:54:13 -0500 Received: from foss.arm.com ([217.140.110.172]:53998 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245711AbiA1QyL (ORCPT ); Fri, 28 Jan 2022 11:54:11 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 610E0113E; Fri, 28 Jan 2022 08:54:11 -0800 (PST) Received: from [10.57.68.47] (unknown [10.57.68.47]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 934F93F793; Fri, 28 Jan 2022 08:54:09 -0800 (PST) Message-ID: Date: Fri, 28 Jan 2022 16:54:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] iommu/iova: Separate out rcache init Content-Language: en-GB To: John Garry , "joro@8bytes.org" , "will@kernel.org" , "mst@redhat.com" , "jasowang@redhat.com" Cc: "xieyongji@bytedance.com" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , Linuxarm References: <1643205319-51669-1-git-send-email-john.garry@huawei.com> <5ac3a678-3126-edd9-cb23-72c05f3dcd34@huawei.com> From: Robin Murphy In-Reply-To: <5ac3a678-3126-edd9-cb23-72c05f3dcd34@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-01-28 11:32, John Garry wrote: > On 26/01/2022 17:00, Robin Murphy wrote: >> As above, I vote for just forward-declaring the free routine in iova.c >> and keeping it entirely private. > > BTW, speaking of forward declarations, it's possible to remove all the > forward declarations in iova.c now that the FQ code is gone - but with a > good bit of rearranging. However I am not sure how much people care > about that or whether the code layout is sane... Indeed, I was very tempted to raise the question there of whether there was any more cleanup or refactoring that could be done to justify collecting all the rcache code together at the top of iova.c. But in the end I didn't, so my opinion still remains a secret... Robin.