ENOSYS has ambiguous meaning.

[Mierunski]

In the errno.h file, we can find:

#define ENOSYS 71 /* Function not implemented */

While checkpatch gives following information:

WARNING:ENOSYS: ENOSYS means 'invalid syscall nr' and nothing else

i.e. I wanted to use it in the following way:

__syscall int uart_configure(struct device *dev, struct uart_config *cfg);

static inline int _impl_uart_configure(struct device *dev,
                       struct uart_config *cfg)
{
    const struct uart_driver_api *api =
                (const struct uart_driver_api *)dev->driver_api;

    if (api->configure) {
        return api->configure(dev, cfg);
    }
    return -ENOSYS;
}

Where -ENOSYS If driver has not implemented this function -ENOTSUP If device does not support given configuration.

Which information if true? errno.h file or checkpatch?

[himanshujha199640]

In linux kernel's context from where checkpatch.pl is actually derived:

https://github.com/torvalds/linux/commit/e15f431fe2d53cd4673510736da7d4fa1090e096 https://github.com/torvalds/linux/commit/91c9afaf97ee554d2cd3042a5ad01ad21c99e8c4

But grepping through Zephyr sources:

himanshu@himanshu-Vostro-3559:~/zephyr$ git grep -w "ENOSYS"
drivers/led_strip/ws2812b_sw.c: return -ENOSYS;
ext/hal/libmetal/libmetal/lib/system/linux/init.c:              return -ENOSYS;
ext/hal/libmetal/libmetal/lib/system/linux/utilities.c:         return -ENOSYS;
lib/libc/minimal/include/errno.h:#define ENOSYS 71 /* Function not implemented */
scripts/checkpatch.pl:# ENOSYS means "bad syscall nr" and nothing else.  This will have a small
scripts/checkpatch.pl:                  WARN("ENOSYS",
scripts/checkpatch.pl:                       "ENOSYS means 'invalid syscall nr' and nothing else\n" . $herecurr);
tests/bluetooth/bluetooth/src/bluetooth.c:#define EXPECTED_ERROR -ENOSYS

So, I believe errno.h is correct here!

[pfalcon]

Where -ENOSYS If driver has not implemented this function -ENOTSUP If device does not support given configuration.

Note that this doesn't correspond to how "driver multiplexor APIs" (spi, i2c, etc.) currently work. If that is to be changed, it should be changed consistently for all APIs. (Low priority IMHO considering all other tasks we have.)

[mnkp]

The issue has been addressed by #33887. I believe we can close it.