linux-imx: include/uapi/linux/ipu.h redefines standard integer types

[ernest_tdx]

Hi,

I'm using the Toradex BSP master branch to build for the Verdin iMX8MM. This BSP uses the meta-freescale layer to support the NXP SoCs. There, things are being updated to follow NXP BSP 6.18.2.  In particular, imx-gst1.0-plugin is now at version "MM_04.10.03_2512_L6.18.2", and linux-imx and linux-imx-headers are now at lf-6.18.y.

When building imx-gst1.0-plugin with Yocto/OE for the verdin-imx8mm, I noticed the following build error:
MACHINE=verdin-imx8mm bitbake imx-gst1.0-plugin:

  | In file included from ../sources/imx-gst1.0-plugin-4.10.3+git/libs/v4l2_core/gstimxv4l2.c:29:
  | /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/recipe-sysroot/usr/include/imx/linux/ipu.h:42:17: error: two or more data types in declaration specifiers
  |    42 | #define uint8_t unsigned char
  |       |                 ^~~~~~~~
  | /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/recipe-sysroot/usr/include/imx/linux/ipu.h:42:26: error: two or more data types in declaration specifiers
  |    42 | #define uint8_t unsigned char
  |       |                          ^~~~
  | /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/recipe-sysroot/usr/include/imx/linux/ipu.h:41:18: error: two or more data types in declaration specifiers
  |    41 | #define uint16_t unsigned short
  |       |                  ^~~~~~~~
  | /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/recipe-sysroot/usr/include/imx/linux/ipu.h:41:27: error: two or more data types in declaration specifiers
  |    41 | #define uint16_t unsigned short
  |       |                           ^~~~~
  | /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/recipe-sysroot/usr/include/imx/linux/ipu.h:40:18: error: two or more data types in declaration specifiers
  |    40 | #define uint32_t unsigned int
  |       |                  ^~~~~~~~
  | /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/recipe-sysroot/usr/include/imx/linux/ipu.h:40:27: error: two or more data types in declaration specifiers
  |    40 | #define uint32_t unsigned int
  |       |                           ^~~

[...]

  | ninja: build stopped: subcommand failed.
  | INFO: autodetecting backend as ninja
  | INFO: calculating backend command to run: /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/recipe-sysroot-native/usr/bin/ninja -j 64 -v
  | WARNING: exit code 1 from a shell command.
  NOTE: recipe imx-gst1.0-plugin-4.10.3+git-r0: task do_compile: Failed
  ERROR: Task (/workdir/oe/build/../layers/meta-freescale/recipes-multimedia/gstreamer/imx-gst1.0-plugin_git.bb:do_compile) failed with exit code '1'
  NOTE: recipe gstreamer1.0-plugins-bad-1.26.6.imx-r0: task do_package: Succeeded
  NOTE: Tasks Summary: Attempted 10003 tasks of which 8796 didn't need to be rerun and 1 failed.
  NOTE: Writing buildhistory
  NOTE: Writing buildhistory took: 6 seconds
  
  Summary: 1 task failed:
    /workdir/oe/build/../layers/meta-freescale/recipes-multimedia/gstreamer/imx-gst1.0-plugin_git.bb:do_compile
      log: /workdir/oe/tmp/work/armv8a-mx8mm-tdx-linux/imx-gst1.0-plugin/4.10.3+git/temp/log.do_compile.827805
  Summary: There was 1 WARNING message.
  Summary: There was 1 ERROR message, returning a non-zero exit code.

 
This happens because "include/imx/linux/ipu.h" is redefining types that are already set as a typedef in "linux/types.h", which is included by ipu.h. It is probably pure chance that this error was not triggered by a userspace program consuming this header before, due to a different include order.

The solution seems relatively straightforward to me: remove the macro defines of uint*_t, which already exist anyways. My assumption is these just remained from some historical growth but there should be no reason for them in a Linux context.

I've attached a patch with what I believe is a decent solution, on top of lf-6.18.y, which fixes my build problems. Any feedback or the integration of this patch would certainly be appreciated.

Thanks,
Ernest - Toradex

[dbaluta · Accepted solution]

@ernest_tdx 

Hello,

We have a similar patch in our lf-6.18 branch scheduled for Q2 2026 Release. Can you please test it and see if it fixes your issue?

[ernest_tdx]

Hi @dbaluta,

The patch you attached seems reasonable as well, I double checked and can confirm this patch also solves the issues.

I really appreciate NXP taking a look at the patches submitted here. If we can ever get a way to find such patches before a major release, that would of course be very helpful for us in backporting them

Thanks and kind regards,

Ernest