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: <20210428150815.136150-1-paul@crapouillou.net> <CY4PR03MB3112198E9789BF3D95959E6F99409@CY4PR03MB3112.namprd03.prod.outlook.com>
 <CY4PR03MB311245DA10E715A44DDC10C099409@CY4PR03MB3112.namprd03.prod.outlook.com>
 <20210503120615.64b396bd@jic23-huawei> <CACRpkdaA5dgG3f8fEqkSny_uUYC_1nFu3=GAPtwS=aoy7qYsJg@mail.gmail.com>
In-Reply-To: <CACRpkdaA5dgG3f8fEqkSny_uUYC_1nFu3=GAPtwS=aoy7qYsJg@mail.gmail.com>
From:   Alexandru Ardelean <ardeleanalex@gmail.com>
Date:   Mon, 3 May 2021 17:35:17 +0300
Message-ID: <CA+U=DsqUmzcpDrzBi7smucLt6X+qRMXxV18D5+0KNXqGzeCGXw@mail.gmail.com>
Subject: Re: [PATCH] tools/iio: iio_event_monitor: Fix ioctl error check
To:     Linus Walleij <linus.walleij@linaro.org>
Cc:     Jonathan Cameron <jic23@kernel.org>,
        "Sa, Nuno" <Nuno.Sa@analog.com>,
        Paul Cercueil <paul@crapouillou.net>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, May 3, 2021 at 5:31 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, May 3, 2021 at 1:05 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> > So, I did a bit of detective work on this one.  Seems this change in error
> > code was actually introduced as a side effect of Alex's recent rework of
> > the IOCTLs.  Prior to that we returned -ENODEV for this case and now
> > we do indeed return EINVAL.
> >
> > So we may need to figure out how to fix that, or decide that such is life
> > and modify this code to give the right error message as done in this patch...
> >
> > Linus / Alex, thoughts?  It's always been a bit messy because we also
> > return -ENODEV in the path where the ioctl hits a driver that is going away
> > so it hasn't uniquely identified a lack of support for a long time, even
> > if that is by far the most likely reason for this return code.
>
> Normally this would be ABI if any existing userspace can break because
> of the wrong error code being returned. Linus (the other one) has
> clearly stated that the ABI is a contract that cannot be broken.
>
> So I would just try to fix the errorpath to go back to returning -ENODEV.

Same from my side.
I was just looking through the code now.

Will send a patch.
Sorry for the breakage.

>
> Yours,
> Linus Walleij