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 1B0DD13B293 for ; Thu, 4 Jun 2026 14:39:52 +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=1780583994; cv=none; b=BK9pCoeXK8XMkkOI4x8h4+qbD3qily1gwW4JXew/HIPK9vYEEZv6szBtvsg+jrVYdnQn/Fz6tTyummTR2gOUVKYnwKiThWT3wgPoyf4PSvVCgUYakAgYeE5DDLQyCiJxuj9xnT6nHj2spSRDMgwPTYYMkvho2gnE9kYdiLSQRiI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780583994; c=relaxed/simple; bh=jsspGrc/g21SEqbQ7sJBZ/S7nQfeaZcXfDBKE0Ak6PM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NoLuM2WLL67Fet6gQpyPGRq6G3GVzL7saZbgPNlawCh/p+1D3Iru7eZKVq720lHbu7BmH9R6Dzhg6Lwq0n+2STbdkCS9I4ElkEzqhRVxwiD/MxZ6ApTWXXVbwijj4RzfmTDXZNi0dz73d3bzus8PJx2X4kK8ktfELPHjxBknIzg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EpSXDkSM; 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="EpSXDkSM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAB041F00893; Thu, 4 Jun 2026 14:39:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780583992; bh=ee8P1tFhKxvly/ZTq0b1RUjGrPK1o7ySfvF6TcwJsFA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=EpSXDkSMw5AZDuqlPmQPMNc8l0eY9JmMHDAbRtmbiB0NzKYOygRT2U0DkZ5/FygiN 7qF5RKNNjOzUtNx+qrXa1QVriiUWFYNBPY+SHvo8Go3QvS9x+NI1iEEsoFAwicSlHE GeREOhls4S+i2b4vAJrTsREN2YR8RJl6M3fG+p7sepnb6sLonpGuZWJgbgpuH0ydSs cxXYgdnLOF8EtniLsDjEy0gbeRrowImn05V/vvwacM/xCJnIZCmnxwD+78QDrq0Mjj GmP1+MyBiN3zxQfPT8X6/aYXFld0uDC99xa50CEHk/AtvO1/4sRkk2rpfLvXdciWeZ fbIuiVkwwEL4g== Date: Thu, 4 Jun 2026 15:39:44 +0100 From: Will Deacon To: Rong Xu Cc: Nathan Chancellor , 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: References: <20260527214510.3907973-1-xur@google.com> <20260527214510.3907973-3-xur@google.com> <178010203122.3743687.12531843798236779880.b4-review@b4> <20260603015354.GD1940387@ax162> 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 Wed, Jun 03, 2026 at 03:15:02PM -0700, Rong Xu wrote: > On Tue, Jun 2, 2026 at 6:54 PM Nathan Chancellor 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 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