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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1862AC433EF for ; Thu, 28 Oct 2021 09:03:48 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 508B460232 for ; Thu, 28 Oct 2021 09:03:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 508B460232 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4A6CC831B4; Thu, 28 Oct 2021 11:03:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id BF11B83178; Thu, 28 Oct 2021 11:03:42 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 1BA8C81FC6 for ; Thu, 28 Oct 2021 11:03:39 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=maz@kernel.org 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 B7C2060232; Thu, 28 Oct 2021 09:03:36 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] 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.2) (envelope-from ) id 1mg1Hy-0025ec-Ce; Thu, 28 Oct 2021 10:03:34 +0100 Date: Thu, 28 Oct 2021 10:01:34 +0100 Message-ID: <871r45bk0h.wl-maz@kernel.org> From: Marc Zyngier To: Michael Walle Cc: u-boot@lists.denx.de, Vladimir Oltean , Hou Zhiqiang , Bharat Gooty , Rayagonda Kokatanur , Simon Glass , Priyanka Jain , Tom Rini Subject: Re: [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree In-Reply-To: <20211027165454.1501398-1-michael@walle.cc> References: <20211027165454.1501398-1-michael@walle.cc> 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: 185.219.108.64 X-SA-Exim-Rcpt-To: michael@walle.cc, u-boot@lists.denx.de, vladimir.oltean@nxp.com, Zhiqiang.Hou@nxp.com, bharat.gooty@broadcom.com, rayagonda.kokatanur@broadcom.com, sjg@chromium.org, priyanka.jain@nxp.com, trini@konsulko.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Wed, 27 Oct 2021 17:54:52 +0100, Michael Walle wrote: > > Please stop throwing every ad-hoc information in the device tree. Use the > official bindings (or maybe some bindings which will get approved soon). > > On the quest of syncing the device tree used in u-boot with the one used in > linux, there is this nice piece: > > gic_lpi_base: syscon@0x80000000 { > compatible = "gic-lpi-base"; > reg = <0x0 0x80000000 0x0 0x100000>; > max-gic-redistributors = <2>; > }; > > There is no offical binding for it. Also, the chances that there will be > one are virtually zero. We need to get rid of it. In fact, most information > there are already known or can be deduced via the offical binding. It is not "virtually zero". It is *exactly* zero. This node only shows that the author didn't understand the nature of the problem, nor were they aware of the existing solution which has been around since July 2018. This solution doesn't require any update to the binding, only to reserve the memory. I really wish people would stop piling crap in u-boot, and that the u-boot maintainers would reach out to people familiar with the architecture before merging this sort of changes. > > More than a month ago NXP [1] said they will look into it and try to get > the bindings together. I don't think this will happen. Actually, I don't > think the culprit is that commit, but rather the one which introduced that > broken binding in the first place [2]. Therefore, revert it, too. > > The funny thing is, I don't even know why this is needed at all. Linux will > happily setup the LPI for us. At least for the LS1028A (but I guess also > for all other layerscape SoC) the u-boot LPI setup code is only called > right before we jump to linux. So u-boot doesn't even seem to use the > interrupts. Now I can't speak of the Broadcom NS3 SoC where this 'feature' > was introduced in the first place [3]. Unfortunately, it's not mentioned in > the commit log *why* it was introduced. But this also seem to have crept > into the layerscape SoCs [4]. All layerscape boards have CONFIG_GIC_V3_ITS > enabled, well except for one; mine, the kontron_sl28 (which has a LS1028A). > I haven't noticed anything out of the ordinary, though. Why is > CONFIG_GIC_V3_ITS needed? Now, that's a very interesting question: u-boot doesn't know how to drive an ITS (there is no support code for it, despite what arch/arm/lib/gic-v3-its.c suggest). Only the LPI allocation code is there. For what purpose? This is a pretty useless piece of code as far as I can see, unless the author had some unspecified ulterior motives (in which case a bit of documentation and a renaming of this file wouldn't go amiss). Thanks, M. -- Without deviation from the norm, progress is not possible.