Re: Fw: [3.18.3] poll() on gpio pins broken

[Michael Welling <mwelling@xxxxxxxx>]

On Sat, Jan 31, 2015 at 02:39:03PM +0100, Alexandre Courbot wrote:
> On Sat, Jan 31, 2015 at 9:33 AM, folkert <folkert@xxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html