From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39B9133F5BF for ; Wed, 3 Jun 2026 01:54:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780451643; cv=none; b=syEpggiqoZ4kD6JxueOoZ7HY9SP4wnFjIZ355fC56E9or5rSr/ybt6E7GMOC/jyD/jDVcUCj54NdrY7Fq/ToBnl9LS3t8SAaQZgG0HfPtBU42LPUzbOg1vIJuqGDPhW14Z8WKp7UgXA9+wojvCVb0wJEs/l/o3vQRoqCzeHyR8Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780451643; c=relaxed/simple; bh=GdRubps+wVyTU+9ahv7/FFmZMJJezNIj2Dp8ajpG58Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XPCXcN/5e8rcf760GS1vIYBKFB5TPcOnxCs93JfdsQOJgtH9YCW5PVysbkUfE28scJS+Wh4X4aNoqqCM83sEijJduHJ93nB/WFFIyQ81DokX9AxIU6omli52IycfA5K3pktWFYRdvtHNQarWA08osFCpXh8iBPPhhVQBp3BKPhE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WavqzsYT; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WavqzsYT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9024E1F00893; Wed, 3 Jun 2026 01:53:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780451641; bh=KYO62/oFjD0abSuq1/jy6x/O1dFV+Q8x1xWCOazlAO4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=WavqzsYTNF5CF0f9tPKtjHExBLcwiGTWEfzrkVi+S+sOHj5OeXuiDdsf66NDMEbDv ru8+pXG0x6BXMkr19TvhvPwXnjGxMK3aXlySJNSSqP606jdOfaqPZJ9ws/i+PJqr1K +NdOUuThL68NVCtqCUsUsKfuI1XKRQp0YpHz+Lv2A0WybAb+TurHz77WelZkE/zMBy vICgMDDf1xTxvAEEWW7YBk33OJ6ZhUfqv232cT80GTRJfPZn5xt/UuK1Cju4a4D+pq ZSjkp9OoT0LBhZWuzMRwv5YzSKbltkYTGDV+Y//SVrJy8U19komqU043mjtIP3tPGe /mAEKb/fUWfuw== Date: Tue, 2 Jun 2026 18:53:54 -0700 From: Nathan Chancellor To: Rong Xu Cc: Will Deacon , Yabin Cui , Han Shen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Kees Cook , Nicolas Schier , Linus Walleij , Arnd Bergmann , Mathieu Desnoyers , Miguel Ojeda , Peter Zijlstra , Jinjie Ruan , Lukas Bulwahn , linux-kernel@vger.kernel.org, Juergen Gross , Helge Deller , Ryan Roberts , Marc Zyngier , Ard Biesheuvel , Vincent Donnefort , Alice Ryhl , x86@kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 2/2] kconfig: Remove the architecture specific config for Propeller Message-ID: <20260603015354.GD1940387@ax162> References: <20260527214510.3907973-1-xur@google.com> <20260527214510.3907973-3-xur@google.com> <178010203122.3743687.12531843798236779880.b4-review@b4> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jun 02, 2026 at 10:52:48AM -0700, Rong Xu wrote: > On Tue, Jun 2, 2026 at 2:43 AM Will Deacon 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. -- Cheers, Nathan