device: supported device API

[JordanYates]

Resurrection of #37836, which was reverted in #38834, due to build system fixes in #39959

Implements an API to iterate over devicetree devices that an arbitrary device supports.
Follows the conventions setup by the dependent devices API.
In addition to the original functionality, this PR now forwards supports when an intermediate device is not present in the final build (For example flash partitions under a flash device, with an intermediate "fixed-partitions" node).

Implements #37793.

[JordanYates]

@carlescufi @mbolivar-nordic @gmarull

[carlescufi]

Can we rethink the name? "supported" is really not very explanatory here. What exactly are we returning here, from the point of view of the Devicetree?

[carlescufi]

Could we use "children" here instead perhaps?

[JordanYates]

The existing API usage is SUPPORTS_ORDS, and as this is the exact same information just in a different forms, I don't believe the naming should be different. Whether the existing API should be changed I have no strong feelings on.

zephyr/include/devicetree/ordinals.h

Lines 46 to 61 in 0d4f685

	/**
	* @brief Get a list of dependency ordinals of what depends directly on a node
	*
	* There is a comma after each ordinal in the expansion, **including**
	* the last one:
	*
	* DT_SUPPORTS_DEP_ORDS(my_node) // supported_ord_1, ..., supported_ord_n,
	*
	* DT_SUPPORTS_DEP_ORDS() may expand to nothing. This happens when @p node_id
	* refers to a leaf node that nothing else depends on.
	*
	* @param node_id Node identifier
	* @return a list of dependency ordinals, with each ordinal followed
	* by a comma (<tt>,</tt>), or an empty expansion
	*/
	#define DT_SUPPORTS_DEP_ORDS(node_id) DT_CAT(node_id, _SUPPORTS_ORDS)

[carlescufi]

OK, no objections in that case @JordanYates

[carlescufi]

This is now in good shape. Thanks @JordanYates.

[carlescufi]

@tbursztyka @mbolivar-nordic @gmarull @ceolin feedback very welcome on this PR.

[mbolivar-nordic]

Looking at this again a second time, is there any reason for the asymmetry here?

We have dependencies both from devicetree and declared by the build system as "injected" dependencies. So if a device D1 which is not created from devicetree requires device D2 that is created from devicetree, we still know that D2 supports D1 at gen_handles.py time. Why not include it here?

[JordanYates]

This comment is perhaps a little bit misleading for the supports direction, as a software construct CANNOT inject any dependencies. This is because DEVICE_DEFINE does not expose the required arguments to Z_DEVICE_DEFINE.

To be honest I'm not entirely sure of the purpose of the injected dependencies in the current implementation. Any ordinals passed to the constructor are not transformed by gen_handles.py, and ordinals are generally useless. If a dependency has an ordinal it implies that it is from devicetree, so why is the dependency not expressed in devicetree in the first place? As already noted, a software device cannot express dependencies.