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 658DDEE49A3 for ; Wed, 23 Aug 2023 15:23:43 +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=rVc3gjwX2MCwkIuHdrdZn/MXsukR8qPaUH8ICq/MyU0=; b=2jHTnv7Du36Yrt 9sM5fTEuyA+VDT2HqDZpIbMqET4n79LSzjhjr/UADjkjU4UmVJbNaFcGXuNe4L/xSYqhdNX0vWCyv MQMUIHF1FD3+77dvqN7L/ANgyX54E6383h049a9J3IhpxDUSZcdRu4KqmDbv6L4tbd2jdjI6a5yFZ xiPX8Z1HNFSAXuFeohflNYZMWA3hJUTYpQoQVki2V37OQje9y0JYTqz3AClAn90EEEQmwpF4JovhS ujYkU4Jn7w0aHXrYVHnmwL4xXaCpmD05wn25LrQUYVsQUC41ItmgioxAFoS5qNIt4BFdCvj0QN18s rmTLEON0AgYtLCqEIrog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qYphN-000yFl-1t; Wed, 23 Aug 2023 15:23:09 +0000 Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qYphK-000yEj-26 for linux-arm-kernel@lists.infradead.org; Wed, 23 Aug 2023 15:23:08 +0000 Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-56a9c951aaaso2110684a12.3 for ; Wed, 23 Aug 2023 08:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692804185; x=1693408985; 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=4jcjq5tQMjyXZ4EekHKM/b7uQYtJc57vmlwhbh+CZDs=; b=ZwRBeOagas9M9sXgaQrbrm+skvTJvLhNu69cLPRzcgsfIpv1NOzgqS0jh3k5rxP+nB qP6nafMwRquXr33jXe7/4agKa0IaYc4wd5WQMB+zc8orq9fkOj6+8GCz36MwChD9vNkv G82asc5wfwJVFgCpv9ZMHcROFuJOXop99JA3doQC2109PcD471fzoudvNs4h95LjUev1 F3qW3gLluQV6Ns8yl4ZpnK92vyJC+gxXRroCP8TrYcOKvUOww5oSI1nkhUoAyW856ipV vEkJYbT+gMM9nzA9LA7w4YwjVq3t+10ZhtlADNqoHWcnywXLgn4iO4LRWpJfGWH/2S6W 0q+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692804185; x=1693408985; 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=4jcjq5tQMjyXZ4EekHKM/b7uQYtJc57vmlwhbh+CZDs=; b=FNkmfuZl31yAnrjCRaRIgAXUuSjgINboWE+1TtpyM4qVv7nzsuuDfF+N7Afgrw33Q3 1YWWKGl0u0riVvX443s4Y61mq9AIrOrn2XYECzKjrurWdTV7XPgCXLRklfFKeCLwwynR vpYbxxNVvsmNPnpGsAyBoA2b3xXRpar0yqQSxFBd+XSaTfySMLEDKWaGGnXoISqxGPJm XwTCSZo2YHnughyzDe/fABntn6ScTG8SCeS8Dc6+0+4D/BwuaQHDj/92mNl0rWWXjroO fgms1VawNgNEqfFmVRfUZkt0S1mRGYTGeMDO+067xXs2m5QWKujnZd/coow7jL49IZvH AeMg== X-Gm-Message-State: AOJu0YzeouI+o7UfJ62aA0zuFG4Z7Zu2YFb9DhcHIssGZYmYqyK3g4B4 gUp2ATt8RoM/IoRvalq731OyhQ== X-Google-Smtp-Source: AGHT+IEiD/SBgLnjm91uUIfm5P3nzoyFIsHOxISHiMUMBgJfnBwYTYUx+bDZpBCVefCGz4SCm+RsYw== X-Received: by 2002:a05:6a20:431c:b0:13e:1712:4c01 with SMTP id h28-20020a056a20431c00b0013e17124c01mr12683630pzk.42.1692804184763; Wed, 23 Aug 2023 08:23:04 -0700 (PDT) Received: from p14s ([2604:3d09:148c:c800:3ae3:a477:fe1c:f18c]) by smtp.gmail.com with ESMTPSA id i3-20020aa787c3000000b006877b0b31c2sm9889234pfo.147.2023.08.23.08.23.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Aug 2023 08:23:04 -0700 (PDT) Date: Wed, 23 Aug 2023 09:23:01 -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> <20230822201205.4csoj4kym2yhuyrf@decrease> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230822201205.4csoj4kym2yhuyrf@decrease> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230823_082306_738878_E99C0683 X-CRM114-Status: GOOD ( 27.53 ) 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 On Tue, Aug 22, 2023 at 03:12:05PM -0500, Nishanth Menon wrote: > On 13:25-20230822, Mathieu Poirier wrote: > > 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? > > Correct - *if* remoteproc3 is the constant node reference. > > To take a trivial example: We ran into this issue with: > https://github.com/kaofishy/bbai64_cortex-r5_example/blob/main/Makefile#L28 > > remoteproc18 apparently changed numbering in a different build. > We are going around in circles. In the above link using an alias will guarantee that "remoteproc18" is available but won't guarantee the functionality enacted by the FW loaded in that remote processor, which is distro dependent. > If remoteproc18 remained the same between different distro builds that > would have probably kept the userspace constant. but it does'nt. it > dependent purely on probe order, which does'nt let userspace remain > consistent. > > Same reason and motivation to do the following: > https://git.beagleboard.org/beagleboard/repos-arm64/-/blob/main/bb-customizations/suite/bookworm/debian/86-remoteproc-noroot.rules > in one technique to do it - but that only works if all the distros > follow the same udev rules - and there is no reasonable way to enforce > that across distributions. > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel