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

On Thu, 2017-02-02 at 12:33 +0100, Rafael J. Wysocki wrote:

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

quoted

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@had
ess.
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?

I don't understand what you're asking of me. I'm not a git master, and
I've never had to deal with merge commits.

Did you want me to run "git reset --hard 3431e490b503" and test the
resulting kernel? I'm pretty sure that's equivalent what my 3 runs of
bisection have done, and it failed.

Cheers