Hi David,
On 1/20/21 6:51 PM, David Gibson wrote:
> On Wed, Jan 20, 2021 at 12:36:47PM +0530, Viresh Kumar wrote:
>> Now that fdtoverlay is part of the kernel build, start using it to test
>> the unitest overlays we have by applying them statically.
>>
>> Some unittest overlays deliberately contain errors that unittest checks
>> for. These overlays will cause fdtoverlay to fail, and are thus not
>> included in the static_test.dtb.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
>> ---
>> drivers/of/unittest-data/Makefile | 50 +++++++++++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
>> index 009f4045c8e4..ece7dfd5cafa 100644
>> --- a/drivers/of/unittest-data/Makefile
>> +++ b/drivers/of/unittest-data/Makefile
>> @@ -38,3 +38,53 @@ DTC_FLAGS_testcases += -@
>>
>> # suppress warnings about intentional errors
>> DTC_FLAGS_testcases += -Wno-interrupts_property
>> +
>> +# Apply overlays statically with fdtoverlay. This is a build time test that
>> +# the overlays can be applied successfully by fdtoverlay. This does not
>> +# guarantee that the overlays can be applied successfully at run time by
>> +# unittest, but it provides a bit of build time test coverage for those
>> +# who do not execute unittest.
>> +#
>> +# The overlays are applied on top of testcases.dtb to create static_test.dtb
>> +# If fdtoverlay detects an error than the kernel build will fail.
>> +# static_test.dtb is not consumed by unittest.
>> +#
>> +# Some unittest overlays deliberately contain errors that unittest checks for.
>> +# These overlays will cause fdtoverlay to fail, and are thus not included
>> +# in the static test:
>> +# overlay.dtb \
>> +# overlay_bad_add_dup_node.dtb \
>> +# overlay_bad_add_dup_prop.dtb \
>> +# overlay_bad_phandle.dtb \
>> +# overlay_bad_symbol.dtb \
>> +# overlay_base.dtb \
>> +
>> +apply_static_overlay := overlay_0.dtb \
>> + overlay_1.dtb \
>> + overlay_2.dtb \
>> + overlay_3.dtb \
>> + overlay_4.dtb \
>> + overlay_5.dtb \
>> + overlay_6.dtb \
>> + overlay_7.dtb \
>> + overlay_8.dtb \
>> + overlay_9.dtb \
>> + overlay_10.dtb \
>> + overlay_11.dtb \
>> + overlay_12.dtb \
>> + overlay_13.dtb \
>> + overlay_15.dtb \
>> + overlay_gpio_01.dtb \
>> + overlay_gpio_02a.dtb \
>> + overlay_gpio_02b.dtb \
>> + overlay_gpio_03.dtb \
>> + overlay_gpio_04a.dtb \
>> + overlay_gpio_04b.dtb
>> +
>> +quiet_cmd_fdtoverlay = FDTOVERLAY $@
>> + cmd_fdtoverlay = $(objtree)/scripts/dtc/fdtoverlay -o $@ -i $^
>> +
>> +$(obj)/static_test.dtb: $(obj)/testcases.dtb $(addprefix $(obj)/,$(apply_static_overlay))
>> + $(call if_changed,fdtoverlay)
>> +
>> +always-$(CONFIG_OF_OVERLAY) += static_test.dtb
>
> The fact that testcases.dts includes /plugin/ still seems completely
> wrong, if it's being used as the base tree.
>
Yes, the build rule for static_test.dtb is using testcases.dtb as the base FDT.
It is a convenient FDT to use because it provides the frame that the overlays
require to be applied. It is fortunate that fdtoverlay does not reject the use
of an FDT with overlay metadata as the base blob.
If Viresh wants to test a more realistic data set then he could create a build
rule that copies testcases.dts into (for example) testcases_base.dts, strip
out the '/plugin/;" then compile that into testcases_base.dtb and use that for
fdtoverlay.
pseudo makefile rule for testcases_base.dts:
sed -e 's|/plugin/;||' > testcases_base.dts
add testcases_base.dtb to the list of objects to build
change the rule for static_test.dtb to use testcases_base.dtb instead of
testcases.dtb
This is probably a good idea instead of depending on the leniency of fdtoverlay.
-Frank
