[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Mc7O2FGT3ZHLbNozQpK6bTei=Y0DLrvDSViqG49xUY4Ew@mail.gmail.com>
Date: Thu, 24 Sep 2020 16:29:06 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Kent Gibson <warthog618@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Linus Walleij <linus.walleij@...aro.org>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v9 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL
and GPIO_V2_LINE_GET_VALUES_IOCTL
On Wed, Sep 23, 2020 at 1:12 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
[snip!]
>
> > + /* Bias requires explicit direction. */
> > + if ((flags & GPIO_V2_LINE_BIAS_FLAGS) &&
> > + !(flags & GPIO_V2_LINE_DIRECTION_FLAGS))
> > + return -EINVAL;
>
> Okay, since this is strict we probably may relax it in the future if
> it will be a use case.
> ...
>
> > + /* Only one bias flag can be set. */
>
> Ditto. (Some controllers allow to set both simultaneously, though I
> can't imagine good use case for that)
>
This is an abstraction layer. Only because some controllers allow
this, doesn't mean we should reflect this in our abstraction layer -
especially if we know well that this has no purpose.
Bartosz
Powered by blists - more mailing lists