Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-10-08 16:27:37) > On 10/8/24 16:12, Stephen Boyd wrote: > > > > The best I can come up with then is to test for a NULL of_root when > > CONFIG_ARM64 and CONFIG_ACPI are enabled, because the tests > > intentionally don't work when both those configs are enabled and the > > 'of_root' isn't populated. In all other cases the 'of_root' missing is a > > bug. I'll probably make this into some sort of kunit helper function in > > of_private.h and send it to DT maintainers. > > Sounds good. Thanks a lot for tracking this down. > > That makes me wonder though why only arm64 has that restriction. Both > riscv and loongarch have ACPI enabled in their defconfig files but call > unflatten_device_tree() unconditionally. > > Oh well ... Some of the reason is described in the thread I linked earlier. In particular, this email from Mark[1]. There's also more comments from Mark on an earlier patchset[2]. Maybe arm64 will allow it later, and then we'll be able to revert this skip patch. [1] https://lore.kernel.org/all/zd4dqpho7em1j...@fvff77s0q05n.cambridge.arm.com/ [2] https://lore.kernel.org/all/ZaZtbU9hre3YhZam@FVFF77S0Q05N/
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 10/8/24 16:12, Stephen Boyd wrote: Quoting Guenter Roeck (2024-10-03 21:52:09) On 10/3/24 17:42, Stephen Boyd wrote: Can you please describe how you run the kunit test? And provide the qemu command you run to boot arm64 with acpi? Example command line: qemu-system-aarch64 -M virt -m 512 \ -kernel arch/arm64/boot/Image -no-reboot -nographic \ -snapshot \ -bios /opt/buildbot/rootfs/arm64/../firmware/QEMU_EFI-aarch64.fd \ -device virtio-blk-device,drive=d0 \ -drive file=rootfs.ext2,if=none,id=d0,format=raw \ -cpu cortex-a57 -serial stdio -monitor none -no-reboot \ --append "kunit.stats_enabled=2 kunit.filter=speed>slow root=/dev/vda rootwait earlycon=pl011,0x900 console=ttyAMA0" That works fine for me. Configuration is arm64 defconfig plus various debug and kunit options. I built the efi image myself from sources. The root file system is from buildroot with modified init script. kunit tests are all built into the kernel and run during boot. Thanks. I figured out that I was missing enabling CONFIG_ACPI. Here's my commandline ./tools/testing/kunit/kunit.py run --arch=arm64 \ --kunitconfig=drivers/of \ --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -smp 2" \ --kconfig_add="CONFIG_ACPI=y" \ --kernel_args="earlycon=pl011,0x900" Now I can boot and reproduce the failure, but there's another problem. ACPI disables itself when it fails to find tables. ACPI: Unable to load the System Description Tables This calls disable_acpi() which sets acpi_disabled to 1. This happens before the unit test runs, meaning we can't reliably use 'acpi_disabled' as a method to skip. The best I can come up with then is to test for a NULL of_root when CONFIG_ARM64 and CONFIG_ACPI are enabled, because the tests intentionally don't work when both those configs are enabled and the 'of_root' isn't populated. In all other cases the 'of_root' missing is a bug. I'll probably make this into some sort of kunit helper function in of_private.h and send it to DT maintainers. Sounds good. Thanks a lot for tracking this down. That makes me wonder though why only arm64 has that restriction. Both riscv and loongarch have ACPI enabled in their defconfig files but call unflatten_device_tree() unconditionally. Oh well ... Thanks, Guenter
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-10-03 21:52:09)
> On 10/3/24 17:42, Stephen Boyd wrote:
> >
> > Can you please describe how you run the kunit test? And provide the qemu
> > command you run to boot arm64 with acpi?
> >
>
> Example command line:
>
> qemu-system-aarch64 -M virt -m 512 \
> -kernel arch/arm64/boot/Image -no-reboot -nographic \
> -snapshot \
> -bios /opt/buildbot/rootfs/arm64/../firmware/QEMU_EFI-aarch64.fd \
> -device virtio-blk-device,drive=d0 \
> -drive file=rootfs.ext2,if=none,id=d0,format=raw \
> -cpu cortex-a57 -serial stdio -monitor none -no-reboot \
> --append "kunit.stats_enabled=2 kunit.filter=speed>slow root=/dev/vda
> rootwait earlycon=pl011,0x900 console=ttyAMA0"
>
> That works fine for me. Configuration is arm64 defconfig plus various
> debug and kunit options. I built the efi image myself from sources.
> The root file system is from buildroot with modified init script.
> kunit tests are all built into the kernel and run during boot.
Thanks. I figured out that I was missing enabling CONFIG_ACPI. Here's my
commandline
./tools/testing/kunit/kunit.py run --arch=arm64 \
--kunitconfig=drivers/of \
--qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -smp 2" \
--kconfig_add="CONFIG_ACPI=y" \
--kernel_args="earlycon=pl011,0x900"
Now I can boot and reproduce the failure, but there's another problem.
ACPI disables itself when it fails to find tables.
ACPI: Unable to load the System Description Tables
This calls disable_acpi() which sets acpi_disabled to 1. This happens
before the unit test runs, meaning we can't reliably use 'acpi_disabled'
as a method to skip.
The best I can come up with then is to test for a NULL of_root when
CONFIG_ARM64 and CONFIG_ACPI are enabled, because the tests
intentionally don't work when both those configs are enabled and the
'of_root' isn't populated. In all other cases the 'of_root' missing is a
bug. I'll probably make this into some sort of kunit helper function in
of_private.h and send it to DT maintainers.
---8<
diff --git a/drivers/of/of_kunit_helpers.c b/drivers/of/of_kunit_helpers.c
index 287d6c91bb37..a1330e183230 100644
--- a/drivers/of/of_kunit_helpers.c
+++ b/drivers/of/of_kunit_helpers.c
@@ -36,6 +36,9 @@ int of_overlay_fdt_apply_kunit(struct kunit *test, void
*overlay_fdt,
int ret;
int *copy_id;
+ if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ACPI) && !of_root)
+ kunit_skip(test, "arm64+acpi rejects overlays");
+
copy_id = kunit_kmalloc(test, sizeof(*copy_id), GFP_KERNEL);
if (!copy_id)
return -ENOMEM;
diff --git a/drivers/of/of_test.c b/drivers/of/of_test.c
index c85a258bc6ae..6cca43bf8029 100644
--- a/drivers/of/of_test.c
+++ b/drivers/of/of_test.c
@@ -38,6 +38,8 @@ static int of_dtb_test_init(struct kunit *test)
{
if (!IS_ENABLED(CONFIG_OF_EARLY_FLATTREE))
kunit_skip(test, "requires CONFIG_OF_EARLY_FLATTREE");
+ if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ACPI) && !of_root)
+ kunit_skip(test, "arm64+acpi doesn't populate a root node on
ACPI systems");
return 0;
}
diff --git a/drivers/of/overlay_test.c b/drivers/of/overlay_test.c
index 19a292cdeee3..3e7ac97a6796 100644
--- a/drivers/of/overlay_test.c
+++ b/drivers/of/overlay_test.c
@@ -64,6 +64,8 @@ static void of_overlay_apply_kunit_cleanup(struct kunit *test)
if (!IS_ENABLED(CONFIG_OF_EARLY_FLATTREE))
kunit_skip(test, "requires CONFIG_OF_EARLY_FLATTREE for root
node");
+ if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ACPI) && !of_root)
+ kunit_skip(test, "arm64+acpi rejects overlays");
kunit_init_test(&fake, "fake test", NULL);
KUNIT_ASSERT_EQ(test, fake.status, KUNIT_SUCCESS);
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 10/3/24 17:42, Stephen Boyd wrote: Quoting Guenter Roeck (2024-10-03 17:25:37) On 10/3/24 16:46, Stephen Boyd wrote: [ ... ] That DT test has been there for a few releases. Is this the first time those tests have been run on arm64+acpi? I didn't try after sending the patches and forgot that the patch was dropped. Previously I had the affected tests disabled and never tracked down the problem. Since the problem is now spreading to additional tests, I finally tracked it down, that is all. Ok great. Good to know this isn't a new problem. Thanks for tracking it down. How are you running kunit tests? I installed the qemu-efi-aarch64 debian package to get QEMU_EFI.fd but passing that to the kunit.py run command with --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" didn't get me beyond the point that the EFI stub boots linux. I think the serial console must not be working and thus the kunit wrapper waits for something to show up but nothing ever does. I haven't dug any further though, so maybe you have a working command. I run all tests during boot, not from the command line. I also use the -bios command but don't recall any issues with the console. I specify the console on the qemu command line; depending on the qemu machine it is either ttyS0 or ttyAMA0. The init script then finds and selects the active console. Can you please describe how you run the kunit test? And provide the qemu command you run to boot arm64 with acpi? Example command line: qemu-system-aarch64 -M virt -m 512 \ -kernel arch/arm64/boot/Image -no-reboot -nographic \ -snapshot \ -bios /opt/buildbot/rootfs/arm64/../firmware/QEMU_EFI-aarch64.fd \ -device virtio-blk-device,drive=d0 \ -drive file=rootfs.ext2,if=none,id=d0,format=raw \ -cpu cortex-a57 -serial stdio -monitor none -no-reboot \ --append "kunit.stats_enabled=2 kunit.filter=speed>slow root=/dev/vda rootwait earlycon=pl011,0x900 console=ttyAMA0" That works fine for me. Configuration is arm64 defconfig plus various debug and kunit options. I built the efi image myself from sources. The root file system is from buildroot with modified init script. kunit tests are all built into the kernel and run during boot. I'll just keep the affected tests disabled on arm64 for the time being. We should skip the tests on arm64+acpi, which is similar to disabling but not exactly the same. There will likely be more DT overlay usage in kunit and so that will lead to more test disabling. Skipping properly is the better solution. Sure, but having those tests fail all the time doesn't help either. I'll re-enable the tests if / when they are skipped. Thanks, Guenter
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-10-03 17:25:37) > On 10/3/24 16:46, Stephen Boyd wrote: > [ ... ] > > That DT test has been there for a few releases. Is this the first time > > those tests have been run on arm64+acpi? I didn't try after sending the > > patches and forgot that the patch was dropped. > > > > Previously I had the affected tests disabled and never tracked down the > problem. > Since the problem is now spreading to additional tests, I finally tracked it > down, > that is all. Ok great. Good to know this isn't a new problem. Thanks for tracking it down. > > > How are you running kunit tests? I installed the qemu-efi-aarch64 debian > > package to get QEMU_EFI.fd but passing that to the kunit.py run command > > with --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" didn't > > get me beyond the point that the EFI stub boots linux. I think the > > serial console must not be working and thus the kunit wrapper waits for > > something to show up but nothing ever does. I haven't dug any further > > though, so maybe you have a working command. > > > > I run all tests during boot, not from the command line. I also use the -bios > command but don't recall any issues with the console. I specify the > console on the qemu command line; depending on the qemu machine it is either > ttyS0 or ttyAMA0. The init script then finds and selects the active console. Can you please describe how you run the kunit test? And provide the qemu command you run to boot arm64 with acpi? > > > Here's my command that isn't working: > > > > ./tools/testing/kunit/kunit.py run --arch=arm64 --kunitconfig=drivers/of > > --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" > > > > I can't really see what that command is actually doing ;-). It eventually runs this qemu command qemu-system-aarch64 -nodefaults -m 1024 -kernel .kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -serial stdio -machine virt -cpu max,pauth-impdef=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd I see that it fails because the architected timer isn't there after I add an earlycon=pl011,0x900 to the kernel commandline. I suspect passing a bios like this is incorrect, but I rarely run qemu manually so I don't know what I'm doing wrong. NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 rcu: srcu_init: Setting srcu_struct sizes based on contention. timer_probe: no matching timers found Kernel panic - not syncing: Unable to initialise architected timer. CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc1-00261-g497f7c30f184 #203 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x38/0x90 dump_stack+0x18/0x24 panic+0x36c/0x380 early_brk64+0x0/0xa8 start_kernel+0x27c/0x558 __primary_switched+0x80/0x88 ---[ end Kernel panic - not syncing: Unable to initialise architected timer. ]--- > > I'll just keep the affected tests disabled on arm64 for the time being. We should skip the tests on arm64+acpi, which is similar to disabling but not exactly the same. There will likely be more DT overlay usage in kunit and so that will lead to more test disabling. Skipping properly is the better solution.
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 10/3/24 16:46, Stephen Boyd wrote: [ ... ] That DT test has been there for a few releases. Is this the first time those tests have been run on arm64+acpi? I didn't try after sending the patches and forgot that the patch was dropped. Previously I had the affected tests disabled and never tracked down the problem. Since the problem is now spreading to additional tests, I finally tracked it down, that is all. How are you running kunit tests? I installed the qemu-efi-aarch64 debian package to get QEMU_EFI.fd but passing that to the kunit.py run command with --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" didn't get me beyond the point that the EFI stub boots linux. I think the serial console must not be working and thus the kunit wrapper waits for something to show up but nothing ever does. I haven't dug any further though, so maybe you have a working command. I run all tests during boot, not from the command line. I also use the -bios command but don't recall any issues with the console. I specify the console on the qemu command line; depending on the qemu machine it is either ttyS0 or ttyAMA0. The init script then finds and selects the active console. Here's my command that isn't working: ./tools/testing/kunit/kunit.py run --arch=arm64 --kunitconfig=drivers/of --qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd" I can't really see what that command is actually doing ;-). I'll just keep the affected tests disabled on arm64 for the time being. Thanks, Guenter
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Quoting Guenter Roeck (2024-09-28 14:32:35) > On 9/28/24 12:27, Shuah Khan wrote: > > On 9/28/24 11:54, Shuah Khan wrote: > >> On 9/28/24 11:31, Guenter Roeck wrote: > >>> On 9/27/24 17:08, Guenter Roeck wrote: > On 9/27/24 13:45, Shuah Khan wrote: > > On 9/27/24 10:19, Guenter Roeck wrote: > >> Copying devicetree maintainers. > >> > >> On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: > >>> On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: > Hi Stephen, > > On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: > > Test that clks registered with 'struct clk_parent_data' work as > > intended and can find their parents. > > > > When testing this on arm64, I see the error below. The error is only > seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" > qemu parameter. > > Any idea what might cause the problem ? > > >>> I noticed that the new overlay tests fail as well, also with "path > >>> '/' not > >>> found". > >>> > >>> [Maybe] answering my own question: I think the problem may be that > >>> there > >>> is no devicetree file and thus no devicetree root when booting through > >>> efi (in other words, of_root is NULL). Would it make sense to skip the > >>> tests in that case ? > >>> > >> > >> The problem is that of_root is not initialized in arm64 boots if ACPI > >> is enabled. > >> > >> From arch/arm64/kernel/setup.c:setup_arch(): > >> > >> if (acpi_disabled) > >> unflatten_device_tree(); // initializes of_root Oof I forgot that Rob didn't apply the patch that let an empty root live on ARM64 ACPI systems. See this thread[1] for all the details. > >> > >> ACPI is enabled if the system boots from EFI. This also affects > >> CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and > >> fails the test if it doesn't. > >> > >> I think those tests need to add a check for this condition, or affected > >> machines won't be able to run those unit tests. The obvious solution > >> would > >> be to check if of_root is set, but then the associated test case in > >> CONFIG_OF_KUNIT_TEST would not make sense. > >> > >> Any suggestions ? > >> I think that's the best we can do for now. Basically add a check like if (IS_ENABLED(CONFIG_ARM64) && acpi_disabled) kunit_skip(test, "ARM64 + ACPI rejects DT overlays"); to the overlay application function and the DT test. > > > > Would it work if these tests check if acpi_disabled and skip if it isn't > > disabled? It might be low overhead condition to check from these tests. > > > > acpi_disabled is exported: > > > > arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); > > arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); > > arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); > > arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); > > > > I don't think that would work. Looking through the use of acpi_init, > I don't think that of_root is always NULL when acpi_init is false; that > just happens to be the case on arm64 when booting through efi. > However, even arm64 has the following code. > > if (acpi_disabled) > psci_dt_init(); > else > psci_acpi_init(); > > While psci_dt_init() doesn't set of_root, it does try to do a devicetree > match. So there must be some other condition where acpi_disabled is set > but of_root is set anyway. I just have not found that code path. > > >>> > >>> I ended up disabling all affected unit tests for arm64. I'll do the same > >>> for other architectures if I encounter the problem there as well. > >>> > >>> Unfortunately that includes all clock unit tests because the tests > >>> requiring > >>> devicetree support can not be enabled/disabled separately, but that can't > >>> be > >>> helped and is still better than "mandatory" failures. > >>> > >> > > > > of_root is set in drivers/of/pdt.c when it creates the root node. > > This could be a definitive test for kunit tests that depend on > > devicetree support. > > > > That is not always the case, including arm64. It is primarily set in > unflatten_devicetree(), which is not called on arm64 unless acpi_is disabled > (see above). > > > It is an exported symbol. drivers/of/base.c exports it. > > > > Yes, checking if of_root is NULL and skipping the test in that case might > help, > but then there is the of_dtb_root_node_populates_of_root unit test which > explicitly fails if of_root is NULL. The comment describing the test is > > /* > * Test that the 'of_root' global variable is always populated when DT code > is > * enabled. Remove thi
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 9/28/24 12:27, Shuah Khan wrote: On 9/28/24 11:54, Shuah Khan wrote: On 9/28/24 11:31, Guenter Roeck wrote: On 9/27/24 17:08, Guenter Roeck wrote: On 9/27/24 13:45, Shuah Khan wrote: On 9/27/24 10:19, Guenter Roeck wrote: Copying devicetree maintainers. On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: Hi Stephen, On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: Test that clks registered with 'struct clk_parent_data' work as intended and can find their parents. When testing this on arm64, I see the error below. The error is only seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" qemu parameter. Any idea what might cause the problem ? I noticed that the new overlay tests fail as well, also with "path '/' not found". [Maybe] answering my own question: I think the problem may be that there is no devicetree file and thus no devicetree root when booting through efi (in other words, of_root is NULL). Would it make sense to skip the tests in that case ? The problem is that of_root is not initialized in arm64 boots if ACPI is enabled. From arch/arm64/kernel/setup.c:setup_arch(): if (acpi_disabled) unflatten_device_tree(); // initializes of_root ACPI is enabled if the system boots from EFI. This also affects CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and fails the test if it doesn't. I think those tests need to add a check for this condition, or affected machines won't be able to run those unit tests. The obvious solution would be to check if of_root is set, but then the associated test case in CONFIG_OF_KUNIT_TEST would not make sense. Any suggestions ? Would it work if these tests check if acpi_disabled and skip if it isn't disabled? It might be low overhead condition to check from these tests. acpi_disabled is exported: arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); I don't think that would work. Looking through the use of acpi_init, I don't think that of_root is always NULL when acpi_init is false; that just happens to be the case on arm64 when booting through efi. However, even arm64 has the following code. if (acpi_disabled) psci_dt_init(); else psci_acpi_init(); While psci_dt_init() doesn't set of_root, it does try to do a devicetree match. So there must be some other condition where acpi_disabled is set but of_root is set anyway. I just have not found that code path. I ended up disabling all affected unit tests for arm64. I'll do the same for other architectures if I encounter the problem there as well. Unfortunately that includes all clock unit tests because the tests requiring devicetree support can not be enabled/disabled separately, but that can't be helped and is still better than "mandatory" failures. of_root is set in drivers/of/pdt.c when it creates the root node. This could be a definitive test for kunit tests that depend on devicetree support. That is not always the case, including arm64. It is primarily set in unflatten_devicetree(), which is not called on arm64 unless acpi_is disabled (see above). It is an exported symbol. drivers/of/base.c exports it. Yes, checking if of_root is NULL and skipping the test in that case might help, but then there is the of_dtb_root_node_populates_of_root unit test which explicitly fails if of_root is NULL. The comment describing the test is /* * Test that the 'of_root' global variable is always populated when DT code is * enabled. Remove this test once of_root is removed from global access. */ The devicetree unit test code explicitly assumes that of_root is set if CONFIG_OF_EARLY_FLATTREE is enabled, but that is not always the case (again, of_root is NULL on arm64 unless acpi is disabled). Guenter
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 9/28/24 11:54, Shuah Khan wrote: On 9/28/24 11:31, Guenter Roeck wrote: On 9/27/24 17:08, Guenter Roeck wrote: On 9/27/24 13:45, Shuah Khan wrote: On 9/27/24 10:19, Guenter Roeck wrote: Copying devicetree maintainers. On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: Hi Stephen, On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: Test that clks registered with 'struct clk_parent_data' work as intended and can find their parents. When testing this on arm64, I see the error below. The error is only seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" qemu parameter. Any idea what might cause the problem ? I noticed that the new overlay tests fail as well, also with "path '/' not found". [Maybe] answering my own question: I think the problem may be that there is no devicetree file and thus no devicetree root when booting through efi (in other words, of_root is NULL). Would it make sense to skip the tests in that case ? The problem is that of_root is not initialized in arm64 boots if ACPI is enabled. From arch/arm64/kernel/setup.c:setup_arch(): if (acpi_disabled) unflatten_device_tree(); // initializes of_root ACPI is enabled if the system boots from EFI. This also affects CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and fails the test if it doesn't. I think those tests need to add a check for this condition, or affected machines won't be able to run those unit tests. The obvious solution would be to check if of_root is set, but then the associated test case in CONFIG_OF_KUNIT_TEST would not make sense. Any suggestions ? Would it work if these tests check if acpi_disabled and skip if it isn't disabled? It might be low overhead condition to check from these tests. acpi_disabled is exported: arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); I don't think that would work. Looking through the use of acpi_init, I don't think that of_root is always NULL when acpi_init is false; that just happens to be the case on arm64 when booting through efi. However, even arm64 has the following code. if (acpi_disabled) psci_dt_init(); else psci_acpi_init(); While psci_dt_init() doesn't set of_root, it does try to do a devicetree match. So there must be some other condition where acpi_disabled is set but of_root is set anyway. I just have not found that code path. I ended up disabling all affected unit tests for arm64. I'll do the same for other architectures if I encounter the problem there as well. Unfortunately that includes all clock unit tests because the tests requiring devicetree support can not be enabled/disabled separately, but that can't be helped and is still better than "mandatory" failures. of_root is set in drivers/of/pdt.c when it creates the root node. This could be a definitive test for kunit tests that depend on devicetree support. It is an exported symbol. drivers/of/base.c exports it. thanks, -- SHuah
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 9/28/24 11:31, Guenter Roeck wrote: On 9/27/24 17:08, Guenter Roeck wrote: On 9/27/24 13:45, Shuah Khan wrote: On 9/27/24 10:19, Guenter Roeck wrote: Copying devicetree maintainers. On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: Hi Stephen, On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: Test that clks registered with 'struct clk_parent_data' work as intended and can find their parents. When testing this on arm64, I see the error below. The error is only seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" qemu parameter. Any idea what might cause the problem ? I noticed that the new overlay tests fail as well, also with "path '/' not found". [Maybe] answering my own question: I think the problem may be that there is no devicetree file and thus no devicetree root when booting through efi (in other words, of_root is NULL). Would it make sense to skip the tests in that case ? The problem is that of_root is not initialized in arm64 boots if ACPI is enabled. From arch/arm64/kernel/setup.c:setup_arch(): if (acpi_disabled) unflatten_device_tree(); // initializes of_root ACPI is enabled if the system boots from EFI. This also affects CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and fails the test if it doesn't. I think those tests need to add a check for this condition, or affected machines won't be able to run those unit tests. The obvious solution would be to check if of_root is set, but then the associated test case in CONFIG_OF_KUNIT_TEST would not make sense. Any suggestions ? Would it work if these tests check if acpi_disabled and skip if it isn't disabled? It might be low overhead condition to check from these tests. acpi_disabled is exported: arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); I don't think that would work. Looking through the use of acpi_init, I don't think that of_root is always NULL when acpi_init is false; that just happens to be the case on arm64 when booting through efi. However, even arm64 has the following code. if (acpi_disabled) psci_dt_init(); else psci_acpi_init(); While psci_dt_init() doesn't set of_root, it does try to do a devicetree match. So there must be some other condition where acpi_disabled is set but of_root is set anyway. I just have not found that code path. I ended up disabling all affected unit tests for arm64. I'll do the same for other architectures if I encounter the problem there as well. Unfortunately that includes all clock unit tests because the tests requiring devicetree support can not be enabled/disabled separately, but that can't be helped and is still better than "mandatory" failures. I am hoping Stephen will have a solution for this problem. In the meantime, I will look into this to see if we can find a check that works. thanks, -- Shuah
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 9/27/24 17:08, Guenter Roeck wrote: On 9/27/24 13:45, Shuah Khan wrote: On 9/27/24 10:19, Guenter Roeck wrote: Copying devicetree maintainers. On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: Hi Stephen, On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: Test that clks registered with 'struct clk_parent_data' work as intended and can find their parents. When testing this on arm64, I see the error below. The error is only seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" qemu parameter. Any idea what might cause the problem ? I noticed that the new overlay tests fail as well, also with "path '/' not found". [Maybe] answering my own question: I think the problem may be that there is no devicetree file and thus no devicetree root when booting through efi (in other words, of_root is NULL). Would it make sense to skip the tests in that case ? The problem is that of_root is not initialized in arm64 boots if ACPI is enabled. From arch/arm64/kernel/setup.c:setup_arch(): if (acpi_disabled) unflatten_device_tree(); // initializes of_root ACPI is enabled if the system boots from EFI. This also affects CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and fails the test if it doesn't. I think those tests need to add a check for this condition, or affected machines won't be able to run those unit tests. The obvious solution would be to check if of_root is set, but then the associated test case in CONFIG_OF_KUNIT_TEST would not make sense. Any suggestions ? Would it work if these tests check if acpi_disabled and skip if it isn't disabled? It might be low overhead condition to check from these tests. acpi_disabled is exported: arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); I don't think that would work. Looking through the use of acpi_init, I don't think that of_root is always NULL when acpi_init is false; that just happens to be the case on arm64 when booting through efi. However, even arm64 has the following code. if (acpi_disabled) psci_dt_init(); else psci_acpi_init(); While psci_dt_init() doesn't set of_root, it does try to do a devicetree match. So there must be some other condition where acpi_disabled is set but of_root is set anyway. I just have not found that code path. I ended up disabling all affected unit tests for arm64. I'll do the same for other architectures if I encounter the problem there as well. Unfortunately that includes all clock unit tests because the tests requiring devicetree support can not be enabled/disabled separately, but that can't be helped and is still better than "mandatory" failures. Guenter
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 9/27/24 13:45, Shuah Khan wrote: On 9/27/24 10:19, Guenter Roeck wrote: Copying devicetree maintainers. On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: Hi Stephen, On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: Test that clks registered with 'struct clk_parent_data' work as intended and can find their parents. When testing this on arm64, I see the error below. The error is only seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" qemu parameter. Any idea what might cause the problem ? I noticed that the new overlay tests fail as well, also with "path '/' not found". [Maybe] answering my own question: I think the problem may be that there is no devicetree file and thus no devicetree root when booting through efi (in other words, of_root is NULL). Would it make sense to skip the tests in that case ? The problem is that of_root is not initialized in arm64 boots if ACPI is enabled. From arch/arm64/kernel/setup.c:setup_arch(): if (acpi_disabled) unflatten_device_tree(); // initializes of_root ACPI is enabled if the system boots from EFI. This also affects CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and fails the test if it doesn't. I think those tests need to add a check for this condition, or affected machines won't be able to run those unit tests. The obvious solution would be to check if of_root is set, but then the associated test case in CONFIG_OF_KUNIT_TEST would not make sense. Any suggestions ? Would it work if these tests check if acpi_disabled and skip if it isn't disabled? It might be low overhead condition to check from these tests. acpi_disabled is exported: arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); I don't think that would work. Looking through the use of acpi_init, I don't think that of_root is always NULL when acpi_init is false; that just happens to be the case on arm64 when booting through efi. However, even arm64 has the following code. if (acpi_disabled) psci_dt_init(); else psci_acpi_init(); While psci_dt_init() doesn't set of_root, it does try to do a devicetree match. So there must be some other condition where acpi_disabled is set but of_root is set anyway. I just have not found that code path. Guenter
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Copying devicetree maintainers. On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: > On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: > > Hi Stephen, > > > > On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: > > > Test that clks registered with 'struct clk_parent_data' work as > > > intended and can find their parents. > > > > > > > When testing this on arm64, I see the error below. The error is only > > seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" > > qemu parameter. > > > > Any idea what might cause the problem ? > > > I noticed that the new overlay tests fail as well, also with "path '/' not > found". > > [Maybe] answering my own question: I think the problem may be that there > is no devicetree file and thus no devicetree root when booting through > efi (in other words, of_root is NULL). Would it make sense to skip the > tests in that case ? > The problem is that of_root is not initialized in arm64 boots if ACPI is enabled. >From arch/arm64/kernel/setup.c:setup_arch(): if (acpi_disabled) unflatten_device_tree();// initializes of_root ACPI is enabled if the system boots from EFI. This also affects CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and fails the test if it doesn't. I think those tests need to add a check for this condition, or affected machines won't be able to run those unit tests. The obvious solution would be to check if of_root is set, but then the associated test case in CONFIG_OF_KUNIT_TEST would not make sense. Any suggestions ? Thanks, Guenter
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On 9/27/24 10:19, Guenter Roeck wrote: Copying devicetree maintainers. On Thu, Sep 26, 2024 at 09:39:38PM -0700, Guenter Roeck wrote: On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote: Hi Stephen, On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote: Test that clks registered with 'struct clk_parent_data' work as intended and can find their parents. When testing this on arm64, I see the error below. The error is only seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd" qemu parameter. Any idea what might cause the problem ? I noticed that the new overlay tests fail as well, also with "path '/' not found". [Maybe] answering my own question: I think the problem may be that there is no devicetree file and thus no devicetree root when booting through efi (in other words, of_root is NULL). Would it make sense to skip the tests in that case ? The problem is that of_root is not initialized in arm64 boots if ACPI is enabled. From arch/arm64/kernel/setup.c:setup_arch(): if (acpi_disabled) unflatten_device_tree();// initializes of_root ACPI is enabled if the system boots from EFI. This also affects CONFIG_OF_KUNIT_TEST, which explicitly checks if of_root exists and fails the test if it doesn't. I think those tests need to add a check for this condition, or affected machines won't be able to run those unit tests. The obvious solution would be to check if of_root is set, but then the associated test case in CONFIG_OF_KUNIT_TEST would not make sense. Any suggestions ? Would it work if these tests check if acpi_disabled and skip if it isn't disabled? It might be low overhead condition to check from these tests. acpi_disabled is exported: arch/arm64/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/loongarch/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/riscv/kernel/acpi.c:EXPORT_SYMBOL(acpi_disabled); arch/x86/kernel/acpi/boot.c:EXPORT_SYMBOL(acpi_disabled); thanks, -- Shuah
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
On Thu, Sep 26, 2024 at 09:14:11PM -0700, Guenter Roeck wrote:
> Hi Stephen,
>
> On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote:
> > Test that clks registered with 'struct clk_parent_data' work as
> > intended and can find their parents.
> >
>
> When testing this on arm64, I see the error below. The error is only
> seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd"
> qemu parameter.
>
> Any idea what might cause the problem ?
>
I noticed that the new overlay tests fail as well, also with "path '/' not
found".
[Maybe] answering my own question: I think the problem may be that there
is no devicetree file and thus no devicetree root when booting through
efi (in other words, of_root is NULL). Would it make sense to skip the
tests in that case ?
Thanks,
Guenter
> Thanks,
> Guenter
>
> ---
> [ 20.464809] KTAP version 1
> [ 20.464865] # Subtest: clk_register_clk_parent_data_of
> [ 20.464936] # module: clk_test
> [ 20.464979] 1..1
> [ 20.465098] KTAP version 1
> [ 20.465208] # Subtest: clk_register_clk_parent_data_of_test
> [ 20.468964] OF: overlay: find target, node: /fragment@0, path '/' not found
> [ 20.469558] OF: overlay: init_overlay_changeset() failed, ret = -22
> [ 20.470177] # clk_register_clk_parent_data_of_test: ASSERTION FAILED
> at drivers/clk/clk_test.c:2760
> [ 20.470177] Expected 0 == ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }), but
> [ 20.470177] ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
> [ 20.471793] not ok 1 clk_parent_data_of_index_test
> [ 20.474095] OF: overlay: find target, node: /fragment@0, path '/' not found
> [ 20.474373] OF: overlay: init_overlay_changeset() failed, ret = -22
> [ 20.474737] # clk_register_clk_parent_data_of_test: ASSERTION FAILED
> at drivers/clk/clk_test.c:2760
> [ 20.474737] Expected 0 == ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }), but
> [ 20.474737] ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
> [ 20.477677] not ok 2 clk_parent_data_of_fwname_test
> [ 20.479773] OF: overlay: find target, node: /fragment@0, path '/' not found
> [ 20.479941] OF: overlay: init_overlay_changeset() failed, ret = -22
> [ 20.480160] # clk_register_clk_parent_data_of_test: ASSERTION FAILED
> at drivers/clk/clk_test.c:2760
> [ 20.480160] Expected 0 == ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }), but
> [ 20.480160] ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
> [ 20.481513] not ok 3 clk_parent_data_of_name_test
> [ 20.483711] OF: overlay: find target, node: /fragment@0, path '/' not found
> [ 20.483878] OF: overlay: init_overlay_changeset() failed, ret = -22
> [ 20.484100] # clk_register_clk_parent_data_of_test: ASSERTION FAILED
> at drivers/clk/clk_test.c:2760
> [ 20.484100] Expected 0 == ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }), but
> [ 20.484100] ({ extern uint8_t
> __dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
> __dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
> __dtbo_kunit_clk_parent_data_test_begin,
> __dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
> [ 20.485444] not ok 4 clk_parent_data_of_fwname_name_test
> [ 20.487432] OF: overlay: find target, node: /fragment@0, path '/' not found
> [ 20.487600] OF: overlay: init_overlay_changeset() failed, ret = -22
> [ 20.487841] # clk_register_clk_parent_data_of_test: ASSER
Re: [PATCH v8 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data
Hi Stephen,
On Thu, Jul 18, 2024 at 02:05:07PM -0700, Stephen Boyd wrote:
> Test that clks registered with 'struct clk_parent_data' work as
> intended and can find their parents.
>
When testing this on arm64, I see the error below. The error is only
seen if I boot through efi, i.e., with "-bios QEMU_EFI-aarch64.fd"
qemu parameter.
Any idea what might cause the problem ?
Thanks,
Guenter
---
[ 20.464809] KTAP version 1
[ 20.464865] # Subtest: clk_register_clk_parent_data_of
[ 20.464936] # module: clk_test
[ 20.464979] 1..1
[ 20.465098] KTAP version 1
[ 20.465208] # Subtest: clk_register_clk_parent_data_of_test
[ 20.468964] OF: overlay: find target, node: /fragment@0, path '/' not found
[ 20.469558] OF: overlay: init_overlay_changeset() failed, ret = -22
[ 20.470177] # clk_register_clk_parent_data_of_test: ASSERTION FAILED at
drivers/clk/clk_test.c:2760
[ 20.470177] Expected 0 == ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }), but
[ 20.470177] ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
[ 20.471793] not ok 1 clk_parent_data_of_index_test
[ 20.474095] OF: overlay: find target, node: /fragment@0, path '/' not found
[ 20.474373] OF: overlay: init_overlay_changeset() failed, ret = -22
[ 20.474737] # clk_register_clk_parent_data_of_test: ASSERTION FAILED at
drivers/clk/clk_test.c:2760
[ 20.474737] Expected 0 == ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }), but
[ 20.474737] ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
[ 20.477677] not ok 2 clk_parent_data_of_fwname_test
[ 20.479773] OF: overlay: find target, node: /fragment@0, path '/' not found
[ 20.479941] OF: overlay: init_overlay_changeset() failed, ret = -22
[ 20.480160] # clk_register_clk_parent_data_of_test: ASSERTION FAILED at
drivers/clk/clk_test.c:2760
[ 20.480160] Expected 0 == ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }), but
[ 20.480160] ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
[ 20.481513] not ok 3 clk_parent_data_of_name_test
[ 20.483711] OF: overlay: find target, node: /fragment@0, path '/' not found
[ 20.483878] OF: overlay: init_overlay_changeset() failed, ret = -22
[ 20.484100] # clk_register_clk_parent_data_of_test: ASSERTION FAILED at
drivers/clk/clk_test.c:2760
[ 20.484100] Expected 0 == ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }), but
[ 20.484100] ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }) == -22 (0xffea)
[ 20.485444] not ok 4 clk_parent_data_of_fwname_name_test
[ 20.487432] OF: overlay: find target, node: /fragment@0, path '/' not found
[ 20.487600] OF: overlay: init_overlay_changeset() failed, ret = -22
[ 20.487841] # clk_register_clk_parent_data_of_test: ASSERTION FAILED at
drivers/clk/clk_test.c:2760
[ 20.487841] Expected 0 == ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_end); }), but
[ 20.487841] ({ extern uint8_t
__dtbo_kunit_clk_parent_data_test_begin[]; extern uint8_t
__dtbo_kunit_clk_parent_data_test_end[]; __of_overlay_apply_kunit((test),
__dtbo_kunit_clk_parent_data_test_begin,
__dtbo_kunit_clk_parent_data_test_e
