From patchwork Tue Mar 21 08:41:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= X-Patchwork-Id: 13182386 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2626C74A5B for ; Tue, 21 Mar 2023 08:43:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230008AbjCUInc (ORCPT ); Tue, 21 Mar 2023 04:43:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230070AbjCUIna (ORCPT ); Tue, 21 Mar 2023 04:43:30 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 468F71A4BF for ; Tue, 21 Mar 2023 01:42:54 -0700 (PDT) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1peXYi-0001Qt-Cv; Tue, 21 Mar 2023 09:41:32 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtp (Exim 4.94.2) (envelope-from ) id 1peXYd-005e8w-Jl; Tue, 21 Mar 2023 09:41:27 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.94.2) (envelope-from ) id 1peXYc-006hGE-Ph; Tue, 21 Mar 2023 09:41:26 +0100 From: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= To: Will Deacon , Joerg Roedel , Lu Baolu , Vladimir Oltean , Sai Prakash Ranjan , Jon Nettleton , Hector Martin , Sven Peter , Jason Gunthorpe , Shameer Kolothum , Yicong Yang , Nicolin Chen , Rob Clark , Andy Gross , Bjorn Andersson , Yong Wu , Matthias Brugger , Orson Zhai , Baolin Wang , Chunyan Zhang Cc: Robin Murphy , linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, kernel@pengutronix.de, Alyssa Rosenzweig , asahi@lists.linux.dev, linux-arm-msm@vger.kernel.org, Konrad Dybcio , AngeloGioacchino Del Regno , linux-mediatek@lists.infradead.org Subject: [PATCH 00/10] iommu: Convert to platform remove callback returning void Date: Tue, 21 Mar 2023 09:41:15 +0100 Message-Id: <20230321084125.337021-1-u.kleine-koenig@pengutronix.de> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2617; i=u.kleine-koenig@pengutronix.de; h=from:subject; bh=rdSh4Xeg6tHQ79VpKnn+68R53WjFDJ2aA4WrZ0yXy7Y=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBkGW2krstvUjjQL/q4EkmqkS0b+KWpRPx1JGlde 3eOjPfzWzKJATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCZBltpAAKCRCPgPtYfRL+ ToMUCACnQcRCXUTbwMElh8PDqFXVRLM9/fPmIh/eTNNZeW37hXTU+p85ntqq8ViojhXklq/A4S2 +6ojPGlqDz/ToIwc70XC6nSNJBiKE+QLXIBFEA+9UPpU6uDsP4TfinB/cdeV5MYQueWfWaHCj15 876m8UHC1y7+2JRIT6yta0v2yE3U8JBvqgHNH688UOQDimcPCRUmE/zD+B3GGIbuynQaGfwcNDY 9B2eHrCHXzPILMBtPe0sSnAxEyXi8GSXnEaPwCcEsqweFtYvrTbEcGmuTqjN8V6pRq1Opg0mQMj jmwVUZwveCV7qKMw4dVOAs7fsRN6HS89wm4ryoWjk/PKprPH X-Developer-Key: i=u.kleine-koenig@pengutronix.de; a=openpgp; fpr=0D2511F322BFAB1C1580266BE2DCDD9132669BD6 X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-msm@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hello, this series adapts the platform drivers below drivers/iommu to use the .remove_new() callback. Compared to the traditional .remove() callback .remove_new() returns no value. This is a good thing because the driver core doesn't (and cannot) cope for errors during remove. The only effect of a non-zero return value in .remove() is that the driver core emits a warning. The device is removed anyhow and an early return from .remove() usually yields a resource leak. By changing the remove callback to return void driver authors cannot reasonably assume any more that there is some kind of cleanup later. After the first patch all drivers return zero unconditionally in their .remove() callback, then the remaining patches convert to .remove_new() without side effects. There is only a single interdependency (namely patch #4 depends on #1). If there are concerns for individual patches[1], please still apply the others. Then I'd only care for the actual change requests and don't need to resend the other unchanged patches at a later point in time. Thanks Uwe [1] I don't expect something more tragic than "You picked the wrong subject prefix" or similar. Uwe Kleine-König (10): iommu/arm-smmu: Drop if with an always false condition iommu/apple-dart: Convert to platform remove callback returning void iommu/arm-smmu-v3: Convert to platform remove callback returning void iommu/arm-smmu: Convert to platform remove callback returning void iommu/ipmmu-vmsa: Convert to platform remove callback returning void iommu/msm: Convert to platform remove callback returning void iommu/mtk: Convert to platform remove callback returning void iommu/mtk_iommu_v1: Convert to platform remove callback returning void iommu/omap: Convert to platform remove callback returning void iommu/sprd: Convert to platform remove callback returning void drivers/iommu/apple-dart.c | 6 ++---- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 ++---- drivers/iommu/arm/arm-smmu/arm-smmu.c | 12 ++---------- drivers/iommu/arm/arm-smmu/qcom_iommu.c | 12 ++++-------- drivers/iommu/ipmmu-vmsa.c | 6 ++---- drivers/iommu/msm_iommu.c | 5 ++--- drivers/iommu/mtk_iommu.c | 5 ++--- drivers/iommu/mtk_iommu_v1.c | 5 ++--- drivers/iommu/omap-iommu.c | 5 ++--- drivers/iommu/sprd-iommu.c | 6 ++---- 10 files changed, 22 insertions(+), 46 deletions(-) base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6