Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3751091imj; Tue, 19 Feb 2019 08:49:21 -0800 (PST) X-Google-Smtp-Source: AHgI3IbWJh4nLlRmzLBO2aaqKtY4w0g2Y97XImNQ3sXeyerPUBBrx69Tn7u0y4orwvRaV6uN4BgK X-Received: by 2002:a63:d507:: with SMTP id c7mr17018106pgg.105.1550594961922; Tue, 19 Feb 2019 08:49:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550594961; cv=none; d=google.com; s=arc-20160816; b=CNRfG5yH/x9ZAYVZhyALmmBdoaUBTNb101HdAf67RzL/z2gujH1P+KZlck9QZdpKSU ZdRVX3LGcO0hujRPyLk9raTOaxFMfdG4zuCFcvhWNWju4V5YLCOFCZ4HbG+qfAXjMxth iJr0HKo6fKwyXnXCkyk1qn2SlbOB3N3iUlpBLuBzU7DScoqsGmdaHrdIQJBIMw7xjk8U aXvp/3ysHgXQR3QJmNU55g6SNwjlYzc/k1CUjvRAXSsA2eBpti8JW2LJyggnsdrGq4Sy T8GC23HXJpRfaUCzwPlpxTa15j6AsQfYJ2xLhYLFqDNd2KPXQ9zmugQ3nyFpW5Yy6cWr H/ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=CkveCeBrVw9HJ1ikRKA46WvInoaDjP4Wjcz4wrC9a78=; b=kyOVVXeRkgE7WYM8fMWh8gBPt5FEKl2N8qTEN13bPC8A0fwggA/dCo4WMNQyqnqCaq 5cFPog7k0nLJzWIH0ru5NqRmqELs/SBW8Tm4LoQWeLiu/gCGLy+Lc+kIOCaFc2IVmfQ2 D9YQvoQjm//yvaqPBMvJmP7iAkitPY9at3v81tsIsMR5l2By5XlUcE/2Wa/CzeKBsRqT FSMfggpOMrO2V2QcQaRDmtcCeSMqCVZhgs6DEY3pQ+UNzQg/abCedjgNbPDHRBZRXp89 JuPpzihSCQl0yyoAkS5sZAzCKW6LWlkaSgT7+Z6zDeE4xJIj406O2eevN+vtAtfehEu2 j9Aw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q11si15005546pgv.595.2019.02.19.08.49.06; Tue, 19 Feb 2019 08:49:21 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729091AbfBSQsb convert rfc822-to-8bit (ORCPT + 99 others); Tue, 19 Feb 2019 11:48:31 -0500 Received: from mx2.suse.de ([195.135.220.15]:60984 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725820AbfBSQsb (ORCPT ); Tue, 19 Feb 2019 11:48:31 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 029C3AE26; Tue, 19 Feb 2019 16:48:29 +0000 (UTC) Date: Tue, 19 Feb 2019 17:48:29 +0100 From: Thomas Bogendoerfer To: Marc Zyngier Cc: Thomas Gleixner , Subject: Re: [PATCH v2 09/10] genirq/irqdomain: fall back to default domain when creating hierarchy domain Message-Id: <20190219174829.26576a5b6bf62cd99adf294a@suse.de> In-Reply-To: <20190219162716.04b0a54b@why.wild-wind.fr.eu.org> References: <20190219155728.19163-1-tbogendoerfer@suse.de> <20190219155728.19163-10-tbogendoerfer@suse.de> <20190219162716.04b0a54b@why.wild-wind.fr.eu.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 Feb 2019 16:27:16 +0000 Marc Zyngier wrote: > On Tue, 19 Feb 2019 16:57:23 +0100 > Thomas Bogendoerfer wrote: > > Hi Thomas, > > > When creating hierarchy domains use irq_default_domain as parent, if no > > parent was given by the caller. This avoids adding helper code for > > querying the underlying platform irq domain. > > > > Signed-off-by: Thomas Bogendoerfer > > --- > > kernel/irq/irqdomain.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > > index 8b0be4bd6565..617c482d0778 100644 > > --- a/kernel/irq/irqdomain.c > > +++ b/kernel/irq/irqdomain.c > > @@ -1021,7 +1021,10 @@ struct irq_domain *irq_domain_create_hierarchy(struct irq_domain *parent, > > else > > domain = irq_domain_create_tree(fwnode, ops, host_data); > > if (domain) { > > - domain->parent = parent; > > + if (parent) > > + domain->parent = parent; > > + else > > + domain->parent = irq_default_domain; > > domain->flags |= flags; > > } > > > > I'm really not keen on this. The whole "default domain" made sense at a > distant point in time (when irqdomains were new and platform code was > blissfully ignoring it), but it really looks like a sore spot in the > hierarchy code, which assumes that you always know what you're building > your hierarchy on top of. > > It also create a small issue in the sense that you can create a root > domain using irq_domain_create_hierarchy() by passing NULL as the > parent. With this patch, the new domain now points to the default one, > with unexpected consequences. > > So let's come back to first principles: How comes you can't obtain the > parent domain at creation time? Because I'd rather give you a way to > retrieve it instead if this. the bridge irq domain could be stacked on different underlying irq domains for different platforms (HUB is IP27, HEART for IP30 and BEDROCK for IP35). And my idea was to set a irq default domain in the IP27/IP30/IP35 platform code so that bridge code will pick up the correct underlying irq domain. As there is no device tree I haven't found an already implemented other way. Right now I have two idea to solve my problem without this patch: - implement a SGI specific helper for getting the underlying irq domain - use a helper function to read irq_default_domain What do you prefer ? Or do you see something else ? Thomas. -- SUSE Linux GmbH GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg)