auto Physical::state(Action value) -> Action
{
auto current =
sdbusplus::xyz::openbmc_project::Led::server::Physical::state();
if lamp_test_in_progress
{
auto requested =
sdbusplus::xyz::openbmc_project::Led::server::Physical::state(value,true);
// Note "true" for skip signal
}
else
{
auto requested =
sdbusplus::xyz::openbmc_project::Led::server::Physical::state(value);
// Default "false"
}
driveLED(current, requested);
return value;
}
========
if lamp_test_in_progress --> That is something to be determined. Mostly, it is a D-Bus object that is indicating the lamp test is in progress.
If doing this is too much for each LED, we can have some kind of listener for the lamp test and set an internal state that can then be used by all objects
Hmm.. This still exposes an issue where we need to send the status of Enclosure LED that gets litup by other actions apart from lamp test. So, need to come up with something else..
Since LampTest is a diagnostic tool, we should not report PropertyChanged signal , which would be confused for a real failure.
So the solution is to use the "skipSignal" feature that is in the interface implementation.
For example: https://github.com/openbmc/phosphor-led-sysfs/blob/master/physical.cpp#L60
auto Physical::state(Action value) -> Action { auto current = sdbusplus::xyz::openbmc_project::Led::server::Physical::state();
if lamp_test_in_progress { auto requested = sdbusplus::xyz::openbmc_project::Led::server::Physical::state(value,true); // Note "true" for skip signal } else { auto requested = sdbusplus::xyz::openbmc_project::Led::server::Physical::state(value); // Default "false" }
}
========
if lamp_test_in_progress --> That is something to be determined. Mostly, it is a D-Bus object that is indicating the lamp test is in progress.
If doing this is too much for each LED, we can have some kind of listener for the lamp test and set an internal state that can then be used by all objects