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 8D965C4332F for ; Wed, 8 Nov 2023 18:48:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2VQoJQGiz1/+jwr0vLR/9yaRbXC7WAAEd0TFLl3jMfQ=; b=C0iifh38uLz94/ EZqfbju950VpmTVBNUf/Z1n/MgLQlhHPkdBbjk5M8OwqczNDOLG3NQqd4PdM5ICfKd3WgE2YmvuRU 7s5FR62dUjLa4E+136cF0cfqaDd8V0sLYzye8uGxd18YFHLDuN7uBYWkY0QAQIu9tkDTP/JZSANU6 17XTUd1C7Q01LJWXKEkRmBG8OdA2HZLSe4wi6aDtI9b7LijgX2RNlZy5ODkHOPLu26kF8HaQ3i5Y4 At0ud6dH1qaip1aE+Xgmwf6JccygmrWvRUEsQpqNIZPrls9cW6y90i9tbHpvk0XMpNYf+axAoGxPR Kk9TSvK97xFg8MSr4LqA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r0nb4-004WqT-2r; Wed, 08 Nov 2023 18:48:14 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r0nb1-004WpF-3D for linux-arm-kernel@lists.infradead.org; Wed, 08 Nov 2023 18:48:13 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 1A551B81CC3; Wed, 8 Nov 2023 18:48:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62616C433C8; Wed, 8 Nov 2023 18:48:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699469288; bh=81EVNP5jYzEQtba8wvig6dhqM3BiAejSQ1+IAtE2Cy0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oR5spj4/mzTsax2cizNb4PqVv2BA53LvE0Gf1y1iGkeQ6H30hvYff8V9yW1bnYHGI Ej8zR3sdrF7F1h/yZs9CVNYqk+EaZL0souD37Vgk6Fx1/SQ+iwHUYhpHMUU1M5oGBV 1F2prjsRStreMVUzIp4jd9VJOSBj7MdWODX6l64oul5aAJ+gtzvKhI8XYli+wIi/FL EGHSGQY5pkqsHgl0V7zlePs585QEqbvNem/uv5UYnUGVVTrRWZJrpuGQEK8BsqgV3M 2u+zvgl6L/1eenZ/VXWPy6wBXG9Fr9HQjHMXEHxwPFzv+g9sO12Bwx12qbWnlXlFss ueNNI5VL/gjfA== Date: Wed, 8 Nov 2023 11:48:05 -0700 From: Nathan Chancellor To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Subject: Re: [PATCH 02/22] fb: atmel_lcdfb: Stop using platform_driver_probe() Message-ID: <20231108184805.GA1579138@dev-arch.thelio-3990X> References: <20231107091740.3924258-1-u.kleine-koenig@pengutronix.de> <20231107091740.3924258-3-u.kleine-koenig@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231107091740.3924258-3-u.kleine-koenig@pengutronix.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231108_104812_328169_C5E27DD1 X-CRM114-Status: GOOD ( 31.21 ) 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: , Cc: linux-fbdev@vger.kernel.org, Alexandre Belloni , Helge Deller , llvm@lists.linux.dev, dri-devel@lists.freedesktop.org, Claudiu Beznea , kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 07, 2023 at 10:17:43AM +0100, Uwe Kleine-K=F6nig wrote: > On today's platforms the benefit of platform_driver_probe() isn't that > relevant any more. It allows to drop some code after booting (or module > loading) for .probe() and discard the .remove() function completely if > the driver is built-in. This typically saves a few 100k. > = > The downside of platform_driver_probe() is that the driver cannot be > bound and unbound at runtime which is ancient and also slightly > complicates testing. There are also thoughts to deprecate > platform_driver_probe() because it adds some complexity in the driver > core for little gain. Also many drivers don't use it correctly. This > driver for example misses to mark the driver struct with __refdata which > is needed to suppress a (W=3D1) modpost warning: > = > WARNING: modpost: drivers/video/fbdev/atmel_lcdfb: section mismatch in r= eference: atmel_lcdfb_driver+0x4 (section: .data) -> atmel_lcdfb_remove (se= ction: .exit.text) > = > Signed-off-by: Uwe Kleine-K=F6nig > --- > drivers/video/fbdev/atmel_lcdfb.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > = > diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atme= l_lcdfb.c > index a908db233409..b218731ef732 100644 > --- a/drivers/video/fbdev/atmel_lcdfb.c > +++ b/drivers/video/fbdev/atmel_lcdfb.c > @@ -1017,7 +1017,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_i= nfo *sinfo) > return ret; > } > = > -static int __init atmel_lcdfb_probe(struct platform_device *pdev) > +static int atmel_lcdfb_probe(struct platform_device *pdev) > { > struct device *dev =3D &pdev->dev; > struct fb_info *info; > @@ -1223,7 +1223,7 @@ static int __init atmel_lcdfb_probe(struct platform= _device *pdev) > return ret; > } > = > -static int __exit atmel_lcdfb_remove(struct platform_device *pdev) > +static int atmel_lcdfb_remove(struct platform_device *pdev) > { > struct device *dev =3D &pdev->dev; > struct fb_info *info =3D dev_get_drvdata(dev); > @@ -1301,7 +1301,8 @@ static int atmel_lcdfb_resume(struct platform_devic= e *pdev) > #endif > = > static struct platform_driver atmel_lcdfb_driver =3D { > - .remove =3D __exit_p(atmel_lcdfb_remove), > + .probe =3D atmel_lcdfb_probe, > + .remove =3D atmel_lcdfb_remove, > .suspend =3D atmel_lcdfb_suspend, > .resume =3D atmel_lcdfb_resume, > .driver =3D { > @@ -1310,7 +1311,7 @@ static struct platform_driver atmel_lcdfb_driver = =3D { > }, > }; > = > -module_platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe); > +module_platform_driver(atmel_lcdfb_driver, ); > = > MODULE_DESCRIPTION("AT91 LCD Controller framebuffer driver"); > MODULE_AUTHOR("Nicolas Ferre "); > -- = > 2.42.0 > = For what it's worth, this introduces a warning when building certain configurations (such as ARCH=3Darm multi_v5_defconfig) with clang: WARNING: modpost: vmlinux: section mismatch in reference: atmel_lcdfb_pro= be+0x6c4 (section: .text) -> atmel_lcdfb_init_fbinfo (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: atmel_lcdfb_pro= be+0x858 (section: .text) -> atmel_lcdfb_fix (section: .init.rodata) This appears to be legitimate to me? GCC did not warn but I assume that is due to differences in inlining. The following clears it up for me, should I send a standalone patch or should this be squashed in? Cheers, Nathan diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_= lcdfb.c index 88c75ae7d315..9e391e5eaf9d 100644 --- a/drivers/video/fbdev/atmel_lcdfb.c +++ b/drivers/video/fbdev/atmel_lcdfb.c @@ -220,7 +220,7 @@ static inline void atmel_lcdfb_power_control(struct atm= el_lcdfb_info *sinfo, int } } = -static const struct fb_fix_screeninfo atmel_lcdfb_fix __initconst =3D { +static const struct fb_fix_screeninfo atmel_lcdfb_fix =3D { .type =3D FB_TYPE_PACKED_PIXELS, .visual =3D FB_VISUAL_TRUECOLOR, .xpanstep =3D 0, @@ -841,7 +841,7 @@ static void atmel_lcdfb_task(struct work_struct *work) atmel_lcdfb_reset(sinfo); } = -static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo) +static int atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo) { struct fb_info *info =3D sinfo->info; int ret =3D 0; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel