Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210503144350.7496-1-aardelean@deviqon.com> <20210508161643.5990ec15@jic23-huawei>
In-Reply-To: <20210508161643.5990ec15@jic23-huawei>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Sat, 8 May 2021 20:21:08 +0200
Message-ID: <CACRpkdaK6AMVUC+B7JW3y28nNeAYHAS9UjC40KfShZNrHLD7rQ@mail.gmail.com>
Subject: Re: [PATCH] iio: core: return ENODEV if ioctl is unknown
To:     Jonathan Cameron <jic23@kernel.org>,
        Greg KH <gregkh@linuxfoundation.org>
Cc:     Alexandru Ardelean <aardelean@deviqon.com>,
        linux-iio <linux-iio@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Paul Cercueil <paul@crapouillou.net>,
        Nuno Sa <nuno.sa@analog.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, May 8, 2021 at 5:15 PM Jonathan Cameron <jic23@kernel.org> wrote:
> On Mon,  3 May 2021 17:43:50 +0300 Alexandru Ardelean <aardelean@deviqon.com> wrote:
>
> > When the ioctl() mechanism was introduced in IIO core to centralize the
> > registration of all ioctls in one place via commit 8dedcc3eee3ac ("iio:
> > core: centralize ioctl() calls to the main chardev"), the return code was
> > changed from ENODEV to EINVAL, when the ioctl code isn't known.
> >
> > This was done by accident.
> >
> > This change reverts back to the old behavior, where if the ioctl() code
> > isn't known, ENODEV is returned (vs EINVAL).
> >
> > This was brought into perspective by this patch:
> >   https://lore.kernel.org/linux-iio/20210428150815.136150-1-paul@crapouillou.net/
> >
> > Fixes: 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev")
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Paul Cercueil <paul@crapouillou.net>
> > Cc: Nuno Sa <nuno.sa@analog.com>
> > Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
>
> This is going to be a little messy to apply as lots of churn in that file.
> What I've done for now is pulled the fixes-togreg branch forwards onto
> current staging/staging-linus but I'll do that again after
> staging/staging-linus moves onto an rc1 or similar base.

This is starting to become a recurring problem is it not?

Have you considered the option to start to send your pull
requests to Linus (Torvalds) directly?

I suppose the current scheme is used because IIO changes
can affect drivers/staging/ but at this point that thing is
so much smaller than the stuff in drivers/iio proper that
I start to question if it's worth it.

Unless you really like to base your work on Gregs tree for
some reason or other, that is.

Yours,
Linus Walleij