For the whole series Reviewed-by: Lyude <ly...@redhat.com>
will push in just a sec On Tue, 2017-07-18 at 18:16 +0300, Paul Kocialkowski wrote: > This patch introduces a workaround for a case where a uevent is > issued > by the kernel because of DP link training failing on a connector > unrelated to the current test. Since the test depends on receiving a > hotplug uevent, it previously passed even though it should not have. > > False positives also occur due to the plug/unplug events being > delayed > and issued at resume time. This is mitigated by catching and flushing > hotplugs everytime a change is made on connectors, but it is not > enough > to ensure that all hotplug events were caught and not delayed. > > The problem here is that it is not possible to find out the exact > reason > why a uevent is issued by the kernel. A possible way to fix this > would > be to introduce more fields (the connector name and some reason why > the > event is triggered would probably be sufficient). > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Cheers, Lyude _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx