Disassociate `struct device` from devicetree nodes for application layer

[bjarki-andreasen]

Introduction

This RFC looks into defining and classifying struct devices from within the device drivers by device class (which API they implement) and presenting them to the application by class agnostic from the devicetree.

Problem description

Consider the following devicetree snippet:

&i2c1 {
    status = "okay";
    clock-frequency = <I2C_BITRATE_STANDARD>;

    mcp7940n@25 {
        compatible = "microchip,mcp7940n";
        reg = <0x25>;
        status = "okay";

        int-gpios = <&gpioa 1>;

        rtc0: rtc {
            compatible = "microchip,mcp7940n-rtc";
            status = "okay";
        };

        bbram0: bbram {
            compatible = "microchip,mcp7940n-bbram";
            status = "okay";
        };
    };
};

The bbram and rtc nodes are endpoints, which don't have any capabilities useful to the devicetree. Yet, with the current devicetree model, we have to create a node for them here to make it available to the application.

Proposed change

The solution proposed in this RFC will allow us to create the child nodes within the device drivers, removing the need for these superfluous nodes in the devicetree, which will reduce the devicetree snippet to the following (just like the Linux devicetree :))

&i2c1 {
    status = "okay";
    clock-frequency = <I2C_BITRATE_STANDARD>;

    mcp7940n@25 {
        compatible = "microchip,mcp7940n";
        reg = <0x25>;
        status = "okay";
        int-gpios = <&gpioa 1>;
    };
};

This results in less boilerplate devicetree code, removes the need for additional devicetree compatibles for the child nodes, and removes the need for using devicetree aliases like bbram0, rtc0, ... from the application. To get the nodes from the application, we will do this instead:

BUILD_ASSERT(DEVICE_CLASS_HAS_ANY(rtc), "application requires an RTC");
BUILD_ASSERT(DEVICE_CLASS_HAS_ANY(bbram), "application requires BBRAM");

const struct device *rtc = DEVICE_CLASS_GET(rtc, 0);
const struct device *bbram DEVICE_CLASS_GET(bbram, 0);

This is possible using sections in elf files, which will find all struct device defined using DEVICE_DEFINE, and which API type the devices implements (their class). From this, we can create macros to find and iterate through struct devices by class agnostic from the devicetree.

Its essentially Linux SYSFS but static and using macros :)

Dependencies

Applications will now be encouraged to use the new class based macros to identify and use devices, instead of devicetree nodes. Subsystems like shells would also be built at the application level, or at their own level between drivers and the application to use the DEVICE_CLASS macros.

Devicetree nodes will still work as before, the drivers and kernel need to know the actual devicetree layout.

Concerns and Unresolved Questions

• Is it practical?
• How much does it break?
• Is a device class based approach (like Linux sysfs) something we want on an embedded platform given its abstraction from the devicetree?
• Can we, and should we, guarantee the enumeration of devices is consistent across builds? CAN0 will always be CAN0 for a particular board for example.
• Can this be expanded to other subsystems like network devices? something like NET_IFACE_GET(ppp, 0);

Alternatives

Create runtime functions instead of macros to sort through all devices by types, this is slower than macros, and we can't check struct devices exist at compile time DEVICE_CLASS_HAS_ANY(...), but it's simple C code with no elf_parser magic, which is faster than looking through strings which we do for bindings now. It will also allow for users to create struct devices in the application, which would not be possible with the macro solution.

[bjarki-andreasen]

I have done a bit of testing on this draft PR #57622

[bjarki-andreasen]

@gmarull What do you think of this idea?

[carlescufi]

Architecture WG:

• @henrikbrixandersen states that this has been brought up before. If the only purpose is to be able to error out if the struct device that is passed around does not conform to a specific API, then this is overkill. @bjarki-trackunit answers that this is not the only purpose. Having sections allows you to list instances of a specific device class. An .elf parser suddenly can figure out what class of device a particular struct device is. This is similar to sysfs in Linux. Example: the .elf parser can list all RTC instances without having to use Devicetree, and based exclusively on the data in the sections of the .elf file. This is useful for devices that are endpoints of something.
• @gmarull likes the idea of device classes, and thinks decoupling is interesting though it comes with its own set of problems, but the feature overall is interesting. @gmarull concerns are with the implementation: device state sharing, but @bjarki-trackunit has changed his approach since. There will be more than one struct device instance, created by the driver. @gmarull mentions https://docs.kernel.org/devicetree/bindings/writing-bindings.html, in particular "DON'T create nodes just for the sake of instantiating drivers. Multi-function devices only need child nodes when the child nodes have their own DT resources. A single node can be multiple providers (e.g. clocks and resets).". @gmarull also mentions the fact that in some cases you want to deterministically obtain a particular instance of a device. @bjarki-trackunit says that we could do something like DEVICE_CLASS_GET_BY_PARENT() for that purpose. Finally, @gmarull mentions that, in some device classes, there is common code (GPIO, regulator, etc) where the config data contains some common field. Today, there is duplication in those drivers that could be removed by having per-class common layers so that drivers do not have to deal with common instantiation.
• @mbolivar-nordic likes the proposal of this PR in general, bringing us closer to the Linux approach. Being able to list devices by class is also a good usecase. Questions for @bjarki-trackunit: how to deal with device instantiation and whether this will work with other toolchains.

[bjarki-andreasen]

Here is a proper attempt at adding the device enumeration feature #58112