From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 7420613B288 for ; Wed, 8 Jan 2025 08:28:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736324896; cv=none; b=TuJmKnhpfFOZWDHE/Deob8vYQX2OpOol51WzzbSHDPBsy8wHMktcgKxH9oo3hibUh2p3p2bViHoT1iOnrArkNZVbMn3tkHx61beNrdsgA6OA/P8iH3O3lL24DiCJs78I3pcAOhLq3iWLc3rSkGepclrhX4PJIm2OhWTbYNKQkZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736324896; c=relaxed/simple; bh=3mZ5vtoOeY4eeomrlHFlW8D7/nhC1ZMpGJNE9zcPbB4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NOlQsDgngOSvR9p2PqGGogxRST+XhNmHBKm25gXQXayFJCraOuao7fvHGzrMDPh6g+DrBvVQuscqGJH3ZqFxLxbI2miycaR/yjjG19jR6INeiKggkfVRlGoReWGHUcscw82tCd3r3h4x8BX17pF9l0KOOxY7drbzrHvYI4PfzgA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=beagleboard.org; spf=fail smtp.mailfrom=beagleboard.org; dkim=pass (2048-bit key) header.d=beagleboard-org.20230601.gappssmtp.com header.i=@beagleboard-org.20230601.gappssmtp.com header.b=p6MeYy3W; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=beagleboard.org Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=beagleboard.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=beagleboard-org.20230601.gappssmtp.com header.i=@beagleboard-org.20230601.gappssmtp.com header.b="p6MeYy3W" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-21661be2c2dso223191735ad.1 for ; Wed, 08 Jan 2025 00:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beagleboard-org.20230601.gappssmtp.com; s=20230601; t=1736324894; x=1736929694; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=L5qGQeE8Ni6zPIaDoaP+YW8VihbqmTFfDZb3xW0nQFw=; b=p6MeYy3W0ueThLLL5hoa0cBmw6lRc2FzPryaY9hjfSKtc7eNNTkIATlAFen1cE2DEf tc7CqYB4D313jZLYXe5xXSC9te+vZshdGyNYMKhiDQps+AX+N0TdpjwHdJ06vET+vWK1 a7WAn2GQk+/PFuunnIR6ipARugP5tidcFmpVqpXpkq85ePMCG1yzy6ninq2dMScPPeTZ cYe9coSS2GgrVMKLE+09rK96v5c6HsGpNlUCeH/ojvhxdOB8Q7g3kZC8V1h523qXRJ7T EZb0GDK0gWrh4gAwTjsRzVuZNj2X+MonRYL3zpDe90+WdZa6YgZMY6rGzxgK0rgyhF3y aEkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736324894; x=1736929694; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L5qGQeE8Ni6zPIaDoaP+YW8VihbqmTFfDZb3xW0nQFw=; b=VncELCoYcg0eILl7JBHVm4IbqpwjyJI4/IFRym/ZpmLzUN5e+OfOnLAjqeq1fv4gkA DdZ58SV2mD2qz9D+e7q/4qDuvMJyjTlQCe7cSNdBqiFGGOilgZ7mAhCqeOF03jWSdp0h PhpZ3tcc5AsX2tIx7g2+ItXsSD+AekDgqzHxVHnSuclS9JeHP7CoN/lqNxCUKLJMR83/ Lxp/+wl0qqjYqNzZToAs+ruCdlwT7sBZneYyStkKQm77N0Z2j4daH7XOvG5VHA/IUKxr BXf4cMW0m/M51nppa+rJrKDZcSxfqXVwlw8/tRS73okM5f9wRFceSlzK/S73qCwS82W4 qjyQ== X-Forwarded-Encrypted: i=1; AJvYcCXFV/9IPmA9q+QGIiYhgF2VTggM0hsNbEZ3gDJ/Br9Nfr2z5Yzs8jnlRQ5wEbnYs/6uLwFxRcZ0oxaCO6s=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0v6KeazJVUkWhtjYjKzHUOJzoe5OE7zxcr7BCo0509aZ4Pl8m YmGfdtjY7gib+LljKe08UCqWK+ZgU9l2briPdWxnC7S+t0Y7t7fDZty/2C4few== X-Gm-Gg: ASbGncsSjdMBXSLK2To8ANfvJ65uRO9EpseBWsc9LDLF+uHFydlziOHgBpZ1J8KNtYH 676GeFPM+jx8I01gl3S/3LztMllFrb64/9rAbjt+s/OstrybHNO8tFl97np50PzE1O756oSg2Va manHT5Osn91FcMYWenUyqq+Xo8hWk2aA1TCSMd1zR9vWRpS1GwlK0PlLrGSp9KrKahyg+fZpvuh 3vLJRdtKGS+lBJ8dhCwCpHhcJPlmTehM13xu4uuUywOcD9F3tWFt8SSJIpi82A= X-Google-Smtp-Source: AGHT+IF2IJxP5p10X/719EBWtqLj4z+QhIIvLPwOq8iskKA4IVVKudQILHAc9gsyjaOiiBimXFQ7gA== X-Received: by 2002:aa7:88cd:0:b0:725:f097:ed21 with SMTP id d2e1a72fcca58-72d21f471d6mr2725263b3a.15.1736324893681; Wed, 08 Jan 2025 00:28:13 -0800 (PST) Received: from [172.16.116.58] ([103.15.228.94]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-842dc7edbadsm31678867a12.65.2025.01.08.00.28.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2025 00:28:12 -0800 (PST) Message-ID: Date: Wed, 8 Jan 2025 13:58:04 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/7] of: overlay: Add support for export-symbols node feature To: Herve Codina Cc: Andrew Davis , Geert Uytterhoeven , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Arnd Bergmann , Greg Kroah-Hartman , Saravana Kannan , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Luca Ceresoli , Thomas Petazzoni , David Gibson References: <20241209151830.95723-1-herve.codina@bootlin.com> <33c61b28-c0b8-478d-8107-c6ed1ff9e466@beagleboard.org> <20241210104141.39acffb1@bootlin.com> <20241210115515.1886f73f@bootlin.com> <6d48095d-59b1-4439-8e2a-927aa1aa1b55@beagleboard.org> <20250108090750.45685a50@bootlin.com> Content-Language: en-US From: Ayush Singh In-Reply-To: <20250108090750.45685a50@bootlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 08/01/25 13:37, Herve Codina wrote: > Hi Ayush, > > On Wed, 8 Jan 2025 13:06:03 +0530 > Ayush Singh wrote: > >> On 10/12/24 16:25, Herve Codina wrote: >>> Hi Ayush, >>> >>> On Tue, 10 Dec 2024 15:26:44 +0530 >>> Ayush Singh wrote: >>> >>>> On 10/12/24 15:11, Herve Codina wrote: >>>>> Hi Ayush, >>>>> >>>>> On Tue, 10 Dec 2024 14:52:22 +0530 >>>>> Ayush Singh wrote: >>>>> >>>>> ... >>>>>> >>>>>> What is the reason for not using symbols directly as described here [3]? >>>>>> >>>>>> I do like this approach since it does not pollute the global symbols. >>>>>> Just want to know if there are any other reasons for it. >>>>>> >>>>> >>>>> Modifying the __symbols__ node at runtime (adding / removing properties in >>>>> it) exposes memory leaks if __symbols__ already exist in the live DT. >>>>> This __symbols__ node exist if the dtb was compiled with '-@' or if you >>>>> chain the overlay (i.e. __symbols__ node created by the first overlay). >>>> >>>> Yeah, that is a problem, specially in a setup which might involve >>>> hot-plugging. >>>> >>>>> >>>>> I think also that some conflicts can appears. What happens if you want to >>>>> add a new label but this label is already present for some other purpose? >>>> >>>> I do not think that actually is a problem. As described in the original >>>> patch [0], the symbol and connector overlay is supposed to be applied as >>>> a group (overwriting any conflicting symbols in the process). >>>> >>>> The reason why this is not a problem is that `__symbols__` are only used >>>> to resolve the phandles (overlays do not support path references yet), >>>> but do not really have a purpose in the livetree (at least far as I >>>> know, but I can be wrong). >>>> >>>>> >>>>> Best regards, >>>>> Hervé >>>> >>>> [0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/ >>> >>> >>> Also, in your first overlay (adding symbols in __sympbols__ node), you have >>> something like: >>> GROVE_PIN1_MUX_I2C_SCL = "/bus@f0000/pinctrl@f4000/grove-i2c-pins"; >>> >>> If I understood correctly, other overlays will have GROVE_PIN1_MUX_I2C_SCL >>> as unresolved symbols and will use GROVE_PIN1_MUX_I2C_SCL to reference the >>> grove-i2c-pins node. >>> This unresolved symbol from the overlay is resolved thanks to the __symbols__ >>> table where you added GROVE_PIN1_MUX_I2C_SCL (first overlay operation). >>> >>> In order to work, you need to have a phandle property set in the >>> grove-i2c-pins node. >>> >>> This is done by dtc when you compile the dtb containing the grove-i2c-pins >>> node (i.e. k3-am625-beagleplay.dts) >>> >>> The phandle property will be set only if: >>> - a label for grove-i2c-pins already exist and -@ option is used >>> or >>> - a label for grove-i2c-pins already exist and it is referenced as a phandle >>> in the dts (k3-am625-beagleplay.dts). >>> >>> Otherwise, dtc will not create the phandle property and without this >>> property, the symbol resolution will not be correct. >>> >>> Best regards, >>> Hervé >>> >> >> Hello Hervé >> >> Thanks for the clarification. things have changed a bit since the last >> message and it seems like trying to add path reference support to >> overlays is not the best way forward [0]. So I would love to help move >> this approach forward. >> >> I do have a question regarding this approach, so here I go: >> >> Can the `export-symbols` node be added to devicetree spec and be >> resolved by the devicetree compiler (and fdtoverlay) instead of being >> runtime resolution. > > Of course, a solution with fdtoverlay is welcome but it should not fully > replace the runtime resolution. In our case, we need runtime resolution > because the overlay is loaded by a driver. > > Both resolutions (fdtoverlay and runtime) should work. I see, it seems linux does not use libfdt for applying overlays internally. > >> >> To get some context, I would like to share the addon-board overlays >> between ZephyrRTOS and Linux kernel. I would be happy to try adding >> support to dtc compiler for it. I am also tagging David Gibson (dtc >> maintainer) in this discussion since he also had some ideas regarding >> the feasibility and pitfalls of adding it to devicetree compiler (and spec). >> >> >> [0]: >> https://lore.kernel.org/devicetree-compiler/6b2dba90-3c52-4933-88f3-b47f96dc7710@beagleboard.org/T/#m900b5ca13cfc28396d4d46d9c3130a7070fa8c90 >> >> Best regards, >> Ayush Singh >> > > Thanks for your help proposal! > > Best regards, > Hervé I will experiment with adding support to dtc and see how things look. Hopefully, 2025 is the year of addon board support. Best regards, Ayush Singh