Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191219171528.6348-1-brgl@bgdev.pl> <20191219171528.6348-13-brgl@bgdev.pl>
 <CAHp75VeMEngXiFmvTrsW7UZMz0ppR-W-J4D1xU+qKGfLXkG3kg@mail.gmail.com>
 <CAMpxmJV4UU21x8rfNMaJ6G2OiRa3qC2vYQWH4C_T+nS4b_NcUw@mail.gmail.com>
 <20191220121543.GY32742@smile.fi.intel.com> <CAMpxmJWPmhqadKcd6b62fScAs5N1TRtoXBq+5MPtC0Q=-p3ALg@mail.gmail.com>
In-Reply-To: <CAMpxmJWPmhqadKcd6b62fScAs5N1TRtoXBq+5MPtC0Q=-p3ALg@mail.gmail.com>
From:   Bartosz Golaszewski <brgl@bgdev.pl>
Date:   Tue, 24 Dec 2019 13:09:41 +0100
Message-ID: <CAMRc=MdECHQQ-i0dZVp_1g8H6P+vjxg1HSCmkN5ySw+8p3W0Dw@mail.gmail.com>
Subject: Re: [PATCH v3 12/13] gpiolib: add new ioctl() for monitoring changes
 in line info
To:     Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Kent Gibson <warthog618@gmail.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

pt., 20 gru 2019 o 18:29 Bartosz Golaszewski
<bgolaszewski@baylibre.com> napisa=C5=82(a):
>
> > > struct gpioline_info alone is 32-bit aligned but its size is 72 bytes
> > > which works for 64-bit alignment. This new structure's biggest elemen=
t
> > > in 64-bit, so it's 64-bit aligned on 64-bit arch. We have 72 bytes of
> > > gpioline_info, 8 bytes of timestamp, 32 bytes of event type and 5 * 3=
2
> > > bytes of padding. Should be fine, but I'll add comments to the header=
.
> >
> > Yes, what I meant is to add comment at least to struct gpioline_info de=
finition
> > that if somebody would like to change it there (which also might be a
> > problematic here, if there is no versioning scheme / length member).
> >
> > > > > +       __u64 timestamp;
> > > > > +       __u32 event_type;
> > > > > +       __u32 padding[5]; /* for future use */
> > > > > +};
> >
> > Offtopic a bit, had you had a chance to look at Buildroot and our scrip=
ts
> > I shared?
> >
>
> Not yet, I'll do that over the weekend.

Now tested using the buildroot image you posted. Thanks for that, I'll
make sure to use it to test the v2 API for lineevents.

Bart