On Sat, Jan 31, 2015 at 02:39:03PM +0100, Alexandre Courbot wrote: > On Sat, Jan 31, 2015 at 9:33 AM, folkert <[email protected]> wrote: > > Michael, > > > >> > For timekeeping I wrote a program which waits for interrupts on > >> > gpio-pins and then tells the local ntp daemon the clock offset. > >> > I'm aware of the pps support in recent kernel but that does not work > >> > (yet) on all platforms (eg cubieboard 1). > >> > > >> > This has worked for quite some time but no longer. > >> > > >> > Until at least kernel 3.12 I could do: > >> > > >> > // export gpio pin > >> > // set direction to in > >> > // set direction to rising > >> > int fd = open("/sys.../value", O_RDONLY); > >> > fdset[0].fd = fd; > >> > fdset[0].events = POLLPRI; > >> > fdset[0].revents = 0; > >> > poll(fdset, 1, -1); > >> > // at this point pin went high > >> > >> Try using lseek before reading the data after the poll. > >> > >> EX. > >> if (fdset[0].revents & POLLPRI) { > >> lseek(fdset[0].fd, 0, SEEK_SET); > >> len = read(fdset[0].fd, buf, MAX_BUF); > >> . > >> . > >> } > >> > >> See if this helps. > > > > Yes, that fixed it! > > Still, shouldn't we consider this as a regression, especially if not > using lseek worked for kernel 3.12 and before?
Perhaps this is a side effect of the sysfs to kernfs change over to happened in 3.14. Looking at 'kernfs_fop_poll' my guess is that 'kernfs_get_active' is returning NULL immediately returning from the poll command and causing described behavior. http://lxr.free-electrons.com/source/fs/kernfs/file.c#L763 > > Linus, what do you think? -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
