From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCCD3C4332F for ; Thu, 17 Nov 2022 20:26:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234680AbiKQU0Q (ORCPT ); Thu, 17 Nov 2022 15:26:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230287AbiKQU0N (ORCPT ); Thu, 17 Nov 2022 15:26:13 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D53FA5DBB3 for ; Thu, 17 Nov 2022 12:26:12 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D0986223F for ; Thu, 17 Nov 2022 20:26:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4B4CC433C1; Thu, 17 Nov 2022 20:26:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668716771; bh=NU8WowZ1PcNl92Yu66s+f9tjA31I88naX1GnSsHLwEY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bQWN/ZzRe77jFNpN+Z7bijYO3IPA0lbckgTPH3vOoxXXqnqELUwgAR0IHGDWSG/n3 Y0G4e/vgOH/yHAs+iYVgRkdbOck/bG/apgBRuiz8G4iZnwuyRY51AT6qY5NGkByXnQ CTTY5dH5UM+/TQad55PVYAQ8yEH9GHtaUhqOyiD4Y7URbNOG/Y10F3kI5m+mY9tUJp ZZgSuEOfxIyvgzbnZHB11saQtEFJPa5CQbnZTg+QQxi/h+/ru6o75E2KDMt1RqXRM0 sLFe597R4A6vi3ieXqd1myhm2V4RdVBAn/whR7XfF/pQVY93zIE8difSaQYHYrlMv1 dGsSkALiwx9VQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ovlSb-006pBs-E7; Thu, 17 Nov 2022 20:26:09 +0000 Date: Thu, 17 Nov 2022 20:26:09 +0000 Message-ID: <86wn7tnx9a.wl-maz@kernel.org> From: Marc Zyngier To: Conor Dooley Cc: Thomas Gleixner , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Conor Dooley Subject: Re: [PATCH] irqchip/sifive-plic: default to enabled In-Reply-To: References: <20221117185942.3896559-1-conor@kernel.org> <86y1s9nzja.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: conor@kernel.org, tglx@linutronix.de, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, conor.dooley@microchip.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Nov 2022 19:57:17 +0000, Conor Dooley wrote: > > On Thu, Nov 17, 2022 at 07:36:57PM +0000, Marc Zyngier wrote: > > On Thu, 17 Nov 2022 18:59:43 +0000, > > Conor Dooley wrote: > > > > > > From: Conor Dooley > > > > > > The SiFive PLIC driver is used by all current implementations, including > > > those that do not have a SiFive PLIC. Default the driver to enabled, > > > with the intention of later removing the current "every SOC selects > > > this" situation in Kconfig.socs at the moment. > > > > > > The speculative "potential others" in the description no longer makes > > > any sense, as the driver is always used. Update the Kconfig symbol's > > > description to reflect the driver's ubiquitous state. > > > > > > Signed-off-by: Conor Dooley > > > --- > > > Hey Marc, > > > > > > I recall some discussion when this driver was extended to other PLICs a > > > few months ago: > > > https://lore.kernel.org/linux-riscv/20511a05f39408c8ffbcc98923c4abd2@kernel.org/ > > > > > > Perhaps I got the wrong impression, but it seemed to me that you intend > > > for future implementations to reuse this driver where possible? > > > > Well, within reasons. People seem to have some very liberal > > interpretations of the architecture spec... > > Yeah, I know.. something something "RISC-V is meant to be extensible" > something something. Even if that means doing some "standard" thing > your own way apparently. Funny how someone's "extensible" is someone else's "terminally broken". I guess HW folks will eventually learn that, possibly the hard way. > > > > I'd like to think, and surely will be proven wrong, that ~all future > > > plic implementations should be similar enough to fit that bill. > > > It's kinda on this basis that I figure switching this thing to default y > > > should be okay. It's already only buildable on RISC-V & every > > > implementation uses it, so no difference there. > > > > If you expect this to be present at all times, why isn't this selected > > by the architecture Kconfig instead? > > Everyone at the moment needs it, but that's not always going to be true. > The AIA APLIC that's currently out for review is the "next generation" > interrupt controller. When we will actually see one in the wild is > another question. > > > I always find it pretty odd to > > have something that is 'default y' and yet constrained by a 'depend > > MYARCH'. A 'select PLIC' would make a lot more sense. > > > > And then you can stop making this user selectable. > > I was considering moving the select to arch level, but settled for this > as while I'd like to stop the individual SOCs doing `select PLIC`, I can > see why someone building for a (future) system with the new AIA stuff > may not care to build it. > > Or maybe the overhead of this one driver is nothing to care about? In the grand scheme of things, it really doesn't matter. Hardly anyone is configuring their own kernel. People use distro kernels, which will have *everything* enabled. As an example, on the arm64 side we have long decided that some things were not worth the trouble, such as selectable root interrupt controllers and non-SMP support. Life is too short to care about those. M. -- Without deviation from the norm, progress is not possible.