From: Will Deacon <will@kernel•org>
To: Rong Xu <xur@google•com>
Cc: Nathan Chancellor <nathan@kernel•org>,
Yabin Cui <yabinc@google•com>, Han Shen <shenhan@google•com>,
Thomas Gleixner <tglx@linutronix•de>,
Ingo Molnar <mingo@redhat•com>, Borislav Petkov <bp@alien8•de>,
Dave Hansen <dave.hansen@linux•intel.com>,
"H. Peter Anvin" <hpa@zytor•com>, Kees Cook <kees@kernel•org>,
Nicolas Schier <nicolas.schier@linux•dev>,
Linus Walleij <linusw@kernel•org>, Arnd Bergmann <arnd@arndb•de>,
Mathieu Desnoyers <mathieu.desnoyers@efficios•com>,
Miguel Ojeda <ojeda@kernel•org>,
Peter Zijlstra <peterz@infradead•org>,
Jinjie Ruan <ruanjinjie@huawei•com>,
Lukas Bulwahn <lukas.bulwahn@redhat•com>,
linux-kernel@vger•kernel.org, Juergen Gross <jgross@suse•com>,
Helge Deller <deller@gmx•de>, Ryan Roberts <ryan.roberts@arm•com>,
Marc Zyngier <maz@kernel•org>, Ard Biesheuvel <ardb@kernel•org>,
Vincent Donnefort <vdonnefort@google•com>,
Alice Ryhl <aliceryhl@google•com>,
x86@kernel•org, linux-arm-kernel@lists•infradead.org
Subject: Re: [PATCH v3 2/2] kconfig: Remove the architecture specific config for Propeller
Date: Thu, 4 Jun 2026 15:39:44 +0100 [thread overview]
Message-ID: <aiGOMPZfk7LIAb59@willie-the-truck> (raw)
In-Reply-To: <CAF1bQ=S-p+Mi80a8C8pZzJ3E3bW_5tr6WBUKVV1LaXC9iBor=g@mail.gmail.com>
On Wed, Jun 03, 2026 at 03:15:02PM -0700, Rong Xu wrote:
> On Tue, Jun 2, 2026 at 6:54 PM Nathan Chancellor <nathan@kernel•org> wrote:
> >
> > On Tue, Jun 02, 2026 at 10:52:48AM -0700, Rong Xu wrote:
> > > On Tue, Jun 2, 2026 at 2:43 AM Will Deacon <will@kernel•org> wrote:
> > > > I still don't think it has anything to do with the arch. If the compiler
> > > > supports the option, then we can use it. The arch code in the kernel
> > > > doesn't need to do anything, right? So can you just check if the
> > > > compiler accepts the option using a 'depends on $(cc-option, ...)' line?
> > >
> > > Yes, arch code in the kernel does not need to do anything—it is just a marker.
> > >
> > > I understand your concern. I can use (cc-options,...) in PROPELLER_CLANG config.
> > > But I will not use -fbasic-block-address-map for backward compatiliby reason.
> > > I would use "-fbasic-block-sections=list=/dev/null".
> > >
> > > I'll send the updated patch shortly.
> >
> > Technically, an architecture needs to add the section generated by this
> > compiler option to their linker script to avoid an orphan section
> > warning (or error from CONFIG_WERROR) if enabled, as has been done in
> > this series.
> >
> > I worry that moving to a dynamic check will cause build breakage if an
> > LLVM target gains support for Propeller without having their kernel
> > image linker script adjusted. Maybe that will not happen very often and
> > even if it does, I do not mind taking on the maintenance burden of
> > fixing it but there is a cost of moving to a dynamic check like this.
> >
>
> This is true.
>
> That said, these orphan sections usually won't impact correctness. The
> linker will group these together even withgout the link script change,
> even though it generates a lot of warnings.
>
> With moving to a dynamic check, correct usage of this feature remains
> the user's responsibility -- I think this is Will's point from the
> very beginning.
> As noted in your previous response, the dynamic check is primarily
> intended to prevent "allmodconfig" build failures.
>
> I am comfortable with either the arch_kconfig or dynamic_check
> approach. Once a preferred solution is decided, please let me know so
> I can submit v4 for review.
I continue to object to the pointless ARCH_ selection and much prefer
having the core Kconfig check the cc-option.
Will
next prev parent reply other threads:[~2026-06-04 14:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 21:45 [PATCH v3 0/2] kconfig: Remove the architecture specific config for AutoFDO and Propeller xur
2026-05-27 21:45 ` [PATCH v3 1/2] kconfig: Remove the architecture specific config for AutoFDO xur
2026-05-30 0:47 ` Nathan Chancellor
2026-06-01 16:52 ` Rong Xu
2026-06-01 19:24 ` Nathan Chancellor
2026-05-27 21:45 ` [PATCH v3 2/2] kconfig: Remove the architecture specific config for Propeller xur
2026-05-30 0:47 ` Nathan Chancellor
2026-06-01 18:18 ` Rong Xu
2026-06-02 9:43 ` Will Deacon
2026-06-02 17:52 ` Rong Xu
2026-06-03 1:53 ` Nathan Chancellor
2026-06-03 22:15 ` Rong Xu
2026-06-04 14:39 ` Will Deacon [this message]
2026-05-29 16:32 ` [PATCH v3 0/2] kconfig: Remove the architecture specific config for AutoFDO and Propeller Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aiGOMPZfk7LIAb59@willie-the-truck \
--to=will@kernel$(echo .)org \
--cc=aliceryhl@google$(echo .)com \
--cc=ardb@kernel$(echo .)org \
--cc=arnd@arndb$(echo .)de \
--cc=bp@alien8$(echo .)de \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=deller@gmx$(echo .)de \
--cc=hpa@zytor$(echo .)com \
--cc=jgross@suse$(echo .)com \
--cc=kees@kernel$(echo .)org \
--cc=linusw@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=lukas.bulwahn@redhat$(echo .)com \
--cc=mathieu.desnoyers@efficios$(echo .)com \
--cc=maz@kernel$(echo .)org \
--cc=mingo@redhat$(echo .)com \
--cc=nathan@kernel$(echo .)org \
--cc=nicolas.schier@linux$(echo .)dev \
--cc=ojeda@kernel$(echo .)org \
--cc=peterz@infradead$(echo .)org \
--cc=ruanjinjie@huawei$(echo .)com \
--cc=ryan.roberts@arm$(echo .)com \
--cc=shenhan@google$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
--cc=vdonnefort@google$(echo .)com \
--cc=x86@kernel$(echo .)org \
--cc=xur@google$(echo .)com \
--cc=yabinc@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox