Hi Viresh, On 1/20/21 11:14 PM, Frank Rowand wrote: > 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. It should be possible to apply this same concept to copying overlay_base.dts to overlay_base_base.dts, removing the "/plugin/;" from overlay_base_base.dts and using an additional rule to use fdtoverlay to apply overlay.dtb on top of overlay_base_base.dtb. Yes, overlay_base_base is a terrible name. Just used to illustrate the point. I tried this by hand and am failing miserably. But I am not using the proper environment (just a quick hack to see if the method might work). So I would have to set things up properly to really test this. If this does work, it would remove my objections to you trying to transform the existing unittest .dts test data files (because you would not have to actually modify the existing .dts files). > > -Frank >
