<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/of/unittest-data, branch v5.10.264</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.264</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.264'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-01-25T22:37:50+00:00</updated>
<entry>
<title>of: Fix double free in of_parse_phandle_with_args_map</title>
<updated>2024-01-25T22:37:50+00:00</updated>
<author>
<name>Christian A. Ehrhardt</name>
<email>lk@c--e.de</email>
</author>
<published>2023-12-29T10:54:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d5f490343c77e6708b6c4aa7dbbfbcbb9546adea'/>
<id>urn:sha1:d5f490343c77e6708b6c4aa7dbbfbcbb9546adea</id>
<content type='text'>
[ Upstream commit 4dde83569832f9377362e50f7748463340c5db6b ]

In of_parse_phandle_with_args_map() the inner loop that
iterates through the map entries calls of_node_put(new)
to free the reference acquired by the previous iteration
of the inner loop. This assumes that the value of "new" is
NULL on the first iteration of the inner loop.

Make sure that this is true in all iterations of the outer
loop by setting "new" to NULL after its value is assigned to "cur".

Extend the unittest to detect the double free and add an additional
test case that actually triggers this path.

Fixes: bd6f2fd5a1 ("of: Support parsing phandle argument lists through a nexus node")
Cc: Stephen Boyd &lt;stephen.boyd@linaro.org&gt;
Signed-off-by: "Christian A. Ehrhardt" &lt;lk@c--e.de&gt;
Link: https://lore.kernel.org/r/20231229105411.1603434-1-lk@c--e.de
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>of: unittest: Use bigger address cells to catch parser regressions</title>
<updated>2020-08-03T22:24:49+00:00</updated>
<author>
<name>Nicolas Saenz Julienne</name>
<email>nsaenzjulienne@suse.de</email>
</author>
<published>2020-08-03T14:25:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bda2127827e9dd2781ae095cda0b8e5bf685c458'/>
<id>urn:sha1:bda2127827e9dd2781ae095cda0b8e5bf685c458</id>
<content type='text'>
Getting address and size cells for dma-ranges/ranges parsing is tricky
and shouldn't rely on the node's count_cells() method. The function
starts looking for cells on the parent node, as its supposed to work
with device nodes, which doesn't work when input with bus nodes, as
generally done when parsing ranges.

Add test to catch regressions on that specific quirk as developers will
be tempted to edit it out in favor of the default method.

Signed-off-by: Nicolas Saenz Julienne &lt;nsaenzjulienne@suse.de&gt;
Link: https://lore.kernel.org/r/9200970a917a9cabdc5b17483b5a8725111eb9d0.camel@suse.de
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
</content>
</entry>
<entry>
<title>of: unittest: kmemleak in duplicate property update</title>
<updated>2020-04-17T13:31:34+00:00</updated>
<author>
<name>Frank Rowand</name>
<email>frank.rowand@sony.com</email>
</author>
<published>2020-04-16T21:42:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29acfb65598f91671413869e0d0a1ec4e74ac705'/>
<id>urn:sha1:29acfb65598f91671413869e0d0a1ec4e74ac705</id>
<content type='text'>
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. &lt;erhard_f@mailbox.org&gt;
Signed-off-by: Frank Rowand &lt;frank.rowand@sony.com&gt;
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
</content>
</entry>
<entry>
<title>of: unittest: add overlay gpio test to catch gpio hog problem</title>
<updated>2020-02-26T16:42:04+00:00</updated>
<author>
<name>Frank Rowand</name>
<email>frank.rowand@sony.com</email>
</author>
<published>2020-02-20T18:40:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f4056e705b2ef7f123a188f6aee23ade70e7d793'/>
<id>urn:sha1:f4056e705b2ef7f123a188f6aee23ade70e7d793</id>
<content type='text'>
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 &lt;frank.rowand@sony.com&gt;
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
</content>
</entry>
<entry>
<title>of/unittest: Add dma-ranges address translation tests</title>
<updated>2019-10-08T18:55:26+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2019-09-20T18:28:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=04db93a95aef392a98f9ffa8745da2e7c58ba75b'/>
<id>urn:sha1:04db93a95aef392a98f9ffa8745da2e7c58ba75b</id>
<content type='text'>
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 &lt;robin.murphy@arm.com&gt;
Tested-by: Nicolas Saenz Julienne &lt;nsaenzjulienne@suse.de&gt;
Reviewed-by: Nicolas Saenz Julienne &lt;nsaenzjulienne@suse.de&gt;
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
</content>
</entry>
<entry>
<title>of: overlay: check prevents multiple fragments touching same property</title>
<updated>2018-11-09T06:12:03+00:00</updated>
<author>
<name>Frank Rowand</name>
<email>frank.rowand@sony.com</email>
</author>
<published>2018-10-05T03:36:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2fe0e8769df9fed5098daea7db933bc414c329d7'/>
<id>urn:sha1:2fe0e8769df9fed5098daea7db933bc414c329d7</id>
<content type='text'>
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 &lt;atull@kernel.org&gt;
Signed-off-by: Frank Rowand &lt;frank.rowand@sony.com&gt;
</content>
</entry>
<entry>
<title>of: overlay: test case of two fragments adding same node</title>
<updated>2018-11-09T06:11:51+00:00</updated>
<author>
<name>Frank Rowand</name>
<email>frank.rowand@sony.com</email>
</author>
<published>2018-10-05T03:34:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a68238a19c3b24e43fd2327d102bcea0ccceb7d0'/>
<id>urn:sha1:a68238a19c3b24e43fd2327d102bcea0ccceb7d0</id>
<content type='text'>
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 &lt;atull@kernel.org&gt;
Signed-off-by: Frank Rowand &lt;frank.rowand@sony.com&gt;
</content>
</entry>
<entry>
<title>of/unittest: Fix I2C bus unit-address error</title>
<updated>2018-09-19T22:10:06+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2018-09-13T19:38:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=62287dce5d0ee207b6a09a0a1abd06b61cee1094'/>
<id>urn:sha1:62287dce5d0ee207b6a09a0a1abd06b61cee1094</id>
<content type='text'>
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 &lt;frowand.list@gmail.com&gt;
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markers</title>
<updated>2018-04-07T10:04:02+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2018-03-23T13:04:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54a702f70589926acf687f0cd5df24d07230c80e'/>
<id>urn:sha1:54a702f70589926acf687f0cd5df24d07230c80e</id>
<content type='text'>
GNU Make automatically deletes intermediate files that are updated
in a chain of pattern rules.

Example 1) %.dtb.o &lt;- %.dtb.S &lt;- %.dtb &lt;- %.dts
Example 2) %.o &lt;- %.c &lt;- %.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 &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Frank Rowand &lt;frowand.list@gmail.com&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: add %.dtb.S and %.dtb to 'targets' automatically</title>
<updated>2018-04-07T10:04:02+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2018-03-23T13:04:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a7f924190924783d3e291624c4f0c3f51481ae2c'/>
<id>urn:sha1:a7f924190924783d3e291624c4f0c3f51481ae2c</id>
<content type='text'>
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 &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Frank Rowand &lt;frowand.list@gmail.com&gt;
</content>
</entry>
</feed>
