[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240118131544.GA151488@rigel>
Date: Thu, 18 Jan 2024 21:15:44 +0800
From: Kent Gibson <warthog618@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Hugo Villeneuve <hugo@...ovil.com>, Bartosz Golaszewski <brgl@...ev.pl>,
gregkh@...uxfoundation.org, jirislaby@...nel.org,
cosmin.tanislav@...log.com, shc_work@...l.ru,
linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
Hugo Villeneuve <hvilleneuve@...onoff.com>
Subject: Re: [PATCH 15/18] serial: max310x: replace ENOTSUPP with preferred
EOPNOTSUPP (checkpatch)
On Thu, Jan 18, 2024 at 10:59:34AM +0200, Andy Shevchenko wrote:
> On Thu, Jan 18, 2024 at 1:59 AM Hugo Villeneuve <hugo@...ovil.com> wrote:
> > On Thu, 18 Jan 2024 01:24:11 +0200
> > Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> > > On Thu, Jan 18, 2024 at 12:39 AM Hugo Villeneuve <hugo@...ovil.com> wrote:
>
> ...
>
> > > > Fixes the following checkpatch warning:
> > > >
> > > > WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP
> > >
> > > NAK.
> > > It's a false positive.
> > >
> > > > According to include/linux/errno.h, ENOTSUPP is
> > > > "Defined for the NFSv3 protocol", so replace it with preferred EOPNOTSUPP.
> > >
> > > The GPIO subsystem uses this internal error code internally. User
> > > space won't get it, so users may not see this one.
> >
> > Hi Andy,
> > I will drop the patch then.
> >
> > What about adding a comment to prevent future fixes?
> >
> > - return -ENOTSUPP;
> > + return -ENOTSUPP; /*
> > + * ENOTSUPP is used for backward compatibility
> > + * with GPIO subsystem.
> > + */
>
> It's kinda useless to add it to a single (GPIO) driver.
> Rather it needs to be mentioned somewhere between
> https://www.kernel.org/doc/html/latest/driver-api/gpio/index.html.
>
> +Cc: Kent, Bart. It seems we have a handful of drivers violating this
> (basically following what checkpatch says) and GPIO not documenting
> this specific error code and its scope. Did I miss anything?
>
You are correct - the GPIO subsystem is expecting ENOTSUPP if the config
is not supported. In some cases it absorbs the failure or emulates the
feature instead (open drain/source, debounce). Returning EOPNOTSUPP
would be unfortunate, so checkpatch is not being helpful here.
And don't get me started on the gpio_chip interface contract being too
vague.
There are a handful of ways this could be addressed (documentation,
checkpatch, handle either, switch to EOPNOTSUPP, ... or some combination),
but making that call is definitely in Bart's court.
Cheers,
Kent.
Powered by blists - more mailing lists