rust/uapi/uapi_helper.h was directly including <uapi/asm-generic/ioctl.h>
instead of the proper <uapi/linux/ioctl.h>.

On powerpc, <uapi/linux/ioctl.h> pulls in <uapi/asm/ioctl.h> first, which
defines _IOC_SIZEBITS, _IOC_DIRBITS, _IOC_NONE, and _IOC_WRITE with the
arch-specific values, before falling through to <asm-generic/ioctl.h>.
By bypassing that chain and including <asm-generic/ioctl.h> directly,
the arch-specific overrides never ran first, so when other headers in
the compilation later brought in the full arch-aware chain, Clang saw
those four macros being defined a second time and emitted:

  uapi/asm-generic/ioctl.h: warning: '_IOC_SIZEBITS' macro redefined
  uapi/asm-generic/ioctl.h: warning: '_IOC_DIRBITS' macro redefined
  uapi/asm-generic/ioctl.h: warning: '_IOC_NONE' macro redefined
  uapi/asm-generic/ioctl.h: warning: '_IOC_WRITE' macro redefined

Fix this by replacing the direct include of <uapi/asm-generic/ioctl.h>
with <uapi/linux/ioctl.h>, which is the correct arch-aware entry point
and already maintains the intended include order.

Applies on linux-next.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608050618.9dekfjtF-lkp@intel.com/
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
---
 rust/uapi/uapi_helper.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/uapi/uapi_helper.h b/rust/uapi/uapi_helper.h
index 86c7b6b284b0..489748ef642c 100644
--- a/rust/uapi/uapi_helper.h
+++ b/rust/uapi/uapi_helper.h
@@ -6,12 +6,12 @@
  * Sorted alphabetically.
  */
 
-#include <uapi/asm-generic/ioctl.h>
 #include <uapi/drm/drm.h>
 #include <uapi/drm/nova_drm.h>
 #include <uapi/drm/panthor_drm.h>
 #include <uapi/linux/android/binder.h>
 #include <uapi/linux/android/binder_netlink.h>
+#include <uapi/linux/ioctl.h>
 #include <uapi/linux/mdio.h>
 #include <uapi/linux/mii.h>
 #include <uapi/linux/ethtool.h>
-- 
2.55.0

On Sat, Aug 8, 2026 at 5:22 AM Mukesh Kumar Chaurasiya (IBM)
<mkchauras@gmail.com> wrote:
>
>   uapi/asm-generic/ioctl.h: warning: '_IOC_SIZEBITS' macro redefined
>   uapi/asm-generic/ioctl.h: warning: '_IOC_DIRBITS' macro redefined
>   uapi/asm-generic/ioctl.h: warning: '_IOC_NONE' macro redefined
>   uapi/asm-generic/ioctl.h: warning: '_IOC_WRITE' macro redefined

Thanks for the patch! I can pick this one up.

I am wondering: the quoted warnings were shortened intentionally,
right? i.e. I saw longer paths when I reproduced this.

If so, then we could put the full ones (at least personally I prefer
that, even if it goes over the line length, because I want that it is
easy to search for, to avoid edit mistakes etc.)

> Applies on linux-next.

This would normally go below the `---` line, i.e. outside the commit
message (and ideally use `git format-patch --base` to provide the base
commit too).

Thanks!

Cheers,
Miguel

On Mon, Aug 10, 2026 at 05:29:02PM +0200, Miguel Ojeda wrote:
> On Sat, Aug 8, 2026 at 5:22 AM Mukesh Kumar Chaurasiya (IBM)
> <mkchauras@gmail.com> wrote:
> >
> >   uapi/asm-generic/ioctl.h: warning: '_IOC_SIZEBITS' macro redefined
> >   uapi/asm-generic/ioctl.h: warning: '_IOC_DIRBITS' macro redefined
> >   uapi/asm-generic/ioctl.h: warning: '_IOC_NONE' macro redefined
> >   uapi/asm-generic/ioctl.h: warning: '_IOC_WRITE' macro redefined
> 
> Thanks for the patch! I can pick this one up.
> 
> I am wondering: the quoted warnings were shortened intentionally,
> right? i.e. I saw longer paths when I reproduced this.
> 
> If so, then we could put the full ones (at least personally I prefer
> that, even if it goes over the line length, because I want that it is
> easy to search for, to avoid edit mistakes etc.)
> 
Yeah, I intertionally trimmed it.
I'll send out with the full path.

> > Applies on linux-next.
> 
> This would normally go below the `---` line, i.e. outside the commit
> message (and ideally use `git format-patch --base` to provide the base
> commit too).
> 
Sure, i'll fix this and send out a new revision.

Thanks,
Mukesh
> Thanks!
> 
> Cheers,
> Miguel

On Tue, Aug 11, 2026 at 8:04 AM Mukesh Kumar Chaurasiya
<mkchauras@gmail.com> wrote:
>
> Sure, i'll fix this and send out a new revision.

Ah, that would be helpful, thanks! I was going to tweak it on apply on
my side, but yeah, a new version is even easier.

Cheers,
Miguel