Hi,


On Wed, 9 Mar 2016 11:00:49 +0100
Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> wrote:

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;
}

There was a thread before [1] about differing between an API not supported and an API not
implemented for a given driver implementation. This would be done by returning DEV_NOT_IMPLEMENTED
instead of DEV_NO_SUPPORT. DEV_NOT_IMPLEMENTED hasn't been added to device.h yet, but the idea got
a green light back then from what I can tell.

This RFC would block that, so we need to keep this in mind and re-visit that discussion.

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.

+1 for this to be considered.

Cheers,
jesus

[1]
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/thread/ONIGOHXRQWFFEAP2UBURZV7IOSFPQH5F/#ONIGOHXRQWFFEAP2UBURZV7IOSFPQH5F