All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] i2c_check_functionality and error code
@ 2016-02-14 23:09 Matt Ranostay
       [not found] ` <CAKzfze-B4dx9aghERaRDu7xz0i6pMJcAUGMQX7OWJpWh7i=bxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 7+ messages in thread
From: Matt Ranostay @ 2016-02-14 23:09 UTC (permalink / raw)
  To: Jonathan Cameron, linux-iio

Jonathan et all,

Has anyone noticed that there is no clear consensus on which error
code to return when a i2c_check_functionality() check fails within the
probe function. I've seen so far ENODEV, ENOTSUPP, EOPNOTSUPP, EIO,
and ENOSYS in drivers/iio

Shouldn't these be made a standard value like -ENOTSUPP?

Thanks,

Matt

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] i2c_check_functionality and error code
  2016-02-14 23:09 [RFC] i2c_check_functionality and error code Matt Ranostay
@ 2016-02-21 20:33     ` Jonathan Cameron
  0 siblings, 0 replies; 7+ messages in thread
From: Jonathan Cameron @ 2016-02-21 20:33 UTC (permalink / raw)
  To: Matt Ranostay, linux-iio-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Linux I2C

On 14/02/16 23:09, Matt Ranostay wrote:
> Jonathan et all,
> 
> Has anyone noticed that there is no clear consensus on which error
> code to return when a i2c_check_functionality() check fails within the
> probe function. I've seen so far ENODEV, ENOTSUPP, EOPNOTSUPP, EIO,
> and ENOSYS in drivers/iio
> 
> Shouldn't these be made a standard value like -ENOTSUPP?
Would make sense - but is this the right choice.

Thought I'd grep HWMON as a possible source of a consensus on this and
got no clear answer.  The most common in there looks to be -ENODEV though
(From the first few pages of results anyway ;)

Hohum. Wolfram what do you think?

Worth cleaning this up?  Perhaps even kernel wise would lead to some
consistency. I've never been that sharp on this in IIO so I can't
really talk ;)

Jonathan


> 
> Thanks,
> 
> Matt
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] i2c_check_functionality and error code
@ 2016-02-21 20:33     ` Jonathan Cameron
  0 siblings, 0 replies; 7+ messages in thread
From: Jonathan Cameron @ 2016-02-21 20:33 UTC (permalink / raw)
  To: Matt Ranostay, linux-iio, Wolfram Sang, Linux I2C

On 14/02/16 23:09, Matt Ranostay wrote:
> Jonathan et all,
> 
> Has anyone noticed that there is no clear consensus on which error
> code to return when a i2c_check_functionality() check fails within the
> probe function. I've seen so far ENODEV, ENOTSUPP, EOPNOTSUPP, EIO,
> and ENOSYS in drivers/iio
> 
> Shouldn't these be made a standard value like -ENOTSUPP?
Would make sense - but is this the right choice.

Thought I'd grep HWMON as a possible source of a consensus on this and
got no clear answer.  The most common in there looks to be -ENODEV though
(From the first few pages of results anyway ;)

Hohum. Wolfram what do you think?

Worth cleaning this up?  Perhaps even kernel wise would lead to some
consistency. I've never been that sharp on this in IIO so I can't
really talk ;)

Jonathan


> 
> Thanks,
> 
> Matt
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] i2c_check_functionality and error code
  2016-02-21 20:33     ` Jonathan Cameron
@ 2016-02-21 22:56         ` Wolfram Sang
  -1 siblings, 0 replies; 7+ messages in thread
From: Wolfram Sang @ 2016-02-21 22:56 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Matt Ranostay, linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux I2C

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

> Hohum. Wolfram what do you think?

I'd go for "EOPNOTSUPP" since it is most descriptive. I wouldn't say we
really need to fix it up in the kernel tree. However, I neither would
vote against it.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] i2c_check_functionality and error code
@ 2016-02-21 22:56         ` Wolfram Sang
  0 siblings, 0 replies; 7+ messages in thread
From: Wolfram Sang @ 2016-02-21 22:56 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: Matt Ranostay, linux-iio, Linux I2C

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

> Hohum. Wolfram what do you think?

I'd go for "EOPNOTSUPP" since it is most descriptive. I wouldn't say we
really need to fix it up in the kernel tree. However, I neither would
vote against it.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] i2c_check_functionality and error code
  2016-02-21 22:56         ` Wolfram Sang
@ 2016-02-24 20:42           ` Jonathan Cameron
  -1 siblings, 0 replies; 7+ messages in thread
From: Jonathan Cameron @ 2016-02-24 20:42 UTC (permalink / raw)
  To: Wolfram Sang; +Cc: Matt Ranostay, linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux I2C

On 21/02/16 22:56, Wolfram Sang wrote:
>> Hohum. Wolfram what do you think?
> 
> I'd go for "EOPNOTSUPP" since it is most descriptive. I wouldn't say we
> really need to fix it up in the kernel tree. However, I neither would
> vote against it.
> 
I'm certainly keen on cleaning this up in IIO at the least.
A bit of consistency is always nice and once we have done it once
it should be reasonably pain free.

Anyhow, patches welcome ;)

Jonathan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] i2c_check_functionality and error code
@ 2016-02-24 20:42           ` Jonathan Cameron
  0 siblings, 0 replies; 7+ messages in thread
From: Jonathan Cameron @ 2016-02-24 20:42 UTC (permalink / raw)
  To: Wolfram Sang; +Cc: Matt Ranostay, linux-iio, Linux I2C

On 21/02/16 22:56, Wolfram Sang wrote:
>> Hohum. Wolfram what do you think?
> 
> I'd go for "EOPNOTSUPP" since it is most descriptive. I wouldn't say we
> really need to fix it up in the kernel tree. However, I neither would
> vote against it.
> 
I'm certainly keen on cleaning this up in IIO at the least.
A bit of consistency is always nice and once we have done it once
it should be reasonably pain free.

Anyhow, patches welcome ;)

Jonathan

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-02-24 20:42 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-14 23:09 [RFC] i2c_check_functionality and error code Matt Ranostay
     [not found] ` <CAKzfze-B4dx9aghERaRDu7xz0i6pMJcAUGMQX7OWJpWh7i=bxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-21 20:33   ` Jonathan Cameron
2016-02-21 20:33     ` Jonathan Cameron
     [not found]     ` <56CA1F0D.2060707-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-02-21 22:56       ` Wolfram Sang
2016-02-21 22:56         ` Wolfram Sang
2016-02-24 20:42         ` Jonathan Cameron
2016-02-24 20:42           ` Jonathan Cameron

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.