[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <3f1c2d5a-ba98-4ae5-a7a0-0328b7552113@app.fastmail.com>
Date: Wed, 14 Feb 2024 16:07:00 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Arend van Spriel" <arend.vanspriel@...adcom.com>,
"Kalle Valo" <kvalo@...nel.org>, "Arnd Bergmann" <arnd@...nel.org>
Cc: "Nathan Chancellor" <nathan@...nel.org>,
"Greg Kroah-Hartman" <gregkh@...e.de>,
"Pieter-Paul Giesberts" <pieterpg@...adcom.com>,
"Nick Desaulniers" <ndesaulniers@...gle.com>,
"Bill Wendling" <morbo@...gle.com>, "Justin Stitt" <justinstitt@...gle.com>,
"Artem Chernyshev" <artem.chernyshev@...-soft.ru>,
"Jonas Gorski" <jonas.gorski@...il.com>, linux-wireless@...r.kernel.org,
brcm80211@...ts.linux.dev, brcm80211-dev-list.pdl@...adcom.com,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] brcmsmac: avoid function pointer casts
On Wed, Feb 14, 2024, at 10:23, Arend van Spriel wrote:
> On 2/14/2024 9:45 AM, Kalle Valo wrote:
>> Arnd Bergmann <arnd@...nel.org> wrote:
>>
>>> From: Arnd Bergmann <arnd@...db.de>
>>>
>>> An old cleanup went a little too far and causes a warning with clang-16
>>> and higher as it breaks control flow integrity (KCFI) rules:
>>>
>>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c:64:34: error: cast from 'void (*)(struct brcms_phy *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
>>> 64 | brcms_init_timer(physhim->wl, (void (*)(void *))fn,
>>> | ^~~~~~~~~~~~~~~~~~~~
>>>
>>> Change this one instance back to passing a void pointer so it can be
>>> used with the timer callback interface.
>>>
>>> Fixes: d89a4c80601d ("staging: brcm80211: removed void * from softmac phy")
>>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>>
>> I guess this should go to wireless tree?
>
> This has been like this forever looking at the "staging" part in the
> Fixes tag. Is it really so urgent now? On the other hand I have no real
> problem with moving this to the wireless tree. Just wondering out loud.
It's probably fine either way. Some maintainers like to backport
the warning fixes to stable kernels, others don't. Since the
warning is currently only enabled at W=1 level, it's probably fine
to fix it for linux-next only, but if we want the fix backported,
it should also go into 6.8.
Arnd
Powered by blists - more mailing lists