kernel.git/drivers/of/unittest-data, branch linux-5.8.y

of: unittest: kmemleak in duplicate property update

2020-04-17T13:31:34Z

kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 5 of 5. When overlay 'overlay_bad_add_dup_prop' is applied, the apply code properly detects that a memory leak will occur if the overlay is removed since the duplicate property is located in a base devicetree node and reports via printk(): OF: overlay: WARNING: memory leak will occur if overlay removed, property: /testcase-data-2/substation@100/motor-1/rpm_avail OF: overlay: WARNING: memory leak will occur if overlay removed, property: /testcase-data-2/substation@100/motor-1/rpm_avail The overlay is removed when the apply code detects multiple changesets modifying the same property. This is reported via printk(): OF: overlay: ERROR: multiple fragments add, update, and/or delete property /testcase-data-2/substation@100/motor-1/rpm_avail As a result of this error, the overlay is removed resulting in the expected memory leak. Add another device node level to the overlay so that the duplicate property is located in a node added by the overlay, thus no memory leak will occur when the overlay is removed. Thus users of kmemleak will not have to debug this leak in the future. Fixes: 2fe0e8769df9 ("of: overlay: check prevents multiple fragments touching same property") Reported-by: Erhard F. Signed-off-by: Frank Rowand Signed-off-by: Rob Herring

of: unittest: add overlay gpio test to catch gpio hog problem

2020-02-26T16:42:04Z

Geert reports that gpio hog nodes are not properly processed when the gpio hog node is added via an overlay reply and provides an RFC patch to fix the problem [1]. Add a unittest that shows the problem. Unittest will report "1 failed" test before applying Geert's RFC patch and "0 failed" after applying Geert's RFC patch. [1] https://lore.kernel.org/linux-devicetree/20191230133852.5890-1-geert+renesas@glider.be/ Signed-off-by: Frank Rowand Signed-off-by: Rob Herring

of/unittest: Add dma-ranges address translation tests

2019-10-08T18:55:26Z

The functions for parsing 'dma-ranges' ranges are buggy and fail to handle several conditions. Add new tests for of_dma_get_range() and for_each_of_pci_range(). With this test, we get 5 new failures which are fixed in subsequent commits: OF: translation of DMA address(0) to CPU address failed node(/testcase-data/address-tests/device@70000000) FAIL of_unittest_dma_ranges_one():798 of_dma_get_range failed on node /testcase-data/address-tests/device@70000000 rc=-22 OF: translation of DMA address(10000000) to CPU address failed node(/testcase-data/address-tests/bus@80000000/device@1000) FAIL of_unittest_dma_ranges_one():798 of_dma_get_range failed on node /testcase-data/address-tests/bus@80000000/device@1000 rc=-22 OF: translation of DMA address(0) to CPU address failed node(/testcase-data/address-tests/pci@90000000) FAIL of_unittest_dma_ranges_one():798 of_dma_get_range failed on node /testcase-data/address-tests/pci@90000000 rc=-22 FAIL of_unittest_pci_dma_ranges():851 for_each_of_pci_range wrong CPU addr (d0000000) on node /testcase-data/address-tests/pci@90000000 FAIL of_unittest_pci_dma_ranges():861 for_each_of_pci_range wrong CPU addr (ffffffffffffffff) on node /testcase-data/address-tests/pci@90000000 Cc: Robin Murphy Tested-by: Nicolas Saenz Julienne Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Rob Herring

of: overlay: check prevents multiple fragments touching same property

2018-11-09T06:12:03Z

Add test case of two fragments updating the same property. After adding the test case, the system hangs at end of boot, after after slub stack dumps from kfree() in crypto modprobe code. Multiple overlay fragments adding, modifying, or deleting the same property is not supported. Add check to detect the attempt and fail the overlay apply. Before this patch, the first fragment error would terminate processing. Allow fragment checking to proceed and report all of the fragment errors before terminating the overlay apply. This is not a hot path, thus not a performance issue (the error is not transient and requires fixing the overlay before attempting to apply it again). After applying this patch, the devicetree unittest messages will include: OF: overlay: ERROR: multiple fragments add, update, and/or delete property /testcase-data-2/substation@100/motor-1/rpm_avail ... ### dt-test ### end of unittest - 212 passed, 0 failed The check to detect two fragments updating the same property is folded into the patch that created the test case to maintain bisectability. Tested-by: Alan Tull Signed-off-by: Frank Rowand

of: overlay: test case of two fragments adding same node

2018-11-09T06:11:51Z

Multiple overlay fragments adding or deleting the same node is not supported. An attempt to do so results in an incorrect devicetree. The node name will be munged for the second add. After adding this patch, the unittest messages will show: Duplicate name in motor-1, renamed to "controller#1" OF: overlay: of_overlay_apply() err=0 ### dt-test ### of_overlay_fdt_apply() expected -22, ret=0, overlay_bad_add_dup_node ### dt-test ### FAIL of_unittest_overlay_high_level():2419 Adding overlay 'overlay_bad_add_dup_node' failed ... ### dt-test ### end of unittest - 210 passed, 1 failed The incorrect (munged) node name "controller#1" can be seen in the /proc filesystem: $ pwd /proc/device-tree/testcase-data-2/substation@100/motor-1 $ ls compatible controller controller#1 name phandle spin $ ls controller power_bus $ ls controller#1 power_bus_emergency Tested-by: Alan Tull Signed-off-by: Frank Rowand

of/unittest: Fix I2C bus unit-address error

2018-09-19T22:10:06Z

dtc has new checks for I2C buses. Fix the warnings in unit-addresses in the unittests. drivers/of/unittest-data/testcases.dtb: Warning (i2c_bus_reg): /testcase-data/overlay-node/test-bus/i2c-test-bus/test-unittest14/i2c@0/test-mux-dev: I2C bus unit address format error, expected "20" drivers/of/unittest-data/overlay_15.dtb: Warning (i2c_bus_reg): /fragment@0/__overlay__/test-unittest15/i2c@0/test-mux-dev: I2C bus unit address format error, expected "20" Cc: Frank Rowand Signed-off-by: Rob Herring

kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markers

2018-04-07T10:04:02Z

GNU Make automatically deletes intermediate files that are updated in a chain of pattern rules. Example 1) %.dtb.o <- %.dtb.S <- %.dtb <- %.dts Example 2) %.o <- %.c <- %.c_shipped A couple of makefiles mark such targets as .PRECIOUS to prevent Make from deleting them, but the correct way is to use .SECONDARY. .SECONDARY Prerequisites of this special target are treated as intermediate files but are never automatically deleted. .PRECIOUS When make is interrupted during execution, it may delete the target file it is updating if the file was modified since make started. If you mark the file as precious, make will never delete the file if interrupted. Both can avoid deletion of intermediate files, but the difference is the behavior when Make is interrupted; .SECONDARY deletes the target, but .PRECIOUS does not. The use of .PRECIOUS is relatively rare since we do not want to keep partially constructed (possibly corrupted) targets. Another difference is that .PRECIOUS works with pattern rules whereas .SECONDARY does not. .PRECIOUS: $(obj)/%.lex.c works, but .SECONDARY: $(obj)/%.lex.c has no effect. However, for the reason above, I do not want to use .PRECIOUS which could cause obscure build breakage. The targets specified as .SECONDARY must be explicit. $(targets) contains all targets that need to include .*.cmd files. So, the intermediates you want to keep are mostly in there. Therefore, mark $(targets) as .SECONDARY. It means primary targets are also marked as .SECONDARY, but I do not see any drawback for this. I replaced some .SECONDARY / .PRECIOUS markers with 'targets'. This will make Kbuild search for non-existing .*.cmd files, but this is not a noticeable performance issue. Signed-off-by: Masahiro Yamada Acked-by: Frank Rowand Acked-by: Ingo Molnar

kbuild: add %.dtb.S and %.dtb to 'targets' automatically

2018-04-07T10:04:02Z

Another common pattern that consists of chained commands is to compile a DTB as binary data into the kernel image or a module. It is used in several places in the source tree. Support it in the core Makefile. $(call if_changed,dt_S_dtb) is more suitable than $(call cmd,dt_S_dtb) in case cmd_dt_S_dtb is changed in the future. Signed-off-by: Masahiro Yamada Acked-by: Frank Rowand

Merge tag 'overlay_apply_fdt_v7-for-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/frowand/linux into dt/next

2018-03-05T19:29:46Z

DT overlay applying rework from Frank Rowand: "Move duplicating and unflattening of an overlay flattened devicetree (FDT) into the overlay application code. To accomplish this, of_overlay_apply() is replaced by of_overlay_fdt_apply()."

of: convert unittest overlay devicetree source to sugar syntax

2018-03-04T08:29:34Z

The unittest-data overlays have been pulled into proper overlay devicetree source files without changing their format. The next step is to convert them to use sugar syntax instead of hand coding overlay fragments structure. A few of the overlays can not be converted because they test absolute target paths in the overlay fragment. dtc does not generate this type of target: overlay_0.dts overlay_1.dts overlay_12.dts overlay_13.dts Two pre-existing unittest overlay devicetree source files are also converted: overlay_bad_phandle.dts overlay_bad_symbol.dts Signed-off-by: Frank Rowand