[PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux