[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250917160644.6f85ca40b1e352fa117dabf9@linux-foundation.org>
Date: Wed, 17 Sep 2025 16:06:44 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: <peterz@...radead.org>, <linux-kernel@...r.kernel.org>,
<linux-cxl@...r.kernel.org>, "Nathan Chancellor" <nathan@...nel.org>, Linus
Torvalds <torvalds@...ux-foundation.org>, Dave Jiang
<dave.jiang@...el.com>, "David Lechner" <dlechner@...libre.com>, Jonathan
Cameron <jonathan.cameron@...wei.com>, Andy Shevchenko
<andriy.shevchenko@...el.com>
Subject: Re: [PATCH v2] cleanup: Fix "unused function" warnings with
conditional guards
On Thu, 4 Sep 2025 15:50:10 -0700 Dan Williams <dan.j.williams@...el.com> wrote:
> While the warning could simply be moved to W=2 [1], there is some small
> value, and not much cost to fixing it.
>
> The issue, Andy reports that the "lock_timer" scheme in
> kernel/time/posix-timers.c, with its custom usage of
> DEFINE_CLASS_IS_COND_GUARD(), results in:
>
> kernel/time/posix-timers.c:89:1: error: unused function 'class_lock_timer_lock_err' [-Werror,-Wunused-function]
> 89 | DEFINE_CLASS_IS_COND_GUARD(lock_timer);
>
> ...with a clang W=1 build. This warning has some value because it can catch
> when a conditional guard is defined, but not evaluated by a conditional
> acquisition helper like scoped_cond_guard() or ACQUIRE().
>
> Andy also reports that plain DEFINE_GUARD() also encounters this warning:
>
> drivers/pwm/core.c:54:1: error: unused function 'class_pwmchip_lock_err' [-Werror,-Wunused-function]
> 54 | DEFINE_GUARD(pwmchip, struct pwm_chip *, pwmchip_lock(_T), pwmchip_unlock(_T))
>
> ...which *is* a false positive.
>
> Fix those 2 issues by teaching scoped_cond_guard() to check for error
> values, and otherwise teach the DEFINE_GUARD() path to mark the conditional
> helpers as __maybe_unused.
Warning about unused static inlines in .c files is just annoying. If
the function is unused in all possible configs (man GREP(1)) then OK.
Otherwise, let it be.
> Alternatively just merge the suggestion in [1], and call it a day.
>
> Link: http://lore.kernel.org/20250813152142.GP4067720@noisy.programming.kicks-ass.net [1]
lgtm, unless we think this (your) patch improves the code for other reasons?
Powered by blists - more mailing lists