[GIT PULL] Kbuild updates for v6.16-rc1

[GIT PULL] Kbuild updates for v6.16-rc1

[Masahiro Yamada]

Hello Linus,

Please pull Kbuild updates for v6.16-rc1.
Thank you


The following changes since commit a5806cd506af5a7c19bcd596e4708b5c464bfd21:

  Linux 6.15-rc7 (2025-05-18 13:57:29 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v6.16

for you to fetch changes up to c50a04f8f45c7f13972f9097622d1d929033ea8c:

  genksyms: Fix enum consts from a reference affecting new values
(2025-06-07 14:38:07 +0900)

----------------------------------------------------------------
Kbuild updates for v6.16

 - Add support for the EXPORT_SYMBOL_GPL_FOR_MODULES() macro, which exports a
   symbol only to specified modules

 - Improve ABI handling in gendwarfksyms

 - Forcibly link lib-y objects to vmlinux even if CONFIG_MODULES=n

 - Add checkers for redundant or missing <linux/export.h> inclusion

 - Deprecate the extra-y syntax

 - Fix a genksyms bug when including enum constants from *.symref files

----------------------------------------------------------------
Henrik Lindström (1):
      Makefile: remove dependency on archscripts for header installation

Khaled Elnaggar (1):
      docs: symbol-namespaces: fix reST warning with literal block

Masahiro Yamada (14):
      kbuild: move kbuild syntax processing to scripts/Makefile.build
      modpost: check forbidden MODULE_IMPORT_NS("module:") at compile time
      docs/core-api/symbol-namespaces: drop table of contents and
section numbering
      tinyconfig: enable CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
      kbuild: link lib-y objects to vmlinux forcibly even when CONFIG_MODULES=n
      kconfig: introduce menu type enum
      kbuild: move W=1 check for scripts/misc-check to top-level Makefile
      scripts/misc-check: add double-quotes to satisfy shellcheck
      scripts/misc-check: check missing #include <linux/export.h> when W=1
      scripts/misc-check: check unnecessary #include <linux/export.h> when W=1
      module: make __mod_device_table__* symbols static
      efi/libstub: use 'targets' instead of extra-y in Makefile
      kbuild: set y instead of 1 to KBUILD_{BUILTIN,MODULES}
      arch: use always-$(KBUILD_BUILTIN) for vmlinux.lds

Masatake YAMATO (1):
      scripts/tags.sh: allow to use alternative ctags implementation

Peter Zijlstra (5):
      modpost: Use for() loop
      module: Add module specific symbol namespace support
      module: Extend the module namespace parsing
      module: Account for the build time module name mangling
      module: Provide EXPORT_SYMBOL_GPL_FOR_MODULES() helper

Petr Pavlu (1):
      genksyms: Fix enum consts from a reference affecting new values

Sami Tolvanen (5):
      gendwarfksyms: Clean up kABI rule look-ups
      gendwarfksyms: Add a kABI rule to override byte_size attributes
      gendwarfksyms: Add a kABI rule to override type strings
      Documentation/kbuild: Drop section numbers
      Documentation/kbuild: Add new gendwarfksyms kABI rules

 Documentation/core-api/symbol-namespaces.rst                 |  63 +++++-----
 Documentation/kbuild/gendwarfksyms.rst                       | 141
+++++++++++++++++-----
 Documentation/kbuild/makefiles.rst                           |   4 +
 .../translations/it_IT/core-api/symbol-namespaces.rst        |  32 +++--
 .../translations/zh_CN/core-api/symbol-namespaces.rst        |  41 +++----
 Makefile                                                     |  28 +++--
 arch/alpha/kernel/Makefile                                   |   2 +-
 arch/arc/kernel/Makefile                                     |   2 +-
 arch/arm/kernel/Makefile                                     |   2 +-
 arch/arm64/kernel/Makefile                                   |   2 +-
 arch/csky/kernel/Makefile                                    |   2 +-
 arch/hexagon/kernel/Makefile                                 |   2 +-
 arch/loongarch/kernel/Makefile                               |   2 +-
 arch/m68k/kernel/Makefile                                    |   2 +-
 arch/microblaze/kernel/Makefile                              |   2 +-
 arch/mips/kernel/Makefile                                    |   2 +-
 arch/nios2/kernel/Makefile                                   |   2 +-
 arch/openrisc/kernel/Makefile                                |   2 +-
 arch/parisc/kernel/Makefile                                  |   2 +-
 arch/powerpc/kernel/Makefile                                 |   2 +-
 arch/riscv/kernel/Makefile                                   |   2 +-
 arch/s390/kernel/Makefile                                    |   2 +-
 arch/sh/kernel/Makefile                                      |   2 +-
 arch/sparc/kernel/Makefile                                   |   2 +-
 arch/um/kernel/Makefile                                      |   2 +-
 arch/x86/kernel/Makefile                                     |   2 +-
 arch/xtensa/kernel/Makefile                                  |   2 +-
 drivers/firmware/efi/libstub/Makefile                        |   2 +-
 include/linux/export.h                                       |  12 +-
 include/linux/module.h                                       |   4 +-
 kernel/configs/tiny.config                                   |   1 +
 kernel/module/main.c                                         |  89
+++++++++++++-
 scripts/Makefile.build                                       |  84
++++++++++++++
 scripts/Makefile.lib                                         |  84
--------------
 scripts/gendwarfksyms/dwarf.c                                |  14 ++-
 scripts/gendwarfksyms/examples/kabi.h                        |  21 +++-
 scripts/gendwarfksyms/examples/kabi_ex.c                     |   7 ++
 scripts/gendwarfksyms/examples/kabi_ex.h                     | 101
+++++++++++++++-
 scripts/gendwarfksyms/gendwarfksyms.h                        |   2 +
 scripts/gendwarfksyms/kabi.c                                 | 161
++++++++++++++++----------
 scripts/gendwarfksyms/types.c                                | 140
+++++++++++++++++++---
 scripts/genksyms/genksyms.c                                  |  27 +++--
 scripts/kconfig/expr.h                                       |  11 ++
 scripts/kconfig/lkc.h                                        |   2 +-
 scripts/kconfig/menu.c                                       |   5 +-
 scripts/kconfig/parser.y                                     |  12 +-
 scripts/misc-check                                           |  66 +++++++++--
 scripts/mod/modpost.c                                        |  56 ++++++++-
 scripts/tags.sh                                              |   2 +-
 49 files changed, 919 insertions(+), 335 deletions(-)


-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[pr-tracker-bot]

The pull request you sent on Sun, 8 Jun 2025 01:41:18 +0900:

> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-v6.16

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8630c59e99363c4b655788fd01134aef9bcd9264

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Heiko Carstens]

On Sun, Jun 08, 2025 at 01:41:18AM +0900, Masahiro Yamada wrote:
> Kbuild updates for v6.16
> 
>  - Add support for the EXPORT_SYMBOL_GPL_FOR_MODULES() macro, which exports a
>    symbol only to specified modules
> 
>  - Improve ABI handling in gendwarfksyms
> 
>  - Forcibly link lib-y objects to vmlinux even if CONFIG_MODULES=n
> 
>  - Add checkers for redundant or missing <linux/export.h> inclusion

As you write in commit a934a57a42f6 ("scripts/misc-check: check missing
#include <linux/export.h> when W=1") this adds now 4000+ extra warnings
for W=1 builds, which makes such builds more or less useless for me.

Also the commit only describes what you want to achieve, but not why.
I can only guess that you want to reduce header dependencies(?).

Don't get me wrong, I can address all of this trivial churn for s390, however
enforcing so many extra warnings to everyone with W=1 builds doesn't look like
the right approach to me.

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Sean Christopherson]

On Wed, Jun 11, 2025, Heiko Carstens wrote:
> On Sun, Jun 08, 2025 at 01:41:18AM +0900, Masahiro Yamada wrote:
> > Kbuild updates for v6.16
> > 
> >  - Add support for the EXPORT_SYMBOL_GPL_FOR_MODULES() macro, which exports a
> >    symbol only to specified modules
> > 
> >  - Improve ABI handling in gendwarfksyms
> > 
> >  - Forcibly link lib-y objects to vmlinux even if CONFIG_MODULES=n
> > 
> >  - Add checkers for redundant or missing <linux/export.h> inclusion
> 
> As you write in commit a934a57a42f6 ("scripts/misc-check: check missing
> #include <linux/export.h> when W=1") this adds now 4000+ extra warnings
> for W=1 builds, which makes such builds more or less useless for me.
> 
> Also the commit only describes what you want to achieve, but not why.
> I can only guess that you want to reduce header dependencies(?).
> 
> Don't get me wrong, I can address all of this trivial churn for s390, however
> enforcing so many extra warnings to everyone with W=1 builds doesn't look like
> the right approach to me.

+1.  This seems like a recipe for an endless game of whack-a-mole.

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Masahiro Yamada]

On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>
> On Sun, Jun 08, 2025 at 01:41:18AM +0900, Masahiro Yamada wrote:
> > Kbuild updates for v6.16
> >
> >  - Add support for the EXPORT_SYMBOL_GPL_FOR_MODULES() macro, which exports a
> >    symbol only to specified modules
> >
> >  - Improve ABI handling in gendwarfksyms
> >
> >  - Forcibly link lib-y objects to vmlinux even if CONFIG_MODULES=n
> >
> >  - Add checkers for redundant or missing <linux/export.h> inclusion
>
> As you write in commit a934a57a42f6 ("scripts/misc-check: check missing
> #include <linux/export.h> when W=1") this adds now 4000+ extra warnings
> for W=1 builds, which makes such builds more or less useless for me.
>
> Also the commit only describes what you want to achieve, but not why.
> I can only guess that you want to reduce header dependencies(?).

Yes.

Here, more numbers.
There are around 32000 *.c files in the tree, but only about 6000 of them
actually export symbols.
However, most of them end up including <linux/export.h>,
even though only 20% of them truly need it.

Header dependency cleanup is necessary.
Many a little makes a mickle.

> Don't get me wrong, I can address all of this trivial churn for s390, however
> enforcing so many extra warnings to everyone with W=1 builds doesn't look like
> the right approach to me.

This is what W=1 is for.
0day bot detects a new W=1 warning, so we can avoid new warnings coming in.

People do not know which headers should be included when.
So, this warning must exist at least until we can get rid of
#include <linux/export.h> from include/linux/module.h,
include/linux/linkage.h etc.


-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Arnd Bergmann]

On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>>
>> Don't get me wrong, I can address all of this trivial churn for s390, however
>> enforcing so many extra warnings to everyone with W=1 builds doesn't look like
>> the right approach to me.
>
> This is what W=1 is for.
> 0day bot detects a new W=1 warning, so we can avoid new warnings coming in.
>
> People do not know which headers should be included when.
> So, this warning must exist at least until we can get rid of
> #include <linux/export.h> from include/linux/module.h,
> include/linux/linkage.h etc.

I think this makes sense in general, but the output here is
excessive if it leads to users no longer wanting to enable W=1.

There are other warnings that I think should be enabled at the
W=1 level (e.g. -Wformat-security) and eventually by default,
but that are still too noisy at that level.

My own cutoff would be at a few hundred warnings in allmodconfig
builds if there is an effort to reduce it further, but it seems
that this one is still at a few thousand, which does not seem ok.

     Arnd

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Masahiro Yamada]

On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> > On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> >>
> >> Don't get me wrong, I can address all of this trivial churn for s390, however
> >> enforcing so many extra warnings to everyone with W=1 builds doesn't look like
> >> the right approach to me.
> >
> > This is what W=1 is for.
> > 0day bot detects a new W=1 warning, so we can avoid new warnings coming in.
> >
> > People do not know which headers should be included when.
> > So, this warning must exist at least until we can get rid of
> > #include <linux/export.h> from include/linux/module.h,
> > include/linux/linkage.h etc.
>
> I think this makes sense in general, but the output here is
> excessive if it leads to users no longer wanting to enable W=1.
>
> There are other warnings that I think should be enabled at the
> W=1 level (e.g. -Wformat-security) and eventually by default,
> but that are still too noisy at that level.
>
> My own cutoff would be at a few hundred warnings in allmodconfig
> builds if there is an effort to reduce it further, but it seems
> that this one is still at a few thousand, which does not seem ok.
>
>      Arnd

Then, what to do?  Downgrade to W=2?

I think nobody cares about W=2 builds,
and the problem of all C files including <linux/export.h>
would remain forever.






--
Best Regards
Masahiro Yamada

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Arnd Bergmann]

On Thu, Jun 12, 2025, at 03:42, Masahiro Yamada wrote:
> On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
>> > On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>> I think this makes sense in general, but the output here is
>> excessive if it leads to users no longer wanting to enable W=1.
>>
>> There are other warnings that I think should be enabled at the
>> W=1 level (e.g. -Wformat-security) and eventually by default,
>> but that are still too noisy at that level.
>>
>> My own cutoff would be at a few hundred warnings in allmodconfig
>> builds if there is an effort to reduce it further, but it seems
>> that this one is still at a few thousand, which does not seem ok.
>
> Then, what to do?  Downgrade to W=2?
>
> I think nobody cares about W=2 builds,

I think the first step would be mass-cleanup patches to get
the initial numbers down. A lot of this can be scripted.

> and the problem of all C files including <linux/export.h>
> would remain forever.

I'm missing a bit of background here, and I don't see this
explained in the 5b20755b7780 ("init: move THIS_MODULE
from <linux/export.h> to <linux/init.h>") changelog text
either

What is the purpose of cleaning the linux/export.h inclusions,
and what makes this one more important than others?
I obviously understand that indirect header inclusions are
a giant mess and that any such cleanup helps, but linux/export.h
seems particularly small compared to many others. It was
originally introduced so a lot of files would no longer have
to pull in linux/module.h if they only care about using
EXPORT_SYMBOL() and THIS_MODULE, so linux/module.h could
eventually become private to kernel/module/*.c.

Is this something you are trying to continue, or are you
doing something else here?

FWIW, I compared the preprocessed sizes of linux/export.h
(~2000) and linux/module.h (~120,000), and it seems that almost
none of those are needed by most of the files including
linux/module.h. The one part that is commonly required is
MODULE_{INFO,AUTHOR,LICENSE,DESCRIPTION}, so maybe there would
be a chance to clean this up at the same time if you are
planning some large-scale reshuffling of #include statements
around export.h.

     Arnd

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Heiko Carstens]

On Thu, Jun 12, 2025 at 10:42:40AM +0900, Masahiro Yamada wrote:
> On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > I think this makes sense in general, but the output here is
> > excessive if it leads to users no longer wanting to enable W=1.
> >
> > There are other warnings that I think should be enabled at the
> > W=1 level (e.g. -Wformat-security) and eventually by default,
> > but that are still too noisy at that level.
> >
> > My own cutoff would be at a few hundred warnings in allmodconfig
> > builds if there is an effort to reduce it further, but it seems
> > that this one is still at a few thousand, which does not seem ok.
> >
> >      Arnd
> 
> Then, what to do?  Downgrade to W=2?
> 
> I think nobody cares about W=2 builds,
> and the problem of all C files including <linux/export.h>
> would remain forever.

For example you could provide a method to opt-out, similar to
RECORDMCOUNT_WARN, except that the default would be enabled.

This option would go away in the (near?) future again, as soon
as everything has been addressed.

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Heiko Carstens]

On Thu, Jun 12, 2025 at 10:01:00AM +0200, Arnd Bergmann wrote:
> On Thu, Jun 12, 2025, at 03:42, Masahiro Yamada wrote:
> > On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> >> > On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> >> I think this makes sense in general, but the output here is
> >> excessive if it leads to users no longer wanting to enable W=1.
> >>
> >> There are other warnings that I think should be enabled at the
> >> W=1 level (e.g. -Wformat-security) and eventually by default,
> >> but that are still too noisy at that level.
> >>
> >> My own cutoff would be at a few hundred warnings in allmodconfig
> >> builds if there is an effort to reduce it further, but it seems
> >> that this one is still at a few thousand, which does not seem ok.
> >
> > Then, what to do?  Downgrade to W=2?
> >
> > I think nobody cares about W=2 builds,
> 
> I think the first step would be mass-cleanup patches to get
> the initial numbers down. A lot of this can be scripted.

I'm not sure this should be separate patches which would then be sent for
review. This is way too much churn for something trivial like this. Only very
few patches have been posted yet, and discussions started:

https://lore.kernel.org/all/aEjwqtotEEH8QMHB@gondor.apana.org.au
https://lore.kernel.org/all/aEl9kO81-kp0hhw0@google.com
https://lore.kernel.org/all/CAHp75Vc7AO_sRgB1Nj6CevbseMFyv5ku8ZS3PwzAuAgysKVxNg@mail.gmail.com

This looks like the start of an immense waste of developer time.

Can't this be scripted and be addressed with a single commit shortly
after/before the next merge window closes?

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Masahiro Yamada]

On Thu, Jun 12, 2025 at 5:01 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Jun 12, 2025, at 03:42, Masahiro Yamada wrote:
> > On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> >> > On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> >> I think this makes sense in general, but the output here is
> >> excessive if it leads to users no longer wanting to enable W=1.
> >>
> >> There are other warnings that I think should be enabled at the
> >> W=1 level (e.g. -Wformat-security) and eventually by default,
> >> but that are still too noisy at that level.
> >>
> >> My own cutoff would be at a few hundred warnings in allmodconfig
> >> builds if there is an effort to reduce it further, but it seems
> >> that this one is still at a few thousand, which does not seem ok.
> >
> > Then, what to do?  Downgrade to W=2?
> >
> > I think nobody cares about W=2 builds,
>
> I think the first step would be mass-cleanup patches to get
> the initial numbers down. A lot of this can be scripted.
>
> > and the problem of all C files including <linux/export.h>
> > would remain forever.
>
> I'm missing a bit of background here, and I don't see this
> explained in the 5b20755b7780 ("init: move THIS_MODULE
> from <linux/export.h> to <linux/init.h>") changelog text
> either

I explained in 5b20755b7780 and also in the comment lines
in scripts/misc-check.


<linux/module.h> is included by modular (i.e. tristate) code,
which is symbol _consumers_.

<linux/export.h> is included by symbol _providers_.

These are independent, or in other words, orthogonal.

Therefore, there is no reason for <linux/module.h>
to include <linux/export.h>.

It is standard to split consumers and providers,
since they are included by different files.
See <linux/clk.h> vs <linux/clk-providers.h> as another example.





> What is the purpose of cleaning the linux/export.h inclusions,
> and what makes this one more important than others?
> I obviously understand that indirect header inclusions are
> a giant mess and that any such cleanup helps, but linux/export.h
> seems particularly small compared to many others. It was
> originally introduced so a lot of files would no longer have
> to pull in linux/module.h if they only care about using
> EXPORT_SYMBOL() and THIS_MODULE, so linux/module.h could
> eventually become private to kernel/module/*.c.

I believe <linux/module.h> will remain, as modules must
define MODULE_LICENSE().


> Is this something you are trying to continue, or are you
> doing something else here?
>
> FWIW, I compared the preprocessed sizes of linux/export.h
> (~2000) and linux/module.h (~120,000), and it seems that almost
> none of those are needed by most of the files including
> linux/module.h. The one part that is commonly required is
> MODULE_{INFO,AUTHOR,LICENSE,DESCRIPTION}, so maybe there would
> be a chance to clean this up at the same time if you are
> planning some large-scale reshuffling of #include statements
> around export.h.
>
>      Arnd

Split <linux/module.h> into public and private is good,
but it is beyond the scope of this work.

Regardless of the file size, if a file does not need to
include <linux/export.h>, the open syscall can be avoided.
80 % of *.c files do not need to include it.



-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Masahiro Yamada]

On Thu, Jun 12, 2025 at 11:29 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>
> On Thu, Jun 12, 2025 at 10:01:00AM +0200, Arnd Bergmann wrote:
> > On Thu, Jun 12, 2025, at 03:42, Masahiro Yamada wrote:
> > > On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >> On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> > >> > On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
> > >> I think this makes sense in general, but the output here is
> > >> excessive if it leads to users no longer wanting to enable W=1.
> > >>
> > >> There are other warnings that I think should be enabled at the
> > >> W=1 level (e.g. -Wformat-security) and eventually by default,
> > >> but that are still too noisy at that level.
> > >>
> > >> My own cutoff would be at a few hundred warnings in allmodconfig
> > >> builds if there is an effort to reduce it further, but it seems
> > >> that this one is still at a few thousand, which does not seem ok.
> > >
> > > Then, what to do?  Downgrade to W=2?
> > >
> > > I think nobody cares about W=2 builds,
> >
> > I think the first step would be mass-cleanup patches to get
> > the initial numbers down. A lot of this can be scripted.
>
> I'm not sure this should be separate patches which would then be sent for
> review. This is way too much churn for something trivial like this. Only very
> few patches have been posted yet, and discussions started:
>
> https://lore.kernel.org/all/aEjwqtotEEH8QMHB@gondor.apana.org.au
> https://lore.kernel.org/all/aEl9kO81-kp0hhw0@google.com
> https://lore.kernel.org/all/CAHp75Vc7AO_sRgB1Nj6CevbseMFyv5ku8ZS3PwzAuAgysKVxNg@mail.gmail.com
>
> This looks like the start of an immense waste of developer time.
>
> Can't this be scripted and be addressed with a single commit shortly
> after/before the next merge window closes?

https://lore.kernel.org/linux-kbuild/20250612160850.3007038-1-masahiroy@kernel.org/T/#u

-- 
Best Regards
Masahiro Yamada