public inbox for driver-core@lists.linux.dev
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Cc: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Scally" <djrscally@gmail.com>,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Aaro Koskinen" <aaro.koskinen@iki.fi>,
	"Janusz Krzysztofik" <jmkrzyszt@gmail.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Bartosz Golaszewski" <brgl@kernel.org>,
	driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Linux-OMAP <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v4 2/3] driver core: make software nodes available earlier
Date: Tue, 31 Mar 2026 16:28:37 +0200	[thread overview]
Message-ID: <a895905f-069b-4fc5-bbf0-34c3978b3f39@app.fastmail.com> (raw)
In-Reply-To: <acuraLhLVgyP-LUK@ashevche-desk.local>

On Tue, Mar 31, 2026, at 13:09, Andy Shevchenko wrote:
> On Tue, Mar 31, 2026 at 12:45:59PM +0200, Arnd Bergmann wrote:
>> On Tue, Mar 31, 2026, at 10:55, Andy Shevchenko wrote:
>>
>> My best guess is that __exit_call should just use
>> __attribute__((unused)) instead of __attribute__((used)) and
>> have the compiler drop it from built-in code instead of the linker:
>
> But why do we need that at all? Can we just drop the full section for good.
> Or i.o.w. where exactly is it being used in the current kernel?

The main use case I see for __exit_call is for device drivers
that can be either loadable modules or built-in: In a loadable module,
you need the cleanup function, but for built-in code you want
it to be dropped at build time.

For the few direct callers of __exitcall, the only explanation I have
is that these could at some point be turned into loadable modules,
and the author wanted to be prepared for changing it later. In theory
we could change those to module_exit(), or just remove them, but
there is little practical benefit either way.

I've tested the __maybe_unused change on randconfig builds now and
found no (build-time) issues with that, so I'm submitting that
now.

     Arnd

  reply	other threads:[~2026-03-31 14:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 12:40 [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770 Bartosz Golaszewski
2026-03-30 12:40 ` [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier Bartosz Golaszewski
2026-03-30 13:47   ` Danilo Krummrich
2026-03-30 14:19     ` Bartosz Golaszewski
2026-03-30 14:34       ` Danilo Krummrich
2026-03-30 12:40 ` [PATCH v4 2/3] driver core: make software nodes available earlier Bartosz Golaszewski
2026-03-30 20:24   ` Andy Shevchenko
2026-03-30 21:46     ` Dmitry Torokhov
2026-03-31  6:25       ` Andy Shevchenko
2026-03-31  6:52         ` Dmitry Torokhov
2026-03-31  8:55           ` Andy Shevchenko
2026-03-31  8:58             ` Bartosz Golaszewski
2026-03-31 10:45             ` Arnd Bergmann
2026-03-31 11:09               ` Andy Shevchenko
2026-03-31 14:28                 ` Arnd Bergmann [this message]
2026-03-30 12:40 ` [PATCH v4 3/3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770 Bartosz Golaszewski
2026-03-30 13:37 ` [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for " Danilo Krummrich
2026-03-30 13:52   ` Bartosz Golaszewski
2026-03-30 14:08     ` Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a895905f-069b-4fc5-bbf0-34c3978b3f39@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=aaro.koskinen@iki.fi \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=brgl@kernel.org \
    --cc=dakr@kernel.org \
    --cc=djrscally@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=jmkrzyszt@gmail.com \
    --cc=khilman@baylibre.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox