All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [RESEND] [media] omap3isp: support 64-bit version of omap3isp_stat_data
Date: Thu, 3 May 2018 18:06:58 -0400	[thread overview]
Message-ID: <CAK8P3a0M5iKCXmKwQAzd9EKWo7Sr_0OR82Q=ozmj3f3Xtyde6A@mail.gmail.com> (raw)
In-Reply-To: <20180503125627.6elsr4iiknnv227c@valkosipuli.retiisi.org.uk>

On Thu, May 3, 2018 at 8:56 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> On Wed, Apr 25, 2018 at 11:30:10PM +0200, Arnd Bergmann wrote:
>> @@ -165,7 +167,14 @@ struct omap3isp_h3a_aewb_config {
>>   * @config_counter: Number of the configuration associated with the data.
>>   */
>>  struct omap3isp_stat_data {
>> +#ifdef __KERNEL__
>> +     struct {
>> +             __s64   tv_sec;
>> +             __s64   tv_usec;
>
> Any particular reason for __s64 here instead of e.g. long or __s32? Kernel
> appears to use long in the timespec64 definition.

The user space 'timeval' definition is 16 bytes wide, with the layout
designed to be compatible between 32-bit and 64-bit, so it has to be like
this to match what user spaces sees with the old header files and a new
libc.

We don't yet know what the exact definition of timeval will be in all
libc implementations, but if they have a 32-bit tv_user field, it needs
padding next to it so the lower 32 bits are in the same place as they
would be using that 64-bit field I used.

         Arnd

  reply	other threads:[~2018-05-03 22:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 21:30 [PATCH] [RESEND] [media] omap3isp: support 64-bit version of omap3isp_stat_data Arnd Bergmann
2018-05-03 12:56 ` Sakari Ailus
2018-05-03 22:06   ` Arnd Bergmann [this message]
2018-05-07 10:18     ` Sakari Ailus
2018-05-07 13:17 ` Laurent Pinchart
2018-05-07 13:19   ` Sakari Ailus
2018-05-07 20:36     ` Arnd Bergmann
2018-05-07 21:33       ` Sakari Ailus
2018-05-08  0:08         ` Arnd Bergmann

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='CAK8P3a0M5iKCXmKwQAzd9EKWo7Sr_0OR82Q=ozmj3f3Xtyde6A@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sakari.ailus@iki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.