The Devicetree HOWTOs do explain device howtos, but not one level up (dt_spec)

[rjmaris]

First of all: I know that accessing by dt_spec is more versatile because the dev struct is contained in a dt_spec structure.
Since samples/drivers/adc offers handling of both 'methods' to create application code, I have a quite good opportunity to compare the two approaches. The newer example (adc_sequence, device focused) looks more readable than the older example (adc_dt). The beginning of the former code,

#define ADC_NODE DT_ALIAS(adc0)

/* Data of ADC device specified in devicetree. */
static const struct device *adc = DEVICE_DT_GET(ADC_NODE);

perfectly well 'maps' to the Get a struct device from a devicetree node section of the HOWTOs.

Contrary, the function accesses in the latter code (function_dt) are simpler, because on dt_spec level.
However, the initial lines of the code makes me (and others) ask whether it's complexity is part of the game or not:

#if !DT_NODE_EXISTS(DT_PATH(zephyr_user)) || \
	!DT_NODE_HAS_PROP(DT_PATH(zephyr_user), io_channels)
#error "No suitable devicetree overlay specified"
#endif

#define DT_SPEC_AND_COMMA(node_id, prop, idx) \
	ADC_DT_SPEC_GET_BY_IDX(node_id, idx),

/* Data of ADC io-channels specified in devicetree. */
static const struct adc_dt_spec adc_channels[] = {
	DT_FOREACH_PROP_ELEM(DT_PATH(zephyr_user), io_channels,
			     DT_SPEC_AND_COMMA)
};

(Of course, the complexity here also lies in the checker whether a zephyr_user section with appropriate content is present in an overlay)
I suppose that the use of DT_SPEC_AND_COMMA helper macro is outdated. Just for this reason it would be helpful if the HOWTOs also address the approach of declaring a dt_spec struct.
If Howto information is available elsewhere, a link to it would be helpful.

[jadonk]

It feels there is unnecessary complexity put to the user that could be handled more generically by the non-dt interfaces when the full configuration information is provided in dt.

For example, the device structure includes a config pointer, but there isn't a generic macro to generate this configuration. Having a model-specific XXX_dt_spec seems fine, but why not use the device-generic config pointer to store this configuration information such that generic configuration APIs could be called?

Can we get a macro that will generically give us something to go into config such that we don't need to call these _dt functions?

I'm probably not clear as I'm so frustrated by the usage model that I cannot organize my thoughts. :-(

[ndrs-pst]

@rjmaris, Yeah, it's a macrobatics way 😄.
Personally, I prefer using the xxx_dt_spec method since I feel more connected to the driver layer itself (e.g. spi_dt_spec, gpio_dt_spec).
Please take a look at https://docs.zephyrproject.org/3.6.0/hardware/peripherals/adc.html to find out which way is suitable for you.

---

If you already know the number of ADC channels, then declaring adc_dt_spec like this should be OK.

static const struct adc_dt_spec adc_chan0 =
    ADC_DT_SPEC_GET_BY_IDX(DT_PATH(zephyr_user), 0);
static const struct adc_dt_spec adc_chan1 =
    ADC_DT_SPEC_GET_BY_IDX(DT_PATH(zephyr_user), 1);