Devicetree vs. UCI defaults in /etc/board.d

Hi there, I was looking at device support for the GL.iNet GL-S1300 (see also PR #12478) by comparing its config with that of the GL-B1300, and was wondering about the conventions/best practices for writing the devicetree and board config.

I have been looking at three files:

1. Where to configure a LED trigger?

It looks like there are two ways to make the WiFi LED blink.

For B1300, it's configured through uci-defaults:

ucidef_set_led_wlan "wlan" "WLAN" "green:wlan" "phy0tpt"

For S1300, it's configured in devicetree:

                wlan {
                        label = "green:wlan";
                        gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
                        linux,default-trigger = "phy0tpt";
                };

The devicetree way seems better to me (if it works), but I don't know much.

2. How to name DTS labels? To prefix or not?

When diffing qcom-ipq4029-gl-b1300.dts and qcom-ipq4029-gl-s1300.dts I noticed that one has labels like led_power and the other has labels like power. I assume that consistency is good, but both prefixed and unprefixed labels seem to be used everywhere. To clarify, I'm asking about Devicetree Source labels, not the (deprecated) label property of LED nodes.

My references:

3. Is it possible/advisable to use DTS #include for common features?

The switch and ports config is the same for B1300 and S1300. They are quite similar. The main practical difference is numbering of GPIO lines. The latter device is sadly discontinued by GL.iNet, perhaps because not many people bought it. The S1300 has missed out on DSA conversion so far. I was wondering how much common devicetree config can/should be split into a separate file?

Thanks!

ad 1.) I configure as much as possible in the dts. AFAIK, it wasn't always possible to define LED triggers in the dts and not all devices were converted.

ad 2.) I don't think there is a rule. I usually go with the prefix.

ad 3.) Yes, it makes code more reusable. You can have several splits/includes, but at a certain point it becomes unmanageable / unreadable.

I suggest you go through the git history and check some of the most recent commits.

Note: I'm a contributor like you, not a member of the development team. This is just what I've been doing.

Thanks @andyboeh. Yeah I have found the git history helpful at times, but sometimes it leaves me more confused. :face_with_spiral_eyes:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.