Date   

Re: [RFC] Add DEV_NOT_IMPLEMENTED error code

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/12/2016 05:52 AM, Andre Guedes wrote:
Hi all,

It seems we don't have a consensus about what error code the device driver
should return in case a given driver API is not implemented. If we take a
look at suspend() and resume() functions, which are not implemented by some
device drivers, we can find three different return codes:
- DEV_OK: used in i2c_dw.c, i2c_atmel_sam3.c and gpio_sch.c
- DEV_INVALID_OP: used in pwm_dw.c, gpio_mmio.c and gpio_atmel_sam3.c
- DEV_NO_SUPPORT: used in i2c_qmsi.c and spi_qmsi.c
We definitely need to have one answer all drivers agree on.

I had an RFC where the suspend/resume functions move to the device
level and out of the device type specific APIs. This allows the PM
app/subsystem/entity to call the PM functions without needing to
know the type of the device.

I think I had agreement on the RFC but it fell by the wayside as we
were creeping up on the release date. I will get it rebased and
published again. Once we get agreement we can appoint all the
stuckies to update the drivers accordingly.

For these situations, a new error code (DEV_NOT_IMPLEMENTED) seems to be
applicable. If a new error code is not desired, we should agree on one
and use it in all device drivers.
In the new model the functions would be required to be implemented, the
RFC included a null implementation for drivers to use if they had no
work to do during suspend/resume. Still a topic for discussion but the
null functions can just return success meaning I have done everything
I need to or can do :-).

Regards,

Andre


Re: [RFC] Add DEV_NOT_IMPLEMENTED error code

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Andre Guedes [mailto:andre.guedes(a)intel.com]
Sent: Friday, February 12, 2016 5:52 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC] Add DEV_NOT_IMPLEMENTED error code

Hi all,

It seems we don't have a consensus about what error code the device driver
should return in case a given driver API is not implemented. If we take a look
at suspend() and resume() functions, which are not implemented by some
device drivers, we can find three different return codes:
- DEV_OK: used in i2c_dw.c, i2c_atmel_sam3.c and gpio_sch.c
- DEV_INVALID_OP: used in pwm_dw.c, gpio_mmio.c and
gpio_atmel_sam3.c
- DEV_NO_SUPPORT: used in i2c_qmsi.c and spi_qmsi.c
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.



For these situations, a new error code (DEV_NOT_IMPLEMENTED) seems to
be applicable. If a new error code is not desired, we should agree on one and
use it in all device drivers.
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.



Regards,

Andre


Re: [RFC] Add DEV_NOT_IMPLEMENTED error code

Mitsis, Peter <Peter.Mitsis@...>
 

See [Peter]

-----Original Message-----
From: Andre Guedes [mailto:andre.guedes(a)intel.com]
Sent: February-12-16 8:52 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC] Add DEV_NOT_IMPLEMENTED error code

Hi all,

It seems we don't have a consensus about what error code the device driver
should return in case a given driver API is not implemented. If we take a look at
suspend() and resume() functions, which are not implemented by some device
drivers, we can find three different return codes:
- DEV_OK: used in i2c_dw.c, i2c_atmel_sam3.c and gpio_sch.c
- DEV_INVALID_OP: used in pwm_dw.c, gpio_mmio.c and gpio_atmel_sam3.c
- DEV_NO_SUPPORT: used in i2c_qmsi.c and spi_qmsi.c

For these situations, a new error code (DEV_NOT_IMPLEMENTED) seems to be
applicable. If a new error code is not desired, we should agree on one and use it
in all device drivers.

Regards,

Andre
[Peter] - Is there a reason why should not use the existing error code ENOSYS? From the description taken from http://www.gnu.org/software/libc/manual/html_node/Error-Codes.html (pasted below) I would think that it would fit our purposes.

Macro: int ENOSYS
Function not implemented. This indicates that the function called is not implemented at all, either in the C library itself or in the operating system. When you get this error, you can be sure that this particular function will always fail with ENOSYS unless you install a new version of the C library or the operating system.

Peter Mitsis


[RFC] Add DEV_NOT_IMPLEMENTED error code

Andre Guedes <andre.guedes@...>
 

Hi all,

It seems we don't have a consensus about what error code the device driver
should return in case a given driver API is not implemented. If we take a
look at suspend() and resume() functions, which are not implemented by some
device drivers, we can find three different return codes:
- DEV_OK: used in i2c_dw.c, i2c_atmel_sam3.c and gpio_sch.c
- DEV_INVALID_OP: used in pwm_dw.c, gpio_mmio.c and gpio_atmel_sam3.c
- DEV_NO_SUPPORT: used in i2c_qmsi.c and spi_qmsi.c

For these situations, a new error code (DEV_NOT_IMPLEMENTED) seems to be
applicable. If a new error code is not desired, we should agree on one
and use it in all device drivers.

Regards,

Andre