Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp573558ybb; Wed, 25 Mar 2020 05:39:53 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuZo6N/uxkklUFx4hVDjiOO28cF1HCabKx9gum9+jp0P10G0y8iRrc3tAOaKQEnSVdBheKg X-Received: by 2002:a4a:1ec3:: with SMTP id 186mr996832ooq.66.1585139993052; Wed, 25 Mar 2020 05:39:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585139993; cv=none; d=google.com; s=arc-20160816; b=DpWgJc0tjC/R1Ddm+Lg6AHc+O16jCFAaVjqWBgNUMYfwxX8wTc5C+/XE+kpPkpsV4Z XrG1Im1BoGvzAYGzO8UM6DcSc17GUR48w3CR2lit/pgKF/cG0B/IYsm7xVdBP4gwzVMT zq2L4IPoc75DOyrl1Z3UAFiU9zS9Vq3n7UHOPKZY5zZBt3pqNdHyuSvVw8ZNg9CQO30t 36udp2Aun387F0JKKeWkR6f3zR3W2LYx3+bbvxm6bljcdMagS0/JgmmC2wb/CrNPlGN3 /cvk3jTuiCO3jgvjCLNDi4PIa3vq6PaH3YoTxUou7ffaYK4SkNEt+8p+uMYFCcbD2YkL 0Q4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=2k1ofVYfYeqNDo0GMSN+8g1bxaYyz40Upz8z7acAnjY=; b=dAoeqC3cn+Rz2BGEEFKRUEfROGf3JVGLOStLPaybIdJjMGPXUWTVZNPbg+pryO3wRf wlBHZ8dSxmrBEsy9MzXze7SJQwV9eF4nOp4Q7mPi2GXImOdA0AHZxK4rb7AviMOftOTB RtH3+uWRzQG6f6gpR8GB5CmPe+8+S2QOnzvaiQ1JmeKver5PCq799GbkTHvBwViUJxdC aiFu1U2alKMJor12juq7abhCjLuKlgA1r/B803AeZpFYxm3hdK/BvnaUV88+3rw/SBfF JJNSMf5IKDdj0h/8YOkTmpU8LDZjkZIHdu+NnKjsb2I4JkgZaHhcd7cXCuoT2haKfvxA wQ1w== 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 a13si13143929otk.158.2020.03.25.05.39.38; Wed, 25 Mar 2020 05:39:53 -0700 (PDT) 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 S1727459AbgCYMjV (ORCPT + 99 others); Wed, 25 Mar 2020 08:39:21 -0400 Received: from elvis.franken.de ([193.175.24.41]:34061 "EHLO elvis.franken.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727316AbgCYMjV (ORCPT ); Wed, 25 Mar 2020 08:39:21 -0400 Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1jH5JN-0002o0-00; Wed, 25 Mar 2020 13:39:09 +0100 Received: by alpha.franken.de (Postfix, from userid 1000) id B928DC09A5; Wed, 25 Mar 2020 13:37:42 +0100 (CET) Date: Wed, 25 Mar 2020 13:37:42 +0100 From: Thomas Bogendoerfer To: Jiaxun Yang Cc: linux-mips@vger.kernel.org, Huacai Chen , Marc Zyngier , Thomas Gleixner , Jason Cooper , Rob Herring , Mark Rutland , Mauro Carvalho Chehab , "David S. Miller" , Greg Kroah-Hartman , Jonathan Cameron , Andy Shevchenko , Allison Randal , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v8 06/11] irqchip: mips-cpu: Convert to simple domain Message-ID: <20200325123742.GA9911@alpha.franken.de> References: <20200325035537.156911-1-jiaxun.yang@flygoat.com> <20200325035537.156911-7-jiaxun.yang@flygoat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200325035537.156911-7-jiaxun.yang@flygoat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 25, 2020 at 11:54:59AM +0800, Jiaxun Yang wrote: > The old code is using legacy domain to setup irq_domain for CPU interrupts > which requires irq_desc to be preallocated. > > However, when MIPS_CPU_IRQ_BASE >= 16, irq_desc for CPU IRQs may end up > unallocated and lead to incorrect behavior. > > Thus we convert the legacy domain to simple domain which can allocate > irq_desc during initialization. > > Signed-off-by: Jiaxun Yang > Co-developed-by: Huacai Chen > Signed-off-by: Huacai Chen > Reviewed-by: Marc Zyngier > --- > drivers/irqchip/irq-mips-cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mips-cpu.c b/drivers/irqchip/irq-mips-cpu.c > index 95d4fd8f7a96..c3cf7fa76424 100644 > --- a/drivers/irqchip/irq-mips-cpu.c > +++ b/drivers/irqchip/irq-mips-cpu.c > @@ -251,7 +251,7 @@ static void __init __mips_cpu_irq_init(struct device_node *of_node) > clear_c0_status(ST0_IM); > clear_c0_cause(CAUSEF_IP); > > - irq_domain = irq_domain_add_legacy(of_node, 8, MIPS_CPU_IRQ_BASE, 0, > + irq_domain = irq_domain_add_simple(of_node, 8, MIPS_CPU_IRQ_BASE, > &mips_cpu_intc_irq_domain_ops, > NULL); this breaks at least IP30 and guess it will break every platform where MIPS_CPU_IRQ_BASE == 0. add_legacy will always do irq_domain_associate_many(), while add_simple doesn't do it, if first_irq == 0. Marc, what is the reason not doing it all the time ? What's the correct way here to work with irq_domain_add_simple() in this case ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]