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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A7AEC433F5 for ; Tue, 12 Apr 2022 18:21:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358687AbiDLSXu (ORCPT ); Tue, 12 Apr 2022 14:23:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233150AbiDLSXt (ORCPT ); Tue, 12 Apr 2022 14:23:49 -0400 Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52A645D64B; Tue, 12 Apr 2022 11:21:31 -0700 (PDT) Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-d6ca46da48so21586696fac.12; Tue, 12 Apr 2022 11:21:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=I9K/IbA6njg/QBogrNbqGgrHZw9vf98X/iD1tq6MrZU=; b=O0UP0rLpyee8/U74KLDMSJTKFZIZaKmPv4EWTyP53yjzC2dkt77IqfUGtpndulFrWk fpfL6iOo/Fnif8xFbziMEnMbJnYIeKwCNg/JugsnGh8/LN7sIrrHSond8m3LZzDCXhxX vN9xtEYzmSc5O6VDB/U1XcEJj1NDslLYPS9qIszBb0ZC8nzsU6CkFsor3Xw0886ooVfY B6uXH8j/pA0pIfOLAWsIxq69DRIRM+FjlwdlO+/97+vEaFtRsae5qcOxRWTbwuittIbE kVUg/p0jtYTQ1FOS3a8kNcuZ1sT9Ss+G0MpKPcFPULopFlYMg4kxS1x0NeGDdTTsN1Tf fNxw== X-Gm-Message-State: AOAM532vzEdQ86xSRStjmv3yMk+QiZrkcYtEnHUuhGCgBr/mKRuqq2uz LvsjNyBE7C+Xjsznx9PKMQ== X-Google-Smtp-Source: ABdhPJwpHRJvNnM83ToUTv3S4bhcDhv4xGnfrj++Kx0/XfUfWlY1G9l0jnSkcRNRMsN4OqKnUnQN5w== X-Received: by 2002:a05:6870:2197:b0:e2:a317:3d8 with SMTP id l23-20020a056870219700b000e2a31703d8mr2665045oae.162.1649787690571; Tue, 12 Apr 2022 11:21:30 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id 65-20020aca0544000000b002f980b50140sm8860760oif.18.2022.04.12.11.21.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 11:21:30 -0700 (PDT) Received: (nullmailer pid 572909 invoked by uid 1000); Tue, 12 Apr 2022 18:21:29 -0000 Date: Tue, 12 Apr 2022 13:21:29 -0500 From: Rob Herring To: Samuel Holland Cc: Rob Herring , Marc Zyngier , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Frank Rowand Subject: Re: [PATCH v3] of/irq: Use interrupts-extended to find parent Message-ID: References: <20220412051529.6293-1-samuel@sholland.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220412051529.6293-1-samuel@sholland.org> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, 12 Apr 2022 00:15:28 -0500, Samuel Holland wrote: > The RISC-V PLIC binding uses interrupts-extended to specify its parent > domain(s). That binding does not allow the interrupt-parent property to > appear in the irqchip node. This prevents of_irq_init from properly > detecting the irqchip hierarchy. > > If no interrupt-parent property is present in the enclosing bus or root > node, then desc->interrupt_parent will be NULL for both the per-CPU > RISC-V INTC (the actual root domain) and the RISC-V PLIC. Similarly, if > the bus or root node specifies `interrupt-parent = <&plic>`, then > of_irq_init will hit the `desc->interrupt_parent == np` check, and again > all parents will be NULL. So things happen to work today for some boards > due to Makefile ordering. > > However, things break when another irqchip ("foo") is stacked on top of > the PLIC. The bus or root node will have `interrupt-parent = <&foo>`, > since that is what all of the other peripherals need. When of_irq_init > runs, it will try to find the PLIC's parent domain. of_irq_find_parent > will fall back to using the interrupt-parent property of the PLIC's > parent node (i.e. the bus or root node), and of_irq_init will see "foo" > as the PLIC's parent domain. But this is wrong, because "foo" is > actually the PLIC's child domain! > > So of_irq_init wrongly attempts to init the stacked irqchip before the > PLIC. This fails and breaks booting. > > Fix this by using the first node referenced by interrupts-extended as > the parent when that property is present. This allows of_irq_init to see > the relationship between the PLIC and the per-CPU RISC-V INTC, and thus > only the RISC-V INTC is (correctly) considered a root domain. > > Signed-off-by: Samuel Holland > --- > > Changes in v3: > - Move the check into of_irq_init. Do not touch of_irq_find_parent. > > Changes in v2: > - Add comments noting the assumptions made here > > drivers/of/irq.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > Applied, thanks!