Hi Maciek,

An obligatory example:

<---- code --------->
struct pinmux_driver_api {
pmux_set set;
pmux_get get;
pmux_pullup pullup;
pmux_input input;
};
...

static inline uint32_t pinmux_pin_input_enable(struct device *dev,
uint32_t pin,
uint8_t func)
{
struct pinmux_driver_api *api;

api = (struct pinmux_driver_api *) dev->driver_api;

/* proposed enhacement */
if (!api->input) {
return DEV_NO_SUPPORT;
}

Note that on many API, some calls have a mandatory support (let's say
spi_transceive),
so such test would not have to be generalized.

What about a different approach:

Thing is, Zephyr is an OS for embedded platform thus the developer is
really close to the hw he is using.
Thus, he should know what's available in terms of drivers and, finally,
what features these drivers expose.

So, instead of multiplying such test, which will take some bytes here
and there.
We could do this test through __ASSERT(). The user, while testing its
app could enable the assert checks
and verify he is not using unsupported features. And he could fix his
code accordingly, then disable the asserts.

Not sure this would fit all uses case though, I might miss something.

Tomasz