linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cosmin Tanislav <demonsingur@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Cosmin Tanislav <cosmin.tanislav@analog.com>
Subject: Re: [PATCH v4 2/2] iio: adc: ad4130: add AD4130 driver
Date: Wed, 8 Jun 2022 23:11:51 +0300	[thread overview]
Message-ID: <37ac71be-78d6-a266-045b-18164d715e57@gmail.com> (raw)
In-Reply-To: <CAHp75Vdvng-fxt-p2bHJiF8i967eh1o_MUgDFN_odhW0sLu69A@mail.gmail.com>



On 6/8/22 18:59, Andy Shevchenko wrote:
> On Wed, Jun 8, 2022 at 12:19 PM Cosmin Tanislav <demonsingur@gmail.com> wrote:
>>
>> AD4130-8 is an ultra-low power, high precision, measurement solution for
>> low bandwidth battery operated applications.
>>
>> The fully integrated AFE (Analog Front-End) includes a multiplexer for up
>> to 16 single-ended or 8 differential inputs, PGA (Programmable Gain
>> Amplifier), 24-bit Sigma-Delta ADC, on-chip reference and oscillator,
>> selectable filter options, smart sequencer, sensor biasing and excitation
>> options, diagnostics, and a FIFO buffer.
> 
> I believe we may gain a few LoCs by slightly bending the rule of 80.
> Also see below.
> 

I'll only go over the 80 columns limit if Jonathan agrees to it.

>> +       *size = ad4130_reg_size[reg];
>> +       if (!*size)
>> +               return -EINVAL;
> 
> Is this check necessary?
> 

Yes. I haven't described all registers in the table, and the registers
can be accessed by the user via the debugfs_reg_access() method.

>> +static void ad4130_gpio_set(struct gpio_chip *gc, unsigned int offset,
>> +                           int value)
>> +{
>> +       struct ad4130_state *st = gpiochip_get_data(gc);
>> +       unsigned int real_offset = st->gpio_offsets[offset];
> 
> Can't you use valid_mask instead of this additional array? In such a
> case the real offset can be got by the number of the set bit, no?
> 

I'm not sure what you mean by this? If valid_mask will prevent all
GPIOs equivalent to the bits not set in the mask from being exposed,
then yes, it could be useful. I wish I knew about it earlier since
it's already the second driver in which I use this approach.

>> +       for (i = 0; i < AD4130_MAX_SETUPS; i++) {
>> +               struct ad4130_slot_info *slot_info = &st->slots_info[i];
>> +
>> +               /* Immediately accept a matching setup info. */
> 
>> +               if (!memcmp(target_setup_info, &slot_info->setup,
>> +                           sizeof(*target_setup_info))) {
> 
> Instead, you may use crc32 and save it, the matching will be much faster.
> 
> The example, where it's done for the same purposes (to compare later)
> https://elixir.bootlin.com/linux/latest/source/drivers/acpi/scan.c#L659
> 

I think it's fine as it is. Most people won't use than many channels
anyway.

>> +                       *slot = i;
>> +                       return 0;
>> +               }
>> +
>> +               /* Ignore all setups which are used by enabled channels. */
>> +               if (slot_info->enabled_channels)
>> +                       continue;
>> +
>> +               /* Find the least used slot. */
> 
> Have you considered to use
> https://elixir.bootlin.com/linux/latest/source/include/linux/list_lru.h
> ?
> 

No. And I don't think I intend to.
>> +       const struct ad4130_filter_config *filter_config =
>> +               &ad4130_filter_configs[filter_mode];
> 
> One line? Or even a helper, since you are using this more than once.
> 

I don't think creating a helper would be helpful here. I can save like,
one character. Or you meant a helper that also declares the
filter_config variable? That would make the code even harder to read.

>> +       switch (ref_sel) {
>> +       case AD4130_REF_REFIN1:
>> +               ret = regulator_get_voltage(st->regulators[2].consumer);
>> +               break;
>> +       case AD4130_REF_REFIN2:
>> +               ret = regulator_get_voltage(st->regulators[3].consumer);
>> +               break;
>> +       case AD4130_REF_AVDD_AVSS:
>> +               ret = regulator_get_voltage(st->regulators[0].consumer);
>> +               break;
>> +       case AD4130_REF_REFOUT_AVSS:
>> +               ret = st->int_ref_uv;
>> +               break;
>> +       default:
>> +               ret = -EINVAL;
>> +               break;
>> +       }
> 
>> +       if (ret < 0)
>> +               return dev_err_probe(dev, ret, "Cannot use reference %u\n",
>> +                                    ref_sel);
> 
> Can it be moved to the caller where it would cleaner to use, I think?
> As a good side effect the all above will be shortened to just return directly.
> 

I'm pretty sure I remember Jonathan suggested moving it inside the
function.

>> +       ret = ad4130_get_ref_voltage(st, setup_info->ref_sel);
>> +       if (ret < 0)
>> +               return ret;
>> +
>> +       return 0;
> 
> In all cases what does the positive return value mean?
> If there is no meaning, drop all these ' < 0' parts and esp. here use simply
> 
> return ad4130_get_ref_voltage(...);
> 

ad4130_get_ref_voltage() returns the voltage of the specified reference
via its return value.

The voltage would be positive, while an error code would be negative.
Same for ad4130_find_table_index() where < 0 is also used.

>> +               for (j = 0; j < AD4130_MAX_PGA; j++) {
>> +                       unsigned int pow = resolution + j - st->bipolar;
> 
>> +                       unsigned int nv = div_u64((((u64)ret * NANO) >>
>> +                                                  pow), MILLI);
> 
> It will be much better if you make it on one line. Moreover, it seems
> it's ivariamt to the loop, why it's inside the loop?
> 

pow depends on j, nv depends on pow.


  reply	other threads:[~2022-06-08 20:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08  9:12 [PATCH v4 0/2] AD4130 Cosmin Tanislav
2022-06-08  9:12 ` [PATCH v4 1/2] dt-bindings: iio: adc: add AD4130 Cosmin Tanislav
2022-06-09 21:03   ` Rob Herring
2022-06-15 12:43     ` Cosmin Tanislav
2022-06-08  9:12 ` [PATCH v4 2/2] iio: adc: ad4130: add AD4130 driver Cosmin Tanislav
2022-06-08 15:59   ` Andy Shevchenko
2022-06-08 20:11     ` Cosmin Tanislav [this message]
2022-06-14 11:47       ` Jonathan Cameron
2022-06-18 13:48   ` 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=37ac71be-78d6-a266-045b-18164d715e57@gmail.com \
    --to=demonsingur@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=cosmin.tanislav@analog.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /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).