linux-kernel - Re: [PATCH v1 3/5] iio: accel: bma400: Add triggered buffer support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Mar 2022 18:12:46 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jagath Jog J <jagathjog1996@...il.com>
Cc:     Dan Robertson <dan@...obertson.com>,
        Jonathan Cameron <jic23@...nel.org>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 3/5] iio: accel: bma400: Add triggered buffer support

On Tue, Mar 22, 2022 at 5:40 PM Jagath Jog J <jagathjog1996@...il.com> wrote:
> On Tue, Mar 22, 2022 at 10:54:53AM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 22, 2022 at 12:21 AM Jagath Jog J <jagathjog1996@...il.com> wrote:
> > > On Mon, Mar 21, 2022 at 10:39:22AM +0200, Andy Shevchenko wrote:
> > > > On Sat, Mar 19, 2022 at 8:10 PM Jagath Jog J <jagathjog1996@...il.com> wrote:

...

> > > > A useless label. Moreover this raises a question: why is it okay to
> > > > always mark IRQ as handled?
> > > >
> > > > > +       return IRQ_HANDLED;
> > >
> > > Since I was not using top-half of the interrupt so I marked IRQ as handled
> > > even for error case in the handler.
> >
> > Yes, but why? Isn't it an erroneous state? Does it mean spurious
> > interrupt? Does it mean interrupt is unserviced?
>
> Sorry, even for erroneous state I was returning IRQ_HANDLED.
> As shown below, now for erroneous state and spurious interrupt I will return
> IRQ_NONE and for valid interrupt IRQ_HANDLED will be returned.
>
> Is below method is correct?

The thing is that I don't know. I am not familiar with this hardware.
So, you have to investigate and decide.

> static irqreturn_t bma400_interrupt(int irq, void *private)
> {
>        struct iio_dev *indio_dev = private;
>        struct bma400_data *data = iio_priv(indio_dev);
>        int ret;
>        __le16 status;
>
>        mutex_lock(&data->mutex);
>        ret = regmap_bulk_read(data->regmap, BMA400_INT_STAT0_REG, &status,
>                               sizeof(status));
>        mutex_unlock(&data->mutex);
>        if (ret)
>                return IRQ_NONE;

>        if (le16_to_cpu(status) & BMA400_INT_DRDY_MSK) {
>                iio_trigger_poll_chained(data->trig);
>                return IRQ_HANDLED;
>         }
>
>         return IRQ_NONE;

If you are going with this approach, try to handle errors first, i.e.

    if (...)
        return IRQ_NONE;
    ...
    return IRQ_HANDLED;

> }

-- 
With Best Regards,
Andy Shevchenko