Error code handling by GPIO subsystem for PIN_CONFIG_PERSIST_STATE config

[LakshmiPraveen Kopparthi <LakshmiPraveen.Kopparthi@xxxxxxxxxxxxx>]

Hello GPIO Maintainers,

I am writing a GPIO device driver for one of our PCIe based
devices.While addressing the warnings and errors reported by checkpatch
script, I ran into an problem while fixing this. 

WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP#197:
FILE: kernel_src/drivers/gpio/gpio-pci1xxxx.c:159:+ ret = -ENOTSUPP;

This warning is reported against the gpio_chip -> set_config()
callback's implementation because for the not supported configurations,
-ENOTSUPP is returned by this callback.If -ENOTSUPP is replaced by --
 -EOPNOTSUPP , the GPIOs are not accessible from both the device node
(char device in /dev) and from sysfs interface as well.

On further analysis it is understood that while trying to access a gpio
from user space,

The gpio sub system calls gpiod_set_transitory() API to issue a set
configuration with PIN_CONFIG_PERSIST_STATE as a parameter.In this
context, set_config() call back in the device's source code gets
called. Since the PIN_CONFIG_PERSIST_STATE configuration is not
supported by our device, It returns an error code.

If the error code is -EOPNOTSUPP, then the gpio access request is
terminated by returning the error code as EOPNOTSUPP.If set_config()
returns ENOTSUPP then the API- gpio_set_config_with_argument_optional()
internally updates the return value to true  thus making the gpio
access request to proceed further.

If gpio_set_config_with_argument_optional() API updated to handle the
EOPNOTSUPP along with ENOTSUPP, then the issue seemed to be resolved.

I am planning to submit a patch to add support for our device. Please
let me know If my understanding is correct or not and also the way
forword on this issue.   

Thanks,
Lakshmi Praveen.