On Tue, Apr 7, 2020 at 10:26 AM Sa, Nuno <Nuno.Sa@xxxxxxxxxx> wrote:
> > From: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
> > Sent: Montag, 6. April 2020 18:20
> > To: Sa, Nuno <Nuno.Sa@xxxxxxxxxx>
> > Cc: linux-iio <linux-iio@xxxxxxxxxxxxxxx>; devicetree
> > <devicetree@xxxxxxxxxxxxxxx>; Jonathan Cameron <jic23@xxxxxxxxxx>;
> > Hartmut Knaack <knaack.h@xxxxxx>; Lars-Peter Clausen
> > <lars@xxxxxxxxxx>; Peter Meerwald-Stadler <pmeerw@xxxxxxxxxx>; Rob
> > Herring <robh+dt@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>;
> > Ardelean, Alexandru <alexandru.Ardelean@xxxxxxxxxx>; Hennerich,
> > Michael <Michael.Hennerich@xxxxxxxxxx>
> > Subject: Re: [PATCH v4 5/6] iio: imu: Add support for adis16475
> >
> > On Mon, Apr 6, 2020 at 6:10 PM Nuno Sá <nuno.sa@xxxxxxxxxx> wrote:
...
> > > + for_each_set_bit(bit, indio_dev->active_scan_mask,
> > > + indio_dev->masklength) {
> >
> > One line?
> >
>
> It goes beyond 80 col limit... I know I could initialize these to some local const but...
That's why question mark is there.
Nonetheless, if it ~2-3 characters more, I would leave it on one line anyway.
JFYI: readability has a priority over 80 limit.
> > > + }
...
> > > + if (scaled_out_freq < 1900 || scaled_out_freq > 2100) {
> > > + dev_err(dev,
> > > + "Invalid value:%u for adi,scaled-output-hz",
> > > + scaled_out_freq);
> >
> > When there is no property or property has a value 0 this message can't
> > tell the difference.
> > Perhaps you have to check return code from device_property_read_u32()
> > call.
> >
>
> Well, I think we don't really need to. If the sync mode is scaled, then this property is mandatory
> (and this is stated in the bindings). So, I don't really care if the property is not there or if it's just
> a wrong value. We should fail either way and I'm not sure an extra if with some other message will
> give us that extra value...
Up to maintainer (I have no strong opinion about this)
> > > + return -EINVAL;
> > > + }
...
> > > + /*
> > > + * It is possible to configure the data ready polarity. Furthermore, we
> > > + * need to update the adis struct if we want data ready as active low.
> > > + */
> > > + irq_type = irqd_get_trigger_type(desc);
> > > + if (irq_type == IRQF_TRIGGER_RISING) {
> > > + polarity = 1;
For the sake of consistency I would assign irq_flag here as well.
> > > + } else if (irq_type == IRQF_TRIGGER_FALLING) {
> > > + polarity = 0;
> > > + st->adis.irq_flag = IRQF_TRIGGER_FALLING;
> > > + } else {
> > > + dev_err(&spi->dev, "Invalid interrupt type 0x%x specified\n",
> > > + irq_type);
> > > + return -EINVAL;
> > > + }
> >
> > Here is the problem. You got type, but you compare it to flags. It's
> > not correct.
> > Although values are the same, the meaning is different.
> >
>
> Hmm, thanks! Honestly, this was copy paste from adis16480 and I never realized this. I will
> use IRQ_TYPE_EDGE_RISING and IRQ_TYPE_EDGE_FALLING. I guess we need a patch changing this
> in adis16480...
As a separate patch, yes.
--
With Best Regards,
Andy Shevchenko
