-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Devicetree: Child node of node on SPI bus itself needs reg property - Bug? #30423
Comments
OK, so I found that it works if I put it like this:
Just have to assign the child node a Thus it just became only a minor inconvenience, because the work-around is not that much of a game changer. But I would still like to know whether this is a bug in the zephyr device tree scripts, or in my understanding of the device tree 😕 |
I can't rule out a bug from reviewing the details description. Will take a more detailed look. |
Hotfix for issue zephyrproject-rtos#30423. Signed-off-by: Martí Bolívar <[email protected]>
@arludwig I can reproduce the issue on v2.4.0 as given in your report, but it doesn't reproduce on master. Bisection shows that 8165008, which removed legacy macro support, also avoids the error. Since this commit doesn't cherry-pick cleanly onto v2.4.0, here is a patch which just turns off legacy define generation in the build system, that is on top of v2.4.0: $ cat 0001-dts.cmake-disable-legacy-macro-generation.patch
From 508267d8fd9ffa76d5309201baee6c81f1fcdad2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mart=C3=AD=20Bol=C3=ADvar?= <[email protected]>
Date: Thu, 10 Dec 2020 10:39:36 -0800
Subject: [PATCH] dts.cmake: disable legacy macro generation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hotfix for issue
https://github.com/zephyrproject-rtos/zephyr/issues/30423.
Signed-off-by: Martí Bolívar <[email protected]>
---
cmake/dts.cmake | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmake/dts.cmake b/cmake/dts.cmake
index 1bed174a93..76e2e4b88a 100644
--- a/cmake/dts.cmake
+++ b/cmake/dts.cmake
@@ -249,6 +249,7 @@ if(SUPPORTS_DTS)
message(STATUS "Generated devicetree_unfixed.h: ${DEVICETREE_UNFIXED_H}")
endif()
+if (FALSE) # disable legacy macros support
execute_process(
COMMAND ${CMD_LEGACY_EXTRACT}
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
@@ -257,6 +258,7 @@ if(SUPPORTS_DTS)
if(NOT "${ret}" STREQUAL "0")
message(FATAL_ERROR "gen_legacy_defines.py failed with return code: ${ret}")
endif()
+endif()
# A file that used to be generated by 'dtc'. zephyr.dts is the new
# equivalent. Will be removed in Zephyr 2.3.
--
2.29.2 Also available here: https://github.com/mbolivar-nordic/zephyr/tree/issue-30423-no-legacy-macros-hotfix As long as you are using the new devicetree API and not the legacy macros in your application, this should suffice to avoid the error. If you're using the legacy macros, I think you will need to move to the new API first, before you can use this patch. Sorry for any inconvenience. Please reopen if I've misunderstood anything or this won't work for you, and thank you for taking the time to file a detailed report. |
Yes, this fixes the issue. Thank you! |
Disclaimer
I am not sure this is actually a bug - it might just be that I have misunderstood some details about the devicetree. But it might also be a bug.
Describe the bug
I am trying to split the wiring and the protocol information of an spi slave device into two nodes. This would allow me to have a physical connector, like a zif-connector, on my board, hardwired to a specific chip select gpio; further more I would be able to specify the actual target device, like an epaper display, in an overlay file, specifying device dependent information, like the max frequency, clock configuration or word size. This way, I could support devices with different requirements by simply changing the overlay.
To achieve this, I define an
spi-target
binding for a node on an spi bus, that takes the actual device as child node. Following example is simplified:(Obviously I will have to write a custom driver for this, but I that is ok and not an issue here.)
I tested this with the following overlay file for a
nrf52840dk_nrf52840
board:When I try to apply this, I get the following error:
Seems zephyr requires the child node itself to have a
reg
property, which kind of defeats my intentions here.To Reproduce
Expected behavior
When I have a device on the spi bus, then this device should be able to have itself children. So I would have expected my aproach to work. This would be a nice way to modularize devicetree information using overlays for mine and related cases.
Impact
This is more of an annoyance as a show stopper, because I can work around using non-related nodes and referring from the device to the
spi-target
via aphandle
property. But from a devicetree structural point of view it would be a lot nicer (and I think also safer / less error prone) and clearer if a hierarchical structure could be used.Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: