Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 31 Mar 2022 11:53:36 +0200
From:   Christoph Hellwig <hch@lst.de>
To:     Heiko Stuebner <heiko@sntech.de>
Cc:     palmer@dabbelt.com, paul.walmsley@sifive.com,
        aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org, wefu@redhat.com,
        liush@allwinnertech.com, guoren@kernel.org, atishp@atishpatra.org,
        anup@brainfault.org, drew@beagleboard.org, hch@lst.de,
        arnd@arndb.de, wens@csie.org, maxime@cerno.tech,
        gfavor@ventanamicro.com, andrea.mondelli@huawei.com,
        behrensj@mit.edu, xinhaoqu@huawei.com, mick@ics.forth.gr,
        allen.baum@esperantotech.com, jscheid@ventanamicro.com,
        rtrauben@gmail.com, samuel@sholland.org, cmuellner@linux.com,
        philipp.tomsich@vrull.eu
Subject: Re: [PATCH v8 02/14] riscv: integrate alternatives better into the
 main architecture
Message-ID: <20220331095336.GB23422@lst.de>
References: <20220324000710.575331-1-heiko@sntech.de> <20220324000710.575331-3-heiko@sntech.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220324000710.575331-3-heiko@sntech.de>
User-Agent: Mutt/1.5.17 (2007-11-01)
Precedence: bulk

On Thu, Mar 24, 2022 at 01:06:58AM +0100, Heiko Stuebner wrote:
> Right now the alternatives need to be explicitly enabled and
> erratas are limited to SiFive ones.
> 
> Over time with more SoCs and additional RiscV extensions, many more
> erratas or other patch-worthy features will emerge, so it doesn't
> really make sense to have the core alternatives able to get
> deactivated.
> 
> So make it part of the core RiscV kernel and drop the main
> RISCV_ERRATA_ALTERNATIVES config symbol.
> 
> This mimics how other architectures like for example arm64 handle
> their alternatives implementation.

For minimal kernels like the k210 it would be really good to be
able to avoid any not strictly neeed code.  So I'd much rather
have the alternatives mechanism only built when it actually is needed,
not (semi-)unconditional.