From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="bf5Nk4oJ" Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9ABC11F; Wed, 22 Nov 2023 15:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1700695422; x=1732231422; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=wLu90c2ONU3nwRPuECsbNVwdI6Y/3s1bCFsGjUjQWds=; b=bf5Nk4oJ25NpqPjcgoH0qyyZwaybM8J+HOuiEmIO+HYRtQc7HJtYqal7 Xs6igblHASFh/Y92xTaxgbiG4V3iH0btRpQW8ZIkVrC5Fijb+x6nfUubX kmDfCySXX0xtVXGnB2zosltPyG8fEZmZdgr0egi+j+szfzdU1V1u19SnK B0K0ta1uZwmDnPK+ye3IU6hZVH4wdaN/LF8wPNHFd0jtn1LdujloI3HCd 3x5oYtSHQvxUN/dL2QoZVyznAo+5s2Y0cnuuL4oPJt15WKo60XkD73Osx jBZj8XLvkvmJAw82wWq7HTfR3tshGqVD80KOiVry0/Kpqyp39vNQYt9So Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10902"; a="391935051" X-IronPort-AV: E=Sophos;i="6.04,219,1695711600"; d="scan'208";a="391935051" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2023 15:23:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10902"; a="760507612" X-IronPort-AV: E=Sophos;i="6.04,219,1695711600"; d="scan'208";a="760507612" Received: from amongesa-mobl.ger.corp.intel.com (HELO intel.com) ([10.252.57.132]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2023 15:23:31 -0800 Date: Thu, 23 Nov 2023 00:23:28 +0100 From: Andi Shyti To: Uwe =?iso-8859-15?Q?Kleine-K=F6nig?= Cc: Greg Kroah-Hartman , Jiri Slaby , Joel Stanley , Andrew Jeffery , Florian Fainelli , Broadcom internal kernel review list , Ray Jui , Scott Branden , Al Cooper , Ilpo =?iso-8859-15?Q?J=E4rvinen?= , Andy Shevchenko , Paul Cercueil , Vladimir Zapolskiy , Matthias Brugger , AngeloGioacchino Del Regno , Thierry Reding , Jonathan Hunter , Kunihiko Hayashi , Masami Hiramatsu , John Ogness , Thomas Gleixner , Tony Lindgren , Petr Mladek , Biju Das , Johan Hovold , Chen-Yu Tsai , Andi Shyti , Thomas Richard , Rob Herring , Geert Uytterhoeven , Arnd Bergmann , Duje =?utf-8?Q?Mihanovi=C4=87?= , "Rafael J. Wysocki" , Jacob Keller , Christophe JAILLET , kernel@pengutronix.de, linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-rpi-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH 03/52] serial: 8250: Convert to platform remove callback returning void Message-ID: References: <20231110152927.70601-1-u.kleine-koenig@pengutronix.de> <20231110152927.70601-4-u.kleine-koenig@pengutronix.de> Precedence: bulk X-Mailing-List: linux-tegra@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231110152927.70601-4-u.kleine-koenig@pengutronix.de> Hi Uwe, On Fri, Nov 10, 2023 at 04:29:31PM +0100, Uwe Kleine-König wrote: > The .remove() callback for a platform driver returns an int which makes > many driver authors wrongly assume it's possible to do error handling by > returning an error code. However the value returned is ignored (apart > from emitting a warning) and this typically results in resource leaks. > > To improve here there is a quest to make the remove callback return > void. In the first step of this quest all drivers are converted to > .remove_new(), which already returns void. Eventually after all drivers > are converted, .remove_new() will be renamed to .remove(). > > Trivially convert this driver from always returning zero in the remove > callback to the void returning variant. > > Signed-off-by: Uwe Kleine-König Reviewed-by: Andi Shyti Thanks, Andi