Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp636100pxb; Fri, 16 Apr 2021 14:22:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2Hj8YAIoqfKB7sWef1Tid2r7ypUbQxtVW6qZL68Au/qYaFCw8Y6WHiNcOCcDLJDiIGzh8 X-Received: by 2002:a17:902:ff09:b029:eb:3d5a:1332 with SMTP id f9-20020a170902ff09b02900eb3d5a1332mr11479770plj.24.1618608130565; Fri, 16 Apr 2021 14:22:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618608130; cv=none; d=google.com; s=arc-20160816; b=kWLwST3D8Ym0J+wuxLMDNDszRlOuq6DmYEzshBKGw1ObkLLtsiWVplG3VUupvHxNN1 GlJwlHS8f6G84dqTmFKT1JNodVqrX4wsyE9Dd2KY31muxziUS+ePbeM3OwGkSYu0LkNz 3k4H3ASWycuEVOLhSxIakDlcF0E8UpyyC9nOOFqrVU9d+FPA99ZmEgl4F8ipUcCyzO1p 2T9R9ysJwxNVCPEDAy3r063fb0DoY4hM1wp3lZgYgtPb7/kJGpVJnHO/j99Uh22X8kdT AboJFEujP+vp5I2k+WBU7/BAchuQ8AQcZsf1RWbe+9d0sVS28RmOJWROuXtD/XUYw+kM TuHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=wubk5M4svP3DQ8nvLnvaYRcZEjh5goxAXjTT0mU9RwQ=; b=HMeoOi52bIUwxbK/szzDMpH3thO/kodY57qzWQrn0v5su0xCwNp9Nzm/watlp0SYeZ gPaLXLGiWkC42doOZoskYNrAUZgtmbAZhIbx0lp8p53qxA2HthE1JboUzpJbtNL12Nxy UdVpJNMRaizPmzvbUAqa2rt5o4dDEyFYWbdX6q8Hi4dotmNEzmfmiuvbDX18RwTh5yqu LhByCFiQVWe5H2RjT4FKhdve9lHJqTvHHXRBggjmWDrtNevSiYWFg8EK16Uo9hIh8LVX l77+P3v2SJNaebaKBvcMNuO+T5jQIhZYlbzpxhqRy4ZA2DkfDi5yX9Re/icx3bb13fyd mD4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z15si7559292pgf.291.2021.04.16.14.21.58; Fri, 16 Apr 2021 14:22:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235974AbhDPRyE (ORCPT + 99 others); Fri, 16 Apr 2021 13:54:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:33716 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235868AbhDPRyA (ORCPT ); Fri, 16 Apr 2021 13:54:00 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AFD3961166; Fri, 16 Apr 2021 17:53:35 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lXSer-007uer-Ji; Fri, 16 Apr 2021 18:53:33 +0100 Date: Fri, 16 Apr 2021 18:53:33 +0100 Message-ID: <877dl22k0y.wl-maz@kernel.org> From: Marc Zyngier To: Robert Hancock Cc: "tglx@linutronix.de" , "linux-kernel@vger.kernel.org" , "michal.simek@xilinx.com" Subject: Re: [PATCH] irqchip/xilinx: Expose Kconfig option In-Reply-To: <2834595e6552c81441592a57dc41146d46484143.camel@calian.com> References: <20210415233250.4071772-1-robert.hancock@calian.com> <87zgxys5xn.wl-maz@kernel.org> <2834595e6552c81441592a57dc41146d46484143.camel@calian.com> 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 (x86_64-pc-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: 62.31.163.78 X-SA-Exim-Rcpt-To: robert.hancock@calian.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, michal.simek@xilinx.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 Fri, 16 Apr 2021 17:05:49 +0100, Robert Hancock wrote: > > On Fri, 2021-04-16 at 14:41 +0100, Marc Zyngier wrote: > > On Fri, 16 Apr 2021 00:32:50 +0100, > > Robert Hancock wrote: > > > Previously the XILINX_INTC config option was hidden and only > > > auto-selected on the MicroBlaze platform. However, this IP can also be > > > used on other platforms. Allow this option to be user-enabled. > > > > > > Signed-off-by: Robert Hancock > > > > I don't think this is a good idea. In general, people have no idea > > which interrupt controller they need to select. So you either end-up > > with a missing interrupt controller, or a bunch you really don't need. > > > > This is essentially a platform constraint, and this should directly be > > selected by the platform if you have this IP in your system. > > > > Thanks, > > > > M. > > The problem is essentially that at the platform level, we don't know, other > than in the MicroBlaze case where we know it will be used as the platform's > primary interrupt controller. In our case, we are using this IP core on the > ZynqMP platform as a secondary cascaded interrupt controller in the FPGA > portion of the device. > But many ZynqMP configurations wouldn't have this device present, it > depends on what the user instantiates in the programmable logic. > Also, this core could just as easily be instantiated in standalone > Xilinx FPGAs which could be connected to many different platforms > over a PCIe, AXI, etc. bus. Not compiling it for some users is great if you happen to *know* what you have to select, which is probably a single digit percentage of the people that build their own kernel. At least having it to depend on ZYNQMP (or some other FPGA platform) would narrow it down. And if you have some other HW in your FPGA, you can make the config fragment for this HW select the right interrupt controller. But I'm definitely not keen on making this a universally user-selectable driver. > So I don't think having this as a platform constraint makes sense. I don't think imposing this on *everyone*, across all supported architectures and platforms makes any sense. Surely, people who build their own HW (because that's what we are talking about here) can be bothered to add the small Kconfig fragment that is required to their kernel build. M. -- Without deviation from the norm, progress is not possible.