Received: by 2002:ab2:7041:0:b0:1f4:bcc8:f211 with SMTP id x1csp163864lql; Fri, 12 Apr 2024 06:58:47 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCX40So8HWNBl8dmZTgxkSGWztFj9Ip8141N3WqOkuza7haV7Q/GF0vFvkdM/Gm86zmBoZ7wae2joo4w2wocN7LCq2FaA8sz51+1lVlBBg== X-Google-Smtp-Source: AGHT+IHfPPb++baruwTadHxUPM2wRx4HRrMdVW6v+Pq/EY7RssJ0pxBW7I83XTH64FooBV9D0h2P X-Received: by 2002:a05:6a20:1b16:b0:1a7:528b:33bd with SMTP id ch22-20020a056a201b1600b001a7528b33bdmr2457441pzb.15.1712930326814; Fri, 12 Apr 2024 06:58:46 -0700 (PDT) Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id k4-20020a170902ce0400b001e5c07ce240si753934plg.397.2024.04.12.06.58.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 06:58:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-142764-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@ventanamicro.com header.s=google header.b=JbvBF3Bj; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-142764-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-142764-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 8F87DB21456 for ; Fri, 12 Apr 2024 13:51:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B35BF85954; Fri, 12 Apr 2024 13:51:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="JbvBF3Bj" Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7EB5284FA6 for ; Fri, 12 Apr 2024 13:51:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712929865; cv=none; b=ZtOk0QUa+jmtfxW6oB3YJE2BSewqUvELXBOZn8CxLSX90ex093Xj3PUmUzw8L9Ani6KYvbrGSr1Gh6Al1u3mUA5IRrD1XoiUHIeMa/lDI62vnDiIG5cz75EbKsQlej9jiUFbNaNJqgzDwf0swQUPmCz43zdkHx0gROHH2B8fO1Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712929865; c=relaxed/simple; bh=m1z4lnBjEM8XYSqF+Cb45YhG/mvQJnOYj/iIHznJC5Q=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=eaKU2YCPFOOjt0K7kAyHfrNa+0CuDlkQgr5JuULBCUfBmVZPisJ/wWHEI4N+gqrrN6oKYokWCFu+5bLRdD8HMWwOYhQXFhFRohkILIORxGvK7nDpJbMENhuB3WXSzyPqE78BFzOLbrnpfxIhBC/OsjlAvBSqGLA823yvhxMobrU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=JbvBF3Bj; arc=none smtp.client-ip=209.85.167.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-516d09bd434so1165156e87.1 for ; Fri, 12 Apr 2024 06:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1712929862; x=1713534662; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=g6ftp8YirSnx3Hs03pwZ0/loDPXIVialAS8QDpJUQK4=; b=JbvBF3BjfJ9PHhtedgW5ImNNgmNTOLFGM+NkhdhiAFDxbHGQACUW4OpaFE9z+rfzfR mZRrPVBj5zFPnztBehac4uMCjq8AmlnsBmQ679LAqs4qDUb35i7AAMXQTvEoTe6eoLKz USOuouYtvGjOGbjtvLba6i0ERJpw67A77TFTuDg4t/jCPPP2TDRIMWDlVG8Mbw4TMUJn Dgk/r1aOCrcjSXS30eJAJbD1QkePn1ZZvic+0h7vSqq3AZLkALSX5sEigoa+lClp8916 GG77PzxRumsOSCTe0/MwsFoDQBqqM2GC+g0A/iDnXq7NqcYvOxRsrN8Hyi+hw1dTym2C iBMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712929862; x=1713534662; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=g6ftp8YirSnx3Hs03pwZ0/loDPXIVialAS8QDpJUQK4=; b=D177oBn7Jqrkg5BTYyiSOTBAy5YxSTXvYbtsy/lH9gM7FEwm3SC+vER7X5qopY4TXm Z6iLcJivLoYWC5gYh6DyuE6jZIlyBntnNfTLsCXLgqIKDZX8IqZ7B+a3VwpcwDSalgnM 57zaCjkkAPBnYIpCtU6/hVNB+YBHm0w9YDIQ4uHsWbZeha5Ka17meT1xaBsnqb7jBKBC HmU6o6j1Fmu3xYq24ZgNhpkYQG4DsJ6kqRphJCap34OEkfgWaq47l3Z0f2OMgHKphmDK mxksZBh3WRBcESWZauZHouQcasXTMxNfwHY/ESnJan9yq15wvmoIJsM6CZfDpRQN7BHu Q3Jg== X-Forwarded-Encrypted: i=1; AJvYcCVEJQZURRglua8zPOiiFTkhLCyv11AAcFWhzXQosWw99NN97Gv1cM2hZoh+0mXa4f3SurOYVUgAGp5JPX79C4u+R7V4gOnKihWuyEnl X-Gm-Message-State: AOJu0YxMk1nMyKqNFtx8adux7Ipr9WZ1IDew+/iqpSxN4J7v4KTp6xv4 daIljU0LZbBR/n/PrYVK39t3/obWWs8xyDuAiJmf4vf26ExvlROvS5Yj9geBGIWjkvXxZlavf/B dDayd4CEdrWgWNkR9kS/FNu+Jg8dCYAiMeIwjJw== X-Received: by 2002:a05:651c:620:b0:2d9:f68a:d82c with SMTP id k32-20020a05651c062000b002d9f68ad82cmr1547619lje.41.1712929861426; Fri, 12 Apr 2024 06:51:01 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240412112931.285507-1-apatel@ventanamicro.com> In-Reply-To: From: Anup Patel Date: Fri, 12 Apr 2024 19:20:49 +0530 Message-ID: Subject: Re: [PATCH] of: property: Add fw_devlink support for interrupt-map property To: Rob Herring Cc: Saravana Kannan , Palmer Dabbelt , Paul Walmsley , Atish Patra , Andrew Jones , Sunil V L , Anup Patel , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 12, 2024 at 6:07=E2=80=AFPM Rob Herring wrote= : > > On Fri, Apr 12, 2024 at 6:29=E2=80=AFAM Anup Patel wrote: > > > > Some of the PCI controllers (such as generic PCI host controller) > > use "interrupt-map" DT property to describe the mapping between > > PCI endpoints and PCI interrupt pins. > > I would go as far as saying that's the only case as that's the only > case where the interrupts are not described in DT. Sure, I will update the text. > > > Currently, there is no fw_devlink created based on "interrupt-map" > > DT property so interrupt controller is not guaranteed to be probed > > before PCI host controller. This mainly affects RISC-V platforms > > where both PCI host controller and interrupt controllers are probed > > as regular platform devices. > > That's *every* system with PCI really. Okay, I will re-word. > > > This creates fw_devlink between consumers (PCI host controller) and > > supplier (interrupt controller) based on "interrupt-map" DT property. > > > > Signed-off-by: Anup Patel > > --- > > drivers/of/property.c | 53 +++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 53 insertions(+) > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c > > index a6358ee99b74..ccbbb651a89a 100644 > > --- a/drivers/of/property.c > > +++ b/drivers/of/property.c > > @@ -1311,6 +1311,58 @@ static struct device_node *parse_interrupts(stru= ct device_node *np, > > return of_irq_parse_one(np, index, &sup_args) ? NULL : sup_args= np; > > } > > > > +static struct device_node *parse_interrupt_map(struct device_node *np, > > + const char *prop_name, i= nt index) > > +{ > > + struct device_node *tn, *ipar, *supnp =3D NULL; > > + u32 addrcells, intcells, cells; > > + const __be32 *imap, *imap_end; > > + int i, imaplen; > > + > > + if (!IS_ENABLED(CONFIG_OF_IRQ)) > > + return NULL; > > + > > + if (strcmp(prop_name, "interrupt-map")) > > + return NULL; > > + > > + ipar =3D of_node_get(np); > > + do { > > + if (!of_property_read_u32(ipar, "#interrupt-cells", &in= tcells)) > > + break; > > + tn =3D ipar; > > + ipar =3D of_irq_find_parent(ipar); > > + of_node_put(tn); > > + } while (ipar); > > + if (!ipar) > > + return NULL; > > + addrcells =3D of_bus_n_addr_cells(ipar); > > + of_node_put(ipar); > > + > > + imap =3D of_get_property(np, "interrupt-map", &imaplen); > > + if (!imap || imaplen <=3D (addrcells + intcells)) > > + return NULL; > > + imap_end =3D imap + imaplen; > > + > > + for (i =3D 0; i <=3D index && imap < imap_end; i++) { > > + if (supnp) > > + of_node_put(supnp); > > + > > + imap +=3D addrcells; > > + imap +=3D intcells; > > + > > + supnp =3D of_find_node_by_phandle(be32_to_cpu(imap[0]))= ; > > + if (!supnp) > > + return NULL; > > + imap +=3D 1; > > + > > + if (of_property_read_u32(supnp, "#interrupt-cells", &ce= lls)) > > + return NULL; > > + imap +=3D cells; > > This is wrong. Technically, you can have #address-cells too. > > The bigger problem I have is this creates 2 sets of 'interrupt-map' > parsing code. Your version skips a lot of things like whether the > interrupt controller is available and there's the list of > 'interrupt-map' abusers to think about. > In my first attempt, I was trying to keep it simple but I guess I over-simplified it. I have an alternate approach to use of_irq_parse_raw() over here (similar to of_irq_parse_pci() in drivers/pci/of.c). Are you okay with this approach ? Regards, Anup