From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E18F4E4D6 for ; Mon, 20 Mar 2023 11:38:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 714C1C433EF; Mon, 20 Mar 2023 11:38:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679312311; bh=YfQJfApGvnHfGU8gi0gNukjaGzsg84xu5lWbeqt0lnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Eb0R3e1JjZqoZgzBIBGjddsyzF5oRvdKqX4zJzfcsM0/DnTdJPwvylLD+N+LKBRzx IUP4xObd68HKq8F/Qvpt1W8+ib5Odyumu8IK77yOV7UrOlBps49shv9e9/SC/xo2kz m0aAW+ll4AWGsB8I2maII0LRP6fC/xl2FJLRDWSewz86h49su8evjRUcjYOvGhEqEP OqxjJPCWzSjGCbGJ72Q91R07MKL6mi3EU3EI8GH5XvBh3WyMEz82QnPL2OuhZKfQhY kOBto01PJnNfY6OWt0wG8oiBvRdeyp56uvftv10KL3GXZXlc50hUNdkT6jkk/wjKoa ZZVIoO4TNk3KQ== Date: Mon, 20 Mar 2023 17:08:27 +0530 From: Vinod Koul To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: Kishon Vijay Abraham I , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Andre Przywara , Wolfram Sang , Icenowy Zheng , Justin Chen , Al Cooper , Pratyush Yadav , Rahul T R , Swapnil Jakhade , Lars-Peter Clausen , Shawn Guo , Sascha Hauer , Liu Ying , Yuan Can , Chun-Kuang Hu , Philipp Zabel , Chunfeng Yun , Matthias Brugger , Thomas Gleixner , Allison Randal , Greg Kroah-Hartman , Miaoqian Lin , Andy Gross , Bjorn Andersson , Yoshihiro Shimoda , Heiko Stuebner , Maxime Coquelin , Alexandre Torgue , Amelie Delaunay , Dan Carpenter , Fabrice Gasnier , JC Kuo , Thierry Reding , Jonathan Hunter , Roger Quadros , Matt Ranostay , Sinthu Raja , Vignesh Raghavendra , Tanmay Patil , Siddharth Vadapalli , Lv Ruyi , linux-phy@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, kernel@pengutronix.de, Broadcom internal kernel review list , Fabio Estevam , NXP Linux Team , AngeloGioacchino Del Regno , dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org, Konrad Dybcio , linux-arm-msm@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-tegra@vger.kernel.org Subject: Re: [PATCH 00/31] phy: Convert to platform remove callback returning void Message-ID: References: <20230307115900.2293120-1-u.kleine-koenig@pengutronix.de> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230307115900.2293120-1-u.kleine-koenig@pengutronix.de> On 07-03-23, 12:58, Uwe Kleine-König wrote: > Hello, > > this patch series adapts the platform drivers below drivers/phy 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. > > All drivers in drivers/spmi returned zero unconditionally in their remove > callback, so they could all be converted trivially to .remove_new(). > > Note that this series depends on commit 5c5a7680e67b ("platform: Provide > a remove callback that returns no value") which is included in v6.3-rc1. Applied, thanks -- ~Vinod