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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFE5CC76188 for ; Mon, 3 Apr 2023 19:50:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232537AbjDCTuu (ORCPT ); Mon, 3 Apr 2023 15:50:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232573AbjDCTus (ORCPT ); Mon, 3 Apr 2023 15:50:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC66B30FC; Mon, 3 Apr 2023 12:50:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3B6E66292E; Mon, 3 Apr 2023 19:50:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B83EEC4339B; Mon, 3 Apr 2023 19:50:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1680551445; bh=lOZoZur0dlMwg23s/E6ookGvEsUZzxEjsaf7n78uxD0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nEBMvaSDo6Kx3uTTuk0gcIjpmL+QxmtvplsE3iV+Yad8oVUuYckRsG32R0nXIl7RF df7SulQgWa+RfGcINl7HL+vcKeBJS6LuhRgnjoJDfbS2hMh3ZIjZ5Daw8Yc0FSZbkY koEdBw32GguOTg412wDd6ymUfsqZp5iBNOEaSJDk= Date: Mon, 3 Apr 2023 21:50:42 +0200 From: Greg Kroah-Hartman To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: Deepak R Varma , Yuan Can , Simon Horman , Sven Van Asbroeck , Vaibhav Hiremath , Johan Hovold , Alex Elder , Eugen Hristev , Mauro Carvalho Chehab , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Steve Longerbeam , Philipp Zabel , Shawn Guo , Sascha Hauer , Neil Armstrong , Kevin Hilman , Laurent Pinchart , Ezequiel Garcia , Maxime Ripard , Paul Kocialkowski , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Parthiban Veerasooran , Christian Gromm , Davidlohr Bueso , Marc Dietrich , Florian Fainelli , Ray Jui , Scott Branden , Umang Jain , Andy Shevchenko , Adrien Thierry , Stefan Wahren , "Fabio M. De Francesco" , Phil Elwell , Jakob Koschel , linux-staging@lists.linux.dev, kernel@pengutronix.de, greybus-dev@lists.linaro.org, linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Fabio Estevam , NXP Linux Team , Jerome Brunet , Martin Blumenstingl , linux-amlogic@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev, ac100@lists.launchpad.net, linux-tegra@vger.kernel.org, Broadcom internal kernel review list , linux-rpi-kernel@lists.infradead.org Subject: Re: [PATCH 00/24] staging: Convert to platform remove callback returning void Message-ID: <2023040305-drudge-scorer-b59c@gregkh> References: <20230403154014.2564054-1-u.kleine-koenig@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230403154014.2564054-1-u.kleine-koenig@pengutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Mon, Apr 03, 2023 at 05:39:50PM +0200, Uwe Kleine-König wrote: > Hello, > > this series adapts the platform drivers below drivers/staging 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 staging already return zero in their remove callback, so > they can be trivially converted. > > The changes to the individual drivers are all orthogonal. If I need to > resend some patches because of some review feedback, I'd like to only > send the patches that actually needed changes, so please pick up the > remaining patches that don't need changing to reduce the amount of mail. Note, I can't take drivers/staging/media/ patches, those go through the v4l maintainer's tree. So I've taken the non-media patches from this series now. thanks, greg k-h