The issue reported is a particular case of a BC configured with
redundant PTP clocks with same priority. When a clock recovers
from a failure, as both clock were configured with same priority
it's expected the active clock source to remain active. But if
the recovered clock presented a better local clock class than
active, it was being selected active. This specific case was fixed.
Closes-bug: 2084723
Test plan: BC with same priority
PASS: Start the PTP service with all clocks out of requirements,
one is selected, no matter which one.
PASS: Then, when the backup clock recovers from failure it is
selected active.
PASS: Then, when the other clock recovers from failure it remains
as backup, no matter the local clock class.
PASS: Then, when the active goes out of requirement, the backup
is set active.
Test plan: GM with same priority
PASS: Start the PTP service with all clocks out of requirements,
one is selected, no matter which one.
PASS: Then, when the backup clock recovers from failure it is selected
active.
PASS: Then, when the other clock recovers from failure it remains
as backup, no matter the local clock class.
PASS: Then, when the active goes out of requirement, the backup
is set active.
Change-Id: Id2568bc8bbaad4cbf15070314f7904d3c3bbd53d
Signed-off-by: Andre Mauricio Zelak <andre.zelak@windriver.com>
06c396fbe3