From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A3511C30658 for ; Tue, 2 Jul 2024 12:24:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=A9p0IBSx10wbSH/pTw4L9Ow6Omy2bHh4fJZpZWCaJGU=; b=DwkZwkOuik9izB3AFF4NdkqoFq tZhFmpacXlr2LcaTLtEhcwHLDmFxt8KczbIqcrJWwaaE2sWkRPFIJ6ZrZT89R1Nc0XKXE+bZgXjls iHSzf/yLnhm2idFDrml3MM/78z9PIoRYq7XW+klGNtWdyNCa/xCGwJTxvxQmqL0ufs9HZoqoGtYlu hVSPKrVEMvBAGY0ISFSVPwcjsSzFDpdAAXwOkm83WEa51MCruAe9WATHTAHmIUEaFhoVZE1Tb+cs8 xV38ZQtUSGz51lUquQGS4sPiQ9rlvfIND+4ytQC/l8TO9wisnQhiEU3YcgTxMJ2Oqd0OXnusqHdn0 7CwIBnMA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sOcYV-00000006f2C-482o; Tue, 02 Jul 2024 12:24:19 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sOcYG-00000006ewI-3tGN for linux-arm-kernel@lists.infradead.org; Tue, 02 Jul 2024 12:24:08 +0000 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 EBA4A339; Tue, 2 Jul 2024 05:24:28 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE07A3F762; Tue, 2 Jul 2024 05:24:01 -0700 (PDT) Message-ID: Date: Tue, 2 Jul 2024 13:23:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/4] iommu: Remove iommu_fwspec ops To: Saravana Kannan Cc: Will Deacon , Joerg Roedel , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, devicetree@vger.kernel.org, Rob Herring , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , Jean-Philippe Brucker , Andy Shevchenko References: From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240702_052405_031642_C18894FF X-CRM114-Status: GOOD ( 18.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 21/06/2024 9:51 pm, Saravana Kannan wrote: > On Fri, Jun 21, 2024 at 8:46 PM Robin Murphy wrote: >> >> v1: https://lore.kernel.org/linux-iommu/cover.1713523251.git.robin.murphy@arm.com >> >> Hi all, >> >> Here's v2 of this little cleanup, with acks and the additional cosmetic >> tweak suggested by Andy. There were some slightly non-trivial changes in >> the rebase so I've left off Jean-Philippe's tested-by from v1, but I've >> given it a quick spin on arm64 ACPI and DT and all seems well still. > > Hi Robin, > > I see in this series you talk about figuring out if a device has a > driver that could match. There has been a "can_match" flag in every > device that's set if a driver that match it is present, but hasn't > probed the device yet (for whatever reason). Just pointing that out in > case that makes things a lot easier for you. As of now, we don't > handle clearing it when the driver is unregistered, but if that really > needs to be handled, that shouldn't be too difficult. Thanks, that's interesting to know. I'm not sure it's directly applicable here since we have the more general case where the IOMMU driver may also be a module that's not even loaded yet. What ultimately matters is whether someone has called iommu_device_register() for a matching IOMMU instance, or may do within a reasonable timeframe, so as long as we can keep relying on fw_devlink and deferred_probe_timeout to do most of the heavy lifting then I'd actually hope we can avoid getting into the low-level details here. Cheers, Robin.