From: "Arnd Bergmann" <arnd@arndb.de>
To: "Geert Uytterhoeven" <geert@linux-m68k.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@oss.qualcomm.com>
Cc: "Andi Shyti" <andi.shyti@kernel.org>,
"Ray Jui" <rjui@broadcom.com>,
"Scott Branden" <sbranden@broadcom.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
llvm@lists.linux.dev
Subject: Re: [PATCH 3/3] i2c: rcar: Fix Wvoid-pointer-to-enum-cast warning
Date: Fri, 28 Nov 2025 09:32:34 +0100 [thread overview]
Message-ID: <8ee7495b-4b6f-4ee8-82e0-a236d0be5c32@app.fastmail.com> (raw)
In-Reply-To: <CAMuHMdUF9nTRkOOi+KnH2ATsFdTWMCtohWZQ1T_vhB=cf_42Yg@mail.gmail.com>
On Thu, Nov 27, 2025, at 14:46, Geert Uytterhoeven wrote:
> On Thu, 27 Nov 2025 at 14:42, Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> wrote:
>>
>> >> kernel_ulong_t, I think.
>> >
>> > include/linux/mod_devicetable.h:typedef unsigned long kernel_ulong_t;
>> >
>> > IIRC, it was introduced originally because "unsigned long" might have
>> > a different size in userspace. Nowadays (for x32), uapi uses
>> > __kernel_ulong_t, though.
>>
>> Maybe, but if you look at the data structures all have kernel_ulong_t,
>> so this fits the logic I was following here - I cast to the type which
>> is both representing pointer and is already used for driver data,
>> because this match data serves similar purpose as mentioned driver data.
It is rather inconsistent: The __kernel_ulong_t type is used in
include/uapi/ in places where x32 uses the 64-bit ABI, as the idea
was to not have to do (much) type conversion there. This of course
failed overall because any ioctl still has to be converted.
The kernel_ulong_t as far as I can tell was only meant to be
used in include/linux/mod_devicetable.h, with the idea of being
able to interpret 64-bit kernel modules from a 32-bit module
loader in userspace. I don't think the latest kmod actually uses
it that way any more.
>> I don't mind casting via unsigned long, but:
>> 1. these are old and trivial issues,
>> 2. they are quite annoying when people want to compile test with W=1,
>> 3. I was trying to fix them (although not sure if for I2C) already,
>> 4. and some others probably as well were trying to fix them,
>> so how many people need to send them and debate before we fix them finally?
>>
>> unsigned long vs kernel_ulong_t is a nit-style discussion IMO, unless we
>> have here more concrete arguments, e.g. statement from Linus that
>> kernel_ulong_t is wrong.
>>
>> If maintainers of this code want unsigned long, please apply the patch
>> and fix directly, but for the sake, let's get it merged...
>
> Sure, let's get it fixed!
Agreed. I don't mind the use of kernel_ulong_t here either, since it's
adjacent to the module device table entries, but I would also pick
'unsigned long' or 'uintptr_t' instead.
Arnd
next prev parent reply other threads:[~2025-11-28 8:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 18:22 [PATCH 1/3] i2c: bcm-iproc: Fix Wvoid-pointer-to-enum-cast warning Krzysztof Kozlowski
2025-11-26 18:22 ` [PATCH 2/3] i2c: pxa: " Krzysztof Kozlowski
2025-11-26 18:23 ` [PATCH 3/3] i2c: rcar: " Krzysztof Kozlowski
2025-11-27 9:02 ` Geert Uytterhoeven
2025-11-27 11:42 ` Krzysztof Kozlowski
2025-11-27 11:48 ` Krzysztof Kozlowski
2025-11-27 12:52 ` Geert Uytterhoeven
2025-11-27 13:42 ` Krzysztof Kozlowski
2025-11-27 13:46 ` Geert Uytterhoeven
2025-11-28 8:32 ` Arnd Bergmann [this message]
2025-12-03 17:38 ` [PATCH 1/3] i2c: bcm-iproc: " Andi Shyti
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=8ee7495b-4b6f-4ee8-82e0-a236d0be5c32@app.fastmail.com \
--to=arnd@arndb.de \
--cc=andi.shyti@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=justinstitt@google.com \
--cc=krzysztof.kozlowski@oss.qualcomm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=magnus.damm@gmail.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=rjui@broadcom.com \
--cc=sbranden@broadcom.com \
--cc=wsa+renesas@sang-engineering.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