Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: michael.hennerich@analog.com
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"device-drivers-devel@blackfin.uclinux.org"
	<device-drivers-devel@blackfin.uclinux.org>,
	Drivers <Drivers@analog.com>
Subject: Re: [PATCH] iio: industrialio-core: iio_write_channel_info accept IIO_VAL_INT_PLUS_NANO
Date: Tue, 07 Jun 2011 14:39:18 +0100	[thread overview]
Message-ID: <4DEE2A06.4010102@cam.ac.uk> (raw)
In-Reply-To: <4DEE226C.1020208@analog.com>

On 06/07/11 14:06, Michael Hennerich wrote:
> On 06/07/2011 03:04 PM, Jonathan Cameron wrote:
>> On 06/07/11 12:21, michael.hennerich@analog.com wrote:
>>> From: Michael Hennerich<michael.hennerich@analog.com>
>>>
>>> Allow iio_write_channel_info() to accept IIO_VAL_INT_PLUS_NANO
>> Hmm. I wonder if this is the right way around to do it.  This puts a hard
>> requirement on the number of digits being what the driver expects.
>>
> 
> Well - this requirement was there before - it was just limited to 6 digits.
> Extra digits were simply cut off.
Yup, but that was fine.  Extra digits are least significant bits, so cutting to the
number that can be handled kind of makes sence
>> Alternative would be an optional callback (not needed if everything is int_plus_micro)
>> that allows the driver to be queried for what it wants and then reads data under
>> the assumption that is what it has.
> 
> Ideally write_raw would take an additional argument. Just like read_raw returns what it has!
Can do, but it still pushes handling logic into the drivers in all cases, whereas the
callback keeps things simple in drivers and keeps handling in the core (and has no
effect at all on existing drivers).
> 
>> Which do people think would work better?
>>
>> The approach here has the flaw that if someone writes a 9 decimal digit value
>> to something expect 6 decimal digits the core will pass it on whereas it should
>> have ignored the last 3 digits.
> 
> I don't think it's getting a big problem.
> The driver itself knows the format what he expects.
> If someone writes more digits than allowed it's simply not a match or fault.
But that's not the case with what you have here.  It is quite capable of
sending something in nano to a device expecting micro and there is no
way for the driver to detect this has happened.
> 
> In order to avoid faults - we could also say 6-8 digits are treated as mirco while 9 and more are treated as nano.
> 
>      switch (fract_digits) {
>      case 6..8: /* IIO_VAL_INT_PLUS_MICRO */
>              fract_mult = 100000;
>              break;
>      case 9..12: /* IIO_VAL_INT_PLUS_NANO */
>              fract_mult = 100000000;
>              break;
>      default:
>              return -EINVAL;
>      }
> 
>>> Signed-off-by: Michael Hennerich<michael.hennerich@analog.com>
>>> ---
>>>   drivers/staging/iio/industrialio-core.c |   27 +++++++++++++++++++++------
>>>   1 files changed, 21 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c
>>> index e5a7663..74158c1 100644
>>> --- a/drivers/staging/iio/industrialio-core.c
>>> +++ b/drivers/staging/iio/industrialio-core.c
>>> @@ -412,25 +412,40 @@ static ssize_t iio_write_channel_info(struct device *dev,
>>>   {
>>>        struct iio_dev *indio_dev = dev_get_drvdata(dev);
>>>        struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
>>> -     int ret, integer = 0, micro = 0, micro_mult = 100000;
>>> +     int ret, fract_digits, integer = 0, fract = 0, fract_mult;
>>>        bool integer_part = true, negative = false;
>>>
>>>        /* Assumes decimal - precision based on number of digits */
>>>        if (!indio_dev->info->write_raw)
>>>                return -EINVAL;
>>> +
>>> +     fract_digits = strnchr(buf, len, '\n') - strnchr(buf, len, '.') - 1;
>>> +
>>> +     switch (fract_digits) {
>>> +     case 6: /* IIO_VAL_INT_PLUS_MICRO */
>>> +             fract_mult = 100000;
>>> +             break;
>>> +     case 9: /* IIO_VAL_INT_PLUS_NANO */
>>> +             fract_mult = 100000000;
>>> +             break;
>>> +     default:
>>> +             return -EINVAL;
>>> +     }
>>> +
>>>        if (buf[0] == '-') {
>>>                negative = true;
>>>                buf++;
>>>        }
>>> +
>>>        while (*buf) {
>>>                if ('0'<= *buf&&  *buf<= '9') {
>>>                        if (integer_part)
>>>                                integer = integer*10 + *buf - '0';
>>>                        else {
>>> -                             micro += micro_mult*(*buf - '0');
>>> -                             if (micro_mult == 1)
>>> +                             fract += fract_mult*(*buf - '0');
>>> +                             if (fract_mult == 1)
>>>                                        break;
>>> -                             micro_mult /= 10;
>>> +                             fract_mult /= 10;
>>>                        }
>>>                } else if (*buf == '\n') {
>>>                        if (*(buf + 1) == '\0')
>>> @@ -448,11 +463,11 @@ static ssize_t iio_write_channel_info(struct device *dev,
>>>                if (integer)
>>>                        integer = -integer;
>>>                else
>>> -                     micro = -micro;
>>> +                     fract = -fract;
>>>        }
>>>
>>>        ret = indio_dev->info->write_raw(indio_dev, this_attr->c,
>>> -                                      integer, micro, this_attr->address);
>>> +                                      integer, fract, this_attr->address);
>>>        if (ret)
>>>                return ret;
>>>
>>
> 
> 


  reply	other threads:[~2011-06-07 13:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 11:21 [PATCH] iio: industrialio-core: iio_write_channel_info accept IIO_VAL_INT_PLUS_NANO michael.hennerich
2011-06-07 13:04 ` Jonathan Cameron
2011-06-07 13:06   ` Michael Hennerich
2011-06-07 13:39     ` Jonathan Cameron [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-06-07 14:57 michael.hennerich
2011-06-07 15:24 ` 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=4DEE2A06.4010102@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=Drivers@analog.com \
    --cc=device-drivers-devel@blackfin.uclinux.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=michael.hennerich@analog.com \
    /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