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

[Alexandre Courbot <gnurou@xxxxxxxxx>]

On Thu, Feb 19, 2015 at 5:53 PM, folkert <folkert@xxxxxxxxxxxxxx> wrote:
>> >> >> 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
>>
>> I think this looks plausible.
>> Folkert what do you say about this?
>
> That looks indeed to be the current situation. It worked different
> before though.
>
> I also think that this interface is cumbersome. I did not measure it(!)
> but I think adding this open/seek + read construction may add all kinds
> of overhead. Especially since my use-case requires the lowest latency
> possible. Not to forget that conversion of the measured value to ascii
> and back.

Folkert, since you have code that can reproduce the issue, could you
see whether you could come with a patch that restores the original
behavior? Maybe by introducing a in-kernel lseek() as soon as the file
is opened?
--
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