-----Original Message-----
From: Andre Guedes [mailto:andre.guedes(a)intel.com]
Sent: Friday, February 12, 2016 8:34 AM
To: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Add DEV_NOT_IMPLEMENTED error code

Hi Daniel,

Quoting Kalowsky, Daniel (2016-02-12 12:53:49)

Early on when we started the driver development, the suspend/resume

functions were developed with the DEV_OK because as far as any OSPM
policy is concerned, there should be no reason these devices would stop it.
This was an not so nice way into fooling that it has happened.

Thanks for the background explanation.

DEV_NO_SUPPORT seems to cover the concept. Not sure we need a

DEV_NOT_IMPLEMENTED. Or as Peter points out ENOSYS works as well.

Yes, DEV_NO_SUPPORT might cover the concept however it brings another
connotation which is "the hardware actually lacks support" (e.g. the
controller doesn't support that feature) and for that case I think the error
code DEV_INVALID_OP might be more suitable.

Good point. You're alternate point (in another post) of ENOSYS not matching is also valid.

I think you've convinced me. The challenge now is to make sure it's used appropriately. As we've shown, we'll need to be explicit with why some functions actually need to return DEV_OK or whatever vs DEV_NO_SUPPORT.

Anyways, if we move forward with DEV_NO_SUPPORT, I think we should fix
the comment in include/device.h since it looks a bit misleading. See below:

--[cut]--
#define DEV_NO_SUPPORT 6 /* Device type not supported */
--[cut]--

Thanks,

Andre