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;
Date:   Tue, 18 Aug 2020 22:00:02 +0800
From:   Kent Gibson <warthog618@gmail.com>
To:     Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        linux-gpio <linux-gpio@vger.kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v4 09/20] gpiolib: cdev: support edge detection for uAPI
 v2
Message-ID: <20200818140002.GA17809@sol>
References: <20200814030257.135463-1-warthog618@gmail.com>
 <20200814030257.135463-10-warthog618@gmail.com>
 <CAMpxmJVeAKpNnX0HXSNSLYqX6T+qxun8ppZ7EwzFb3WsS=nanw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMpxmJVeAKpNnX0HXSNSLYqX6T+qxun8ppZ7EwzFb3WsS=nanw@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Aug 16, 2020 at 04:32:34PM +0200, Bartosz Golaszewski wrote:
> On Fri, Aug 14, 2020 at 5:04 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > Add support for edge detection to lines requested using
> > GPIO_V2_GET_LINE_IOCTL.
> >
[snip]

> >
> > +       /* event_buffer_size only valid with edge detection */
> > +       has_edge_detection = gpio_v2_line_config_has_edge_detection(lc);
> > +       if (lr.event_buffer_size && !has_edge_detection)
> > +               return -EINVAL;
> > +
> >         line = kzalloc(struct_size(line, descs, lr.num_lines),
> >                        GFP_KERNEL);
> >         if (!line)
> > @@ -666,6 +944,16 @@ static int line_create(struct gpio_device *gdev, void __user *ip)
> >         line->gdev = gdev;
> >         get_device(&gdev->dev);
> >
> > +       line->edets = kcalloc(lr.num_lines, sizeof(*line->edets),
> > +                             GFP_KERNEL);
> 
> You're allocating num_lines of edge detectors even if only certain
> lines have edge detection (via attributes). I don't like it but it
> made me think about struct line. How about having struct line which
> actually only represents a single line (and it contains the relevant
> gpio_desc pointer as well as the associated edge detector and any
> other data only relevant for this line) and a set of lines would be
> aggregated in struct line_request or line_request_data which would
> additionally contain common fields? Does that even make sense?
> 

You are right, and it makes total sense.

I'm not totally thrilled with the block allocation either, but an
earlier draft with edge detectors/debouncers created and destroyed as
required resulted in complicated lifecycle management that this approach
avoids.

I'll have a look at restructuring it as you suggest.
The only downside that springs to mind is that the gpiolib API expects
a desc array, which we'll no longer have handy, so it would have to be
built on the fly as per the sparse gets/sets.

Cheers,
Kent.