Re: [PATCH] perf arm_spe: Fix bitfield dependency failure

[David Laight <david.laight.linux@gmail.com>]

On Fri, 23 Jan 2026 12:08:47 +0000
Leo Yan <leo.yan@arm.com> wrote:

> On Fri, Jan 23, 2026 at 10:27:42AM +0000, James Clark wrote:
> 
> [...]
> 
> > > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > > index adf4cde320aa..8d16619cd098 100644
> > > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > > @@ -7,6 +7,7 @@
> > >   #ifndef INCLUDE__ARM_SPE_PKT_DECODER_H__
> > >   #define INCLUDE__ARM_SPE_PKT_DECODER_H__
> > > +#include <linux/kernel.h>
> > >   #include <linux/bitfield.h>  
> > 
> > This isn't the first time I've seen this issue. Isn't the real fix to
> > include kernel.h in bitfield.h if it depends on it?  
> 
> Good point!
> 
> bitfield.h is a common header so I did not change it.  I digged a bit
> and found diverage between kernel's bitfield.h and tool's bitfield.h.
> 
> 1) The kernel's bitfield.h includes asm/byteorder.h, and finally it
>    includes linux/byteorder/generic.h, cpu_to_le{16|32|64} are defined
>    in this file.
> 
> 2) The tool's bitfield.h will includes asm/byteorder.h, but this hooks
>    to the headers provided by the toolchain.  cpu_to_le{16|32|64} are
>    not C lib API, they are defined in tool's kernel.h.

Perhaps cpu_to_le16() and friends should be defined in the tools
asm/byteorder.h rather than its kernel.h.

	David

> 
>    As a result, we need to include kernel.h for perf build.
> 
> As you said, we can include kernel.h in bitfield.h, I will respin and
> send a new series.
> 
> > Usually you shouldn't
> > have to know what all the dependencies of a header are when you include it.
> > Or is there a reason it wasn't done that way in the first place? Maybe this
> > has been discussed before?  
> 
> This issue is for tools only, and only Arm modules in perf folder use
> this header, I don't expect this is widely spread issue.
> 
> Thanks,
> Leo
>