Le 15/01/2020 à 17:18, Arnd Bergmann a écrit : > On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta <filip.boz...@rt-rk.com> wrote: >> >> This patch implements functionality of following ioctl: >> >> SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read >> >> Sets enhanced time read which is used for reading time with timestamps >> and events. The third ioctl's argument is a pointer to an 'int'. Enhanced >> reading is set if the third argument is different than 0, otherwise >> normal >> time reading is set. >> >> Implementation notes: >> >> Because the implemented ioctl has 'int' as its third argument, the >> implementation was straightforward. >> >> Signed-off-by: Filip Bozuta <filip.boz...@rt-rk.com> > > I think this one is wrong when you go between 32-bit and 64-bit
kernel uses an "int" and "int" is always 32bit. The problem is most likely with timespec I think. > targets, and it gets worse with the kernel patches that just got > merged for linux-5.5, which extends the behavior to deal with > 64-bit time_t on 32-bit architectures. > > Please have a look at > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=80fe7430c70859 > > Arnd > Yes, we already had the same kind of problem with SIOCGSTAMP and SIOCGSTAMPNS. Do the kernel patches add new ioctl numbers to differentiate 32bit and 64bit time_t? Thanks, Laurent
