Re: [PATCH v3 2/2] kconfig: Remove the architecture specific config for Propeller

[Will Deacon]

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@xxxxxxxxxx> 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@xxxxxxxxxx> 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