Re: Per-device-instance software configuration in devicetree


Benjamin Lindqvist
 

Hi,

Enforcing "zephyr," suffix is a great idea given that software config is allowed in the dts - the one grievance I have is that using dts overlays for configuration purposes isn't great UX. It's not very welcoming first of all, but it's also harder to control during build time (Kconfigs can be selected/defaulted by both new custom Kconfigs and is also more easily controllable via CMake and other build scripts). Perhaps some form of dts overlay inlet that is easily accessible via CMake could be constructed? I.e. just a wrapper for conditionally activating overlays that is easier to work with than creating a bunch of files in your project root.

I don't think the idea is bad without this feature - just throwing out a potential UX improvement out there :)

Best,
Ben

On Sun, Apr 10, 2022 at 7:49 PM Simon Glass <sjg@...> wrote:
Hi,

I strongly agree with this approach.

U-Boot has the same issue (no other way to provide config) and has quite a few software-related bindings. The idea of device tree only describing the hardware is out-of-date, IMO.

See also the /options node:


Regards,
Simon


On Fri, 8 Apr 2022 at 07:14, Carles Cufi via lists.zephyrproject.org <carles.cufi=nordicsemi.no@...> wrote:

For completeness I’d also like to point to our current use of Devicetree to configure OpenAMP resources, a construct that is fundamentally software in nature.

 

https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/ipc/zephyr%2Cipc-openamp-static-vrings.yaml

 

Carles

 

From: devel@... <devel@...> On Behalf Of Erwan Gouriou via lists.zephyrproject.org
Sent: 08 April 2022 15:09
To: Bolivar, Marti <Marti.Bolivar@...>
Cc: devel@...; tomasz.bursztyka@...; kumar.gala@...
Subject: Re: [Zephyr-devel] Per-device-instance software configuration in devicetree

 

Hi Marti,

 

This makes sense. Few years ago this proposal would have been turned down,

as we wanted to stick with Linux practices. But I think today we have the necessary

experience with device tree to consider this is the right thing for us to do.

 

Erwan

 

 

 

On Thu, 7 Apr 2022 at 19:23, Bolivar, Marti via lists.zephyrproject.org <marti.bolivar=nordicsemi.no@...> wrote:

Hi,

Summary:

    This is a proposal for how to handle per-struct-device
    software configuration for Zephyr in devicetree.

    My goals are to:

    - summarize the problem and proposed solution
    - look for consensus or more feedback

    TL;DR: we propose zephyr-specific configuration should
    be allowed in devicetree, but in properties beginning
    with "zephyr,".

Please read this if you need more context on DT than what
I've written below:

https://docs.zephyrproject.org/latest/build/dts/index.html

Zephyr developers allocate individual 'struct device'
instances using devicetree. They can also perform initial
hardware configuration in devicetree. For example,
developers can already configure things like bus devices,
associated GPIOs, clock rates, line rates, etc. in the
devicetree nodes that are used to allocate devices.

For more details, watch my talk from ZDS 2021:

https://www.youtube.com/watch?v=sWaxQyIgEBY

However, there is no obvious place to configure *software*
features that are associated with individual struct devices.
This is a problem because developers need to do this, too.

There's no obvious place because the contents of the
devicetree are "supposed" to only be a description of the
hardware and its initial configuration. Things like the
sizes of buffers associated with a particular struct device
don't fit those categories. For this reason, there's been
resistance to putting per-device software configuration
values into devicetree in the past.

Unfortunately, we don't really have a good alternative to
devicetree for this in Zephyr. Each 'struct device' is
created from a devicetree node. The device instantiation
macros have no other device-specific context at build time
beyond the contents of that devicetree node. Since Zephyr
drivers are generally statically allocated and configured,
and the devicetree is the only build-time place to stash
device-specific context, it really is the only place for
this that we have now.

And in fact, some software features are already being
configured in devicetree. One example is in this PR:

https://github.com/zephyrproject-rtos/zephyr/pull/43806/

Although the above PR is for a devicetree compatible that is
already specific to zephyr, we want to be able to do similar
types of configuration as properties in nodes that might
also have bindings in the Linux kernel or other projects
using devicetree.

That is a problem because the namespace of properties
associated with each devicetree compatible in a binding is
shared among projects using devicetree. We want to try to
avoid using property names in a Zephyr-specific way that
might pose egregious source compatibility issues with other
projects.

This is important because DTS source compatibility with
other operating systems is a design goal for our use of
devicetree:

https://docs.zephyrproject.org/latest/build/dts/design.html#source-compatibility-with-other-operating-systems

As a compromise to avoid things getting out of control while
still solving the problem, I'm proposing that *all* new
values which are clearly software configuration for Zephyr
*may* go into devicetree properties, but those properties
must begin with "zephyr,".

Examples:

  - you MAY NOT make a "foo-buffer-size" property
  - you MAY make a "zephyr,foo-buffer-size" property

  - you MAY NOT make a "work-queue-priority" property
  - you MAY make a "zephyr,work-queue-priority" property

This keeps things clean by not clashing with property names
that other devicetree users may add for the same
compatibles.

Kumar is on board with this proposal.

The ship has already sailed on some cases, like the
usb-audio-* related bindings here:

https://docs.zephyrproject.org/latest/build/dts/api/bindings.html#generic-or-vendor-independent

There's no proposal on the table right now to re-work those
so they have a "zephyr," prefix. At this time, we're just
talking about new bindings changes.

Feedback and more discussion is welcome. Once this is
resolved, I'll write up the results in the zephyr bindings
documentation so it doesn't get lost, and will request that
individual driver subsystem maintainers help enforce this.

Thanks,
Martí



Join devel@lists.zephyrproject.org to automatically receive all group messages.