Re: [PATCH] iio: core: return ENODEV if ioctl is unknown

From: Jonathan Cameron <jic23@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	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>
Subject: Re: [PATCH] iio: core: return ENODEV if ioctl is unknown
Date: Sun, 9 May 2021 11:19:25 +0100	[thread overview]
Message-ID: <20210509111925.52f3f4e3@jic23-huawei> (raw)
In-Reply-To: <CACRpkdaK6AMVUC+B7JW3y28nNeAYHAS9UjC40KfShZNrHLD7rQ@mail.gmail.com>

On Sat, 8 May 2021 20:21:08 +0200
Linus Walleij <linus.walleij@linaro.org> wrote:

> 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?

This particular one isn't a result of the path IIO patches take,
but rather my jumping the gun on getting these out there before
there is an rc1 release.  So would have been in the same position
but referring to Linus' tree rather than Greg's if things went
directly.

> 
> 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.

I guess the perfectionist in me wants to clear the remaining
stuff out of staging before changing the structure that has
worked well (and become very comfortable!). Perhaps you are
right that I shouldn't wait quite as long as that will take.

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

Definitely appreciate Greg's help (and patience), but no
particularly strong reason to waste his time dealing with my
mess ups. Hopefully they'll reduce now IIO trees are going directly
into linux-next though.

> 
> Yours,
> Linus Walleij