linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v9 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL
Date: Thu, 24 Sep 2020 16:09:21 +0800	[thread overview]
Message-ID: <20200924080921.GE17562@sol> (raw)
In-Reply-To: <CAHp75VdQUbDnjQEr5X5q6WdU6rD=uBNznNn5=Vy=pvdwVj_hEA@mail.gmail.com>

On Wed, Sep 23, 2020 at 02:11:54PM +0300, Andy Shevchenko wrote:
> On Tue, Sep 22, 2020 at 5:35 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > Add support for requesting lines using the GPIO_V2_GET_LINE_IOCTL, and
> > returning their current values using GPIO_V2_LINE_GET_VALUES_IOCTL.
> >
> > The struct linereq implementation is based on the v1 struct linehandle
> > implementation.
> 
> ...
> 

Ooops, nearly missed this one...

> > +       /*
> > +        * Do not allow OPEN_SOURCE & OPEN_DRAIN flags in a single request. If
> 
> You see, in some cases you are using "OR:ed" as understandable for
> programmers, and here & which should be and in plain English and
> really confusing from a programmer's perspective. That's why I prefer
> to see plain English rather than something which is full of encoded
> meanings.
> 

Understand these are pulled directly from the v1 implementation, so I
think that is actually one of Bart's.

But, yeah, it should be 'and'.

> > +        * the hardware actually supports enabling both at the same time the
> > +        * electrical result would be disastrous.
> > +        */
> 
> ...
> 
> > +       /* 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.
> ...
> 

Again, this is drawn directly from the v1 implementation, and I didn't go
changing anything from v1 without good reason.

> > +       /* 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)
> 
> > +       if (((flags & GPIO_V2_LINE_FLAG_BIAS_DISABLED) &&
> > +            (flags & (GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN |
> > +                      GPIO_V2_LINE_FLAG_BIAS_PULL_UP))) ||
> > +           ((flags & GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN) &&
> > +            (flags & GPIO_V2_LINE_FLAG_BIAS_PULL_UP)))
> > +               return -EINVAL;
> 
> ...
> 
> > +static void gpio_v2_line_config_flags_to_desc_flags(u64 flags,
> > +                                                   unsigned long *flagsp)
> > +{
> 
> > +       assign_bit(FLAG_ACTIVE_LOW, flagsp,
> > +                  flags & GPIO_V2_LINE_FLAG_ACTIVE_LOW);
> 
> What I meant is to attach also this to the other assign_bit():s below.
> And just in case a question: why not __asign_bit() do we really need atomicity?
> 

These are initialized as per their order in the flags so it is easier to
tell if any are missing.

The atomicity is not required here, but it is elsewhere so you are
oblidged to use it for all accesses, no?

> > +       if (flags & GPIO_V2_LINE_FLAG_OUTPUT)
> > +               set_bit(FLAG_IS_OUT, flagsp);
> > +       else if (flags & GPIO_V2_LINE_FLAG_INPUT)
> > +               clear_bit(FLAG_IS_OUT, flagsp);
> > +
> > +       assign_bit(FLAG_OPEN_DRAIN, flagsp,
> > +                  flags & GPIO_V2_LINE_FLAG_OPEN_DRAIN);
> > +       assign_bit(FLAG_OPEN_SOURCE, flagsp,
> > +                  flags & GPIO_V2_LINE_FLAG_OPEN_SOURCE);
> > +       assign_bit(FLAG_PULL_UP, flagsp,
> > +                  flags & GPIO_V2_LINE_FLAG_BIAS_PULL_UP);
> > +       assign_bit(FLAG_PULL_DOWN, flagsp,
> > +                  flags & GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN);
> > +       assign_bit(FLAG_BIAS_DISABLE, flagsp,
> > +                  flags & GPIO_V2_LINE_FLAG_BIAS_DISABLED);
> > +}
> 
> ...
> 
> > +static long linereq_get_values(struct linereq *lr, void __user *ip)
> > +{
> > +       struct gpio_v2_line_values lv;
> > +       DECLARE_BITMAP(vals, GPIO_V2_LINES_MAX);
> > +       struct gpio_desc **descs;
> > +       unsigned int i, didx, num_get;
> > +       int ret;
> 
> > +       /* NOTE: It's ok to read values of output lines. */
> > +       if (copy_from_user(&lv, ip, sizeof(lv)))
> > +               return -EFAULT;
> > +
> > +       for (num_get = 0, i = 0; i < lr->num_lines; i++) {
> > +               if (lv.mask & BIT_ULL(i)) {
> > +                       num_get++;
> > +                       descs = &lr->lines[i].desc;
> > +               }
> > +       }
> 
> So what you can do here is something like
> 
> DECLARE_BITMAP(mask, u64);
> 
> ...
> 
> bitmap_from_u64(mask, lv.mask);
> num_get = bitmap_weight(mask, lr->num_lines);
> if (num_get == 0)
>   return -EINVAL;
> 
> for_each_set_bit(i, mask, lr->num_lines)
>       descs = &lr->lines[i].desc;
> // I'm not sure I understood a purpose of the above
> // ah, looks like malloc() avoidance, but you may move it below...
> 
> > +       if (num_get == 0)
> > +               return -EINVAL;
> > +
> 
> > +       if (num_get != 1) {
> 
> ...something like
> 
> if (num_get == 1)
>   descs = ...[find_first_bit(mask, lr->num_lines)];
> else {
>  ...
>  for_each_set_bit() {
>   ...
>  }
> }
> 

As per elsewhere - will give it a shot.

> > +               descs = kmalloc_array(num_get, sizeof(*descs), GFP_KERNEL);
> > +               if (!descs)
> > +                       return -ENOMEM;
> > +               for (didx = 0, i = 0; i < lr->num_lines; i++) {
> > +                       if (lv.mask & BIT_ULL(i)) {
> > +                               descs[didx] = lr->lines[i].desc;
> > +                               didx++;
> > +                       }
> > +               }
> > +       }
> > +       ret = gpiod_get_array_value_complex(false, true, num_get,
> > +                                           descs, NULL, vals);
> > +
> > +       if (num_get != 1)
> > +               kfree(descs);
> > +       if (ret)
> > +               return ret;
> > +
> 
> > +       lv.bits = 0;
> > +       for (didx = 0, i = 0; i < lr->num_lines; i++) {
> > +               if (lv.mask & BIT_ULL(i)) {
> > +                       if (test_bit(didx, vals))
> > +                               lv.bits |= BIT_ULL(i);
> > +                       didx++;
> > +               }
> > +       }
> 
> So here...
> 
> > +       if (copy_to_user(ip, &lv, sizeof(lv)))
> > +               return -EFAULT;
> > +
> > +       return 0;
> > +}
> 
> ...
> 
> > +       /* Make sure this is terminated */
> > +       ulr.consumer[sizeof(ulr.consumer)-1] = '\0';
> > +       if (strlen(ulr.consumer)) {
> > +               lr->label = kstrdup(ulr.consumer, GFP_KERNEL);
> > +               if (!lr->label) {
> > +                       ret = -ENOMEM;
> > +                       goto out_free_linereq;
> > +               }
> > +       }
> 
> Still don't get why we can\t use kstrndup() here...
> 

I know ;-).

Another one directly from v1, and the behaviour there is to leave
lr->label nulled if consumer is empty.
It just avoids a pointless malloc for the null terminator.

Cheers,
Kent.

  reply	other threads:[~2020-09-24  8:09 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  2:31 [PATCH v9 00/20] gpio: cdev: add uAPI v2 Kent Gibson
2020-09-22  2:31 ` [PATCH v9 01/20] gpiolib: cdev: gpio_desc_to_lineinfo() should set info offset Kent Gibson
2020-09-22  2:31 ` [PATCH v9 02/20] gpiolib: cdev: replace strncpy() with strscpy() Kent Gibson
2020-09-22  2:31 ` [PATCH v9 03/20] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes Kent Gibson
2020-09-22  2:31 ` [PATCH v9 04/20] gpio: uapi: define uAPI v2 Kent Gibson
2020-09-22  7:41   ` Arnd Bergmann
2020-09-22  9:50     ` Bartosz Golaszewski
2020-09-22 10:07       ` Kent Gibson
2020-09-28 13:42       ` strace decoding for GPIO uAPI Kent Gibson
2020-09-29 13:20         ` Bartosz Golaszewski
2020-09-29 15:04           ` Kent Gibson
2020-09-29 16:19           ` Andy Shevchenko
2020-09-23 10:04   ` [PATCH v9 04/20] gpio: uapi: define uAPI v2 Andy Shevchenko
2020-09-23 10:30     ` Kent Gibson
2020-09-23 11:16       ` Andy Shevchenko
2020-09-23 12:18         ` Arnd Bergmann
2020-09-23 15:15           ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 05/20] gpiolib: make cdev a build option Kent Gibson
2020-09-22  2:31 ` [PATCH v9 06/20] gpiolib: add build option for CDEV v1 ABI Kent Gibson
2020-09-22  2:31 ` [PATCH v9 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL Kent Gibson
2020-09-23 11:11   ` Andy Shevchenko
2020-09-24  8:09     ` Kent Gibson [this message]
2020-09-25 10:06       ` Andy Shevchenko
2020-09-26  9:16         ` Kent Gibson
2020-09-27  9:00           ` Andy Shevchenko
2020-09-27 12:39             ` Kent Gibson
2020-09-24 14:29     ` Bartosz Golaszewski
2020-09-22  2:31 ` [PATCH v9 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL Kent Gibson
2020-09-23 15:41   ` Andy Shevchenko
2020-09-24  2:39     ` Kent Gibson
2020-09-24  8:39       ` Andy Shevchenko
2020-09-24  9:48         ` Kent Gibson
2020-09-25 10:12           ` Andy Shevchenko
2020-09-25 11:56             ` Kent Gibson
2020-09-25 14:43               ` Andy Shevchenko
2020-09-25  5:32     ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 09/20] gpiolib: cdev: support edge detection for uAPI v2 Kent Gibson
2020-09-23 15:47   ` Andy Shevchenko
2020-09-24  3:07     ` Kent Gibson
2020-09-25  9:35       ` Andy Shevchenko
2020-09-25 12:26         ` Kent Gibson
2020-09-25 14:48           ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 10/20] gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL Kent Gibson
2020-09-23 16:14   ` Andy Shevchenko
2020-09-23 16:15     ` Andy Shevchenko
2020-09-24  3:24       ` Kent Gibson
2020-09-24  8:26         ` Andy Shevchenko
2020-09-24  9:26           ` Kent Gibson
2020-09-25  9:49             ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 11/20] gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL Kent Gibson
2020-09-23 16:18   ` Andy Shevchenko
2020-09-24  7:32     ` Kent Gibson
2020-09-24  8:21       ` Andy Shevchenko
2020-09-24  9:08         ` Kent Gibson
2020-09-24 12:46       ` Kent Gibson
2020-09-25  9:57         ` Andy Shevchenko
2020-09-25 12:16           ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 12/20] gpiolib: cdev: support setting debounce Kent Gibson
2020-09-23 16:27   ` Andy Shevchenko
2020-09-24  7:48     ` Kent Gibson
2020-09-25  9:43       ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 13/20] gpio: uapi: document uAPI v1 as deprecated Kent Gibson
2020-09-22  7:49   ` Arnd Bergmann
2020-09-22  8:11     ` Andy Shevchenko
2020-09-22  9:05     ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 14/20] tools: gpio: port lsgpio to v2 uAPI Kent Gibson
2020-09-22  2:31 ` [PATCH v9 15/20] tools: gpio: port gpio-watch " Kent Gibson
2020-09-22  2:31 ` [PATCH v9 16/20] tools: gpio: rename nlines to num_lines Kent Gibson
2020-09-22  2:31 ` [PATCH v9 17/20] tools: gpio: port gpio-hammer to v2 uAPI Kent Gibson
2020-09-23 16:30   ` Andy Shevchenko
2020-09-24  7:50     ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 18/20] tools: gpio: port gpio-event-mon " Kent Gibson
2020-09-22  2:31 ` [PATCH v9 19/20] tools: gpio: add multi-line monitoring to gpio-event-mon Kent Gibson
2020-09-22  2:31 ` [PATCH v9 20/20] tools: gpio: add debounce support " Kent Gibson
2020-09-23 16:35 ` [PATCH v9 00/20] gpio: cdev: add uAPI v2 Andy Shevchenko
2020-09-24  8:00   ` Kent Gibson
2020-09-25  9:44     ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200924080921.GE17562@sol \
    --to=warthog618@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).