From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Kent Gibson <warthog618@gmail.com>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Linus Walleij <linus.walleij@linaro.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v1 1/2] gpiolib: Fix line event handling in compatible mode
Date: Wed, 11 Dec 2019 10:18:39 +0100 [thread overview]
Message-ID: <CAMpxmJVMW=3k2odB9UKEzeopZ0q7T48Cux6ux=1j72Hv5A4yOQ@mail.gmail.com> (raw)
In-Reply-To: <20191210165548.GY32742@smile.fi.intel.com>
wt., 10 gru 2019 o 17:55 Andy Shevchenko
<andriy.shevchenko@linux.intel.com> napisał(a):
>
> > For Go the structs are aligned based on the size of their components so
> > that arrays of struct are naturally aligned. The struct is given a
> > hidden trailing pad so that a subsequent struct will be correctly aligned.
> > The sizeof the struct includes this hidden pad.
> > I'm pretty sure the same is true for gcc.
> >
> > The gpioevent_data contains a __u64 which causes the whole struct to be
> > 64 bit aligned on 64 bit, so it actually looks like this internally:
> >
> > struct gpioevent_data {
> > __u64 timestamp;
> > __u32 id;
> > __u32 pad; // hidden
> > };
> >
> > so 16 bytes.
> >
> > On 32 bit the struct is 32 bit aligned and the trailing pad is missing,
> > so 12 bytes. This causes grief for the read due to the size mismatch.
>
> Exactly.
>
> > (I'm sorry to say I had to add the pad to my Go gpiod library to get it
> > to read event data - but forgot to go back later and work out why -
> > until now :-()
> >
> > Your new info change struct has the same problem, as it also contains a
> > __u64 and ends up with an odd number of __u32s, so gets a trailing pad
> > on 64 bit. Using __packed seems to inhibit the trailing pad.
> > Or you could explicitly add the pad so the struct will be 64bit aligned
> > even on 32bit.
>
> I spoke to colleague of mine and has been told that best option is to fill all
> gaps explicitly to have all members in the struct + 8 bytes alignment at the
> end (also with explicit member).
>
> > Neither of those options are available for the
> > gpioevent_data, as that would break the ABI.
>
> ABI needs v2 actually.
>
I finally sat down to integrate this with my series and figured that
this can't go on top of it. It's a bug-fix actually and maybe even
stable material.
On the other hand - if we have so few users of GPIO chardev with
32-bit user-space and 64-bit kernel - maybe we should just bite the
bullet, not fix this one, deprecate it and introduce a proper v2 of
the API?
Bart
next prev parent reply other threads:[~2019-12-11 9:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-04 19:42 [PATCH v1 1/2] gpiolib: Fix line event handling in compatible mode Andy Shevchenko
2019-12-04 19:42 ` [PATCH v1 2/2] gpiolib: Make use of assign_bit() API Andy Shevchenko
2019-12-13 10:03 ` Linus Walleij
2019-12-06 10:57 ` [PATCH v1 1/2] gpiolib: Fix line event handling in compatible mode Bartosz Golaszewski
2019-12-10 9:06 ` Bartosz Golaszewski
2019-12-10 13:44 ` Andy Shevchenko
2019-12-10 14:39 ` Kent Gibson
2019-12-10 16:55 ` Andy Shevchenko
2019-12-11 9:18 ` Bartosz Golaszewski [this message]
2019-12-11 9:29 ` Kent Gibson
2019-12-11 10:47 ` Andy Shevchenko
2019-12-11 13:15 ` Bartosz Golaszewski
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='CAMpxmJVMW=3k2odB9UKEzeopZ0q7T48Cux6ux=1j72Hv5A4yOQ@mail.gmail.com' \
--to=bgolaszewski@baylibre.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=warthog618@gmail.com \
/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).