drivers/of/unittest-data/overlay_bad_add_dup_prop.dtso

Source file repositories/reference/linux-study-clean/drivers/of/unittest-data/overlay_bad_add_dup_prop.dtso

File Facts

System
Linux kernel
Corpus path
drivers/of/unittest-data/overlay_bad_add_dup_prop.dtso
Extension
.dtso
Size
1118 bytes
Lines
39
Domain
Driver Families
Bucket
drivers/of
Inferred role
Driver Families: drivers/of
Status
atlas-only

Why This File Exists

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Dependency Surface

Detected Declarations

Annotated Snippet

// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
/plugin/;

/*
 * &electric_1/motor-1/electric and &spin_ctrl_1/electric are the same node:
 *   /testcase-data-2/substation@100/motor-1/electric
 *
 * Thus the property "rpm_avail" in each fragment will
 * result in an attempt to update the same property twice.
 * This will result in an error and the overlay apply
 * will fail.
 *
 * The previous version of this test did not include the extra
 * level of node 'electric'.  That resulted in the 'rpm_avail'
 * property being located in the pre-existing node 'motor-1'.
 * Modifying a property results in a WARNING that a memory leak
 * will occur if the overlay is removed.  Since the overlay apply
 * fails, the memory leak does actually occur, and kmemleak will
 * further report the memory leak if CONFIG_DEBUG_KMEMLEAK is
 * enabled.  Adding the overlay node 'electric' avoids the
 * memory leak and thus people who use kmemleak will not
 * have to debug this non-problem again.
 */

&electric_1 {
	motor-1 {
		electric {
			rpm_avail = <100>;
		};
	};
};

&spin_ctrl_1 {
	electric {
		rpm_avail = <100 200>;
	};
};

Annotation

Implementation Notes