From: Jeremy Fertic <jeremyfertic@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
devel@driverdev.osuosl.org, Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
linux-iio@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Hartmut Knaack <knaack.h@gmx.de>
Subject: Re: [PATCH 04/11] staging: iio: adt7316: fix handling of dac high resolution option
Date: Thu, 13 Dec 2018 15:01:46 -0700 [thread overview]
Message-ID: <20181213220146.GA2496@r2700x.localdomain> (raw)
In-Reply-To: <20181212082315.GI3116@kadam>
On Wed, Dec 12, 2018 at 11:23:16AM +0300, Dan Carpenter wrote:
> On Tue, Dec 11, 2018 at 05:54:56PM -0700, Jeremy Fertic wrote:
> > @@ -651,10 +649,12 @@ static ssize_t adt7316_store_da_high_resolution(struct device *dev,
> > u8 config3;
> > int ret;
> >
> > + if (chip->id == ID_ADT7318 || chip->id == ID_ADT7519)
> > + return -EPERM;
>
> return -EINVAL is more appropriate than -EPERM.
>
> regards,
> dan carpenter
>
I chose -EPERM because the driver uses it quite a few times in similar
circumstances. At least with this driver, -EINVAL is used when the user
attempts to write data that would never be valid. -EPERM is used when
either the current device settings prevent some functionality from being
used, or the device never supports that functionality. This patch is the
latter, that these two chip ids never support this function.
I'll change to -EINVAL in a v2 series, but I wonder if I should hold off
on a separate patch for other instances in this driver since it will be
undergoing a substantial refactoring. Is there any rule of thumb about
when -EPERM is appropriate for a driver, or is -EINVAL almost always the
better option?
next prev parent reply other threads:[~2018-12-13 22:01 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-12 0:54 [PATCH 00/11] staging: iio: adt7316: dac fixes Jeremy Fertic
2018-12-12 0:54 ` [PATCH 01/11] staging: iio: adt7316: fix register and bit definitions Jeremy Fertic
2018-12-16 11:19 ` Jonathan Cameron
2018-12-12 0:54 ` [PATCH 02/11] staging: iio: adt7316: invert the logic of the check for an ldac pin Jeremy Fertic
2018-12-12 8:19 ` Dan Carpenter
2018-12-13 22:06 ` Jeremy Fertic
2018-12-14 6:18 ` Dan Carpenter
2018-12-16 11:23 ` Jonathan Cameron
2018-12-12 0:54 ` [PATCH 03/11] staging: iio: adt7316: fix dac_bits assignment Jeremy Fertic
2018-12-16 11:37 ` Jonathan Cameron
2018-12-17 21:30 ` Jeremy Fertic
2018-12-22 18:03 ` Jonathan Cameron
2018-12-22 18:03 ` Jonathan Cameron
2018-12-12 0:54 ` [PATCH 04/11] staging: iio: adt7316: fix handling of dac high resolution option Jeremy Fertic
2018-12-12 8:23 ` Dan Carpenter
2018-12-13 22:01 ` Jeremy Fertic [this message]
2018-12-14 6:26 ` Dan Carpenter
2018-12-14 21:29 ` Jeremy Fertic
2018-12-12 0:54 ` [PATCH 05/11] staging: iio: adt7316: fix the dac read calculation Jeremy Fertic
2018-12-16 11:45 ` Jonathan Cameron
2018-12-12 0:54 ` [PATCH 06/11] staging: iio: adt7316: fix the dac write calculation Jeremy Fertic
2018-12-16 11:47 ` Jonathan Cameron
2018-12-12 0:54 ` [PATCH 07/11] staging: iio: adt7316: use correct variable in DAC_internal_Vref read Jeremy Fertic
2018-12-16 11:51 ` Jonathan Cameron
2018-12-12 0:55 ` [PATCH 08/11] staging: iio: adt7316: allow adt751x to use internal vref for all dacs Jeremy Fertic
2018-12-16 11:54 ` Jonathan Cameron
2018-12-12 0:55 ` [PATCH 09/11] staging: iio: adt7316: remove dac vref buffer bypass from adt751x Jeremy Fertic
2018-12-16 11:56 ` Jonathan Cameron
2018-12-12 0:55 ` [PATCH 10/11] staging: iio: adt7316: change interpretation of write to dac update mode Jeremy Fertic
2018-12-12 8:31 ` Dan Carpenter
2018-12-12 11:05 ` Jonathan Cameron
2018-12-16 11:59 ` Jonathan Cameron
2018-12-12 0:55 ` [PATCH 11/11] staging: iio: adt7316: correct spelling of ADT7316_DA_EN_VIA_DAC_LDCA Jeremy Fertic
2018-12-16 12:00 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181213220146.GA2496@r2700x.localdomain \
--to=jeremyfertic@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).