Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp885374pxf; Wed, 7 Apr 2021 14:08:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuhv8uU2Ijyrz8JuX58d1tjgNH9MzDSsQtXRkhbRSGiKAsqhkoVtcTQ4dz4zbnzA2+1iTM X-Received: by 2002:a92:b747:: with SMTP id c7mr4189117ilm.242.1617829681919; Wed, 07 Apr 2021 14:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617829681; cv=none; d=google.com; s=arc-20160816; b=yZWn0mRyuCrBWSnKixZMUKUzh6TBDJ7N5HyiT5D020wWr0opPJRPE2/rbKeT8pwAB1 tv1cT/hAdQyIdW2qfAAiMfiTUn8nzHgW6yny9SVWhg/JrWOYARNkxjfpCCOopyl9kLWi PMM9mOL1rh3MrTfNHFGwf0YTtlLcyYYXWP1+58jXaYGlNgQRi7yT8KUmodFVtg7CFYhh 6A44IBF3mAkDAZyJPYkJciSkxbRfxLpXe+HqfTuFGdg8VpOf9pG5n0+8isUwuF8RZnVf OGPrKhST3TXIzz8F45Sxz2pFzz3EsVQFMLLiWjj+/1P1idKuZz5hHrLJkcGSZ/XJcVgw Hu/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=/ZE3NClD3KqnjT4ROQ1TsBEaHGQZKlKWPea6oZsVB5s=; b=RAIXcOkjJVUqsI0yZbyNZJY3xr5Q51Qcija6GPteV1KmhacbRuAlDsKkBRZGqJSCrO bdWe+1vZlrm7ET+VMALcturVciYtN2rVvg/n2sXOZ4sqfMdY9S+587LrXuYWafDhnfBb /p8qEP44nrcykKfDYtntSExFsdDVhCSLyEQu/q1lvyncHZLLFv04A0ogQ9VlgrRl92sB HduwmdqpkVL84rmJRo0b78hkx2SS/5H6YMg0qQKTajeWDRyab0oV6L2ZFEKSyrusZSUN hCkux/6PY1IZqwFnenqU+cXhbJmjVmf+yXHP+lBiOkwxsVgcmj13MIzgEU9PW2qODr9D WYGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=uGmHAP1E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y18si5000468ili.52.2021.04.07.14.07.49; Wed, 07 Apr 2021 14:08:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=uGmHAP1E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345086AbhDGOno (ORCPT + 99 others); Wed, 7 Apr 2021 10:43:44 -0400 Received: from fllv0016.ext.ti.com ([198.47.19.142]:34880 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348773AbhDGOn2 (ORCPT ); Wed, 7 Apr 2021 10:43:28 -0400 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 137EWMlD081494; Wed, 7 Apr 2021 09:32:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1617805942; bh=/ZE3NClD3KqnjT4ROQ1TsBEaHGQZKlKWPea6oZsVB5s=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=uGmHAP1EdO5bHcQhm8Mv+BUmRytLIH1lXKUQ8ha/vXJzZszJg+g3thRoZHCfzUsjO nRb8tupTlEjMU8WCI2dwTSXgblZ5Rx6zPeZP0nvgW3Yh3PlorKvkS3fZPHhxcQUBnd wL4K79yJrIz9iBK7nzad1fSOYKKzk4LQpLSWQjjU= Received: from DFLE105.ent.ti.com (dfle105.ent.ti.com [10.64.6.26]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 137EWMvV045630 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 7 Apr 2021 09:32:22 -0500 Received: from DFLE104.ent.ti.com (10.64.6.25) by DFLE105.ent.ti.com (10.64.6.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 7 Apr 2021 09:32:22 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2 via Frontend Transport; Wed, 7 Apr 2021 09:32:22 -0500 Received: from [10.250.37.105] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 137EWLMA070655; Wed, 7 Apr 2021 09:32:22 -0500 Subject: Re: [PATCH 1/3] remoteproc: pru: Fixup interrupt-parent logic for fw events To: Mathieu Poirier CC: Bjorn Andersson , Grzegorz Jaszczyk , Jan Kiszka , Vignesh Raghavendra , Lokesh Vutla , , , , References: <20210323223839.17464-1-s-anna@ti.com> <20210323223839.17464-2-s-anna@ti.com> <20210406232837.GA330882@xps15> From: Suman Anna Message-ID: <00b3fcf3-c3ed-9c2c-712e-952af019f16b@ti.com> Date: Wed, 7 Apr 2021 09:32:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210406232837.GA330882@xps15> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/6/21 6:28 PM, Mathieu Poirier wrote: > On Tue, Mar 23, 2021 at 05:38:37PM -0500, Suman Anna wrote: >> The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses >> of_irq_find_parent() with PRU device node to get a handle to the PRUSS >> Interrupt Controller at present. This logic however requires that the >> PRU nodes always define a interrupt-parent property. This property is >> neither a required/defined property as per the PRU remoteproc binding, >> nor is relevant from a DT node point of view without any associated >> interrupts. The curret logic finds a wrong interrupt controller and >> fails to perform proper mapping without any interrupt-parent property >> in the PRU nodes. >> >> Fix this logic to always find and use the sibling interrupt controller. >> Also, while at this, fix the acquired interrupt controller device node >> reference properly. >> >> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration") >> Signed-off-by: Suman Anna >> --- >> drivers/remoteproc/pru_rproc.c | 15 ++++++++++++--- >> 1 file changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c >> index 16979c1cd2f4..a9d07c0751be 100644 >> --- a/drivers/remoteproc/pru_rproc.c >> +++ b/drivers/remoteproc/pru_rproc.c >> @@ -284,7 +284,7 @@ static int pru_handle_intrmap(struct rproc *rproc) >> struct pru_rproc *pru = rproc->priv; >> struct pru_irq_rsc *rsc = pru->pru_interrupt_map; >> struct irq_fwspec fwspec; >> - struct device_node *irq_parent; >> + struct device_node *parent, *irq_parent; >> int i, ret = 0; >> >> /* not having pru_interrupt_map is not an error */ >> @@ -312,9 +312,16 @@ static int pru_handle_intrmap(struct rproc *rproc) >> >> /* >> * parse and fill in system event to interrupt channel and >> - * channel-to-host mapping >> + * channel-to-host mapping. The interrupt controller to be used >> + * for these mappings for a given PRU remoteproc is always its >> + * corresponding sibling PRUSS INTC node. >> */ >> - irq_parent = of_irq_find_parent(pru->dev->of_node); > > If I understand correctly when an interrupt controller node wasn't speficied in > the parent this was unwinding until it found one... Correct if not specified in each PRU node, and ends up finding the complete wrong interrupt controller (GIC) as it walks up the tree. > >> + parent = of_get_parent(dev_of_node(pru->dev)); >> + if (!parent) >> + return -ENODEV; >> + >> + irq_parent = of_get_child_by_name(parent, "interrupt-controller"); >> + of_node_put(parent); >> if (!irq_parent) { >> kfree(pru->mapped_irq); >> return -ENODEV; >> @@ -337,11 +344,13 @@ static int pru_handle_intrmap(struct rproc *rproc) >> goto map_fail; >> } >> } >> + of_node_put(irq_parent); >> >> return ret; >> >> map_fail: >> pru_dispose_irq_mapping(pru); >> + of_node_put(irq_parent); > > Reviewed-by: Mathieu Poirier Thanks, Suman > >> >> return ret; >> } >> -- >> 2.30.1 >>