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 5F1A7C83F2D for ; Thu, 29 Aug 2024 15:46:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JQ/V12BCbUHD2Gafdg3lYqtKMFzhULqHX93I66TEWHo=; b=ohv8FoxkfGL38eL1FnU1SM2/Uy 948Ljbt6R9HkFGxZZnForq1sKnTSYmYoFKQwRyLgQRpMAMYU05/K71JHaGnMv5/jgbvBp+rybQaf9 nx8jzuohSLy9sHoMzFsVFqwQVSZcQrPa8Bc7szduJM/jpkmMCCWwKVHqEx+4NyweWdvG0vtmNO16H 9Mo0wN39Gkaq+msB9orzs1f8b5hXmSbrErYXo4QqNHvZg5ablpTZwu3RsVWwi4dqP+Vnp2HXZ4Jq7 K7bKU0p7BZpwF/DZ3UFMwN/cfC9sEdys5tVNw/P4RWtCEuRVwqv2LmBVTPCoLXQ6BI3yh83oJXfSi XkOZMVJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjhM2-00000002g9Z-081d; Thu, 29 Aug 2024 15:46:34 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjhKo-00000002fub-3G2s for linux-arm-kernel@lists.infradead.org; Thu, 29 Aug 2024 15:45:20 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D8A9BA441E1; Thu, 29 Aug 2024 15:45:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C421C4CEC1; Thu, 29 Aug 2024 15:45:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724946317; bh=VIY5HaE7JEsJLMzs9MMF9q38bi2uPDkUtjNeBnAxG/I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZpX/oRyxClc9YiG9o6xKE5jQw2jRGFQMpdFckrio93oUHx5SCLEDiSKjiMlZn2Urh Ivumr6vnpv0dovvr+Ne7nYPjF8D9k7/nV7GDiyQr+N5y5rhpYwWIUKjdOUUhwz6BXQ FZte1sDARnCFVGUOkdba75ztEvoOpNnl23MP4lCBy4YqzOvjprYlf6CksH57SMYJEI RxHqbTyLkAAL3r4ShgrSCoDX0c7Fj7LYOGHAuURSnWVIJlsUJuOPXGTfNLVA++T4Sl dSlmVVeoNrQ5WCFBwabIAojPDfY6bLWgo+zGTW+GmfsoiKxoApSmXREUkDioMatkgG gY6cO8fb6y7tg== Date: Thu, 29 Aug 2024 10:45:15 -0500 From: Rob Herring To: Kuninori Morimoto Cc: Daniel Vetter , David Airlie , Helge Deller , Jaroslav Kysela , Laurent Pinchart , Liam Girdwood , Maarten Lankhorst , Mark Brown , Mauro Carvalho Chehab , Maxime Ripard , Michal Simek , Saravana Kannan , Takashi Iwai , Thomas Zimmermann , Tomi Valkeinen , devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-fbdev@vger.kernel.org, linux-media@vger.kernel.org, linux-omap@vger.kernel.org, linux-sound@vger.kernel.org, Sakari Ailus Subject: Re: [PATCH v4 1/9] of: property: add of_graph_get_next_port() Message-ID: <20240829154515.GD465065-robh@kernel.org> References: <87bk1d2pvt.wl-kuninori.morimoto.gx@renesas.com> <87a5gx2pva.wl-kuninori.morimoto.gx@renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a5gx2pva.wl-kuninori.morimoto.gx@renesas.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240829_084518_951622_5950D70A X-CRM114-Status: GOOD ( 17.11 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 28, 2024 at 05:11:37AM +0000, Kuninori Morimoto wrote: > We have endpoint base functions > - of_graph_get_next_device_endpoint() > - of_graph_get_device_endpoint_count() > - for_each_of_graph_device_endpoint() > > Here, for_each_of_graph_device_endpoint() loop finds each endpoints > > ports { > port@0 { > (1) endpoint {...}; > }; > port@1 { > (2) endpoint {...}; > }; > ... > }; > > In above case, it finds endpoint as (1) -> (2) -> ... > > Basically, user/driver knows which port is used for what, but not in > all cases. For example on flexible/generic driver case, how many ports > are used is not fixed. > > For example Sound Generic Card driver which is used from many venders > can't know how many ports are used. Because the driver is very > flexible/generic, it is impossible to know how many ports are used, > it depends on each vender SoC and/or its used board. > > And more, the port can have multi endpoints. For example Generic Sound > Card case, it supports many type of connection between CPU / Codec, and > some of them uses multi endpoint in one port. > Then, Generic Sound Card want to handle each connection via "port" > instead of "endpoint". > But, it is very difficult to handle each "port" via existing > for_each_of_graph_device_endpoint(). Getting "port" via of_get_parent() > from "endpoint" doesn't work. see below. > > ports { > port@0 { > (1) endpoint@0 {...}; > (2) endpoint@1 {...}; > }; > port@1 { > (3) endpoint {...}; > }; > ... > }; > > In other case, we want to handle "ports" same as "port" for some reasons. > > node { > => ports@0 { > port@0 { ... }; > port@1 { ... }; > ... > }; > => ports@1 { > ... > }; > }; There is no schema that supports this structure. The closest thing we have is in-ports and out-ports in Coresight bindings. In any case, it should be a separate patch, not buried in here. Rob