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 X-Spam-Level: X-Spam-Status: No, score=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29BC3C4363C for ; Wed, 7 Oct 2020 08:06:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A02C22076C for ; Wed, 7 Oct 2020 08:06:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QZRjqeV2"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="yZsHLsXp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A02C22076C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2lpLDkfpDFE896+Am9qwKLPq9pEdzqI1OkKVln6oeaA=; b=QZRjqeV2BxexqtSj6qE8OBhAQ SykEfF96IjoSUquWWtEomtQVvw0qNJefS/76r2DxFKwLgFu91auz1tMxwWDbOXFWGhARu7slssZC9 0oydtDZHTlaW7k6mzWAr1sXg/N+rByw0LfccPEjh3/20VBfdXybJas4+fCh/oSwin1n9bvbg5jIqF LFvl8EYPb1fMxmY4GiFItIcPYzsEz07unB/IjrQr+fWinks3V/e72RjopQMxwH5VTUVGt4HFsZSuI cR2pRXvuSUeHWoV+5eM6HNy+ClVm/HB8r3e++eNJQac8RABq4PfOIsMD9zxmplC9tkmS4UqbbUXqP im5Ad+lsg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ4SC-00089j-Uz; Wed, 07 Oct 2020 08:05:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ4SA-000895-Ip for linux-arm-kernel@lists.infradead.org; Wed, 07 Oct 2020 08:05:39 +0000 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 691F42076C; Wed, 7 Oct 2020 08:05:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602057937; bh=qSgDO/KF1PkgYuOLLQdWJ8Ae8ug3/f7wzPW5vva4H1E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=yZsHLsXpN5Jwt3RVPi2o2roe4CmqWmEzWxtUjFpy6HhUqcC6FHSabw/mvacXdmP7M ie6GlFzTrw/DAjNeJdQz30TZAW2X2ZmDwBKKtg4gpvaTVhlh4ee6qDPd5UzTwo/Rq5 nWNh4bnHthFMgoxuP02WPmnTY54gdbOjD9vKYXGk= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kQ4S7-000I86-BD; Wed, 07 Oct 2020 09:05:35 +0100 MIME-Version: 1.0 Date: Wed, 07 Oct 2020 09:05:34 +0100 From: Marc Zyngier To: Thomas Gleixner Subject: Re: [PATCH v2 1/4] genirq/irqdomain: Allow partial trimming of irq_data hierarchy In-Reply-To: <87eemb6qdj.fsf@nanos.tec.linutronix.de> References: <20201006101137.1393797-1-maz@kernel.org> <20201006101137.1393797-2-maz@kernel.org> <87eemb6qdj.fsf@nanos.tec.linutronix.de> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <10788c0d08fccbcbc1ac590a855e70d3@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: tglx@linutronix.de, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, thierry.reding@gmail.com, jonathanh@nvidia.com, digetx@gmail.com, skomatineni@nvidia.com, vreddytalla@nvidia.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201007_040538_699969_71FB1890 X-CRM114-Status: GOOD ( 17.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Venkat Reddy Talla , linux-kernel@vger.kernel.org, Jonathan Hunter , Thierry Reding , Sowjanya Komatineni , linux-tegra@vger.kernel.org, Dmitry Osipenko , kernel-team@android.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-10-06 21:39, Thomas Gleixner wrote: > On Tue, Oct 06 2020 at 11:11, Marc Zyngier wrote: >> It appears that some HW is ugly enough that not all the interrupts >> connected to a particular interrupt controller end up with the same >> hierarchy repth (some of them are terminated early). This leaves > > depth? > >> the irqchip hacker with only two choices, both equally bad: >> >> - create discrete domain chains, one for each "hierarchy depth", >> which is very hard to maintain >> >> - create fake hierarchy levels for the shallow paths, leading >> to all kind of problems (what are the safe hwirq values for these >> fake levels?) >> >> Instead, let's offer the possibility to cut short a single interrupt > > s/let's offer/implement/ Thanks for that, I'll fix it locally. [...] > This is butt ugly, really. Especially the use case where the tegra PMC > domain removes itself from the hierarchy from .alloc() I don't disagree at all. It is both horrible and dangerous. My preference would have been to split the PMC domain into discrete domains, each one having having its own depth. But that's incredibly hard to express in DT, and would break the combination of old/new DT and kernel. > That said, I don't have a better idea either. Sigh... A (very minor) improvement would be to turn the trim call in the PMC driver into a flag set in the first invalid irq_data structure, and let __irq_domain_alloc_irqs() do the dirty work. Still crap, but at least would prevent some form of abuse. Thoughts? M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel