Received: by 10.192.165.148 with SMTP id m20csp2264222imm; Thu, 26 Apr 2018 08:16:34 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpBlazVkaSYKFuI5GphjPM7xVA7xHAlOGgZrDywn4Rqm1DVypyQOpJdchMeukUtMtpZDO1/ X-Received: by 2002:a17:902:6549:: with SMTP id d9-v6mr3522400pln.196.1524755794447; Thu, 26 Apr 2018 08:16:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524755794; cv=none; d=google.com; s=arc-20160816; b=OoU3cYPqtt6a48tn/tAkqZHDto7LiYKjbkUuKENWMZzoCX79uyX7jYKCm3AFNqGhyw 7ucHs+RCQobmQy+mxqA+UZMQvGANCe5Z1j7TGBnS53lhQ1fIcTgmJhg9a6njT+m/SkxU OjimZ4+TGuHch4j/drC1ZizeTfdMrDuazMcsnQ3R5/jE9DKGC+TPZYHoP5hIwgLCqvuc XD/fiEwbmwmHUn4WiL6GhqOLt4FU7L5PQmZ6wMe5Ls2Kk5GuMKoMOB2u+XO+Xt4Uy4FX kYKxie3P6mySulMEJUFiotYslmk3F61a+QvhuKymUJ3zX+zZOR/P+96zVJfGMkxkcKTV Y4VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=JxECd+M+V4mEqnlw9zbp4+eZenEaaxrbfsLhlCE/mkc=; b=FU89ldTjGrPOfLJSvfazU16ZJWV0Wy+Ox3l7SYzGgmBT+/YykOyP7yOoj54lSIEq2B aAqKGTWfGjGZtBrvmR3riCilYaQrK1cD28Q27P1hLjPKsUMOqtrCWt30XZP9MC4EXdH+ lIdfMe1HMr6i0u00Jb8xnyPOOUZpoxzTer6HnyjEGxV2ybDsAxPUDJU9cn8Z7DlxU6Y4 5V2x9Gji64fsnqk081L4bf3hrA4EvTaViofZppc1riq33DgaIVgnQJxlDJjg0Bepk7zU uryHDTThdmmJeg6BzuL8FreRDxoF5xqPe9kJS5gHLWLGnqs7ONlsh4xHqncfvoiMlyOn RjVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ZqBi8WrP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si12455663pfe.79.2018.04.26.08.16.19; Thu, 26 Apr 2018 08:16:34 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ZqBi8WrP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756593AbeDZPPC (ORCPT + 99 others); Thu, 26 Apr 2018 11:15:02 -0400 Received: from mail-qt0-f193.google.com ([209.85.216.193]:34633 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755698AbeDZPPB (ORCPT ); Thu, 26 Apr 2018 11:15:01 -0400 Received: by mail-qt0-f193.google.com with SMTP id m5-v6so2569962qti.1 for ; Thu, 26 Apr 2018 08:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JxECd+M+V4mEqnlw9zbp4+eZenEaaxrbfsLhlCE/mkc=; b=ZqBi8WrPXSHGODo0pST+5Pf8wpx+ATge74ulamugv8mkygUl7mf8R8IBNoXMRDMdh+ pbUb8NErLpRtPDTaP8Nwyqm70z3Iz2AdHkZzlCfcps5vlwyGkkAl/2bun920bp2Yqo/7 +6xk9xzhoemZ8xI4Fpcfe4AFrr4KoGxn+VTfIkSSngiGwpjdbZnaP21yyEKgEukyPX/J X/gkBX4Bg0hmPpHyuMceU84rUzF8hbH/VPmhEznKdBIOxvoZ4TQyQceXms9ualmRChRx nC1SU/4dfmKp75IM4U9XDHExoDTBOFDcyWfKwNPzc9jfe9cFQ8eWQiBguwvtMn4Y+e4H Ecbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JxECd+M+V4mEqnlw9zbp4+eZenEaaxrbfsLhlCE/mkc=; b=sFksmpDdxro4tZwDqlcR5ZS728DsXRj3m8zz+mRK8iEtRkcNPNX7yO0rgZRMBn4/sI Y0xf3sDTmYk9kVS2fl+sYuKlD9q0p3VQuwXUV9gsI8B17k583Aalf6+BcCO7iUl81crL XSZHOGU+B//V3wjH0ZtiRSKYMxKmfnUjrDiOXhpExz/viPzP0IiAS4qfZooR9NANKtzQ Rb8jguZXIa1Uq+3XAinSVMWvY8Xfz7xBdvqw9zBUVSXxUrLtV4tFBY+v19/RdLQymIiH EP4Zt5RoAbgkD03C1ad2fJfvgNIVxYHX3zp3otIPhLhu1KmnQ8hYH5s4Xt/Rmg9lYH01 4rHw== X-Gm-Message-State: ALQs6tAxzMDEARmRs9jR8xQQqSMeaqVPMNMoxoVVq1Z9u6kSfQOEteOC wZhwAk5j+Cq/55+FkCkLYpkJMuLQ6M/1IQDu8Wg= X-Received: by 2002:ac8:546:: with SMTP id c6-v6mr37184193qth.163.1524755700247; Thu, 26 Apr 2018 08:15:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.3 with HTTP; Thu, 26 Apr 2018 08:14:59 -0700 (PDT) In-Reply-To: References: From: Arnd Bergmann Date: Thu, 26 Apr 2018 17:14:59 +0200 X-Google-Sender-Auth: nYo1NyvbATjaLowW7b_gg9sdGaU Message-ID: Subject: Re: [PATCH 8/8] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control To: Baolin Wang Cc: Jaroslav Kysela , Takashi Iwai , Liam Girdwood , Mark Brown , Takashi Sakamoto , Ingo Molnar , SF Markus Elfring , Dan Carpenter , jeeja.kp@intel.com, Vinod Koul , Guneshwor Singh , subhransu.s.prusty@intel.com, Bhumika Goyal , gudishax.kranthikumar@intel.com, Naveen M , hardik.t.shah@intel.com, Arvind Yadav , Fabian Frederick , alsa-devel@alsa-project.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 24, 2018 at 2:06 PM, Baolin Wang wrote: > -struct snd_pcm_mmap_status { > +/* > + * For mmap operations, we need the 64-bit layout, both for compat mode, > + * and for y2038 compatibility. For 64-bit applications, the two definitions > + * are identical, so we keep the traditional version. > + */ > +#ifdef __SND_STRUCT_TIME64 > +#define __snd_pcm_mmap_status64 snd_pcm_mmap_status > +#define __snd_pcm_mmap_control64 snd_pcm_mmap_control > +#define __snd_pcm_sync_ptr64 snd_pcm_sync_ptr > +#else > +#define __snd_pcm_mmap_status snd_pcm_mmap_status > +#define __snd_pcm_mmap_control snd_pcm_mmap_control > +#define __snd_pcm_sync_ptr snd_pcm_sync_ptr > +#endif > + > +struct __snd_pcm_mmap_status { > snd_pcm_state_t state; /* RO: state - SNDRV_PCM_STATE_XXXX */ > int pad1; /* Needed for 64 bit alignment */ > snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */ One more thing here: this definition is slightly suboptimal because in an alsa-lib that gets built with 64-bit time_t, we end up with an unusable __snd_pcm_mmap_status structure (__snd_pcm_mmap_status64 works fine, and that would be the normal thing to use). Just in case we want to be able to build an alsa-lib that is capable of running both on new kernels with 64-bit time_t interfaces exposed to applications and also on old kernels that don't have the new ioctls, we probably want another fixup merged in: diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h index 18fbdcb2c7b6..638c717d3eb9 100644 --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -496,19 +496,30 @@ struct snd_pcm_status { #define __snd_pcm_mmap_status64 snd_pcm_mmap_status #define __snd_pcm_mmap_control64 snd_pcm_mmap_control #define __snd_pcm_sync_ptr64 snd_pcm_sync_ptr +#define __snd_timespec64 timespec +struct __snd_timespec { + __s32 tv_sec; + __s32 tv_nsec; +}; #else #define __snd_pcm_mmap_status snd_pcm_mmap_status #define __snd_pcm_mmap_control snd_pcm_mmap_control #define __snd_pcm_sync_ptr snd_pcm_sync_ptr +#define __snd_timespec timespec +struct __snd_timespec64 { + __s64 tv_sec; + __s64 tv_nsec; +}; + #endif struct __snd_pcm_mmap_status { snd_pcm_state_t state; /* RO: state - SNDRV_PCM_STATE_XXXX */ int pad1; /* Needed for 64 bit alignment */ snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */ - struct timespec tstamp; /* Timestamp */ + struct __snd_timespec tstamp; /* Timestamp */ snd_pcm_state_t suspended_state; /* RO: suspended stream state */ - struct timespec audio_tstamp; /* from sample counter or wall clock */ + struct __snd_timespec audio_tstamp; /* from sample counter or wall clock */ }; struct __snd_pcm_mmap_control { @@ -532,11 +543,6 @@ struct __snd_pcm_sync_ptr { } c; }; -struct __snd_timespec64 { - __s64 tv_sec; - __s64 tv_nsec; -}; - #if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN) typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)]; typedef char __pad_after_uframe[0]; With this change, alsa-lib can either access whichever structure matches the glibc 'timespec' definition, or it can ask for __struct __snd_pcm_mmap_status and struct __snd_pcm_mmap_status64 explicitly, regardless of the time_t definition. Arnd