Merge #434759 from ~baconyao/checkbox-iiotg/+git/checkbox-provider-intliotg:fix-ishtp
Fix: Refactor the ISHTP test cases
According to the answer from Intel in LP#1979735, I refactor the ISHTP
cases.
1. Remove the ishtp/is-support job and adjust the dependency.
2. For EHL deivce which supports the Eclite feature, add eclite
cases and has_eclite manifest.
3. For other devices which unsopport the the Eclite, just check the
ishtp modules be loaded is enough.
4. Modify the ishtp path of job "ishtp/device-detect" from iio to
ishtp. Once the ishtp modules are loaded, the path /sys/bus/ishtp
will exist and there should have at least one node under devices
directory.
According to the answer from Intel in LP#1979735, I refactor the ISHTP
cases.
1. Remove the ishtp/is-support job and adjust the dependency.
2. For EHL deivce which supports the Eclite feature, add eclite
cases and has_eclite manifest.
3. For other devices which unsopport the the Eclite, just check the
ishtp modules be loaded is enough.
4. Modify the ishtp path of job "ishtp/device-detect" from iio to
ishtp. Once the ishtp modules are loaded, the path /sys/bus/ishtp
will exist and there should have at least one node under devices
directory.
Merge #434914 from ~baconyao/checkbox-iiotg/+git/checkbox-provider-intliotg:fix-watchdog
Change: Redesign the watchdog test plan
Redesign the watchdog test plan in order to cover the more generic
scenario, therefore, I exclude all of the genereic watchdog cases and
use the new designed flow.
For an image, there are four combinations based on the source and
type. There are two sources, stock and oem, and two types, classic
and core.
The differences between stock and oem image is the value of
RuntimeWatchdogSec is 0 in stock but should not be 0 in oem image.
For stock classic image, we have to probe the module of watchdog by
ourself via the WATCHDOG_TYPE variable in config. As for core image,
the module is loaded automatically, however, we still need to check
its identity because it might be the wrong moudle if the BIOS setting
is wrong.
The following files are migrating from generic checkbox, so no need to be reviewed
- failed_service_check.sh
- for watchdog/general/post-trigger-system-reset-auto only
- udev_resource.py
- for watchdog/general/detect
- I keep the original logic of watchdog/detect for project image
Redesign the watchdog test plan in order to cover the more generic
scenario, therefore, I exclude all of the genereic watchdog cases and
use the new designed flow.
For an image, there are four combinations based on the source and
type. There are two sources, stock and oem, and two types, classic
and core.
The differences between stock and oem image is the value of
RuntimeWatchdogSec is 0 in stock but should not be 0 in oem image.
For stock classic image, we have to probe the module of watchdog by
ourself via the WATCHDOG_TYPE variable in config. As for core image,
the module is loaded automatically, however, we still need to check
its identity because it might be the wrong moudle if the BIOS setting
is wrong.
The following files are migrating from generic checkbox, so no need to be reviewed
- failed_service_check.sh
- for watchdog/general/post-trigger-system-reset-auto only
- udev_resource.py
- for watchdog/general/detect
- I keep the origianl logic of watchdog/detect for project image
