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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3B063EE4993 for ; Tue, 22 Aug 2023 19:25:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=x//eXeC5Dyf1TKxVxsslihiNe6gLBDtWYLPduKGto/o=; b=B0O/1N7DBNdNVP WgWjNVlMMsNfjwOM/SN0rLnGZxsUGRxYrIBqjZpu2GBE+4epz7YzcxEY5/rHqdwY+CMKVUjl9js/W HmEb4gfQxC5DSh4MJBykj8lYbB/G0heGVBu1FaAUNr4RsoyZp0HnaUcZkxp/S73xgcySb6Z+h7A8K pgMiNBlNoepA6tVSgwf/4fIv+ZdYN5CijGj0RjXEfHCvCFawhPb40UqJXfkxCEYXpHYuPk6zBUzzS aX9buuSbjw6IFb1jBykBeJE9oF+JG8paDYmfxRLRxVbo3zsYRVUv0SNFNHamcgj7velDPEwfVIL1+ lVetDBcYMDL+nPO+eUsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qYX0D-00GhrQ-1D; Tue, 22 Aug 2023 19:25:21 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qYX0A-00Ghqp-2Q for linux-arm-kernel@lists.infradead.org; Tue, 22 Aug 2023 19:25:20 +0000 Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1bc83a96067so29068475ad.0 for ; Tue, 22 Aug 2023 12:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692732315; x=1693337115; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=a1G5m8Qjmh6jxuKz8UMaMjH/jWYmISiVf2CP4Ro+UAY=; b=nlIifxq5oK59/+pYadZdfblkJhLw6Wf3kugMEjW/uM48NiTw+MEQquBAdNN3yINmbD G+WWwh/Pzr1+cjfFDD2NjH7RmIVfDUTU2A0OctPa2W9L0sWWs2W0v+o+z+RG8vT7YKju zjJT87CjUaXWXDuraadxViGz5sZ8tWTSkGJTpKx12WajS8z6AKVq/RwMCk2X2Z8carxZ u/shkw0jB0Aax9jmMviiz6zCh5lhoETGbQFc6yuCE4hghGIxtVPwcb4gNTOYkgoiivBd njXujFVP42SKzRLbjGteCe2RONqCvLfW2pTkhcHprrWmcQOBAMZqA/PT0XBUZsgesyry +38g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692732315; x=1693337115; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a1G5m8Qjmh6jxuKz8UMaMjH/jWYmISiVf2CP4Ro+UAY=; b=PyRmeL2p0ByUEg2EyRhyc7tX9WzHAXSimwlOHvajtbeIuAkJEvDd/WhO79uiqvhUD5 vDWNOf2EjEzezCkIUylmp0WsVKuIUJZRq/sQ9C13vkvd9UT8LGfOBUL/+Qbo+Ahbn1Hq b95e2pC3l/Of/SkQvH25xEivEvEEPDnAsaq1mu1a7pEBh4EVMPsDSbbcM/3GFYdRobOS ZusHD32vEWQ7eELQhGs2DH8GaFbM2sVBw1AFKXD00Upl/Fq5y7/eTjwDFO7v30DdEQyS hRce2NSb+T8GRSi1gI5wjZHGizM9m/JwUy+iFTJpVkjDzkcF2+XShbqMdLYjp3gArwwS oqUg== X-Gm-Message-State: AOJu0YzlGYoT/hzjPku5chfrvY1rY2TkcdsbkEuXpxdPayuwWetvzdiu tbh4nNOOMSRwpMMxdiqvxf5MKplaQS18bxp98Ro= X-Google-Smtp-Source: AGHT+IEaJfj8jetHWv6UJxqJomeGDsdD4fGQV/B1z8Y4BwNnSPKNCwY61lFIuQahs/kESgkkORG+gA== X-Received: by 2002:a17:903:120d:b0:1bb:c971:ef92 with SMTP id l13-20020a170903120d00b001bbc971ef92mr8792158plh.59.1692732315450; Tue, 22 Aug 2023 12:25:15 -0700 (PDT) Received: from p14s ([2604:3d09:148c:c800:4e2f:8663:6f0a:bb69]) by smtp.gmail.com with ESMTPSA id a7-20020a170902ecc700b001b2069072ccsm9377559plh.18.2023.08.22.12.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Aug 2023 12:25:14 -0700 (PDT) Date: Tue, 22 Aug 2023 13:25:12 -0600 From: Mathieu Poirier To: Nishanth Menon Cc: Bjorn Andersson , linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Robert Nelson , Kevin Cahalan Subject: Re: [PATCH] remoteproc: core: Honor device tree /alias entries when assigning IDs Message-ID: References: <20230807140247.956255-1-nm@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230807140247.956255-1-nm@ti.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230822_122518_823197_D0F6585D X-CRM114-Status: GOOD ( 33.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Nishanth, On Mon, Aug 07, 2023 at 09:02:47AM -0500, Nishanth Menon wrote: > On many platforms, such as Beaglebone-AI64 with many remote > processors, firmware configurations provided by the distributions can > vary substantially depending on the distribution build's functionality > and the specific remote cores enabled in that variant. Ensuring > consistent udev rules mapping remoteproc nodes to constant remote > proc device indices across distributions (yocto, ubuntu, debian and > it's variants, ...) on a board basis can be challenging due to the > various functions of these distributions. Varied device node paths > create challenges for applications that operate on remote processors, > especially in minimal embedded systems(initrd like) that may not > have udev-like capabilities and rely on a more straightforward bare > filesystem. This challenge is similar to that faced by I2C, RTC or the > GPIO subsystems. > I'm puzzled by this patch. I can see how using an alias can help in boards with various HW configuration. That said, and as written above, FW files for remote processors can vary based on the build's functionality. As such "remoteproc3" will reference the same HW device on all distributions but the functionality enacted by the FW may be different. As such I don't see how an alias can help here. Can you provide a concrete example that highlights the benefits? Thanks, Mathieu > Assign remoteproc device IDs based on device tree /aliases entries if > present, falling back to the existing numbering scheme if there is no > /aliases entry (which includes when the system isn't booted using DT) > or a numbering conflict. If the alias node is not present, the driver > behaves as before. > > Cc: Robert Nelson > Reported-by: Kevin Cahalan > Signed-off-by: Nishanth Menon > --- > Test log: Beaglebone-AI64 > https://gist.github.com/nmenon/365cf80d6c0685dd9be7c2cb18d7c937 (along > with a test change to force the sequence of initialization) > > The report occurred on Beagle discord channel - so I am not > sure how to share the logs of the report. > > drivers/remoteproc/remoteproc_core.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 695cce218e8c..a12f3d37b8de 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2417,6 +2418,25 @@ static int rproc_alloc_ops(struct rproc *rproc, const struct rproc_ops *ops) > return 0; > } > > +static int rproc_device_get_id(struct device *dev) > +{ > + int of_id = -1, id = -1; > + > + if (dev->of_node) > + of_id = of_alias_get_id(dev->of_node, "remoteproc"); > + > + if (of_id >= 0) { > + id = ida_simple_get(&rproc_dev_index, of_id, of_id + 1, GFP_KERNEL); > + if (id < 0) > + dev_warn(dev, "/aliases ID %d not available\n", of_id); > + } > + > + if (id < 0) > + id = ida_alloc(&rproc_dev_index, GFP_KERNEL); > + > + return id; > +} > + > /** > * rproc_alloc() - allocate a remote processor handle > * @dev: the underlying device > @@ -2476,7 +2496,7 @@ struct rproc *rproc_alloc(struct device *dev, const char *name, > goto put_device; > > /* Assign a unique device index and name */ > - rproc->index = ida_alloc(&rproc_dev_index, GFP_KERNEL); > + rproc->index = rproc_device_get_id(dev); > if (rproc->index < 0) { > dev_err(dev, "ida_alloc failed: %d\n", rproc->index); > goto put_device; > -- > 2.40.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel