Re: Why hid-sensor-hub's IIO doesn't work properly in >= 4.3 (possibly badly bisected)

On Thursday, February 02, 2017 11:35:05 AM Bastien Nocera wrote:

On Wed, 2017-02-01 at 15:57 -0800, Srinivas Pandruvada wrote:

quoted

On Thu, 2017-02-02 at 00:38 +0100, Rafael J. Wysocki wrote:

quoted

+ Srinivas

On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote:

quoted

Hey Rafael,

On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote:

quoted

On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@hadess.
ne
t>
wrote:

quoted

On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote:

quoted

Hey,

TLDR:
# first bad commit:
[50ba22479c324c0d9dc8134d519dcba92d83a8a7]
Merge
back earlier ACPI PM material for v4.3.

hid-sensor-hub devices only start sending events through
the
IIO
trigger after a suspend/resume cycle.

quoted

Srinivas, does it sound like anything familiar to you?

I guess this is related to
https://github.com/hadess/iio-sensor-proxy/issues/82

There is some race between user space and iio. So the driver powerup
never gets called back to power a hub during system boot. So the
workaround was to add to systemd unit file for iio-sensor-proxy 
[Unit]
After=multi-user.target

Something changed timings in the kernel, which triggered this issue.

I don't think it's simply "timings", or at least it's a big enough
window of opportunity that I can reproduce the bug 100% of the time
when not adding timeouts to iio-sensor-proxy's timeout.

Putting the machine on suspend and resuming it also fixes the problem
(for a machine I've been testing that can be suspended, it's not an
option for all of them).

quoted

I never got chance to root cause this.

Well, at least the root cause is limited to a single commit, shame it's
a merge one.

In fact this is a merge that doesn't change any code by itself (I thought it
did, but that was not correct), so if that had been more than timings, you'd
have seen breakage on at least one of the merged branches.

Moreover, it merges the commits under 3431e490b503 back on top of material
that went into 4.2, so if you only see the problem in 4.3 and later, this has to
be the 3431e490b503 branch.

Can you double check 3431e490b503 alone, please?

Thanks,
Rafael