There exists a header file in include/linux/ called libfdt.h that is
just a wrapper for libfdt header file in scripts/dtc/libfdt/. This makes
the headers inside libfdt copy at scripts/dtc/libfdt/ part of the kernel
headers for building external modules.

Do not exclude them, otherwise modules that include <linux/libfdt.h>
will fail to build externally.

Fixes: aaed5c7739be ("kbuild: slim down package for building external modules")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 scripts/package/install-extmod-build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
index 2576cf7902dbb..d1e448d7f59f6 100755
--- a/scripts/package/install-extmod-build
+++ b/scripts/package/install-extmod-build
@@ -11,7 +11,8 @@ is_enabled() {
 
 find_in_scripts() {
 	find scripts \
-		\( -name atomic -o -name dtc -o -name kconfig -o -name package \) -prune -o \
+		\( -name atomic -o -name kconfig -o -name package -o \
+		   \( -path '*/dtc/*' -a ! -path '*/libfdt*' \) \) -prune -o \
 		! -name unifdef -a ! -name mk_elfconfig -a \( -type f -o -type l \) -print
 }
 
-- 
2.52.0

+ Rob, Saravana, and devicetree@ since this concerns files they own.

On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> There exists a header file in include/linux/ called libfdt.h that is
> just a wrapper for libfdt header file in scripts/dtc/libfdt/. This makes
> the headers inside libfdt copy at scripts/dtc/libfdt/ part of the kernel
> headers for building external modules.
> 
> Do not exclude them, otherwise modules that include <linux/libfdt.h>
> will fail to build externally.
> 
> Fixes: aaed5c7739be ("kbuild: slim down package for building external modules")
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>

This does indeed bring back scripts/dtc/libfdt back into the headers
package that I examined. However, how does including libfdt.h in an
external module actually work, even with this change? libfdt appears to
be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in the
list, so how can you actually use any of the functions from libfdt
within the module? Would you just build and link the pieces that your
module needs using the other source files?

> ---
>  scripts/package/install-extmod-build | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> index 2576cf7902dbb..d1e448d7f59f6 100755
> --- a/scripts/package/install-extmod-build
> +++ b/scripts/package/install-extmod-build
> @@ -11,7 +11,8 @@ is_enabled() {
>  
>  find_in_scripts() {
>  	find scripts \
> -		\( -name atomic -o -name dtc -o -name kconfig -o -name package \) -prune -o \
> +		\( -name atomic -o -name kconfig -o -name package -o \
> +		   \( -path '*/dtc/*' -a ! -path '*/libfdt*' \) \) -prune -o \
>  		! -name unifdef -a ! -name mk_elfconfig -a \( -type f -o -type l \) -print
>  }
>  
> -- 
> 2.52.0
>

在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：
> + Rob, Saravana, and devicetree@ since this concerns files they own.
> 
> On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > There exists a header file in include/linux/ called libfdt.h that
> > is
> > just a wrapper for libfdt header file in scripts/dtc/libfdt/. This
> > makes
> > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the
> > kernel
> > headers for building external modules.
> > 
> > Do not exclude them, otherwise modules that include
> > <linux/libfdt.h>
> > will fail to build externally.
> > 
> > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > external modules")
> > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> 
> This does indeed bring back scripts/dtc/libfdt back into the headers
> package that I examined. However, how does including libfdt.h in an
> external module actually work, even with this change? libfdt appears
> to
> be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in the
> list, so how can you actually use any of the functions from libfdt
> within the module? Would you just build and link the pieces that your
> module needs using the other source files?

To be honest what I met is quite weird -- my module [1] does not use
libfdt at all. However, as a MIPS platform-specific module, it includes
arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.

Or maybe I should prevent libfdt.h inclusion from other kernel headers?
It looks like only two headers in MIPS architecture-specific code
includes libfdt.h, asm/bootinfo.h and asm/machine.h .

Thanks,
Icenowy

> 
> > ---
> >  scripts/package/install-extmod-build | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/package/install-extmod-build
> > b/scripts/package/install-extmod-build
> > index 2576cf7902dbb..d1e448d7f59f6 100755
> > --- a/scripts/package/install-extmod-build
> > +++ b/scripts/package/install-extmod-build
> > @@ -11,7 +11,8 @@ is_enabled() {
> >  
> >  find_in_scripts() {
> >         find scripts \
> > -               \( -name atomic -o -name dtc -o -name kconfig -o -
> > name package \) -prune -o \
> > +               \( -name atomic -o -name kconfig -o -name package -
> > o \
> > +                  \( -path '*/dtc/*' -a ! -path '*/libfdt*' \) \)
> > -prune -o \
> >                 ! -name unifdef -a ! -name mk_elfconfig -a \( -type
> > f -o -type l \) -print
> >  }
> >  
> > -- 
> > 2.52.0
> > 

在 2026-02-04星期三的 11:26 +0800，Icenowy Zheng写道：
> 在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：
> > + Rob, Saravana, and devicetree@ since this concerns files they
> > own.
> > 
> > On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > > There exists a header file in include/linux/ called libfdt.h that
> > > is
> > > just a wrapper for libfdt header file in scripts/dtc/libfdt/.
> > > This
> > > makes
> > > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the
> > > kernel
> > > headers for building external modules.
> > > 
> > > Do not exclude them, otherwise modules that include
> > > <linux/libfdt.h>
> > > will fail to build externally.
> > > 
> > > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > > external modules")
> > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > 
> > This does indeed bring back scripts/dtc/libfdt back into the
> > headers
> > package that I examined. However, how does including libfdt.h in an
> > external module actually work, even with this change? libfdt
> > appears
> > to
> > be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in
> > the
> > list, so how can you actually use any of the functions from libfdt
> > within the module? Would you just build and link the pieces that
> > your
> > module needs using the other source files?
> 
> To be honest what I met is quite weird -- my module [1] does not use
> libfdt at all. However, as a MIPS platform-specific module, it
> includes
> arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.
> 
> Or maybe I should prevent libfdt.h inclusion from other kernel
> headers?
> It looks like only two headers in MIPS architecture-specific code
> includes libfdt.h, asm/bootinfo.h and asm/machine.h .
> 
> Thanks,
> Icenowy

Ah, forgot to place the [1] reference link, although I doubt whether
it's really related to the context:

[1] https://github.com/Icenowy/mips-loong-3nod-laptop-driver

> 
> > 
> > > ---
> > >  scripts/package/install-extmod-build | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/scripts/package/install-extmod-build
> > > b/scripts/package/install-extmod-build
> > > index 2576cf7902dbb..d1e448d7f59f6 100755
> > > --- a/scripts/package/install-extmod-build
> > > +++ b/scripts/package/install-extmod-build
> > > @@ -11,7 +11,8 @@ is_enabled() {
> > >  
> > >  find_in_scripts() {
> > >         find scripts \
> > > -               \( -name atomic -o -name dtc -o -name kconfig -o
> > > -
> > > name package \) -prune -o \
> > > +               \( -name atomic -o -name kconfig -o -name package
> > > -
> > > o \
> > > +                  \( -path '*/dtc/*' -a ! -path '*/libfdt*' \)
> > > \)
> > > -prune -o \
> > >                 ! -name unifdef -a ! -name mk_elfconfig -a \( -
> > > type
> > > f -o -type l \) -print
> > >  }
> > >  
> > > -- 
> > > 2.52.0
> > > 
> 

On Wed, Feb 04, 2026 at 11:27:24AM +0800, Icenowy Zheng wrote:
> 在 2026-02-04星期三的 11:26 +0800，Icenowy Zheng写道：
> > 在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：
> > > + Rob, Saravana, and devicetree@ since this concerns files they
> > > own.
> > > 
> > > On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > > > There exists a header file in include/linux/ called libfdt.h that
> > > > is
> > > > just a wrapper for libfdt header file in scripts/dtc/libfdt/.
> > > > This
> > > > makes
> > > > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the
> > > > kernel
> > > > headers for building external modules.
> > > > 
> > > > Do not exclude them, otherwise modules that include
> > > > <linux/libfdt.h>
> > > > will fail to build externally.
> > > > 
> > > > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > > > external modules")
> > > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > 
> > > This does indeed bring back scripts/dtc/libfdt back into the
> > > headers
> > > package that I examined. However, how does including libfdt.h in an
> > > external module actually work, even with this change? libfdt
> > > appears
> > > to
> > > be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in
> > > the
> > > list, so how can you actually use any of the functions from libfdt
> > > within the module? Would you just build and link the pieces that
> > > your
> > > module needs using the other source files?
> > 
> > To be honest what I met is quite weird -- my module [1] does not use
> > libfdt at all. However, as a MIPS platform-specific module, it
> > includes
> > arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.
> > 
> > Or maybe I should prevent libfdt.h inclusion from other kernel
> > headers?
> > It looks like only two headers in MIPS architecture-specific code
> > includes libfdt.h, asm/bootinfo.h and asm/machine.h .

Ah, thanks for that information. Moving the libfdt.h bits out of
bootinfo.h does not seem like it would be too difficult but I am less
sure about asm/machine.h. Alternatively, maybe this could be avoided by
separating out what you would need from bootinfo.h into its own header
but I did not look too hard.

As for a solution within install-extmod-build, maybe the libfdt headers
could be included so that inadvertent inclusions of libfdt.h do not
break the build but the link fails if the module actually tries to use
any libfdt functions?

> Ah, forgot to place the [1] reference link, although I doubt whether
> it's really related to the context:
> 
> [1] https://github.com/Icenowy/mips-loong-3nod-laptop-driver

This was helpful for testing the following diff, so thanks for providing
it still.

Cheers,
Nathan

在 2026-02-04星期三的 01:45 -0700，Nathan Chancellor写道：
> On Wed, Feb 04, 2026 at 11:27:24AM +0800, Icenowy Zheng wrote:
> > 在 2026-02-04星期三的 11:26 +0800，Icenowy Zheng写道：
> > > 在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：
> > > > + Rob, Saravana, and devicetree@ since this concerns files they
> > > > own.
> > > > 
> > > > On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > > > > There exists a header file in include/linux/ called libfdt.h
> > > > > that
> > > > > is
> > > > > just a wrapper for libfdt header file in scripts/dtc/libfdt/.
> > > > > This
> > > > > makes
> > > > > the headers inside libfdt copy at scripts/dtc/libfdt/ part of
> > > > > the
> > > > > kernel
> > > > > headers for building external modules.
> > > > > 
> > > > > Do not exclude them, otherwise modules that include
> > > > > <linux/libfdt.h>
> > > > > will fail to build externally.
> > > > > 
> > > > > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > > > > external modules")
> > > > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > > 
> > > > This does indeed bring back scripts/dtc/libfdt back into the
> > > > headers
> > > > package that I examined. However, how does including libfdt.h
> > > > in an
> > > > external module actually work, even with this change? libfdt
> > > > appears
> > > > to
> > > > be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs
> > > > in
> > > > the
> > > > list, so how can you actually use any of the functions from
> > > > libfdt
> > > > within the module? Would you just build and link the pieces
> > > > that
> > > > your
> > > > module needs using the other source files?
> > > 
> > > To be honest what I met is quite weird -- my module [1] does not
> > > use
> > > libfdt at all. However, as a MIPS platform-specific module, it
> > > includes
> > > arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.
> > > 
> > > Or maybe I should prevent libfdt.h inclusion from other kernel
> > > headers?
> > > It looks like only two headers in MIPS architecture-specific code
> > > includes libfdt.h, asm/bootinfo.h and asm/machine.h .
> 
> Ah, thanks for that information. Moving the libfdt.h bits out of
> bootinfo.h does not seem like it would be too difficult but I am less
> sure about asm/machine.h. Alternatively, maybe this could be avoided
> by
> separating out what you would need from bootinfo.h into its own
> header
> but I did not look too hard.

A bad joke -- the driver seems to require no bootinfo.h now. It's a
stale inclusion (because it's taken from some downstream tree and
rewritten to use mainline i8042 lock). Sorry for this...

Although I do think the libfdt.h inclusion should be removed from MIPS
headers.

For testing this any stub module can work with `#include
<asm/bootinfo.h>` (or machine.h) injected...

> 
> As for a solution within install-extmod-build, maybe the libfdt
> headers
> could be included so that inadvertent inclusions of libfdt.h do not
> break the build but the link fails if the module actually tries to
> use
> any libfdt functions?

I don't think it proper either.

By the way, should include/linux/libfdt.h be removed from extmod build
installations? As it's not going to work...

> 
> > Ah, forgot to place the [1] reference link, although I doubt
> > whether
> > it's really related to the context:
> > 
> > [1] https://github.com/Icenowy/mips-loong-3nod-laptop-driver
> 
> This was helpful for testing the following diff, so thanks for
> providing
> it still.
> 
> Cheers,
> Nathan

On Wed, Feb 4, 2026 at 2:45 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Wed, Feb 04, 2026 at 11:27:24AM +0800, Icenowy Zheng wrote:
> > 在 2026-02-04星期三的 11:26 +0800，Icenowy Zheng写道：
> > > 在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：
> > > > + Rob, Saravana, and devicetree@ since this concerns files they
> > > > own.
> > > >
> > > > On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > > > > There exists a header file in include/linux/ called libfdt.h that
> > > > > is
> > > > > just a wrapper for libfdt header file in scripts/dtc/libfdt/.
> > > > > This
> > > > > makes
> > > > > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the
> > > > > kernel
> > > > > headers for building external modules.
> > > > >
> > > > > Do not exclude them, otherwise modules that include
> > > > > <linux/libfdt.h>
> > > > > will fail to build externally.
> > > > >
> > > > > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > > > > external modules")
> > > > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > >
> > > > This does indeed bring back scripts/dtc/libfdt back into the
> > > > headers
> > > > package that I examined. However, how does including libfdt.h in an
> > > > external module actually work, even with this change? libfdt
> > > > appears
> > > > to
> > > > be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in
> > > > the
> > > > list, so how can you actually use any of the functions from libfdt
> > > > within the module? Would you just build and link the pieces that
> > > > your
> > > > module needs using the other source files?
> > >
> > > To be honest what I met is quite weird -- my module [1] does not use
> > > libfdt at all. However, as a MIPS platform-specific module, it
> > > includes
> > > arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.
> > >
> > > Or maybe I should prevent libfdt.h inclusion from other kernel
> > > headers?
> > > It looks like only two headers in MIPS architecture-specific code
> > > includes libfdt.h, asm/bootinfo.h and asm/machine.h .
>
> Ah, thanks for that information. Moving the libfdt.h bits out of
> bootinfo.h does not seem like it would be too difficult but I am less
> sure about asm/machine.h. Alternatively, maybe this could be avoided by
> separating out what you would need from bootinfo.h into its own header
> but I did not look too hard.

There shouldn't be that many locations using libfdt functions. Add the
header where it is used. IWYU

> As for a solution within install-extmod-build, maybe the libfdt headers
> could be included so that inadvertent inclusions of libfdt.h do not
> break the build but the link fails if the module actually tries to use
> any libfdt functions?

You do this and then we get to keep the work-around forever as no one
will care. MIPS is a mess that needs to be cleaned up.

Rob

On Wed, Feb 04, 2026 at 07:31:57AM -0600, Rob Herring wrote:
> On Wed, Feb 4, 2026 at 2:45 AM Nathan Chancellor <nathan@kernel.org> wrote:
> > Ah, thanks for that information. Moving the libfdt.h bits out of
> > bootinfo.h does not seem like it would be too difficult but I am less
> > sure about asm/machine.h. Alternatively, maybe this could be avoided by
> > separating out what you would need from bootinfo.h into its own header
> > but I did not look too hard.
> 
> There shouldn't be that many locations using libfdt functions. Add the
> header where it is used. IWYU
> 
> > As for a solution within install-extmod-build, maybe the libfdt headers
> > could be included so that inadvertent inclusions of libfdt.h do not
> > break the build but the link fails if the module actually tries to use
> > any libfdt functions?
> 
> You do this and then we get to keep the work-around forever as no one
> will care. MIPS is a mess that needs to be cleaned up.

Yeah, that is a valid perspective, I won't push that further. Thanks for
chiming in.

Cheers,
Nathan

On Wed, Feb 04, 2026 at 01:45:23AM -0700, Nathan Chancellor wrote:
> On Wed, Feb 04, 2026 at 11:27:24AM +0800, Icenowy Zheng wrote:
> > 在 2026-02-04星期三的 11:26 +0800，Icenowy Zheng写道：
> > > 在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：
> > > > + Rob, Saravana, and devicetree@ since this concerns files they
> > > > own.
> > > > 
> > > > On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > > > > There exists a header file in include/linux/ called libfdt.h that
> > > > > is
> > > > > just a wrapper for libfdt header file in scripts/dtc/libfdt/.
> > > > > This
> > > > > makes
> > > > > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the
> > > > > kernel
> > > > > headers for building external modules.
> > > > > 
> > > > > Do not exclude them, otherwise modules that include
> > > > > <linux/libfdt.h>
> > > > > will fail to build externally.
> > > > > 
> > > > > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > > > > external modules")
> > > > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > > 
> > > > This does indeed bring back scripts/dtc/libfdt back into the
> > > > headers
> > > > package that I examined. However, how does including libfdt.h in an
> > > > external module actually work, even with this change? libfdt
> > > > appears
> > > > to
> > > > be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in
> > > > the
> > > > list, so how can you actually use any of the functions from libfdt
> > > > within the module? Would you just build and link the pieces that
> > > > your
> > > > module needs using the other source files?
> > > 
> > > To be honest what I met is quite weird -- my module [1] does not use
> > > libfdt at all. However, as a MIPS platform-specific module, it
> > > includes
> > > arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.
> > > 
> > > Or maybe I should prevent libfdt.h inclusion from other kernel
> > > headers?
> > > It looks like only two headers in MIPS architecture-specific code
> > > includes libfdt.h, asm/bootinfo.h and asm/machine.h .
> 
> Ah, thanks for that information. Moving the libfdt.h bits out of
> bootinfo.h does not seem like it would be too difficult but I am less
> sure about asm/machine.h. Alternatively, maybe this could be avoided by
> separating out what you would need from bootinfo.h into its own header
> but I did not look too hard.
> 
> As for a solution within install-extmod-build, maybe the libfdt headers
> could be included so that inadvertent inclusions of libfdt.h do not
> break the build but the link fails if the module actually tries to use
> any libfdt functions?
> 
> > Ah, forgot to place the [1] reference link, although I doubt whether
> > it's really related to the context:
> > 
> > [1] https://github.com/Icenowy/mips-loong-3nod-laptop-driver
> 
> This was helpful for testing the following diff, so thanks for providing
> it still.
> 
> Cheers,
> Nathan

Of course forgot to provide said diff...

diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
index 2576cf7902db..45cc3863e8a7 100755
--- a/scripts/package/install-extmod-build
+++ b/scripts/package/install-extmod-build
@@ -25,6 +25,9 @@ mkdir -p "${destdir}"
 	find "arch/${SRCARCH}" -name Kbuild.platforms -o -name Platform
 	find include \( -name config -o -name generated \) -prune -o \( -type f -o -type l \) -print
 	find_in_scripts
+	echo scripts/dtc/libfdt/fdt.h
+	echo scripts/dtc/libfdt/libfdt.h
+	echo scripts/dtc/libfdt/libfdt_env.h
 ) | tar -c -f - -C "${srctree}" -T - | tar -xf - -C "${destdir}"
 
 {

On Tue, Feb 3, 2026 at 8:16 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> + Rob, Saravana, and devicetree@ since this concerns files they own.
>
> On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > There exists a header file in include/linux/ called libfdt.h that is
> > just a wrapper for libfdt header file in scripts/dtc/libfdt/. This makes
> > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the kernel
> > headers for building external modules.
> >
> > Do not exclude them, otherwise modules that include <linux/libfdt.h>
> > will fail to build externally.
> >
> > Fixes: aaed5c7739be ("kbuild: slim down package for building external modules")
> > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
>
> This does indeed bring back scripts/dtc/libfdt back into the headers
> package that I examined. However, how does including libfdt.h in an
> external module actually work, even with this change? libfdt appears to
> be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in the
> list, so how can you actually use any of the functions from libfdt
> within the module? Would you just build and link the pieces that your
> module needs using the other source files?

Right. Modules should not use libfdt functions.

Rob