[PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Stephen Boyd]

This patch series adds unit tests for the clk fixed rate basic type and
the clk registration functions that use struct clk_parent_data. To get
there, we add support for loading a DTB into the UML kernel that's
running the unit tests along with probing platform drivers to bind to
device nodes specified in DT.

With this series, we're able to exercise some of the code in the common
clk framework that uses devicetree lookups to find parents and the fixed
rate clk code that scans devicetree directly and creates clks. Please
review.

I Cced everyone to all the patches so they get the full context. I'm
hoping I can take the whole pile through the clk tree as they almost all
depend on each other. In the future I imagine it will be easy to add
more test nodes to the clk.dtsi file and not need to go across various
maintainer trees like this series does.

Stephen Boyd (8):
  dt-bindings: Add linux,kunit binding
  of: Enable DTB loading on UML for KUnit tests
  kunit: Add test managed platform_device/driver APIs
  clk: Add test managed clk provider/consumer APIs
  dt-bindings: kunit: Add fixed rate clk consumer test
  clk: Add KUnit tests for clk fixed rate basic type
  dt-bindings: clk: Add KUnit clk_parent_data test
  clk: Add KUnit tests for clks registered with struct clk_parent_data

 .../clock/linux,clk-kunit-parent-data.yaml    |  47 ++
 .../kunit/linux,clk-kunit-fixed-rate.yaml     |  35 ++
 .../bindings/kunit/linux,kunit.yaml           |  24 +
 arch/um/kernel/dtb.c                          |  29 +-
 drivers/clk/.kunitconfig                      |   3 +
 drivers/clk/Kconfig                           |   7 +
 drivers/clk/Makefile                          |   6 +
 drivers/clk/clk-fixed-rate_test.c             | 296 ++++++++++++
 drivers/clk/clk-kunit.c                       | 204 ++++++++
 drivers/clk/clk-kunit.h                       |  28 ++
 drivers/clk/clk_test.c                        | 456 +++++++++++++++++-
 drivers/of/Kconfig                            |  26 +
 drivers/of/Makefile                           |   1 +
 drivers/of/kunit/.kunitconfig                 |   4 +
 drivers/of/kunit/Makefile                     |   4 +
 drivers/of/kunit/clk.dtsi                     |  30 ++
 drivers/of/kunit/kunit.dtsi                   |   9 +
 drivers/of/kunit/kunit.dtso                   |   4 +
 drivers/of/kunit/uml_dtb_test.c               |  55 +++
 include/kunit/platform_driver.h               |  15 +
 lib/kunit/Makefile                            |   6 +
 lib/kunit/platform_driver-test.c              | 107 ++++
 lib/kunit/platform_driver.c                   | 207 ++++++++
 23 files changed, 1599 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/linux,clk-kunit-parent-data.yaml
 create mode 100644 Documentation/devicetree/bindings/kunit/linux,clk-kunit-fixed-rate.yaml
 create mode 100644 Documentation/devicetree/bindings/kunit/linux,kunit.yaml
 create mode 100644 drivers/clk/clk-fixed-rate_test.c
 create mode 100644 drivers/clk/clk-kunit.c
 create mode 100644 drivers/clk/clk-kunit.h
 create mode 100644 drivers/of/kunit/.kunitconfig
 create mode 100644 drivers/of/kunit/Makefile
 create mode 100644 drivers/of/kunit/clk.dtsi
 create mode 100644 drivers/of/kunit/kunit.dtsi
 create mode 100644 drivers/of/kunit/kunit.dtso
 create mode 100644 drivers/of/kunit/uml_dtb_test.c
 create mode 100644 include/kunit/platform_driver.h
 create mode 100644 lib/kunit/platform_driver-test.c
 create mode 100644 lib/kunit/platform_driver.c


base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 1/8] dt-bindings: Add linux,kunit binding

[Stephen Boyd]

Document the linux,kunit board compatible string. This board is loaded
into the Linux kernel when KUnit is testing devicetree dependent code.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
 .../bindings/kunit/linux,kunit.yaml           | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/kunit/linux,kunit.yaml

diff --git a/Documentation/devicetree/bindings/kunit/linux,kunit.yaml b/Documentation/devicetree/bindings/kunit/linux,kunit.yaml
new file mode 100644
index 000000000000..dfe6da4796e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/kunit/linux,kunit.yaml
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/kunit/linux,kunit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: KUnit
+
+maintainers:
+  - Brendan Higgins <brendanhiggins@google.com>
+  - David Gow <davidgow@google.com>
+
+description:
+  KUnit board used to unit test the Linux kernel in User Mode Linux (UML).
+
+properties:
+  $nodename:
+    const: "/"
+  compatible:
+    const: linux,kunit
+
+additionalProperties: true
+
+...
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Stephen Boyd]

To fully exercise common clk framework code in KUnit we need to
associate 'struct device' pointers with 'struct device_node' pointers so
that things like clk_get() can parse DT nodes for 'clocks' and so that
clk providers can use DT to provide clks; the most common mode of
operation for clk providers.

Adding support to KUnit so that it loads a DTB is fairly simple after
commit b31297f04e86 ("um: Add devicetree support"). We can simply pass a
pre-compiled deviectree blob (DTB) on the kunit.py commandline and UML
will load it. The problem is that tests won't know that the commandline
has been modified, nor that a DTB has been loaded. Take a different
approach so that tests can skip if a DTB hasn't been loaded.

Reuse the Makefile logic from the OF unittests to build a DTB into the
kernel. This DTB will be for the mythical machine "linux,kunit", i.e.
the devicetree for the KUnit "board". In practice, it is a dtsi file
that will gather includes for kunit tests that rely in part on a
devicetree being loaded. The devicetree should only be loaded if
CONFIG_OF_KUNIT=y. Make that a choice config parallel to the existing
CONFIG_OF_UNITTEST so that only one devicetree can be loaded in the
system at a time. Similarly, the kernel commandline option to load a
DTB is ignored if CONFIG_OF_KUNIT is enabled so that only one DTB is
loaded at a time.

Add a simple unit test to confirm that the DTB loading worked. Future
tests will add to the kunit.dtsi file to include their specific test
nodes.

Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
 arch/um/kernel/dtb.c            | 29 +++++++++++++++--
 drivers/of/Kconfig              | 26 ++++++++++++++++
 drivers/of/Makefile             |  1 +
 drivers/of/kunit/.kunitconfig   |  4 +++
 drivers/of/kunit/Makefile       |  4 +++
 drivers/of/kunit/kunit.dtsi     |  8 +++++
 drivers/of/kunit/kunit.dtso     |  4 +++
 drivers/of/kunit/uml_dtb_test.c | 55 +++++++++++++++++++++++++++++++++
 8 files changed, 128 insertions(+), 3 deletions(-)
 create mode 100644 drivers/of/kunit/.kunitconfig
 create mode 100644 drivers/of/kunit/Makefile
 create mode 100644 drivers/of/kunit/kunit.dtsi
 create mode 100644 drivers/of/kunit/kunit.dtso
 create mode 100644 drivers/of/kunit/uml_dtb_test.c

diff --git a/arch/um/kernel/dtb.c b/arch/um/kernel/dtb.c
index 484141b06938..ee63951b12df 100644
--- a/arch/um/kernel/dtb.c
+++ b/arch/um/kernel/dtb.c
@@ -15,9 +15,32 @@ void uml_dtb_init(void)
 	long long size;
 	void *area;
 
-	area = uml_load_file(dtb, &size);
-	if (!area)
-		return;
+	if (IS_ENABLED(CONFIG_OF_KUNIT)) {
+		/*
+		 * __dtbo_kunit_begin[] and __dtbo_kunit_end[] are magically
+		 * created by cmd_dt_S_dtbo in scripts/Makefile.lib from the
+		 * drivers/of/kunit/kunit.dtsi file.
+		 */
+		extern uint8_t __dtbo_kunit_begin[];
+		extern uint8_t __dtbo_kunit_end[];
+
+		size = __dtbo_kunit_end - __dtbo_kunit_begin;
+		if (!size) {
+			pr_warn("%s: kunit testcases is empty\n", __func__);
+			return;
+		}
+
+		/* creating copy */
+		area = memblock_alloc(size, 8);
+		if (!area)
+			return;
+
+		memcpy(area, __dtbo_kunit_begin, size);
+	} else {
+		area = uml_load_file(dtb, &size);
+		if (!area)
+			return;
+	}
 
 	if (!early_init_dt_scan(area)) {
 		pr_err("invalid DTB %s\n", dtb);
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 80b5fd44ab1c..1f968b6a3dde 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -12,6 +12,20 @@ menuconfig OF
 
 if OF
 
+choice
+	prompt "Devicetree Runtime Tests"
+	default OF_UNITTEST
+
+config OF_KUNIT
+	bool "Devicetree KUnit support" if KUNIT
+	depends on UML
+	select IRQ_DOMAIN
+	select OF_EARLY_FLATTREE
+	help
+	  This option builds in KUnit test cases that rely on device tree infrastructure.
+	  A fake Device Tree Blob (DTB) is loaded on the UML kernel running KUnit so that
+	  KUnit tests can test device tree dependent code.
+
 config OF_UNITTEST
 	bool "Device Tree runtime unit tests"
 	depends on !SPARC
@@ -25,6 +39,18 @@ config OF_UNITTEST
 
 	  If unsure, say N here, but this option is safe to enable.
 
+endchoice
+
+config OF_DTB_KUNIT_TEST
+	tristate "Devicetree KUnit DTB Test" if !KUNIT_ALL_TESTS
+	depends on KUNIT
+	default KUNIT_ALL_TESTS
+	help
+	  This option builds unit tests for the "linux,kunit" DTB built into
+	  the UML kernel image.
+
+	  If unsure, say N here, but this option is safe to enable.
+
 config OF_ALL_DTBS
 	bool "Build all Device Tree Blobs"
 	depends on COMPILE_TEST
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e0360a44306e..16eef3fdf60a 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -19,4 +19,5 @@ obj-y	+= kexec.o
 endif
 endif
 
+obj-y += kunit/
 obj-$(CONFIG_OF_UNITTEST) += unittest-data/
diff --git a/drivers/of/kunit/.kunitconfig b/drivers/of/kunit/.kunitconfig
new file mode 100644
index 000000000000..1def0ad30d29
--- /dev/null
+++ b/drivers/of/kunit/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_OF=y
+CONFIG_OF_KUNIT=y
+CONFIG_OF_DTB_KUNIT_TEST=y
diff --git a/drivers/of/kunit/Makefile b/drivers/of/kunit/Makefile
new file mode 100644
index 000000000000..ffe0447e1ac7
--- /dev/null
+++ b/drivers/of/kunit/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_OF_KUNIT) += kunit.dtbo.o
+
+obj-$(CONFIG_OF_DTB_KUNIT_TEST) += uml_dtb_test.o
diff --git a/drivers/of/kunit/kunit.dtsi b/drivers/of/kunit/kunit.dtsi
new file mode 100644
index 000000000000..82f6c3e2b8d5
--- /dev/null
+++ b/drivers/of/kunit/kunit.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+	model = "KUnit UML";
+	compatible = "linux,kunit";
+};
+
+/* Include testcase dtsi files below */
diff --git a/drivers/of/kunit/kunit.dtso b/drivers/of/kunit/kunit.dtso
new file mode 100644
index 000000000000..50187e8d1422
--- /dev/null
+++ b/drivers/of/kunit/kunit.dtso
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "kunit.dtsi"
diff --git a/drivers/of/kunit/uml_dtb_test.c b/drivers/of/kunit/uml_dtb_test.c
new file mode 100644
index 000000000000..8966c9ebf51f
--- /dev/null
+++ b/drivers/of/kunit/uml_dtb_test.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit tests for DTB loading on UML
+ */
+#include <linux/kconfig.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+
+#include <kunit/test.h>
+
+/*
+ * Test that of_machine_is_compatible() returns positive int when loaded DTB
+ * matches.
+ */
+static void uml_dtb_of_machine_compatible_test(struct kunit *test)
+{
+	KUNIT_EXPECT_GT(test, of_machine_is_compatible("linux,kunit"), 0);
+}
+
+/*
+ * Test that of_flat_dt_get_machine_name() returns the expected 'model' from the
+ * loaded DTB.
+ */
+static void uml_dtb_of_flat_dt_get_machine_name_test(struct kunit *test)
+{
+	KUNIT_EXPECT_STREQ(test, of_flat_dt_get_machine_name(), "KUnit UML");
+}
+
+static struct kunit_case uml_dtb_test_cases[] = {
+	KUNIT_CASE(uml_dtb_of_machine_compatible_test),
+	KUNIT_CASE(uml_dtb_of_flat_dt_get_machine_name_test),
+	{}
+};
+
+static int uml_dtb_test_init(struct kunit *test)
+{
+	if (!IS_ENABLED(CONFIG_OF_KUNIT))
+		kunit_skip(test, "requires CONFIG_OF_KUNIT");
+
+	return 0;
+}
+
+/*
+ * Test suite to confirm DTB is loaded on UML.
+ */
+static struct kunit_suite uml_dtb_suite = {
+	.name = "uml_dtb",
+	.init = uml_dtb_test_init,
+	.test_cases = uml_dtb_test_cases,
+};
+
+kunit_test_suites(
+	&uml_dtb_suite,
+);
+MODULE_LICENSE("GPL");
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 3/8] kunit: Add test managed platform_device/driver APIs

[Stephen Boyd]

Introduce KUnit resource wrappers around platform_driver_register(),
platform_device_alloc(), and platform_device_add() so that test authors
can register platform drivers/devices from their tests and have the
drivers/devices automatically be unregistered when the test is done.

This makes test setup code simpler when a platform driver or platform
device is needed. Add a few test cases at the same time to make sure the
APIs work as intended.

Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---

Should this be moved to drivers/base/ and called platform_kunit.c?
The include/kunit/platform_driver.h could also be
kunit/platform_device.h to match linux/platform_device.h if that is more
familiar.

And I'm not super certain about allocating a driver structure and
embedding it in a wrapper struct. Maybe the code should just use
kunit_get_current_test() instead?

 include/kunit/platform_driver.h  |  15 +++
 lib/kunit/Makefile               |   6 +
 lib/kunit/platform_driver-test.c | 107 ++++++++++++++++
 lib/kunit/platform_driver.c      | 207 +++++++++++++++++++++++++++++++
 4 files changed, 335 insertions(+)
 create mode 100644 include/kunit/platform_driver.h
 create mode 100644 lib/kunit/platform_driver-test.c
 create mode 100644 lib/kunit/platform_driver.c

diff --git a/include/kunit/platform_driver.h b/include/kunit/platform_driver.h
new file mode 100644
index 000000000000..dc211ff8f893
--- /dev/null
+++ b/include/kunit/platform_driver.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _KUNIT_PLATFORM_DRIVER_H
+#define _KUNIT_PLATFORM_DRIVER_H
+
+struct kunit;
+struct platform_device;
+struct platform_driver;
+
+struct platform_device *
+kunit_platform_device_alloc(struct kunit *test, const char *name, int id);
+int kunit_platform_device_add(struct kunit *test, struct platform_device *pdev);
+
+int kunit_platform_driver_register(struct kunit *test, struct platform_driver *drv);
+
+#endif
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index 29aff6562b42..5964d8231ff5 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_KUNIT) +=			kunit.o
 
+# Core KUnit code
 kunit-objs +=				test.o \
 					resource.o \
 					string-stream.o \
@@ -11,7 +12,12 @@ ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
 kunit-objs +=				debugfs.o
 endif
 
+# KUnit helpers
+kunit-objs +=				platform_driver.o
+
+# KUnit tests
 obj-$(CONFIG_KUNIT_TEST) +=		kunit-test.o
+obj-$(CONFIG_KUNIT_TEST) +=		platform_driver-test.o
 
 # string-stream-test compiles built-in only.
 ifeq ($(CONFIG_KUNIT_TEST),y)
diff --git a/lib/kunit/platform_driver-test.c b/lib/kunit/platform_driver-test.c
new file mode 100644
index 000000000000..c926fe01b40a
--- /dev/null
+++ b/lib/kunit/platform_driver-test.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for platform driver infrastructure.
+ */
+
+#include <linux/platform_device.h>
+
+#include <kunit/platform_driver.h>
+#include <kunit/test.h>
+
+/*
+ * Test that kunit_platform_device_alloc() creates a platform device.
+ */
+static void kunit_platform_device_alloc_test(struct kunit *test)
+{
+	KUNIT_EXPECT_NOT_ERR_OR_NULL(test,
+			kunit_platform_device_alloc(test, "kunit-platform", 1));
+}
+
+/*
+ * Test that kunit_platform_device_add() registers a platform device on the
+ * platform bus with the proper name and id.
+ */
+static void kunit_platform_device_add_test(struct kunit *test)
+{
+	struct platform_device *pdev;
+	const char *name = "kunit-platform";
+	const int id = -1;
+
+	pdev = kunit_platform_device_alloc(test, name, id);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
+
+	KUNIT_EXPECT_EQ(test, 0, kunit_platform_device_add(test, pdev));
+	KUNIT_EXPECT_TRUE(test, dev_is_platform(&pdev->dev));
+	KUNIT_EXPECT_STREQ(test, pdev->name, name);
+	KUNIT_EXPECT_EQ(test, pdev->id, id);
+}
+
+static struct kunit_case kunit_platform_device_test_cases[] = {
+	KUNIT_CASE(kunit_platform_device_alloc_test),
+	KUNIT_CASE(kunit_platform_device_add_test),
+	{}
+};
+
+static struct kunit_suite kunit_platform_device_suite = {
+	.name = "kunit_platform_device",
+	.test_cases = kunit_platform_device_test_cases,
+};
+
+struct kunit_platform_driver_test_context {
+	struct platform_driver pdrv;
+	const char *data;
+};
+
+static inline struct kunit_platform_driver_test_context *
+to_test_context(struct platform_device *pdev)
+{
+	return container_of(to_platform_driver(pdev->dev.driver),
+			    struct kunit_platform_driver_test_context,
+			    pdrv);
+}
+
+static int kunit_platform_driver_probe(struct platform_device *pdev)
+{
+	struct kunit_platform_driver_test_context *ctx;
+
+	ctx = to_test_context(pdev);
+	ctx->data = "test data";
+
+	return 0;
+}
+
+/* Test that kunit_platform_driver_register() registers a driver that probes. */
+static void kunit_platform_driver_register_test(struct kunit *test)
+{
+	struct platform_device *pdev;
+	struct kunit_platform_driver_test_context *ctx;
+
+	ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+
+	pdev = kunit_platform_device_alloc(test, "kunit-platform", -1);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
+	KUNIT_ASSERT_EQ(test, 0, kunit_platform_device_add(test, pdev));
+
+	ctx->pdrv.probe = kunit_platform_driver_probe;
+	ctx->pdrv.driver.name = "kunit-platform";
+	ctx->pdrv.driver.owner = THIS_MODULE;
+
+	KUNIT_EXPECT_EQ(test, 0, kunit_platform_driver_register(test, &ctx->pdrv));
+	KUNIT_EXPECT_STREQ(test, ctx->data, "test data");
+}
+
+static struct kunit_case kunit_platform_driver_test_cases[] = {
+	KUNIT_CASE(kunit_platform_driver_register_test),
+	{}
+};
+
+static struct kunit_suite kunit_platform_driver_suite = {
+	.name = "kunit_platform_driver",
+	.test_cases = kunit_platform_driver_test_cases,
+};
+
+kunit_test_suites(&kunit_platform_device_suite,
+		  &kunit_platform_driver_suite);
+
+MODULE_LICENSE("GPL");
diff --git a/lib/kunit/platform_driver.c b/lib/kunit/platform_driver.c
new file mode 100644
index 000000000000..11d155114936
--- /dev/null
+++ b/lib/kunit/platform_driver.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test managed platform driver
+ */
+
+#include <linux/device/driver.h>
+#include <linux/platform_device.h>
+
+#include <kunit/resource.h>
+
+struct kunit_platform_device_alloc_params {
+	const char *name;
+	int id;
+};
+
+static int kunit_platform_device_alloc_init(struct kunit_resource *res, void *context)
+{
+	struct kunit_platform_device_alloc_params *params = context;
+	struct platform_device *pdev;
+
+	pdev = platform_device_alloc(params->name, params->id);
+	if (!pdev)
+		return -ENOMEM;
+
+	res->data = pdev;
+
+	return 0;
+}
+
+static void kunit_platform_device_alloc_exit(struct kunit_resource *res)
+{
+	struct platform_device *pdev = res->data;
+
+	platform_device_put(pdev);
+}
+
+/**
+ * kunit_platform_device_alloc() - Allocate a KUnit test managed platform device
+ * @test: test context
+ * @dev: platform device to alloc
+ *
+ * Register a test managed platform device. The device is put when the test completes.
+ *
+ * Returns: 0 on success, negative errno on failure.
+ */
+struct platform_device *
+kunit_platform_device_alloc(struct kunit *test, const char *name, int id)
+{
+	struct platform_device *pdev;
+	struct kunit_platform_device_alloc_params params = {
+		.name = name,
+		.id = id,
+	};
+
+	pdev = kunit_alloc_resource(test,
+				   kunit_platform_device_alloc_init,
+				   kunit_platform_device_alloc_exit,
+				   GFP_KERNEL, &params);
+	if (!pdev)
+		return ERR_PTR(-ENOMEM);
+
+	return pdev;
+}
+EXPORT_SYMBOL_GPL(kunit_platform_device_alloc);
+
+static int kunit_platform_device_add_init(struct kunit_resource *res, void *context)
+{
+	struct platform_device *pdev = context;
+	int ret;
+
+	ret = platform_device_add(pdev);
+	if (ret) {
+		platform_device_put(pdev);
+		return ret;
+	}
+	res->data = pdev;
+
+	return 0;
+}
+
+static void kunit_platform_device_add_exit(struct kunit_resource *res)
+{
+	struct platform_device *pdev = res->data;
+
+	platform_device_unregister(pdev);
+}
+
+/**
+ * kunit_platform_device_add() - Register a KUnit test managed platform device
+ * @test: test context
+ * @dev: platform device to add
+ *
+ * Register a test managed platform device. The device is unregistered when the
+ * test completes.
+ *
+ * Returns: 0 on success, negative errno on failure.
+ */
+int kunit_platform_device_add(struct kunit *test, struct platform_device *pdev)
+{
+	struct platform_device *res;
+
+	res = kunit_alloc_resource(test,
+				   kunit_platform_device_add_init,
+				   kunit_platform_device_add_exit,
+				   GFP_KERNEL, pdev);
+	if (!res)
+		return -EINVAL;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(kunit_platform_device_add);
+
+static int kunit_platform_driver_register_init(struct kunit_resource *res, void *context)
+{
+	struct platform_driver *drv = context;
+	int ret;
+
+	ret = platform_driver_register(drv);
+	if (ret)
+		return ret;
+	res->data = drv;
+
+	/*
+	 * Wait for the driver to probe (or at least flush out of the deferred
+	 * workqueue)
+	 */
+	wait_for_device_probe();
+
+	return 0;
+}
+
+static void kunit_platform_driver_register_exit(struct kunit_resource *res)
+{
+	struct platform_driver *drv = res->data;
+
+	platform_driver_unregister(drv);
+}
+
+/**
+ * kunit_platform_driver_register() - Register a KUnit test managed platform driver
+ * @test: test context
+ * @drv: platform driver to register
+ *
+ * Register a test managed platform driver. This allows callers to embed the
+ * @drv in a container structure and use container_of() in the probe function
+ * to pass information to kunit tests. It can be assumed that the driver has
+ * probed when this function returns.
+ *
+ * Example:
+ *
+ * .. code-block:: c
+ *
+ *	struct kunit_test_context {
+ *		struct platform_driver pdrv;
+ *		const char *data;
+ *	};
+ *
+ *	static inline struct kunit_test_context *
+ *	to_test_context(struct platform_device *pdev)
+ *	{
+ *		return container_of(to_platform_driver(pdev->dev.driver),
+ *				    struct kunit_test_context,
+ *				    pdrv);
+ *	}
+ *
+ *	static int kunit_platform_driver_probe(struct platform_device *pdev)
+ *	{
+ *		struct kunit_test_context *ctx;
+ *
+ *		ctx = to_test_context(pdev);
+ *		ctx->data = "test data";
+ *
+ *		return 0;
+ *	}
+ *
+ *	static void kunit_platform_driver_test(struct kunit *test)
+ *	{
+ *		struct kunit_test_context *ctx;
+ *
+ *		ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+ *		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+ *
+ *		ctx->pdrv.probe = kunit_platform_driver_probe;
+ *		ctx->pdrv.driver.name = "kunit-platform";
+ *		ctx->pdrv.driver.owner = THIS_MODULE;
+ *
+ *		KUNIT_EXPECT_EQ(test, 0, kunit_platform_driver_register(test, &ctx->pdrv));
+ *		KUNIT_EXPECT_STREQ(test, ctx->data, "test data");
+ *	}
+ *
+ * Returns: 0 on success, negative errno on failure.
+ */
+int kunit_platform_driver_register(struct kunit *test,
+				   struct platform_driver *drv)
+{
+	struct platform_driver *res;
+
+	res = kunit_alloc_resource(test,
+				   kunit_platform_driver_register_init,
+				   kunit_platform_driver_register_exit,
+				   GFP_KERNEL, drv);
+	if (!res)
+		return -EINVAL;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(kunit_platform_driver_register);
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 4/8] clk: Add test managed clk provider/consumer APIs

[Stephen Boyd]

Unit tests are more ergonomic and simpler to understand if they don't
have to hoist a bunch of code into the test harness init and exit
functions. Add some test managed wrappers for the clk APIs so that clk
unit tests can write more code in the actual test and less code in the
harness.

Only add APIs that are used for now. More wrappers can be added in the
future as necessary.

Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
 drivers/clk/Makefile    |   5 +
 drivers/clk/clk-kunit.c | 204 ++++++++++++++++++++++++++++++++++++++++
 drivers/clk/clk-kunit.h |  28 ++++++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/clk/clk-kunit.c
 create mode 100644 drivers/clk/clk-kunit.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e3ca0d058a25..7efce649b0d3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -17,6 +17,11 @@ ifeq ($(CONFIG_OF), y)
 obj-$(CONFIG_COMMON_CLK)	+= clk-conf.o
 endif
 
+# KUnit specific helpers
+ifeq ($(CONFIG_COMMON_CLK), y)
+obj-$(CONFIG_KUNIT)		+= clk-kunit.o
+endif
+
 # hardware specific clock types
 # please keep this section sorted lexicographically by file path name
 obj-$(CONFIG_COMMON_CLK_APPLE_NCO)  	+= clk-apple-nco.o
diff --git a/drivers/clk/clk-kunit.c b/drivers/clk/clk-kunit.c
new file mode 100644
index 000000000000..78d85b3a7a4a
--- /dev/null
+++ b/drivers/clk/clk-kunit.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit helpers for clk tests
+ */
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+
+#include <kunit/resource.h>
+
+#include "clk-kunit.h"
+
+static void kunit_clk_disable_unprepare(struct kunit_resource *res)
+{
+	struct clk *clk = res->data;
+
+	clk_disable_unprepare(clk);
+}
+
+/**
+ * kunit_clk_prepare_enable() - Test managed clk_prepare_enable()
+ * @test: The test context
+ * @clk: clk to prepare and enable
+ *
+ * Returns: 0 on success, or negative errno on failure.
+ */
+int kunit_clk_prepare_enable(struct kunit *test, struct clk *clk)
+{
+	if (!kunit_alloc_resource(test, NULL, kunit_clk_disable_unprepare,
+				  GFP_KERNEL, clk))
+		return -EINVAL;
+
+	return clk_prepare_enable(clk);
+}
+EXPORT_SYMBOL_GPL(kunit_clk_prepare_enable);
+
+static void kunit_clk_put(struct kunit_resource *res)
+{
+	struct clk *clk = res->data;
+
+	clk_put(clk);
+}
+
+/**
+ * kunit_clk_get() - Test managed clk_get()
+ * @test: The test context
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Returns: new clk consumer or ERR_PTR on failure
+ */
+struct clk *
+kunit_clk_get(struct kunit *test, struct device *dev, const char *con_id)
+{
+	struct clk *clk;
+
+	clk = clk_get(dev, con_id);
+	if (IS_ERR(clk))
+		return clk;
+
+	if (!kunit_alloc_resource(test, NULL, kunit_clk_put, GFP_KERNEL, clk)) {
+		clk_put(clk);
+		return ERR_PTR(-EINVAL);
+	}
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(kunit_clk_get);
+
+/**
+ * kunit_of_clk_get() - Test managed of_clk_get()
+ * @test: The test context
+ * @np: device_node for clock "consumer"
+ * @index: index in 'clocks' property of @np
+ *
+ * Returns: new clk consumer or ERR_PTR on failure
+ */
+struct clk *
+kunit_of_clk_get(struct kunit *test, struct device_node *np, int index)
+{
+	struct clk *clk;
+
+	clk = of_clk_get(np, index);
+	if (IS_ERR(clk))
+		return clk;
+
+	if (!kunit_alloc_resource(test, NULL, kunit_clk_put, GFP_KERNEL, clk)) {
+		clk_put(clk);
+		return ERR_PTR(-EINVAL);
+	}
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(kunit_of_clk_get);
+
+/**
+ * kunit_clk_hw_get_clk() - Test managed clk_hw_get_clk()
+ * @test: The test context
+ * @hw: clk_hw associated with the clk being consumed
+ * @con_id: connection ID string on device
+ *
+ * Returns: new clk consumer or ERR_PTR on failure
+ */
+struct clk *
+kunit_clk_hw_get_clk(struct kunit *test, struct clk_hw *hw, const char *con_id)
+{
+	struct clk *clk;
+
+	clk = clk_hw_get_clk(hw, con_id);
+	if (IS_ERR(clk))
+		return clk;
+
+	if (!kunit_alloc_resource(test, NULL, kunit_clk_put, GFP_KERNEL, clk)) {
+		clk_put(clk);
+		return ERR_PTR(-EINVAL);
+	}
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(kunit_clk_hw_get_clk);
+
+/**
+ * kunit_clk_hw_get_clk_prepared_enabled() - Test managed clk_hw_get_clk() + clk_prepare_enable()
+ * @test: The test context
+ * @hw: clk_hw associated with the clk being consumed
+ * @con_id: connection ID string on device
+ *
+ * Returns: new clk consumer that is prepared and enabled or ERR_PTR on failure
+ */
+struct clk *
+kunit_clk_hw_get_clk_prepared_enabled(struct kunit *test, struct clk_hw *hw,
+				      const char *con_id)
+{
+	int ret;
+	struct clk *clk;
+
+	clk = kunit_clk_hw_get_clk(test, hw, con_id);
+	if (IS_ERR(clk))
+		return clk;
+
+	ret = kunit_clk_prepare_enable(test, clk);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(kunit_clk_hw_get_clk_prepared_enabled);
+
+static void kunit_clk_hw_unregister(struct kunit_resource *res)
+{
+	struct clk_hw *hw = res->data;
+
+	clk_hw_unregister(hw);
+}
+
+/**
+ * kunit_clk_hw_register() - Test managed clk_hw_register()
+ * @test: The test context
+ * @dev: device that is registering this clock
+ * @hw: link to hardware-specific clock data
+ *
+ * Returns: 0 on success or a negative errno value on failure
+ */
+int kunit_clk_hw_register(struct kunit *test, struct device *dev, struct clk_hw *hw)
+{
+	int ret;
+
+	ret = clk_hw_register(dev, hw);
+	if (ret)
+		return ret;
+
+	if (!kunit_alloc_resource(test, NULL, kunit_clk_hw_unregister, GFP_KERNEL, hw)) {
+		clk_hw_unregister(hw);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/**
+ * kunit_of_clk_hw_register() - Test managed of_clk_hw_register()
+ * @test: The test context
+ * @node: device_node of device that is registering this clock
+ * @hw: link to hardware-specific clock data
+ *
+ * Returns: 0 on success or a negative errno value on failure
+ */
+int kunit_of_clk_hw_register(struct kunit *test, struct device_node *node, struct clk_hw *hw)
+{
+	int ret;
+
+	ret = of_clk_hw_register(node, hw);
+	if (ret)
+		return ret;
+
+	if (!kunit_alloc_resource(test, NULL, kunit_clk_hw_unregister, GFP_KERNEL, hw)) {
+		clk_hw_unregister(hw);
+		return -EINVAL;
+	}
+
+	return 0;
+}
diff --git a/drivers/clk/clk-kunit.h b/drivers/clk/clk-kunit.h
new file mode 100644
index 000000000000..153597d69269
--- /dev/null
+++ b/drivers/clk/clk-kunit.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _CLK_KUNIT_H
+#define _CLK_KUNIT_H
+
+struct clk;
+struct clk_hw;
+struct device;
+struct device_node;
+struct kunit;
+
+struct clk *
+kunit_clk_get(struct kunit *test, struct device *dev, const char *con_id);
+struct clk *
+kunit_of_clk_get(struct kunit *test, struct device_node *np, int index);
+
+struct clk *
+kunit_clk_hw_get_clk(struct kunit *test, struct clk_hw *hw, const char *con_id);
+struct clk *
+kunit_clk_hw_get_clk_prepared_enabled(struct kunit *test, struct clk_hw *hw,
+				      const char *con_id);
+
+int kunit_clk_prepare_enable(struct kunit *test, struct clk *clk);
+
+int kunit_clk_hw_register(struct kunit *test, struct device *dev, struct clk_hw *hw);
+int kunit_of_clk_hw_register(struct kunit *test, struct device_node *node,
+			     struct clk_hw *hw);
+
+#endif
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 5/8] dt-bindings: kunit: Add fixed rate clk consumer test

[Stephen Boyd]

Describe a binding for a device that consumes a fixed rate clk in DT so
that a KUnit test can get the clk registered by of_fixed_clk_setup() and
test that it is setup properly.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
 .../kunit/linux,clk-kunit-fixed-rate.yaml     | 35 +++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/kunit/linux,clk-kunit-fixed-rate.yaml

diff --git a/Documentation/devicetree/bindings/kunit/linux,clk-kunit-fixed-rate.yaml b/Documentation/devicetree/bindings/kunit/linux,clk-kunit-fixed-rate.yaml
new file mode 100644
index 000000000000..2d46eb7a6273
--- /dev/null
+++ b/Documentation/devicetree/bindings/kunit/linux,clk-kunit-fixed-rate.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/kunit/linux,clk-kunit-fixed-rate.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: KUnit clk fixed rate test clk consumer
+
+maintainers:
+  - Stephen Boyd <sboyd@kernel.org>
+
+description: |
+  A clk consumer of a fixed rate clk used to test the fixed rate clk
+  implementation in the Linux kernel.
+
+properties:
+  compatible:
+    const: linux,clk-kunit-fixed-rate
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    clock-consumer {
+      compatible = "linux,clk-kunit-fixed-rate";
+      clocks = <&fixed_clk>;
+    };
+...
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 6/8] clk: Add KUnit tests for clk fixed rate basic type

[Stephen Boyd]

Test that the fixed rate basic type clk works as intended.

Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---

This should be extended somewhat to test various combinations of the
registration functions.

 drivers/clk/.kunitconfig          |   3 +
 drivers/clk/Kconfig               |   7 +
 drivers/clk/Makefile              |   1 +
 drivers/clk/clk-fixed-rate_test.c | 296 ++++++++++++++++++++++++++++++
 drivers/of/kunit/clk.dtsi         |  15 ++
 drivers/of/kunit/kunit.dtsi       |   1 +
 6 files changed, 323 insertions(+)
 create mode 100644 drivers/clk/clk-fixed-rate_test.c
 create mode 100644 drivers/of/kunit/clk.dtsi

diff --git a/drivers/clk/.kunitconfig b/drivers/clk/.kunitconfig
index 2fbeb71316f8..3616cebd22f5 100644
--- a/drivers/clk/.kunitconfig
+++ b/drivers/clk/.kunitconfig
@@ -1,5 +1,8 @@
 CONFIG_KUNIT=y
+CONFIG_OF=y
+CONFIG_OF_KUNIT=y
 CONFIG_COMMON_CLK=y
 CONFIG_CLK_KUNIT_TEST=y
+CONFIG_CLK_FIXED_RATE_KUNIT_TEST=y
 CONFIG_CLK_GATE_KUNIT_TEST=y
 CONFIG_UML_PCI_OVER_VIRTIO=n
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index d79905f3e174..4849046b821f 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -479,6 +479,13 @@ config CLK_KUNIT_TEST
 	help
 	  Kunit tests for the common clock framework.
 
+config CLK_FIXED_RATE_KUNIT_TEST
+	tristate "Basic fixed rate clk type KUnit test" if !KUNIT_ALL_TESTS
+	depends on KUNIT
+	default KUNIT_ALL_TESTS
+	help
+	  KUnit tests for the basic fixed rate clk type.
+
 config CLK_GATE_KUNIT_TEST
 	tristate "Basic gate type Kunit test" if !KUNIT_ALL_TESTS
 	depends on KUNIT
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7efce649b0d3..e0689e9f73a4 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_CLK_KUNIT_TEST)	+= clk_test.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-divider.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-fixed-factor.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-fixed-rate.o
+obj-$(CONFIG_CLK_FIXED_RATE_KUNIT_TEST)	+= clk-fixed-rate_test.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-gate.o
 obj-$(CONFIG_CLK_GATE_KUNIT_TEST) += clk-gate_test.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-multiplier.o
diff --git a/drivers/clk/clk-fixed-rate_test.c b/drivers/clk/clk-fixed-rate_test.c
new file mode 100644
index 000000000000..82e9e59a327c
--- /dev/null
+++ b/drivers/clk/clk-fixed-rate_test.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for clk fixed rate basic type
+ */
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include <kunit/platform_driver.h>
+#include <kunit/resource.h>
+#include <kunit/test.h>
+
+#include "clk-kunit.h"
+
+/**
+ * struct kunit_clk_hw_fixed_rate_params - Parameters to pass to __clk_hw_register_fixed_rate()
+ * @dev: device registering clk
+ * @np: device_node of device registering clk
+ * @name: name of clk
+ * @parent_name: parent name of clk
+ * @parent_hw: clk_hw pointer to parent of clk
+ * @parent_data: parent_data describing parent of clk
+ * @flags: clk framework flags
+ * @fixed_rate: frequency of clk
+ * @fixed_accuracy: accuracy of clk
+ * @clk_fixed_flags: fixed rate specific clk flags
+ */
+struct kunit_clk_hw_fixed_rate_params {
+	struct device *dev;
+	struct device_node *np;
+	const char *name;
+	const char *parent_name;
+	const struct clk_hw *parent_hw;
+	const struct clk_parent_data *parent_data;
+	unsigned long flags;
+	unsigned long fixed_rate;
+	unsigned long fixed_accuracy;
+	unsigned long clk_fixed_flags;
+};
+
+static int
+kunit_clk_hw_register_fixed_rate_init(struct kunit_resource *res, void *context)
+{
+	struct kunit_clk_hw_fixed_rate_params *params = context;
+	struct clk_hw *hw;
+
+	hw = __clk_hw_register_fixed_rate(params->dev, params->np,
+					  params->name,
+					  params->parent_name,
+					  params->parent_hw,
+					  params->parent_data,
+					  params->flags,
+					  params->fixed_rate,
+					  params->fixed_accuracy,
+					  params->clk_fixed_flags,
+					  false);
+	if (IS_ERR(hw))
+		return PTR_ERR(hw);
+
+	res->data = hw;
+
+	return 0;
+}
+
+static void kunit_clk_hw_register_fixed_rate_free(struct kunit_resource *res)
+{
+	struct clk_hw *hw = res->data;
+
+	clk_hw_unregister_fixed_rate(hw);
+}
+
+/**
+ * kunit_clk_hw_register_fixed_rate() - Test managed __clk_hw_register_fixed_rate()
+ * @test: The test context
+ * @params: Arguments to __clk_hw_register_fixed_rate()
+ *
+ * Returns: registered fixed rate clk_hw or ERR_PTR on failure.
+ */
+static struct clk_hw *
+kunit_clk_hw_register_fixed_rate(struct kunit *test, struct kunit_clk_hw_fixed_rate_params *params)
+{
+	struct clk_hw *hw;
+
+	hw = kunit_alloc_resource(test,
+				  kunit_clk_hw_register_fixed_rate_init,
+				  kunit_clk_hw_register_fixed_rate_free,
+				  GFP_KERNEL, params);
+	if (!hw)
+		return ERR_PTR(-EINVAL);
+
+	return hw;
+}
+
+/**
+ * kunit_clk_hw_unregister_fixed_rate() - Test managed clk_hw_unregister_fixed_rate()
+ * @test: The test context
+ * @hw: fixed rate clk to unregister upon test completion
+ *
+ * Automatically unregister @hw when @test is complete via
+ * clk_hw_unregister_fixed_rate().
+ *
+ * Returns: 0 on success or negative errno on failure
+ */
+static int kunit_clk_hw_unregister_fixed_rate(struct kunit *test, struct clk_hw *hw)
+{
+	if (!kunit_alloc_resource(test, NULL,
+				  kunit_clk_hw_register_fixed_rate_free,
+				  GFP_KERNEL, hw))
+		return -ENOMEM;
+
+	return 0;
+}
+
+/*
+ * Test that clk_get_rate() on a fixed rate clk registered with
+ * clk_hw_register_fixed_rate() gets the proper frequency.
+ */
+static void clk_fixed_rate_rate_test(struct kunit *test)
+{
+	struct clk_hw *hw;
+	struct clk *clk;
+	const unsigned long fixed_rate = 230000;
+
+	hw = clk_hw_register_fixed_rate(NULL, "test-fixed-rate", NULL, 0, fixed_rate);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, hw);
+	KUNIT_ASSERT_EQ(test, 0, kunit_clk_hw_unregister_fixed_rate(test, hw));
+
+	clk = kunit_clk_hw_get_clk_prepared_enabled(test, hw, __func__);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, clk);
+
+	KUNIT_EXPECT_EQ(test, fixed_rate, clk_get_rate(clk));
+}
+
+/*
+ * Test that clk_get_accuracy() on a fixed rate clk registered via
+ * clk_hw_register_fixed_rate_with_accuracy() gets the proper accuracy.
+ */
+static void clk_fixed_rate_accuracy_test(struct kunit *test)
+{
+	struct clk_hw *hw;
+	struct clk *clk;
+	const unsigned long fixed_accuracy = 5000;
+
+	hw = clk_hw_register_fixed_rate_with_accuracy(NULL, "test-fixed-rate",
+						      NULL, 0, 0,
+						      fixed_accuracy);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, hw);
+	KUNIT_ASSERT_EQ(test, 0, kunit_clk_hw_unregister_fixed_rate(test, hw));
+
+	clk = kunit_clk_hw_get_clk(test, hw, __func__);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, clk);
+
+	KUNIT_EXPECT_EQ(test, fixed_accuracy, clk_get_accuracy(clk));
+}
+
+/*
+ * Test that clk_get_parent() on a fixed rate clk gets the proper parent.
+ */
+static void clk_fixed_rate_parent_test(struct kunit *test)
+{
+	struct clk_hw *hw, *parent_hw;
+	struct clk *expected_parent, *actual_parent;
+	struct clk *clk;
+	const char *parent_name = "test-fixed-rate-parent";
+	struct kunit_clk_hw_fixed_rate_params parent_params = {
+		.name = parent_name,
+	};
+
+	parent_hw = kunit_clk_hw_register_fixed_rate(test, &parent_params);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, parent_hw);
+	KUNIT_ASSERT_STREQ(test, parent_name, clk_hw_get_name(parent_hw));
+
+	expected_parent = kunit_clk_hw_get_clk(test, parent_hw, __func__);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, expected_parent);
+
+	hw = clk_hw_register_fixed_rate(NULL, "test-fixed-rate", parent_name, 0, 0);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, hw);
+	KUNIT_ASSERT_EQ(test, 0, kunit_clk_hw_unregister_fixed_rate(test, hw));
+
+	clk = kunit_clk_hw_get_clk(test, hw, __func__);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, clk);
+
+	actual_parent = clk_get_parent(clk);
+	KUNIT_EXPECT_TRUE(test, clk_is_match(expected_parent, actual_parent));
+}
+
+static struct kunit_case clk_fixed_rate_test_cases[] = {
+	KUNIT_CASE(clk_fixed_rate_rate_test),
+	KUNIT_CASE(clk_fixed_rate_accuracy_test),
+	KUNIT_CASE(clk_fixed_rate_parent_test),
+	{}
+};
+
+static struct kunit_suite clk_fixed_rate_suite = {
+	.name = "clk_fixed_rate",
+	.test_cases = clk_fixed_rate_test_cases,
+};
+
+struct clk_fixed_rate_of_test_context {
+	struct device *dev;
+	struct platform_driver pdrv;
+};
+
+static inline struct clk_fixed_rate_of_test_context *
+pdev_to_clk_fixed_rate_of_test_context(struct platform_device *pdev)
+{
+	return container_of(to_platform_driver(pdev->dev.driver),
+			    struct clk_fixed_rate_of_test_context,
+			    pdrv);
+}
+
+/*
+ * Test that of_fixed_clk_setup() registers a fixed rate clk with the proper
+ * rate.
+ */
+static void clk_fixed_rate_of_probe_test(struct kunit *test)
+{
+	struct clk_fixed_rate_of_test_context *ctx = test->priv;
+	struct device *dev = ctx->dev;
+	struct clk *clk;
+
+	clk = kunit_clk_get(test, dev, NULL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, clk);
+
+	KUNIT_ASSERT_EQ(test, 0, kunit_clk_prepare_enable(test, clk));
+	KUNIT_EXPECT_EQ(test, 50000000, clk_get_rate(clk));
+}
+
+/*
+ * Test that of_fixed_clk_setup() registers a fixed rate clk with the proper
+ * accuracy.
+ */
+static void clk_fixed_rate_of_accuracy_test(struct kunit *test)
+{
+	struct clk_fixed_rate_of_test_context *ctx = test->priv;
+	struct device *dev = ctx->dev;
+	struct clk *clk;
+
+	clk = kunit_clk_get(test, dev, NULL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, clk);
+
+	KUNIT_EXPECT_EQ(test, 300, clk_get_accuracy(clk));
+}
+
+static struct kunit_case clk_fixed_rate_of_cases[] = {
+	KUNIT_CASE(clk_fixed_rate_of_probe_test),
+	KUNIT_CASE(clk_fixed_rate_of_accuracy_test),
+	{}
+};
+
+static int clk_fixed_rate_of_test_probe(struct platform_device *pdev)
+{
+	struct clk_fixed_rate_of_test_context *ctx;
+
+	ctx = pdev_to_clk_fixed_rate_of_test_context(pdev);
+	ctx->dev = &pdev->dev;
+
+	return 0;
+}
+
+static int clk_fixed_rate_of_init(struct kunit *test)
+{
+	struct clk_fixed_rate_of_test_context *ctx;
+	static const struct of_device_id match_table[] = {
+		{ .compatible = "linux,clk-kunit-fixed-rate" },
+		{ }
+	};
+
+	if (!IS_ENABLED(CONFIG_OF_KUNIT))
+		kunit_skip(test, "requires CONFIG_OF_KUNIT");
+
+	ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+	test->priv = ctx;
+
+	ctx->pdrv.probe = clk_fixed_rate_of_test_probe;
+	ctx->pdrv.driver.of_match_table = match_table;
+	ctx->pdrv.driver.name = __func__;
+	ctx->pdrv.driver.owner = THIS_MODULE;
+
+	return kunit_platform_driver_register(test, &ctx->pdrv);
+}
+
+static struct kunit_suite clk_fixed_rate_of_suite = {
+	.name = "clk_fixed_rate_of",
+	.init = clk_fixed_rate_of_init,
+	.test_cases = clk_fixed_rate_of_cases,
+};
+
+kunit_test_suites(
+	&clk_fixed_rate_suite,
+	&clk_fixed_rate_of_suite,
+);
+MODULE_LICENSE("GPL");
diff --git a/drivers/of/kunit/clk.dtsi b/drivers/of/kunit/clk.dtsi
new file mode 100644
index 000000000000..e3466bcfeb4b
--- /dev/null
+++ b/drivers/of/kunit/clk.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+	fixed_50MHz: clock-50MHz {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <50000000>;
+		clock-accuracy = <300>;
+	};
+
+	clock-consumer-fixed-50 {
+		compatible = "linux,clk-kunit-fixed-rate";
+		clocks = <&fixed_50MHz>;
+	};
+};
diff --git a/drivers/of/kunit/kunit.dtsi b/drivers/of/kunit/kunit.dtsi
index 82f6c3e2b8d5..bce5bd8b9505 100644
--- a/drivers/of/kunit/kunit.dtsi
+++ b/drivers/of/kunit/kunit.dtsi
@@ -6,3 +6,4 @@ / {
 };
 
 /* Include testcase dtsi files below */
+#include "clk.dtsi"
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 7/8] dt-bindings: clk: Add KUnit clk_parent_data test

[Stephen Boyd]

Describe a binding for a device that provides and consumes clks in DT so
that a KUnit test can register clks based on the device node and test
clk_hw_register() with clk_parent_data.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
 .../clock/linux,clk-kunit-parent-data.yaml    | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/linux,clk-kunit-parent-data.yaml

diff --git a/Documentation/devicetree/bindings/clock/linux,clk-kunit-parent-data.yaml b/Documentation/devicetree/bindings/clock/linux,clk-kunit-parent-data.yaml
new file mode 100644
index 000000000000..29609e07c115
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/linux,clk-kunit-parent-data.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/linux,clk-kunit-parent-data.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: KUnit clk provider for clk_parent_data unit tests
+
+maintainers:
+  - Stephen Boyd <sboyd@kernel.org>
+
+description: |
+  A clk provider to test the struct clk_parent_data implementation in the Linux
+  kernel.
+
+properties:
+  compatible:
+    const: linux,clk-kunit-parent-data
+
+  clocks:
+    items:
+      - description: Fixed parent
+      - description: 50 MHz fixed parent
+
+  clock-names:
+    items:
+      - const: parent_fwname
+      - const: "50"
+
+  "#clock-cells":
+    const: 1
+
+required:
+  - compatible
+  - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    clock-controller {
+      compatible = "linux,clk-kunit-parent-data";
+      #clock-cells = <1>;
+      clocks = <&fixed_parent>, <&fixed_50MHz>;
+      clock-names = "parent_fwname", "50";
+    };
+...
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

[PATCH 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data

[Stephen Boyd]

Test that clks registered with 'struct clk_parent_data' work as
intended and can find their parents.

Cc: Christian Marangi <ansuelsmth@gmail.com>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
---
 drivers/clk/clk_test.c    | 456 +++++++++++++++++++++++++++++++++++++-
 drivers/of/kunit/clk.dtsi |  15 ++
 2 files changed, 470 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
index f9a5c2964c65..ad63958b809d 100644
--- a/drivers/clk/clk_test.c
+++ b/drivers/clk/clk_test.c
@@ -4,10 +4,14 @@
  */
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
 
 /* Needed for clk_hw_get_clk() */
 #include "clk.h"
+#include "clk-kunit.h"
 
+#include <kunit/platform_driver.h>
 #include <kunit/test.h>
 
 #define DUMMY_CLOCK_INIT_RATE	(42 * 1000 * 1000)
@@ -2394,6 +2398,454 @@ static struct kunit_suite clk_mux_notifier_test_suite = {
 	.test_cases = clk_mux_notifier_test_cases,
 };
 
+struct clk_register_clk_parent_data_test_case {
+	const char *desc;
+	struct clk_parent_data pdata;
+};
+
+static void
+clk_register_clk_parent_data_test_case_to_desc(
+		const struct clk_register_clk_parent_data_test_case *t, char *desc)
+{
+	strcpy(desc, t->desc);
+}
+
+static const struct clk_register_clk_parent_data_test_case
+clk_register_clk_parent_data_of_cases[] = {
+	{
+		/*
+		 * Test that a clk registered with a struct device_node can
+		 * find a parent based on struct clk_parent_data::index.
+		 */
+		.desc = "clk_parent_data_of_index_test",
+		.pdata.index = 0,
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device_node can
+		 * find a parent based on struct clk_parent_data::fwname.
+		 */
+		.desc = "clk_parent_data_of_fwname_test",
+		.pdata.fw_name = "parent_fwname",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device_node can
+		 * find a parent based on struct clk_parent_data::name.
+		 */
+		.desc = "clk_parent_data_of_name_test",
+		/* The index must be negative to indicate firmware not used */
+		.pdata.index = -1,
+		.pdata.name = "1mhz_fixed_legacy",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device_node can
+		 * find a parent based on struct
+		 * clk_parent_data::{fw_name,name}.
+		 */
+		.desc = "clk_parent_data_of_fwname_name_test",
+		.pdata.fw_name = "parent_fwname",
+		.pdata.name = "not_matching",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device_node can
+		 * find a parent based on struct clk_parent_data::{index,name}.
+		 * Index takes priority.
+		 */
+		.desc = "clk_parent_data_of_index_name_priority_test",
+		.pdata.index = 0,
+		.pdata.name = "not_matching",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device_node can
+		 * find a parent based on struct
+		 * clk_parent_data::{index,fwname,name}. The fw_name takes
+		 * priority over index and name.
+		 */
+		.desc = "clk_parent_data_of_index_fwname_name_priority_test",
+		.pdata.index = 1,
+		.pdata.fw_name = "parent_fwname",
+		.pdata.name = "not_matching",
+	},
+};
+
+KUNIT_ARRAY_PARAM(clk_register_clk_parent_data_of_test, clk_register_clk_parent_data_of_cases,
+		  clk_register_clk_parent_data_test_case_to_desc)
+
+/**
+ * struct clk_register_clk_parent_data_of_ctx - Context for clk_parent_data OF tests
+ * @np: device node of clk under test
+ * @hw: clk_hw for clk under test
+ */
+struct clk_register_clk_parent_data_of_ctx {
+	struct device_node *np;
+	struct clk_hw hw;
+};
+
+static int clk_register_clk_parent_data_of_test_init(struct kunit *test)
+{
+	struct clk_register_clk_parent_data_of_ctx *ctx;
+
+	if (!IS_ENABLED(CONFIG_OF_KUNIT))
+		kunit_skip(test, "requires CONFIG_OF_KUNIT");
+
+	ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+	test->priv = ctx;
+
+	ctx->np = of_find_compatible_node(NULL, NULL, "linux,clk-kunit-parent-data");
+	if (!ctx->np)
+		return -ENODEV;
+
+	return 0;
+}
+
+static void clk_register_clk_parent_data_of_test_exit(struct kunit *test)
+{
+	struct clk_register_clk_parent_data_of_ctx *ctx = test->priv;
+
+	of_node_put(ctx->np);
+}
+
+/*
+ * Test that a clk registered with a struct device_node can find a parent based on
+ * struct clk_parent_data when the hw member isn't set.
+ */
+static void clk_register_clk_parent_data_of_test(struct kunit *test)
+{
+	struct clk_register_clk_parent_data_of_ctx *ctx = test->priv;
+	struct clk_hw *parent_hw;
+	const struct clk_register_clk_parent_data_test_case *test_param;
+	struct clk_init_data init = { };
+	struct clk *expected_parent, *actual_parent;
+
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->np);
+
+	expected_parent = kunit_of_clk_get(test, ctx->np, 0);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, expected_parent);
+
+	test_param = test->param_value;
+	init.parent_data = &test_param->pdata;
+	init.num_parents = 1;
+	init.name = "parent_data_of_test_clk";
+	init.ops = &clk_dummy_single_parent_ops;
+	ctx->hw.init = &init;
+	KUNIT_ASSERT_EQ(test, 0, kunit_of_clk_hw_register(test, ctx->np, &ctx->hw));
+
+	parent_hw = clk_hw_get_parent(&ctx->hw);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, parent_hw);
+
+	actual_parent = kunit_clk_hw_get_clk(test, parent_hw, __func__);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, actual_parent);
+
+	KUNIT_EXPECT_TRUE(test, clk_is_match(expected_parent, actual_parent));
+}
+
+static struct kunit_case clk_register_clk_parent_data_of_test_cases[] = {
+	KUNIT_CASE_PARAM(clk_register_clk_parent_data_of_test,
+			 clk_register_clk_parent_data_of_test_gen_params),
+	{}
+};
+
+/*
+ * Test suite for registering clks with struct clk_parent_data and a struct
+ * device_node.
+ */
+static struct kunit_suite clk_register_clk_parent_data_of_suite = {
+	.name = "clk_register_clk_parent_data_of",
+	.init = clk_register_clk_parent_data_of_test_init,
+	.exit = clk_register_clk_parent_data_of_test_exit,
+	.test_cases = clk_register_clk_parent_data_of_test_cases,
+};
+
+/**
+ * struct clk_register_clk_parent_data_device_ctx - Context for clk_parent_data device tests
+ * @dev: device of clk under test
+ * @hw: clk_hw for clk under test
+ * @pdrv: driver to attach to find @dev
+ */
+struct clk_register_clk_parent_data_device_ctx {
+	struct device *dev;
+	struct clk_hw hw;
+	struct platform_driver pdrv;
+};
+
+static inline struct clk_register_clk_parent_data_device_ctx *
+clk_register_clk_parent_data_driver_to_test_context(struct platform_device *pdev)
+{
+	return container_of(to_platform_driver(pdev->dev.driver),
+			    struct clk_register_clk_parent_data_device_ctx, pdrv);
+}
+
+static int clk_register_clk_parent_data_device_probe(struct platform_device *pdev)
+{
+	struct clk_register_clk_parent_data_device_ctx *ctx;
+
+	ctx = clk_register_clk_parent_data_driver_to_test_context(pdev);
+	ctx->dev = &pdev->dev;
+
+	return 0;
+}
+
+static void clk_register_clk_parent_data_device_driver(struct kunit *test)
+{
+	struct clk_register_clk_parent_data_device_ctx *ctx = test->priv;
+	static const struct of_device_id match_table[] = {
+		{ .compatible = "linux,clk-kunit-parent-data" },
+		{ }
+	};
+
+	ctx->pdrv.probe = clk_register_clk_parent_data_device_probe;
+	ctx->pdrv.driver.of_match_table = match_table;
+	ctx->pdrv.driver.name = __func__;
+	ctx->pdrv.driver.owner = THIS_MODULE;
+
+	KUNIT_ASSERT_EQ(test, 0, kunit_platform_driver_register(test, &ctx->pdrv));
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->dev);
+}
+
+static const struct clk_register_clk_parent_data_test_case
+clk_register_clk_parent_data_device_cases[] = {
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::index.
+		 */
+		.desc = "clk_parent_data_device_index_test",
+		.pdata.index = 1,
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::fwname.
+		 */
+		.desc = "clk_parent_data_device_fwname_test",
+		.pdata.fw_name = "50",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::name.
+		 */
+		.desc = "clk_parent_data_device_name_test",
+		/* The index must be negative to indicate firmware not used */
+		.pdata.index = -1,
+		.pdata.name = "50_clk",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::{fw_name,name}.
+		 */
+		.desc = "clk_parent_data_device_fwname_name_test",
+		.pdata.fw_name = "50",
+		.pdata.name = "not_matching",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::{index,name}. Index
+		 * takes priority.
+		 */
+		.desc = "clk_parent_data_device_index_name_priority_test",
+		.pdata.index = 1,
+		.pdata.name = "not_matching",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::{index,fwname,name}.
+		 * The fw_name takes priority over index and name.
+		 */
+		.desc = "clk_parent_data_device_index_fwname_name_priority_test",
+		.pdata.index = 0,
+		.pdata.fw_name = "50",
+		.pdata.name = "not_matching",
+	},
+};
+
+KUNIT_ARRAY_PARAM(clk_register_clk_parent_data_device_test,
+		  clk_register_clk_parent_data_device_cases,
+		  clk_register_clk_parent_data_test_case_to_desc)
+
+/*
+ * Test that a clk registered with a struct device can find a parent based on
+ * struct clk_parent_data when the hw member isn't set.
+ */
+static void clk_register_clk_parent_data_device_test(struct kunit *test)
+{
+	struct clk_register_clk_parent_data_device_ctx *ctx;
+	const struct clk_register_clk_parent_data_test_case *test_param;
+	struct clk_hw *parent_hw;
+	struct clk_init_data init = { };
+	struct clk *expected_parent, *actual_parent;
+
+	ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+	test->priv = ctx;
+
+	clk_register_clk_parent_data_device_driver(test);
+
+	expected_parent = kunit_clk_get(test, ctx->dev, "50");
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, expected_parent);
+
+	test_param = test->param_value;
+	init.parent_data = &test_param->pdata;
+	init.num_parents = 1;
+	init.name = "parent_data_device_test_clk";
+	init.ops = &clk_dummy_single_parent_ops;
+	ctx->hw.init = &init;
+	KUNIT_ASSERT_EQ(test, 0, kunit_clk_hw_register(test, ctx->dev, &ctx->hw));
+
+	parent_hw = clk_hw_get_parent(&ctx->hw);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, parent_hw);
+
+	actual_parent = kunit_clk_hw_get_clk(test, parent_hw, __func__);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, actual_parent);
+
+	KUNIT_EXPECT_TRUE(test, clk_is_match(expected_parent, actual_parent));
+}
+
+static const struct clk_register_clk_parent_data_test_case
+clk_register_clk_parent_data_device_hw_cases[] = {
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::hw.
+		 */
+		.desc = "clk_parent_data_device_hw_index_test",
+		/* The index must be negative to indicate firmware not used */
+		.pdata.index = -1,
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::hw when
+		 * struct clk_parent_data::fw_name is set.
+		 */
+		.desc = "clk_parent_data_device_hw_fwname_test",
+		.pdata.fw_name = "50",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::hw when struct
+		 * clk_parent_data::name is set.
+		 */
+		.desc = "clk_parent_data_device_hw_name_test",
+		/* The index must be negative to indicate firmware not used */
+		.pdata.index = -1,
+		.pdata.name = "50_clk",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::hw when struct
+		 * clk_parent_data::{fw_name,name} are set.
+		 */
+		.desc = "clk_parent_data_device_hw_fwname_name_test",
+		.pdata.fw_name = "50",
+		.pdata.name = "not_matching",
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::hw when struct
+		 * clk_parent_data::index is set. The hw pointer takes
+		 * priority.
+		 */
+		.desc = "clk_parent_data_device_hw_index_priority_test",
+		.pdata.index = 0,
+	},
+	{
+		/*
+		 * Test that a clk registered with a struct device can find a
+		 * parent based on struct clk_parent_data::hw when
+		 * struct clk_parent_data::{index,fwname,name} are set.
+		 * The hw pointer takes priority over everything else.
+		 */
+		.desc = "clk_parent_data_device_hw_index_fwname_name_priority_test",
+		.pdata.index = 0,
+		.pdata.fw_name = "50",
+		.pdata.name = "not_matching",
+	},
+};
+
+KUNIT_ARRAY_PARAM(clk_register_clk_parent_data_device_hw_test,
+		  clk_register_clk_parent_data_device_hw_cases,
+		  clk_register_clk_parent_data_test_case_to_desc)
+
+/*
+ * Test that a clk registered with a struct device can find a
+ * parent based on struct clk_parent_data::hw.
+ */
+static void clk_register_clk_parent_data_device_hw_test(struct kunit *test)
+{
+	struct clk_register_clk_parent_data_device_ctx *ctx;
+	const struct clk_register_clk_parent_data_test_case *test_param;
+	struct clk_dummy_context *parent;
+	struct clk_hw *parent_hw;
+	struct clk_parent_data pdata = { };
+	struct clk_init_data init = { };
+
+	ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
+	test->priv = ctx;
+
+	clk_register_clk_parent_data_device_driver(test);
+
+	parent = kunit_kzalloc(test, sizeof(*parent), GFP_KERNEL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, parent);
+
+	parent_hw = &parent->hw;
+	parent_hw->init = CLK_HW_INIT_NO_PARENT("parent-clk",
+						&clk_dummy_rate_ops, 0);
+
+	KUNIT_ASSERT_EQ(test, 0, kunit_clk_hw_register(test, ctx->dev, parent_hw));
+
+	test_param = test->param_value;
+	memcpy(&pdata, &test_param->pdata, sizeof(pdata));
+	pdata.hw = parent_hw;
+	init.parent_data = &pdata;
+	init.num_parents = 1;
+	init.ops = &clk_dummy_single_parent_ops;
+	init.name = "parent_data_device_hw_test_clk";
+	ctx->hw.init = &init;
+	KUNIT_ASSERT_EQ(test, 0, kunit_clk_hw_register(test, ctx->dev, &ctx->hw));
+
+	KUNIT_EXPECT_PTR_EQ(test, parent_hw, clk_hw_get_parent(&ctx->hw));
+}
+
+static struct kunit_case clk_register_clk_parent_data_device_test_cases[] = {
+	KUNIT_CASE_PARAM(clk_register_clk_parent_data_device_test,
+			 clk_register_clk_parent_data_device_test_gen_params),
+	KUNIT_CASE_PARAM(clk_register_clk_parent_data_device_hw_test,
+			 clk_register_clk_parent_data_device_hw_test_gen_params),
+	{}
+};
+
+static int clk_register_clk_parent_data_device_init(struct kunit *test)
+{
+	if (!IS_ENABLED(CONFIG_OF_KUNIT))
+		kunit_skip(test, "requires CONFIG_OF_KUNIT");
+
+	return 0;
+}
+
+/*
+ * Test suite for registering clks with struct clk_parent_data and a struct
+ * device.
+ */
+static struct kunit_suite clk_register_clk_parent_data_device_suite = {
+	.name = "clk_register_clk_parent_data_device",
+	.init = clk_register_clk_parent_data_device_init,
+	.test_cases = clk_register_clk_parent_data_device_test_cases,
+};
+
 kunit_test_suites(
 	&clk_leaf_mux_set_rate_parent_test_suite,
 	&clk_test_suite,
@@ -2405,7 +2857,9 @@ kunit_test_suites(
 	&clk_range_test_suite,
 	&clk_range_maximize_test_suite,
 	&clk_range_minimize_test_suite,
+	&clk_register_clk_parent_data_of_suite,
+	&clk_register_clk_parent_data_device_suite,
 	&clk_single_parent_mux_test_suite,
-	&clk_uncached_test_suite
+	&clk_uncached_test_suite,
 );
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/of/kunit/clk.dtsi b/drivers/of/kunit/clk.dtsi
index e3466bcfeb4b..4ac14dd78063 100644
--- a/drivers/of/kunit/clk.dtsi
+++ b/drivers/of/kunit/clk.dtsi
@@ -6,10 +6,25 @@ fixed_50MHz: clock-50MHz {
 		#clock-cells = <0>;
 		clock-frequency = <50000000>;
 		clock-accuracy = <300>;
+		clock-output-names = "50_clk";
 	};
 
 	clock-consumer-fixed-50 {
 		compatible = "linux,clk-kunit-fixed-rate";
 		clocks = <&fixed_50MHz>;
 	};
+
+	fixed_parent: clock-1MHz {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1000000>;
+		clock-output-names = "1mhz_fixed_legacy";
+	};
+
+	clock-provider-of {
+		compatible = "linux,clk-kunit-parent-data";
+		clocks = <&fixed_parent>, <&fixed_50MHz>;
+		clock-names = "parent_fwname", "50";
+		#clock-cells = <1>;
+	};
 };
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[David Gow]

[-- Attachment #1.1: Type: text/plain, Size: 5227 bytes --]

On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>
> This patch series adds unit tests for the clk fixed rate basic type and
> the clk registration functions that use struct clk_parent_data. To get
> there, we add support for loading a DTB into the UML kernel that's
> running the unit tests along with probing platform drivers to bind to
> device nodes specified in DT.
>
> With this series, we're able to exercise some of the code in the common
> clk framework that uses devicetree lookups to find parents and the fixed
> rate clk code that scans devicetree directly and creates clks. Please
> review.
>

Thanks Stephen -- this is really neat!

This works well here, and I love all of the tests for the
KUnit/device-tree integration as well.

I'm still looking through the details of it (alas, I've mostly lived
in x86-land, so my device-tree knowledge is, uh, spotty to say the
least), but apart from possibly renaming some things or similarly
minor tweaks, I've not got any real suggestions thus far.

I do wonder whether we'll want, on the KUnit side, to have some way of
supporting KUnit device trees on non-UML architecctures (e.g., if we
need to test something architecture-specific, or on a big-endian
platform, etc), but I think that's a question for the future, rather
than something that affects this series.

Similarly, I wonder if there's something we could do with device tree
overlays, in order to make it possible for tests to swap nodes in and
out for testing.

I don't think either of those ideas should block this from getting in though.

> I Cced everyone to all the patches so they get the full context. I'm
> hoping I can take the whole pile through the clk tree as they almost all
> depend on each other. In the future I imagine it will be easy to add
> more test nodes to the clk.dtsi file and not need to go across various
> maintainer trees like this series does.

That seems pretty sensible to me. I expect there'll be a few minor
conflicts on the KUnit side (there are a bunch of small
lib/kunit/Makefile changes in 6.3, and there's a plan to do some more
serious changes to the kunit_resource API at some point, though I have
my doubts they'll all hit in 6.4), but I doubt they'll cause too much
strife.

Cheers,
-- David

>
> Stephen Boyd (8):
>   dt-bindings: Add linux,kunit binding
>   of: Enable DTB loading on UML for KUnit tests
>   kunit: Add test managed platform_device/driver APIs
>   clk: Add test managed clk provider/consumer APIs
>   dt-bindings: kunit: Add fixed rate clk consumer test
>   clk: Add KUnit tests for clk fixed rate basic type
>   dt-bindings: clk: Add KUnit clk_parent_data test
>   clk: Add KUnit tests for clks registered with struct clk_parent_data
>
>  .../clock/linux,clk-kunit-parent-data.yaml    |  47 ++
>  .../kunit/linux,clk-kunit-fixed-rate.yaml     |  35 ++
>  .../bindings/kunit/linux,kunit.yaml           |  24 +
>  arch/um/kernel/dtb.c                          |  29 +-
>  drivers/clk/.kunitconfig                      |   3 +
>  drivers/clk/Kconfig                           |   7 +
>  drivers/clk/Makefile                          |   6 +
>  drivers/clk/clk-fixed-rate_test.c             | 296 ++++++++++++
>  drivers/clk/clk-kunit.c                       | 204 ++++++++
>  drivers/clk/clk-kunit.h                       |  28 ++
>  drivers/clk/clk_test.c                        | 456 +++++++++++++++++-
>  drivers/of/Kconfig                            |  26 +
>  drivers/of/Makefile                           |   1 +
>  drivers/of/kunit/.kunitconfig                 |   4 +
>  drivers/of/kunit/Makefile                     |   4 +
>  drivers/of/kunit/clk.dtsi                     |  30 ++
>  drivers/of/kunit/kunit.dtsi                   |   9 +
>  drivers/of/kunit/kunit.dtso                   |   4 +
>  drivers/of/kunit/uml_dtb_test.c               |  55 +++
>  include/kunit/platform_driver.h               |  15 +
>  lib/kunit/Makefile                            |   6 +
>  lib/kunit/platform_driver-test.c              | 107 ++++
>  lib/kunit/platform_driver.c                   | 207 ++++++++
>  23 files changed, 1599 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/linux,clk-kunit-parent-data.yaml
>  create mode 100644 Documentation/devicetree/bindings/kunit/linux,clk-kunit-fixed-rate.yaml
>  create mode 100644 Documentation/devicetree/bindings/kunit/linux,kunit.yaml
>  create mode 100644 drivers/clk/clk-fixed-rate_test.c
>  create mode 100644 drivers/clk/clk-kunit.c
>  create mode 100644 drivers/clk/clk-kunit.h
>  create mode 100644 drivers/of/kunit/.kunitconfig
>  create mode 100644 drivers/of/kunit/Makefile
>  create mode 100644 drivers/of/kunit/clk.dtsi
>  create mode 100644 drivers/of/kunit/kunit.dtsi
>  create mode 100644 drivers/of/kunit/kunit.dtso
>  create mode 100644 drivers/of/kunit/uml_dtb_test.c
>  create mode 100644 include/kunit/platform_driver.h
>  create mode 100644 lib/kunit/platform_driver-test.c
>  create mode 100644 lib/kunit/platform_driver.c
>
>
> base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c
> --
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
> https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
>

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Rob Herring]

On Wed, Mar 1, 2023 at 7:38 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> This patch series adds unit tests for the clk fixed rate basic type and
> the clk registration functions that use struct clk_parent_data. To get
> there, we add support for loading a DTB into the UML kernel that's
> running the unit tests along with probing platform drivers to bind to
> device nodes specified in DT.
>
> With this series, we're able to exercise some of the code in the common
> clk framework that uses devicetree lookups to find parents and the fixed
> rate clk code that scans devicetree directly and creates clks. Please
> review.
>
> I Cced everyone to all the patches so they get the full context. I'm
> hoping I can take the whole pile through the clk tree as they almost all
> depend on each other. In the future I imagine it will be easy to add
> more test nodes to the clk.dtsi file and not need to go across various
> maintainer trees like this series does.
>
> Stephen Boyd (8):
>   dt-bindings: Add linux,kunit binding
>   of: Enable DTB loading on UML for KUnit tests
>   kunit: Add test managed platform_device/driver APIs
>   clk: Add test managed clk provider/consumer APIs
>   dt-bindings: kunit: Add fixed rate clk consumer test
>   clk: Add KUnit tests for clk fixed rate basic type
>   dt-bindings: clk: Add KUnit clk_parent_data test
>   clk: Add KUnit tests for clks registered with struct clk_parent_data

Good to see bindings for this. I've been meaning to do something about
the DT unittest ones being undocumented, but I hadn't really decided
whether it was worth writing schemas for them. The compatibles at
least show up with 'make dt_compatible_check'. Perhaps we want to just
define some vendor (not 'linux') that's an exception rather than
requiring schemas (actually, that already works for 'foo'). It's
likely that we want test DTs that fail normal checks and schemas get
in the way of that as we don't have a way to turn off checks.

We already have GPIO tests in the DT unittests, so why is clocks
different? Or should the GPIO tests be moved out (yes, please!)?

What happens when/if the DT unittest is converted to kunit? I think
that would look confusing from the naming. My initial thought is
'kunit' should be dropped from the naming of a lot of this. Note that
the original kunit submission converted the DT unittests. I would
still like to see that happen. Frank disagreed over what's a unit test
or not, then agreed, then didn't... I don't really care. If there's a
framework to use, then we should use it IMO.

>
>  .../clock/linux,clk-kunit-parent-data.yaml    |  47 ++
>  .../kunit/linux,clk-kunit-fixed-rate.yaml     |  35 ++
>  .../bindings/kunit/linux,kunit.yaml           |  24 +
>  arch/um/kernel/dtb.c                          |  29 +-
>  drivers/clk/.kunitconfig                      |   3 +
>  drivers/clk/Kconfig                           |   7 +
>  drivers/clk/Makefile                          |   6 +
>  drivers/clk/clk-fixed-rate_test.c             | 296 ++++++++++++
>  drivers/clk/clk-kunit.c                       | 204 ++++++++
>  drivers/clk/clk-kunit.h                       |  28 ++
>  drivers/clk/clk_test.c                        | 456 +++++++++++++++++-
>  drivers/of/Kconfig                            |  26 +
>  drivers/of/Makefile                           |   1 +
>  drivers/of/kunit/.kunitconfig                 |   4 +
>  drivers/of/kunit/Makefile                     |   4 +
>  drivers/of/kunit/clk.dtsi                     |  30 ++
>  drivers/of/kunit/kunit.dtsi                   |   9 +
>  drivers/of/kunit/kunit.dtso                   |   4 +
>  drivers/of/kunit/uml_dtb_test.c               |  55 +++
>  include/kunit/platform_driver.h               |  15 +
>  lib/kunit/Makefile                            |   6 +
>  lib/kunit/platform_driver-test.c              | 107 ++++
>  lib/kunit/platform_driver.c                   | 207 ++++++++

Humm, we have DT platform driver unittests too. What's the difference?

Anyways, that's all just my initial reaction from only halfway looking
at this. :)

Rob

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Rob Herring]

On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
>
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > This patch series adds unit tests for the clk fixed rate basic type and
> > the clk registration functions that use struct clk_parent_data. To get
> > there, we add support for loading a DTB into the UML kernel that's
> > running the unit tests along with probing platform drivers to bind to
> > device nodes specified in DT.
> >
> > With this series, we're able to exercise some of the code in the common
> > clk framework that uses devicetree lookups to find parents and the fixed
> > rate clk code that scans devicetree directly and creates clks. Please
> > review.
> >
>
> Thanks Stephen -- this is really neat!
>
> This works well here, and I love all of the tests for the
> KUnit/device-tree integration as well.
>
> I'm still looking through the details of it (alas, I've mostly lived
> in x86-land, so my device-tree knowledge is, uh, spotty to say the
> least), but apart from possibly renaming some things or similarly
> minor tweaks, I've not got any real suggestions thus far.
>
> I do wonder whether we'll want, on the KUnit side, to have some way of
> supporting KUnit device trees on non-UML architecctures (e.g., if we
> need to test something architecture-specific, or on a big-endian
> platform, etc), but I think that's a question for the future, rather
> than something that affects this series.

I'll say that's a requirement. We should be able to structure the
tests to not interfere with the running system's DT. The DT unittest
does that.

As a side topic, Is anyone looking at getting UML to work on arm64?
It's surprising how much x86 stuff there is which is I guess one
reason it hasn't happened.

> Similarly, I wonder if there's something we could do with device tree
> overlays, in order to make it possible for tests to swap nodes in and
> out for testing.

Yes, that's how the DT unittest works. But it is pretty much one big
overlay (ignoring the overlay tests). It could probably be more
modular where it is apply overlay, test, remove overlay, repeat.

Rob

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Stephen Boyd]

Quoting Rob Herring (2023-03-02 09:32:09)
> On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
> >
> > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > This patch series adds unit tests for the clk fixed rate basic type and
> > > the clk registration functions that use struct clk_parent_data. To get
> > > there, we add support for loading a DTB into the UML kernel that's
> > > running the unit tests along with probing platform drivers to bind to
> > > device nodes specified in DT.
> > >
> > > With this series, we're able to exercise some of the code in the common
> > > clk framework that uses devicetree lookups to find parents and the fixed
> > > rate clk code that scans devicetree directly and creates clks. Please
> > > review.
> > >
> >
> > Thanks Stephen -- this is really neat!
> >
> > This works well here, and I love all of the tests for the
> > KUnit/device-tree integration as well.
> >
> > I'm still looking through the details of it (alas, I've mostly lived
> > in x86-land, so my device-tree knowledge is, uh, spotty to say the
> > least), but apart from possibly renaming some things or similarly
> > minor tweaks, I've not got any real suggestions thus far.
> >
> > I do wonder whether we'll want, on the KUnit side, to have some way of
> > supporting KUnit device trees on non-UML architecctures (e.g., if we
> > need to test something architecture-specific, or on a big-endian
> > platform, etc), but I think that's a question for the future, rather
> > than something that affects this series.
> 
> I'll say that's a requirement. We should be able to structure the
> tests to not interfere with the running system's DT. The DT unittest
> does that.

That could be another choice in the unit test choice menu.
CONFIG_OF_KUNIT_NOT_UML that injects some built-in DTB overlay on an
architecture that wants to run tests.

> 
> As a side topic, Is anyone looking at getting UML to work on arm64?
> It's surprising how much x86 stuff there is which is I guess one
> reason it hasn't happened.

I've no idea but it would be nice indeed.

> 
> > Similarly, I wonder if there's something we could do with device tree
> > overlays, in order to make it possible for tests to swap nodes in and
> > out for testing.
> 
> Yes, that's how the DT unittest works. But it is pretty much one big
> overlay (ignoring the overlay tests). It could probably be more
> modular where it is apply overlay, test, remove overlay, repeat.
> 

I didn't want to rely on the overlay code to inject DT nodes. Having
tests written for the fake KUnit machine is simple. It closely matches
how clk code probes the DTB and how nodes are created and populated on
the platform bus as devices. CLK_OF_DECLARE() would need the overlay to
be applied early too, which doesn't happen otherwise as far as I know.

But perhaps this design is too much of an end-to-end test and not a unit
test? In the spirit of unit testing we shouldn't care about how the node
is added to the live devicetree, just that there is a devicetree at all.

Supporting overlays to more easily test combinations sounds like a good
idea. Probably some kunit_*() prefixed functions could be used to
apply a test managed overlay and automatically remove it when the test
is over would work. The clk registration tests could use this API to
inject an overlay and then manually call the of_platform_populate()
function to create the platform device(s). The overlay could be built in
drivers/clk/ too and then probably some macroish function can find the
blob and apply it.

Is there some way to delete the platform devices that we populate from
the overlay? I'd like the tests to be hermetic.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Stephen Boyd]

Quoting Rob Herring (2023-03-02 09:13:59)
> On Wed, Mar 1, 2023 at 7:38 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > This patch series adds unit tests for the clk fixed rate basic type and
> > the clk registration functions that use struct clk_parent_data. To get
> > there, we add support for loading a DTB into the UML kernel that's
> > running the unit tests along with probing platform drivers to bind to
> > device nodes specified in DT.
> >
> > With this series, we're able to exercise some of the code in the common
> > clk framework that uses devicetree lookups to find parents and the fixed
> > rate clk code that scans devicetree directly and creates clks. Please
> > review.
> >
> > I Cced everyone to all the patches so they get the full context. I'm
> > hoping I can take the whole pile through the clk tree as they almost all
> > depend on each other. In the future I imagine it will be easy to add
> > more test nodes to the clk.dtsi file and not need to go across various
> > maintainer trees like this series does.
> >
> > Stephen Boyd (8):
> >   dt-bindings: Add linux,kunit binding
> >   of: Enable DTB loading on UML for KUnit tests
> >   kunit: Add test managed platform_device/driver APIs
> >   clk: Add test managed clk provider/consumer APIs
> >   dt-bindings: kunit: Add fixed rate clk consumer test
> >   clk: Add KUnit tests for clk fixed rate basic type
> >   dt-bindings: clk: Add KUnit clk_parent_data test
> >   clk: Add KUnit tests for clks registered with struct clk_parent_data
> 
> Good to see bindings for this. I've been meaning to do something about
> the DT unittest ones being undocumented, but I hadn't really decided
> whether it was worth writing schemas for them. The compatibles at
> least show up with 'make dt_compatible_check'. Perhaps we want to just
> define some vendor (not 'linux') that's an exception rather than
> requiring schemas (actually, that already works for 'foo').

Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?

> It's
> likely that we want test DTs that fail normal checks and schemas get
> in the way of that as we don't have a way to turn off checks.

Having the schemas is nice to make sure tests that are expecting some
binding are actually getting that. But supporting broken bindings is
also important to test any error paths in functions that parse
properties. Maybe we keep the schema and have it enforce that incorrect
properties are being set?

Do we really need to test incorrect bindings? Doesn't the
dt_bindings_check catch these problems so we don't have to write DTB
verifiers in the kernel?

> 
> We already have GPIO tests in the DT unittests, so why is clocks
> different? Or should the GPIO tests be moved out (yes, please!)?

Ah I didn't notice the GPIO tests in there. There are i2c tests too,
right? All I can say is clks are using kunit, that's the difference ;-)

> 
> What happens when/if the DT unittest is converted to kunit? I think
> that would look confusing from the naming. My initial thought is
> 'kunit' should be dropped from the naming of a lot of this. Note that
> the original kunit submission converted the DT unittests. I would
> still like to see that happen. Frank disagreed over what's a unit test
> or not, then agreed, then didn't... I don't really care. If there's a
> framework to use, then we should use it IMO.

Honestly I don't want to get involved in migrating the existing DT
unittest code to kunit. I'm aware that it was attempted years ago when
kunit was introduced. Maybe if the overlay route works well enough I can
completely sidestep introducing any code in drivers/of/ besides some
kunit wrappers for this. I'll cross my fingers!

> 
> >
> >  .../clock/linux,clk-kunit-parent-data.yaml    |  47 ++
> >  .../kunit/linux,clk-kunit-fixed-rate.yaml     |  35 ++
> >  .../bindings/kunit/linux,kunit.yaml           |  24 +
> >  arch/um/kernel/dtb.c                          |  29 +-
> >  drivers/clk/.kunitconfig                      |   3 +
> >  drivers/clk/Kconfig                           |   7 +
> >  drivers/clk/Makefile                          |   6 +
> >  drivers/clk/clk-fixed-rate_test.c             | 296 ++++++++++++
> >  drivers/clk/clk-kunit.c                       | 204 ++++++++
> >  drivers/clk/clk-kunit.h                       |  28 ++
> >  drivers/clk/clk_test.c                        | 456 +++++++++++++++++-
> >  drivers/of/Kconfig                            |  26 +
> >  drivers/of/Makefile                           |   1 +
> >  drivers/of/kunit/.kunitconfig                 |   4 +
> >  drivers/of/kunit/Makefile                     |   4 +
> >  drivers/of/kunit/clk.dtsi                     |  30 ++
> >  drivers/of/kunit/kunit.dtsi                   |   9 +
> >  drivers/of/kunit/kunit.dtso                   |   4 +
> >  drivers/of/kunit/uml_dtb_test.c               |  55 +++
> >  include/kunit/platform_driver.h               |  15 +
> >  lib/kunit/Makefile                            |   6 +
> >  lib/kunit/platform_driver-test.c              | 107 ++++
> >  lib/kunit/platform_driver.c                   | 207 ++++++++
> 
> Humm, we have DT platform driver unittests too. What's the difference?

Yes, I added unit tests for the kunit platform device/driver wrappers
added in this series.

> 
> Anyways, that's all just my initial reaction from only halfway looking
> at this. :)

Thanks for taking the time to review even halfway.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Geert Uytterhoeven]

Hi Stephen,

On Thu, Mar 2, 2023 at 8:28 PM Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Rob Herring (2023-03-02 09:32:09)
> > On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
> > > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> > > > This patch series adds unit tests for the clk fixed rate basic type and
> > > > the clk registration functions that use struct clk_parent_data. To get
> > > > there, we add support for loading a DTB into the UML kernel that's
> > > > running the unit tests along with probing platform drivers to bind to
> > > > device nodes specified in DT.
> > > >
> > > > With this series, we're able to exercise some of the code in the common
> > > > clk framework that uses devicetree lookups to find parents and the fixed
> > > > rate clk code that scans devicetree directly and creates clks. Please
> > > > review.
> > > >
> > >
> > > Thanks Stephen -- this is really neat!
> > >
> > > This works well here, and I love all of the tests for the
> > > KUnit/device-tree integration as well.
> > >
> > > I'm still looking through the details of it (alas, I've mostly lived
> > > in x86-land, so my device-tree knowledge is, uh, spotty to say the
> > > least), but apart from possibly renaming some things or similarly
> > > minor tweaks, I've not got any real suggestions thus far.
> > >
> > > I do wonder whether we'll want, on the KUnit side, to have some way of
> > > supporting KUnit device trees on non-UML architecctures (e.g., if we
> > > need to test something architecture-specific, or on a big-endian
> > > platform, etc), but I think that's a question for the future, rather
> > > than something that affects this series.
> >
> > I'll say that's a requirement. We should be able to structure the
> > tests to not interfere with the running system's DT. The DT unittest
> > does that.
>
> That could be another choice in the unit test choice menu.
> CONFIG_OF_KUNIT_NOT_UML that injects some built-in DTB overlay on an
> architecture that wants to run tests.

As long as you use compatible values that don't exist elsewhere,
and don't overwrite anything, you can load your kunit test overlays
on any running system that has DT support.

> > As a side topic, Is anyone looking at getting UML to work on arm64?
> > It's surprising how much x86 stuff there is which is I guess one
> > reason it hasn't happened.
>
> I've no idea but it would be nice indeed.

I believe that's non-trivial. At least for arm32 (I didn't have any arm64
systems last time I asked the experts).

> > > Similarly, I wonder if there's something we could do with device tree
> > > overlays, in order to make it possible for tests to swap nodes in and
> > > out for testing.
> >
> > Yes, that's how the DT unittest works. But it is pretty much one big
> > overlay (ignoring the overlay tests). It could probably be more
> > modular where it is apply overlay, test, remove overlay, repeat.
>
> I didn't want to rely on the overlay code to inject DT nodes. Having
> tests written for the fake KUnit machine is simple. It closely matches
> how clk code probes the DTB and how nodes are created and populated on
> the platform bus as devices. CLK_OF_DECLARE() would need the overlay to
> be applied early too, which doesn't happen otherwise as far as I know.

Don't all generic clock drivers also create a platform driver?
At least drivers/clk/clk-fixed-factor.c does.

> But perhaps this design is too much of an end-to-end test and not a unit
> test? In the spirit of unit testing we shouldn't care about how the node
> is added to the live devicetree, just that there is a devicetree at all.
>
> Supporting overlays to more easily test combinations sounds like a good
> idea. Probably some kunit_*() prefixed functions could be used to
> apply a test managed overlay and automatically remove it when the test
> is over would work. The clk registration tests could use this API to
> inject an overlay and then manually call the of_platform_populate()
> function to create the platform device(s). The overlay could be built in
> drivers/clk/ too and then probably some macroish function can find the
> blob and apply it.

No need to manually call of_platform_populate() to create the
platform devices. That is taken care of automatically when applying
an overlay.

> Is there some way to delete the platform devices that we populate from
> the overlay? I'd like the tests to be hermetic.

Removing the overlay will delete the platform devices.

All of that works if you have your own code to apply a DT overlay.
The recent fw_devlinks patches did cause some regressions, cfr.
https://lore.kernel.org/all/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com

P.S. Shameless plug: for loading overlays from userspace, there are
     my overlay branches, cfr. https://elinux.org/R-Car/DT-Overlays

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Rob Herring]

On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Rob Herring (2023-03-02 09:13:59)
> > On Wed, Mar 1, 2023 at 7:38 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > This patch series adds unit tests for the clk fixed rate basic type and
> > > the clk registration functions that use struct clk_parent_data. To get
> > > there, we add support for loading a DTB into the UML kernel that's
> > > running the unit tests along with probing platform drivers to bind to
> > > device nodes specified in DT.
> > >
> > > With this series, we're able to exercise some of the code in the common
> > > clk framework that uses devicetree lookups to find parents and the fixed
> > > rate clk code that scans devicetree directly and creates clks. Please
> > > review.
> > >
> > > I Cced everyone to all the patches so they get the full context. I'm
> > > hoping I can take the whole pile through the clk tree as they almost all
> > > depend on each other. In the future I imagine it will be easy to add
> > > more test nodes to the clk.dtsi file and not need to go across various
> > > maintainer trees like this series does.
> > >
> > > Stephen Boyd (8):
> > >   dt-bindings: Add linux,kunit binding
> > >   of: Enable DTB loading on UML for KUnit tests
> > >   kunit: Add test managed platform_device/driver APIs
> > >   clk: Add test managed clk provider/consumer APIs
> > >   dt-bindings: kunit: Add fixed rate clk consumer test
> > >   clk: Add KUnit tests for clk fixed rate basic type
> > >   dt-bindings: clk: Add KUnit clk_parent_data test
> > >   clk: Add KUnit tests for clks registered with struct clk_parent_data
> >
> > Good to see bindings for this. I've been meaning to do something about
> > the DT unittest ones being undocumented, but I hadn't really decided
> > whether it was worth writing schemas for them. The compatibles at
> > least show up with 'make dt_compatible_check'. Perhaps we want to just
> > define some vendor (not 'linux') that's an exception rather than
> > requiring schemas (actually, that already works for 'foo').
>
> Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?

We'd want to use the same thing on the DT unittests or anything else
potentially. How about just 'test'?

> > It's
> > likely that we want test DTs that fail normal checks and schemas get
> > in the way of that as we don't have a way to turn off checks.
>
> Having the schemas is nice to make sure tests that are expecting some
> binding are actually getting that. But supporting broken bindings is
> also important to test any error paths in functions that parse
> properties. Maybe we keep the schema and have it enforce that incorrect
> properties are being set?

I wasn't suggesting throwing them out. More why I hadn't written any I guess.

> Do we really need to test incorrect bindings? Doesn't the
> dt_bindings_check catch these problems so we don't have to write DTB
> verifiers in the kernel?

Fair enough. Using my frequently stated position against me. :)

I do have a secret plan to implement (debug) type checks into the
of_property_* APIs by extracting the type information from schemas
into C.


> > We already have GPIO tests in the DT unittests, so why is clocks
> > different? Or should the GPIO tests be moved out (yes, please!)?
>
> Ah I didn't notice the GPIO tests in there. There are i2c tests too,
> right? All I can say is clks are using kunit, that's the difference ;-)

Yeah, they should perhaps all move to the subsystems.

> > What happens when/if the DT unittest is converted to kunit? I think
> > that would look confusing from the naming. My initial thought is
> > 'kunit' should be dropped from the naming of a lot of this. Note that
> > the original kunit submission converted the DT unittests. I would
> > still like to see that happen. Frank disagreed over what's a unit test
> > or not, then agreed, then didn't... I don't really care. If there's a
> > framework to use, then we should use it IMO.
>
> Honestly I don't want to get involved in migrating the existing DT
> unittest code to kunit. I'm aware that it was attempted years ago when
> kunit was introduced. Maybe if the overlay route works well enough I can
> completely sidestep introducing any code in drivers/of/ besides some
> kunit wrappers for this. I'll cross my fingers!

Yeah, I wasn't expecting you to. I just want to make sure this meshes
with any future conversion to kunit.

There's also some plans to always populate the DT root node if not
present. That may help here. Or not. There's been a few versions
posted with Frank's in the last week or 2.

Rob

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Stephen Boyd]

Quoting Rob Herring (2023-03-02 12:18:34)
> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Rob Herring (2023-03-02 09:13:59)
> > >
> > > Good to see bindings for this. I've been meaning to do something about
> > > the DT unittest ones being undocumented, but I hadn't really decided
> > > whether it was worth writing schemas for them. The compatibles at
> > > least show up with 'make dt_compatible_check'. Perhaps we want to just
> > > define some vendor (not 'linux') that's an exception rather than
> > > requiring schemas (actually, that already works for 'foo').
> >
> > Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?
> 
> We'd want to use the same thing on the DT unittests or anything else
> potentially. How about just 'test'?

Sounds good.

> 
> > > It's
> > > likely that we want test DTs that fail normal checks and schemas get
> > > in the way of that as we don't have a way to turn off checks.
> >
> > Having the schemas is nice to make sure tests that are expecting some
> > binding are actually getting that. But supporting broken bindings is
> > also important to test any error paths in functions that parse
> > properties. Maybe we keep the schema and have it enforce that incorrect
> > properties are being set?
> 
> I wasn't suggesting throwing them out. More why I hadn't written any I guess.
> 
> > Do we really need to test incorrect bindings? Doesn't the
> > dt_bindings_check catch these problems so we don't have to write DTB
> > verifiers in the kernel?
> 
> Fair enough. Using my frequently stated position against me. :)
> 
> I do have a secret plan to implement (debug) type checks into the
> of_property_* APIs by extracting the type information from schemas
> into C.
> 

Ok. I suspect we may want to test error paths though so I don't know
what to do here. For now I'll just leave the bindings in place and
change the prefix to "test".

> 
> > > We already have GPIO tests in the DT unittests, so why is clocks
> > > different? Or should the GPIO tests be moved out (yes, please!)?
> >
> > Ah I didn't notice the GPIO tests in there. There are i2c tests too,
> > right? All I can say is clks are using kunit, that's the difference ;-)
> 
> Yeah, they should perhaps all move to the subsystems.

Got it.

> 
> > > What happens when/if the DT unittest is converted to kunit? I think
> > > that would look confusing from the naming. My initial thought is
> > > 'kunit' should be dropped from the naming of a lot of this. Note that
> > > the original kunit submission converted the DT unittests. I would
> > > still like to see that happen. Frank disagreed over what's a unit test
> > > or not, then agreed, then didn't... I don't really care. If there's a
> > > framework to use, then we should use it IMO.
> >
> > Honestly I don't want to get involved in migrating the existing DT
> > unittest code to kunit. I'm aware that it was attempted years ago when
> > kunit was introduced. Maybe if the overlay route works well enough I can
> > completely sidestep introducing any code in drivers/of/ besides some
> > kunit wrappers for this. I'll cross my fingers!
> 
> Yeah, I wasn't expecting you to. I just want to make sure this meshes
> with any future conversion to kunit.

Phew!

> 
> There's also some plans to always populate the DT root node if not
> present. That may help here. Or not. There's been a few versions
> posted with Frank's in the last week or 2.
> 

Ok. I think I have some time to try this overlay approach so let me see
what is needed.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 1/8] dt-bindings: Add linux,kunit binding

[David Gow]

[-- Attachment #1.1: Type: text/plain, Size: 2087 bytes --]

On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Document the linux,kunit board compatible string. This board is loaded
> into the Linux kernel when KUnit is testing devicetree dependent code.

As with the series as a whole, this might need to change a little bit
if we want to either use devicetree overlays and/or other
architectures.

That being said, I'm okay with having this until then: the only real
topic for bikeshedding is the name.
- Is KUnit best as a board name, or part of the vendor name?
- Do we want to include the architecture in the name?
Should it be "linux,kunit", "linux-kunit,uml", "linux,kunit-uml", etc?


>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Brendan Higgins <brendan.higgins@linux.dev>
> Cc: David Gow <davidgow@google.com>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
>  .../bindings/kunit/linux,kunit.yaml           | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/kunit/linux,kunit.yaml
>
> diff --git a/Documentation/devicetree/bindings/kunit/linux,kunit.yaml b/Documentation/devicetree/bindings/kunit/linux,kunit.yaml
> new file mode 100644
> index 000000000000..dfe6da4796e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kunit/linux,kunit.yaml
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kunit/linux,kunit.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: KUnit
> +
> +maintainers:
> +  - Brendan Higgins <brendanhiggins@google.com>
> +  - David Gow <davidgow@google.com>
> +
> +description:
> +  KUnit board used to unit test the Linux kernel in User Mode Linux (UML).
> +
> +properties:
> +  $nodename:
> +    const: "/"
> +  compatible:
> +    const: linux,kunit
> +
> +additionalProperties: true
> +
> +...
> --
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
> https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
>

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[David Gow]

[-- Attachment #1.1: Type: text/plain, Size: 9970 bytes --]

On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>
> To fully exercise common clk framework code in KUnit we need to
> associate 'struct device' pointers with 'struct device_node' pointers so
> that things like clk_get() can parse DT nodes for 'clocks' and so that
> clk providers can use DT to provide clks; the most common mode of
> operation for clk providers.
>
> Adding support to KUnit so that it loads a DTB is fairly simple after
> commit b31297f04e86 ("um: Add devicetree support"). We can simply pass a
> pre-compiled deviectree blob (DTB) on the kunit.py commandline and UML
> will load it. The problem is that tests won't know that the commandline
> has been modified, nor that a DTB has been loaded. Take a different
> approach so that tests can skip if a DTB hasn't been loaded.
>
> Reuse the Makefile logic from the OF unittests to build a DTB into the
> kernel. This DTB will be for the mythical machine "linux,kunit", i.e.
> the devicetree for the KUnit "board". In practice, it is a dtsi file
> that will gather includes for kunit tests that rely in part on a
> devicetree being loaded. The devicetree should only be loaded if
> CONFIG_OF_KUNIT=y. Make that a choice config parallel to the existing
> CONFIG_OF_UNITTEST so that only one devicetree can be loaded in the
> system at a time. Similarly, the kernel commandline option to load a
> DTB is ignored if CONFIG_OF_KUNIT is enabled so that only one DTB is
> loaded at a time.

This feels a little bit like it's just papering over the real problem,
which is that there's no way tests can skip themselves if no DTB is
loaded.

That being said, I do think that there's probably some sense in
supporting the compiled-in DTB as well (it's definitely simpler than
patching kunit.py to always pass the extra command-line option in, for
example).
But maybe it'd be nice to have the command-line option override the
built-in one if present.

>
> Add a simple unit test to confirm that the DTB loading worked. Future
> tests will add to the kunit.dtsi file to include their specific test
> nodes.
>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
>  arch/um/kernel/dtb.c            | 29 +++++++++++++++--
>  drivers/of/Kconfig              | 26 ++++++++++++++++
>  drivers/of/Makefile             |  1 +
>  drivers/of/kunit/.kunitconfig   |  4 +++
>  drivers/of/kunit/Makefile       |  4 +++
>  drivers/of/kunit/kunit.dtsi     |  8 +++++
>  drivers/of/kunit/kunit.dtso     |  4 +++
>  drivers/of/kunit/uml_dtb_test.c | 55 +++++++++++++++++++++++++++++++++
>  8 files changed, 128 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/of/kunit/.kunitconfig
>  create mode 100644 drivers/of/kunit/Makefile
>  create mode 100644 drivers/of/kunit/kunit.dtsi
>  create mode 100644 drivers/of/kunit/kunit.dtso
>  create mode 100644 drivers/of/kunit/uml_dtb_test.c
>
> diff --git a/arch/um/kernel/dtb.c b/arch/um/kernel/dtb.c
> index 484141b06938..ee63951b12df 100644
> --- a/arch/um/kernel/dtb.c
> +++ b/arch/um/kernel/dtb.c
> @@ -15,9 +15,32 @@ void uml_dtb_init(void)
>         long long size;
>         void *area;
>
> -       area = uml_load_file(dtb, &size);
> -       if (!area)
> -               return;
> +       if (IS_ENABLED(CONFIG_OF_KUNIT)) {
> +               /*
> +                * __dtbo_kunit_begin[] and __dtbo_kunit_end[] are magically
> +                * created by cmd_dt_S_dtbo in scripts/Makefile.lib from the
> +                * drivers/of/kunit/kunit.dtsi file.
> +                */
> +               extern uint8_t __dtbo_kunit_begin[];
> +               extern uint8_t __dtbo_kunit_end[];
> +
> +               size = __dtbo_kunit_end - __dtbo_kunit_begin;
> +               if (!size) {
> +                       pr_warn("%s: kunit testcases is empty\n", __func__);
> +                       return;
> +               }
> +
> +               /* creating copy */
> +               area = memblock_alloc(size, 8);
> +               if (!area)
> +                       return;
> +
> +               memcpy(area, __dtbo_kunit_begin, size);
> +       } else {

I think this should probably override the KUnit dtb if present (so,
try to load the dtb, and fallback to the builtin one). If not, I think
we should at least print a warning if a DTB is specified on the
command-line, but we're not using it.


> +               area = uml_load_file(dtb, &size);
> +               if (!area)
> +                       return;
> +       }
>
>         if (!early_init_dt_scan(area)) {
>                 pr_err("invalid DTB %s\n", dtb);
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 80b5fd44ab1c..1f968b6a3dde 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -12,6 +12,20 @@ menuconfig OF
>
>  if OF
>
> +choice
> +       prompt "Devicetree Runtime Tests"
> +       default OF_UNITTEST
> +
> +config OF_KUNIT
> +       bool "Devicetree KUnit support" if KUNIT
> +       depends on UML
> +       select IRQ_DOMAIN
> +       select OF_EARLY_FLATTREE
> +       help
> +         This option builds in KUnit test cases that rely on device tree infrastructure.
> +         A fake Device Tree Blob (DTB) is loaded on the UML kernel running KUnit so that
> +         KUnit tests can test device tree dependent code.
> +
>  config OF_UNITTEST
>         bool "Device Tree runtime unit tests"
>         depends on !SPARC
> @@ -25,6 +39,18 @@ config OF_UNITTEST
>
>           If unsure, say N here, but this option is safe to enable.
>
> +endchoice
> +
> +config OF_DTB_KUNIT_TEST
> +       tristate "Devicetree KUnit DTB Test" if !KUNIT_ALL_TESTS
> +       depends on KUNIT
> +       default KUNIT_ALL_TESTS
> +       help
> +         This option builds unit tests for the "linux,kunit" DTB built into
> +         the UML kernel image.
> +
> +         If unsure, say N here, but this option is safe to enable.
> +
>  config OF_ALL_DTBS
>         bool "Build all Device Tree Blobs"
>         depends on COMPILE_TEST
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index e0360a44306e..16eef3fdf60a 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -19,4 +19,5 @@ obj-y += kexec.o
>  endif
>  endif
>
> +obj-y += kunit/
>  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> diff --git a/drivers/of/kunit/.kunitconfig b/drivers/of/kunit/.kunitconfig
> new file mode 100644
> index 000000000000..1def0ad30d29
> --- /dev/null
> +++ b/drivers/of/kunit/.kunitconfig
> @@ -0,0 +1,4 @@
> +CONFIG_KUNIT=y
> +CONFIG_OF=y
> +CONFIG_OF_KUNIT=y
> +CONFIG_OF_DTB_KUNIT_TEST=y
> diff --git a/drivers/of/kunit/Makefile b/drivers/of/kunit/Makefile
> new file mode 100644
> index 000000000000..ffe0447e1ac7
> --- /dev/null
> +++ b/drivers/of/kunit/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_OF_KUNIT) += kunit.dtbo.o
> +
> +obj-$(CONFIG_OF_DTB_KUNIT_TEST) += uml_dtb_test.o
> diff --git a/drivers/of/kunit/kunit.dtsi b/drivers/of/kunit/kunit.dtsi
> new file mode 100644
> index 000000000000..82f6c3e2b8d5
> --- /dev/null
> +++ b/drivers/of/kunit/kunit.dtsi
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/ {
> +       model = "KUnit UML";
> +       compatible = "linux,kunit";
> +};
> +
> +/* Include testcase dtsi files below */
> diff --git a/drivers/of/kunit/kunit.dtso b/drivers/of/kunit/kunit.dtso
> new file mode 100644
> index 000000000000..50187e8d1422
> --- /dev/null
> +++ b/drivers/of/kunit/kunit.dtso
> @@ -0,0 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +
> +#include "kunit.dtsi"
> diff --git a/drivers/of/kunit/uml_dtb_test.c b/drivers/of/kunit/uml_dtb_test.c
> new file mode 100644
> index 000000000000..8966c9ebf51f
> --- /dev/null
> +++ b/drivers/of/kunit/uml_dtb_test.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit tests for DTB loading on UML
> + */
> +#include <linux/kconfig.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +
> +#include <kunit/test.h>
> +
> +/*
> + * Test that of_machine_is_compatible() returns positive int when loaded DTB
> + * matches.
> + */
> +static void uml_dtb_of_machine_compatible_test(struct kunit *test)
> +{
> +       KUNIT_EXPECT_GT(test, of_machine_is_compatible("linux,kunit"), 0);
> +}
> +
> +/*
> + * Test that of_flat_dt_get_machine_name() returns the expected 'model' from the
> + * loaded DTB.
> + */
> +static void uml_dtb_of_flat_dt_get_machine_name_test(struct kunit *test)
> +{
> +       KUNIT_EXPECT_STREQ(test, of_flat_dt_get_machine_name(), "KUnit UML");
> +}
> +
> +static struct kunit_case uml_dtb_test_cases[] = {
> +       KUNIT_CASE(uml_dtb_of_machine_compatible_test),
> +       KUNIT_CASE(uml_dtb_of_flat_dt_get_machine_name_test),
> +       {}
> +};
> +
> +static int uml_dtb_test_init(struct kunit *test)
> +{
> +       if (!IS_ENABLED(CONFIG_OF_KUNIT))
> +               kunit_skip(test, "requires CONFIG_OF_KUNIT");
> +
> +       return 0;
> +}
> +
> +/*
> + * Test suite to confirm DTB is loaded on UML.
> + */
> +static struct kunit_suite uml_dtb_suite = {
> +       .name = "uml_dtb",
> +       .init = uml_dtb_test_init,
> +       .test_cases = uml_dtb_test_cases,
> +};
> +
> +kunit_test_suites(
> +       &uml_dtb_suite,
> +);
> +MODULE_LICENSE("GPL");
> --
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
> https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
>
> --
> You received this message because you are subscribed to the Google Groups "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kunit-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kunit-dev/20230302013822.1808711-3-sboyd%40kernel.org.

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 3/8] kunit: Add test managed platform_device/driver APIs

[David Gow]

[-- Attachment #1.1: Type: text/plain, Size: 15205 bytes --]

On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Introduce KUnit resource wrappers around platform_driver_register(),
> platform_device_alloc(), and platform_device_add() so that test authors
> can register platform drivers/devices from their tests and have the
> drivers/devices automatically be unregistered when the test is done.
>
> This makes test setup code simpler when a platform driver or platform
> device is needed. Add a few test cases at the same time to make sure the
> APIs work as intended.
>
> Cc: Brendan Higgins <brendan.higgins@linux.dev>
> Cc: David Gow <davidgow@google.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
>
> Should this be moved to drivers/base/ and called platform_kunit.c?
> The include/kunit/platform_driver.h could also be
> kunit/platform_device.h to match linux/platform_device.h if that is more
> familiar.

DRM has a similar thing already (albeit with a root_device, which is
more common with KUnit tests generally):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_kunit_helpers.h

But that's reasonably drm-specific, so it makes sense that it lives
with DRM stuff. platform_device is a bit more generic.

I'd probably personally err on the side of having these in
drivers/base/, as I think we'll ultimately need similar things for a
lot of different devices, and I'd rather not end up with things like
USB device helpers living in the lib/kunit directory alongside the
"core" KUnit code. But I could be persuaded otherwise.

>
> And I'm not super certain about allocating a driver structure and
> embedding it in a wrapper struct. Maybe the code should just use
> kunit_get_current_test() instead?

I think there are enough cases througout the kernel where
device/driver structs are needed that having this makes sense.
Combined with the fact that, while kunit_get_current_test() can be
used even when KUnit is not loaded, actually doing anything with the
resulting struct kunit pointer will probably require (at least for the
moment) KUnit functions to be reachable, so would break if
CONFIG_KUNIT=m.

So, unless you actually find kunit_get_current_test() and friends to
be easier to work with, I'd probably stick with this.

>
>  include/kunit/platform_driver.h  |  15 +++
>  lib/kunit/Makefile               |   6 +
>  lib/kunit/platform_driver-test.c | 107 ++++++++++++++++
>  lib/kunit/platform_driver.c      | 207 +++++++++++++++++++++++++++++++
>  4 files changed, 335 insertions(+)
>  create mode 100644 include/kunit/platform_driver.h
>  create mode 100644 lib/kunit/platform_driver-test.c
>  create mode 100644 lib/kunit/platform_driver.c
>
> diff --git a/include/kunit/platform_driver.h b/include/kunit/platform_driver.h
> new file mode 100644
> index 000000000000..dc211ff8f893
> --- /dev/null
> +++ b/include/kunit/platform_driver.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _KUNIT_PLATFORM_DRIVER_H
> +#define _KUNIT_PLATFORM_DRIVER_H
> +
> +struct kunit;
> +struct platform_device;
> +struct platform_driver;
> +
> +struct platform_device *
> +kunit_platform_device_alloc(struct kunit *test, const char *name, int id);
> +int kunit_platform_device_add(struct kunit *test, struct platform_device *pdev);
> +
> +int kunit_platform_driver_register(struct kunit *test, struct platform_driver *drv);
> +
> +#endif
> diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
> index 29aff6562b42..5964d8231ff5 100644
> --- a/lib/kunit/Makefile
> +++ b/lib/kunit/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_KUNIT) +=                 kunit.o
>
> +# Core KUnit code
>  kunit-objs +=                          test.o \
>                                         resource.o \
>                                         string-stream.o \
> @@ -11,7 +12,12 @@ ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
>  kunit-objs +=                          debugfs.o
>  endif
>
> +# KUnit helpers
> +kunit-objs +=                          platform_driver.o
> +
> +# KUnit tests
>  obj-$(CONFIG_KUNIT_TEST) +=            kunit-test.o
> +obj-$(CONFIG_KUNIT_TEST) +=            platform_driver-test.o
>
>  # string-stream-test compiles built-in only.
>  ifeq ($(CONFIG_KUNIT_TEST),y)
> diff --git a/lib/kunit/platform_driver-test.c b/lib/kunit/platform_driver-test.c
> new file mode 100644
> index 000000000000..c926fe01b40a
> --- /dev/null
> +++ b/lib/kunit/platform_driver-test.c
> @@ -0,0 +1,107 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test for platform driver infrastructure.
> + */
> +
> +#include <linux/platform_device.h>
> +
> +#include <kunit/platform_driver.h>
> +#include <kunit/test.h>
> +
> +/*
> + * Test that kunit_platform_device_alloc() creates a platform device.
> + */
> +static void kunit_platform_device_alloc_test(struct kunit *test)
> +{
> +       KUNIT_EXPECT_NOT_ERR_OR_NULL(test,
> +                       kunit_platform_device_alloc(test, "kunit-platform", 1));
> +}
> +
> +/*
> + * Test that kunit_platform_device_add() registers a platform device on the
> + * platform bus with the proper name and id.
> + */
> +static void kunit_platform_device_add_test(struct kunit *test)
> +{
> +       struct platform_device *pdev;
> +       const char *name = "kunit-platform";
> +       const int id = -1;
> +
> +       pdev = kunit_platform_device_alloc(test, name, id);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
> +
> +       KUNIT_EXPECT_EQ(test, 0, kunit_platform_device_add(test, pdev));
> +       KUNIT_EXPECT_TRUE(test, dev_is_platform(&pdev->dev));
> +       KUNIT_EXPECT_STREQ(test, pdev->name, name);
> +       KUNIT_EXPECT_EQ(test, pdev->id, id);
> +}
> +
> +static struct kunit_case kunit_platform_device_test_cases[] = {
> +       KUNIT_CASE(kunit_platform_device_alloc_test),
> +       KUNIT_CASE(kunit_platform_device_add_test),
> +       {}
> +};
> +
> +static struct kunit_suite kunit_platform_device_suite = {
> +       .name = "kunit_platform_device",
> +       .test_cases = kunit_platform_device_test_cases,
> +};
> +
> +struct kunit_platform_driver_test_context {
> +       struct platform_driver pdrv;
> +       const char *data;
> +};
> +
> +static inline struct kunit_platform_driver_test_context *
> +to_test_context(struct platform_device *pdev)
> +{
> +       return container_of(to_platform_driver(pdev->dev.driver),
> +                           struct kunit_platform_driver_test_context,
> +                           pdrv);
> +}
> +
> +static int kunit_platform_driver_probe(struct platform_device *pdev)
> +{
> +       struct kunit_platform_driver_test_context *ctx;
> +
> +       ctx = to_test_context(pdev);
> +       ctx->data = "test data";
> +
> +       return 0;
> +}
> +
> +/* Test that kunit_platform_driver_register() registers a driver that probes. */
> +static void kunit_platform_driver_register_test(struct kunit *test)
> +{
> +       struct platform_device *pdev;
> +       struct kunit_platform_driver_test_context *ctx;
> +
> +       ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> +
> +       pdev = kunit_platform_device_alloc(test, "kunit-platform", -1);
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
> +       KUNIT_ASSERT_EQ(test, 0, kunit_platform_device_add(test, pdev));
> +
> +       ctx->pdrv.probe = kunit_platform_driver_probe;
> +       ctx->pdrv.driver.name = "kunit-platform";
> +       ctx->pdrv.driver.owner = THIS_MODULE;
> +
> +       KUNIT_EXPECT_EQ(test, 0, kunit_platform_driver_register(test, &ctx->pdrv));
> +       KUNIT_EXPECT_STREQ(test, ctx->data, "test data");
> +}
> +
> +static struct kunit_case kunit_platform_driver_test_cases[] = {
> +       KUNIT_CASE(kunit_platform_driver_register_test),
> +       {}
> +};
> +
> +static struct kunit_suite kunit_platform_driver_suite = {
> +       .name = "kunit_platform_driver",
> +       .test_cases = kunit_platform_driver_test_cases,
> +};
> +
> +kunit_test_suites(&kunit_platform_device_suite,
> +                 &kunit_platform_driver_suite);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/lib/kunit/platform_driver.c b/lib/kunit/platform_driver.c
> new file mode 100644
> index 000000000000..11d155114936
> --- /dev/null
> +++ b/lib/kunit/platform_driver.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Test managed platform driver
> + */
> +
> +#include <linux/device/driver.h>
> +#include <linux/platform_device.h>
> +
> +#include <kunit/resource.h>
> +
> +struct kunit_platform_device_alloc_params {
> +       const char *name;
> +       int id;
> +};

FYI: It's my plan to eventually get rid of (or at least de-emphasize)
the whole 'init' function aspect of KUnit resources so we don't need
all of these extra structs and the like. It probably won't make it in
for 6.4, but we'll see...


> +
> +static int kunit_platform_device_alloc_init(struct kunit_resource *res, void *context)
> +{
> +       struct kunit_platform_device_alloc_params *params = context;
> +       struct platform_device *pdev;
> +
> +       pdev = platform_device_alloc(params->name, params->id);
> +       if (!pdev)
> +               return -ENOMEM;
> +
> +       res->data = pdev;
> +
> +       return 0;
> +}
> +
> +static void kunit_platform_device_alloc_exit(struct kunit_resource *res)
> +{
> +       struct platform_device *pdev = res->data;
> +
> +       platform_device_put(pdev);
> +}
> +
> +/**
> + * kunit_platform_device_alloc() - Allocate a KUnit test managed platform device
> + * @test: test context
> + * @dev: platform device to alloc
> + *
> + * Register a test managed platform device. The device is put when the test completes.
> + *
> + * Returns: 0 on success, negative errno on failure.
> + */
> +struct platform_device *
> +kunit_platform_device_alloc(struct kunit *test, const char *name, int id)
> +{
> +       struct platform_device *pdev;
> +       struct kunit_platform_device_alloc_params params = {
> +               .name = name,
> +               .id = id,
> +       };
> +
> +       pdev = kunit_alloc_resource(test,
> +                                  kunit_platform_device_alloc_init,
> +                                  kunit_platform_device_alloc_exit,
> +                                  GFP_KERNEL, &params);
> +       if (!pdev)
> +               return ERR_PTR(-ENOMEM);
> +
> +       return pdev;
> +}
> +EXPORT_SYMBOL_GPL(kunit_platform_device_alloc);
> +
> +static int kunit_platform_device_add_init(struct kunit_resource *res, void *context)
> +{
> +       struct platform_device *pdev = context;
> +       int ret;
> +
> +       ret = platform_device_add(pdev);
> +       if (ret) {
> +               platform_device_put(pdev);
> +               return ret;
> +       }
> +       res->data = pdev;
> +
> +       return 0;
> +}
> +
> +static void kunit_platform_device_add_exit(struct kunit_resource *res)
> +{
> +       struct platform_device *pdev = res->data;
> +
> +       platform_device_unregister(pdev);
> +}
> +
> +/**
> + * kunit_platform_device_add() - Register a KUnit test managed platform device
> + * @test: test context
> + * @dev: platform device to add
> + *
> + * Register a test managed platform device. The device is unregistered when the
> + * test completes.
> + *
> + * Returns: 0 on success, negative errno on failure.
> + */
> +int kunit_platform_device_add(struct kunit *test, struct platform_device *pdev)
> +{
> +       struct platform_device *res;
> +
> +       res = kunit_alloc_resource(test,
> +                                  kunit_platform_device_add_init,
> +                                  kunit_platform_device_add_exit,
> +                                  GFP_KERNEL, pdev);
> +       if (!res)
> +               return -EINVAL;
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(kunit_platform_device_add);
> +
> +static int kunit_platform_driver_register_init(struct kunit_resource *res, void *context)
> +{
> +       struct platform_driver *drv = context;
> +       int ret;
> +
> +       ret = platform_driver_register(drv);
> +       if (ret)
> +               return ret;
> +       res->data = drv;
> +
> +       /*
> +        * Wait for the driver to probe (or at least flush out of the deferred
> +        * workqueue)
> +        */
> +       wait_for_device_probe();
> +
> +       return 0;
> +}
> +
> +static void kunit_platform_driver_register_exit(struct kunit_resource *res)
> +{
> +       struct platform_driver *drv = res->data;
> +
> +       platform_driver_unregister(drv);
> +}
> +
> +/**
> + * kunit_platform_driver_register() - Register a KUnit test managed platform driver
> + * @test: test context
> + * @drv: platform driver to register
> + *
> + * Register a test managed platform driver. This allows callers to embed the
> + * @drv in a container structure and use container_of() in the probe function
> + * to pass information to kunit tests. It can be assumed that the driver has
> + * probed when this function returns.
> + *
> + * Example:
> + *
> + * .. code-block:: c
> + *
> + *     struct kunit_test_context {
> + *             struct platform_driver pdrv;
> + *             const char *data;
> + *     };
> + *
> + *     static inline struct kunit_test_context *
> + *     to_test_context(struct platform_device *pdev)
> + *     {
> + *             return container_of(to_platform_driver(pdev->dev.driver),
> + *                                 struct kunit_test_context,
> + *                                 pdrv);
> + *     }
> + *
> + *     static int kunit_platform_driver_probe(struct platform_device *pdev)
> + *     {
> + *             struct kunit_test_context *ctx;
> + *
> + *             ctx = to_test_context(pdev);
> + *             ctx->data = "test data";
> + *
> + *             return 0;
> + *     }
> + *
> + *     static void kunit_platform_driver_test(struct kunit *test)
> + *     {
> + *             struct kunit_test_context *ctx;
> + *
> + *             ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
> + *             KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
> + *
> + *             ctx->pdrv.probe = kunit_platform_driver_probe;
> + *             ctx->pdrv.driver.name = "kunit-platform";
> + *             ctx->pdrv.driver.owner = THIS_MODULE;
> + *
> + *             KUNIT_EXPECT_EQ(test, 0, kunit_platform_driver_register(test, &ctx->pdrv));
> + *             KUNIT_EXPECT_STREQ(test, ctx->data, "test data");
> + *     }
> + *
> + * Returns: 0 on success, negative errno on failure.
> + */
> +int kunit_platform_driver_register(struct kunit *test,
> +                                  struct platform_driver *drv)
> +{
> +       struct platform_driver *res;
> +
> +       res = kunit_alloc_resource(test,
> +                                  kunit_platform_driver_register_init,
> +                                  kunit_platform_driver_register_exit,
> +                                  GFP_KERNEL, drv);
> +       if (!res)
> +               return -EINVAL;
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(kunit_platform_driver_register);
> --
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
> https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
>

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 4/8] clk: Add test managed clk provider/consumer APIs

[David Gow]

[-- Attachment #1.1: Type: text/plain, Size: 9656 bytes --]

On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Unit tests are more ergonomic and simpler to understand if they don't
> have to hoist a bunch of code into the test harness init and exit
> functions. Add some test managed wrappers for the clk APIs so that clk
> unit tests can write more code in the actual test and less code in the
> harness.
>
> Only add APIs that are used for now. More wrappers can be added in the
> future as necessary.
>
> Cc: Brendan Higgins <brendan.higgins@linux.dev>
> Cc: David Gow <davidgow@google.com>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---

Looks good, modulo bikeshedding below.

>  drivers/clk/Makefile    |   5 +
>  drivers/clk/clk-kunit.c | 204 ++++++++++++++++++++++++++++++++++++++++
>  drivers/clk/clk-kunit.h |  28 ++++++
>  3 files changed, 237 insertions(+)
>  create mode 100644 drivers/clk/clk-kunit.c
>  create mode 100644 drivers/clk/clk-kunit.h
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index e3ca0d058a25..7efce649b0d3 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -17,6 +17,11 @@ ifeq ($(CONFIG_OF), y)
>  obj-$(CONFIG_COMMON_CLK)       += clk-conf.o
>  endif
>
> +# KUnit specific helpers
> +ifeq ($(CONFIG_COMMON_CLK), y)
> +obj-$(CONFIG_KUNIT)            += clk-kunit.o

Do we want to compile these in whenever KUnit is enabled, or only when
we're building clk tests specifically? I suspect this would be served
better by being under a CLK_KUNIT config option, which all of the
tests then depend on. (Whether that's the existing
CONFIG_CLK_KUNIT_TEST, and all of the clk tests live under the same
config option, or a separate parent option would be up to you).

Equally, this could be a bit interesting if CONFIG_KUNIT=m. Given
CONFIG_COMMON_CLK=y, this would end up as a clk-kunit module, no?

> +endif
> +
>  # hardware specific clock types
>  # please keep this section sorted lexicographically by file path name
>  obj-$(CONFIG_COMMON_CLK_APPLE_NCO)     += clk-apple-nco.o
> diff --git a/drivers/clk/clk-kunit.c b/drivers/clk/clk-kunit.c
> new file mode 100644
> index 000000000000..78d85b3a7a4a
> --- /dev/null
> +++ b/drivers/clk/clk-kunit.c
> @@ -0,0 +1,204 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit helpers for clk tests
> + */
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +
> +#include <kunit/resource.h>
> +
> +#include "clk-kunit.h"
> +
> +static void kunit_clk_disable_unprepare(struct kunit_resource *res)

We need to decide on the naming scheme of these, and in particular if
they should be kunit_clk or clk_kunit (or something else).

I'd lean to clk_kunit, if only to match DRM's KUnit helpers being
drm_kunit_helper better, and so that these are more tightly bound to
the subsystem being tested.
(i.e., so I don't have to scroll through every subsystem's helpers
when autocompleting kunit_).


> +{
> +       struct clk *clk = res->data;
> +
> +       clk_disable_unprepare(clk);
> +}
> +
> +/**
> + * kunit_clk_prepare_enable() - Test managed clk_prepare_enable()
> + * @test: The test context
> + * @clk: clk to prepare and enable
> + *
> + * Returns: 0 on success, or negative errno on failure.
> + */
> +int kunit_clk_prepare_enable(struct kunit *test, struct clk *clk)
> +{
> +       if (!kunit_alloc_resource(test, NULL, kunit_clk_disable_unprepare,
> +                                 GFP_KERNEL, clk))
> +               return -EINVAL;
> +
> +       return clk_prepare_enable(clk);
> +}
> +EXPORT_SYMBOL_GPL(kunit_clk_prepare_enable);
> +
> +static void kunit_clk_put(struct kunit_resource *res)
> +{
> +       struct clk *clk = res->data;
> +
> +       clk_put(clk);
> +}
> +
> +/**
> + * kunit_clk_get() - Test managed clk_get()
> + * @test: The test context
> + * @dev: device for clock "consumer"
> + * @id: clock consumer ID
> + *
> + * Returns: new clk consumer or ERR_PTR on failure
> + */
> +struct clk *
> +kunit_clk_get(struct kunit *test, struct device *dev, const char *con_id)
> +{
> +       struct clk *clk;
> +
> +       clk = clk_get(dev, con_id);
> +       if (IS_ERR(clk))
> +               return clk;
> +
> +       if (!kunit_alloc_resource(test, NULL, kunit_clk_put, GFP_KERNEL, clk)) {
> +               clk_put(clk);
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       return clk;
> +}
> +EXPORT_SYMBOL_GPL(kunit_clk_get);
> +
> +/**
> + * kunit_of_clk_get() - Test managed of_clk_get()
> + * @test: The test context
> + * @np: device_node for clock "consumer"
> + * @index: index in 'clocks' property of @np
> + *
> + * Returns: new clk consumer or ERR_PTR on failure
> + */
> +struct clk *
> +kunit_of_clk_get(struct kunit *test, struct device_node *np, int index)
> +{
> +       struct clk *clk;
> +
> +       clk = of_clk_get(np, index);
> +       if (IS_ERR(clk))
> +               return clk;
> +
> +       if (!kunit_alloc_resource(test, NULL, kunit_clk_put, GFP_KERNEL, clk)) {
> +               clk_put(clk);
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       return clk;
> +}
> +EXPORT_SYMBOL_GPL(kunit_of_clk_get);
> +
> +/**
> + * kunit_clk_hw_get_clk() - Test managed clk_hw_get_clk()
> + * @test: The test context
> + * @hw: clk_hw associated with the clk being consumed
> + * @con_id: connection ID string on device
> + *
> + * Returns: new clk consumer or ERR_PTR on failure
> + */
> +struct clk *
> +kunit_clk_hw_get_clk(struct kunit *test, struct clk_hw *hw, const char *con_id)
> +{
> +       struct clk *clk;
> +
> +       clk = clk_hw_get_clk(hw, con_id);
> +       if (IS_ERR(clk))
> +               return clk;
> +
> +       if (!kunit_alloc_resource(test, NULL, kunit_clk_put, GFP_KERNEL, clk)) {
> +               clk_put(clk);
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       return clk;
> +}
> +EXPORT_SYMBOL_GPL(kunit_clk_hw_get_clk);
> +
> +/**
> + * kunit_clk_hw_get_clk_prepared_enabled() - Test managed clk_hw_get_clk() + clk_prepare_enable()
> + * @test: The test context
> + * @hw: clk_hw associated with the clk being consumed
> + * @con_id: connection ID string on device
> + *
> + * Returns: new clk consumer that is prepared and enabled or ERR_PTR on failure
> + */
> +struct clk *
> +kunit_clk_hw_get_clk_prepared_enabled(struct kunit *test, struct clk_hw *hw,
> +                                     const char *con_id)
> +{
> +       int ret;
> +       struct clk *clk;
> +
> +       clk = kunit_clk_hw_get_clk(test, hw, con_id);
> +       if (IS_ERR(clk))
> +               return clk;
> +
> +       ret = kunit_clk_prepare_enable(test, clk);
> +       if (ret)
> +               return ERR_PTR(ret);
> +
> +       return clk;
> +}
> +EXPORT_SYMBOL_GPL(kunit_clk_hw_get_clk_prepared_enabled);
> +
> +static void kunit_clk_hw_unregister(struct kunit_resource *res)
> +{
> +       struct clk_hw *hw = res->data;
> +
> +       clk_hw_unregister(hw);
> +}
> +
> +/**
> + * kunit_clk_hw_register() - Test managed clk_hw_register()
> + * @test: The test context
> + * @dev: device that is registering this clock
> + * @hw: link to hardware-specific clock data
> + *
> + * Returns: 0 on success or a negative errno value on failure
> + */
> +int kunit_clk_hw_register(struct kunit *test, struct device *dev, struct clk_hw *hw)
> +{
> +       int ret;
> +
> +       ret = clk_hw_register(dev, hw);
> +       if (ret)
> +               return ret;
> +
> +       if (!kunit_alloc_resource(test, NULL, kunit_clk_hw_unregister, GFP_KERNEL, hw)) {
> +               clk_hw_unregister(hw);
> +               return -EINVAL;
> +       }
> +
> +       return 0;
> +}
> +
> +/**
> + * kunit_of_clk_hw_register() - Test managed of_clk_hw_register()
> + * @test: The test context
> + * @node: device_node of device that is registering this clock
> + * @hw: link to hardware-specific clock data
> + *
> + * Returns: 0 on success or a negative errno value on failure
> + */
> +int kunit_of_clk_hw_register(struct kunit *test, struct device_node *node, struct clk_hw *hw)
> +{
> +       int ret;
> +
> +       ret = of_clk_hw_register(node, hw);
> +       if (ret)
> +               return ret;
> +
> +       if (!kunit_alloc_resource(test, NULL, kunit_clk_hw_unregister, GFP_KERNEL, hw)) {
> +               clk_hw_unregister(hw);
> +               return -EINVAL;
> +       }
> +
> +       return 0;
> +}
> diff --git a/drivers/clk/clk-kunit.h b/drivers/clk/clk-kunit.h
> new file mode 100644
> index 000000000000..153597d69269
> --- /dev/null
> +++ b/drivers/clk/clk-kunit.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _CLK_KUNIT_H
> +#define _CLK_KUNIT_H
> +
> +struct clk;
> +struct clk_hw;
> +struct device;
> +struct device_node;
> +struct kunit;
> +
> +struct clk *
> +kunit_clk_get(struct kunit *test, struct device *dev, const char *con_id);
> +struct clk *
> +kunit_of_clk_get(struct kunit *test, struct device_node *np, int index);
> +
> +struct clk *
> +kunit_clk_hw_get_clk(struct kunit *test, struct clk_hw *hw, const char *con_id);
> +struct clk *
> +kunit_clk_hw_get_clk_prepared_enabled(struct kunit *test, struct clk_hw *hw,
> +                                     const char *con_id);
> +
> +int kunit_clk_prepare_enable(struct kunit *test, struct clk *clk);
> +
> +int kunit_clk_hw_register(struct kunit *test, struct device *dev, struct clk_hw *hw);
> +int kunit_of_clk_hw_register(struct kunit *test, struct device_node *node,
> +                            struct clk_hw *hw);
> +
> +#endif
> --
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
> https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
>

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 1/8] dt-bindings: Add linux,kunit binding

[Geert Uytterhoeven]

Hi David,

On Fri, Mar 3, 2023 at 8:16 AM David Gow <davidgow@google.com> wrote:
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> > Document the linux,kunit board compatible string. This board is loaded
> > into the Linux kernel when KUnit is testing devicetree dependent code.
>
> As with the series as a whole, this might need to change a little bit
> if we want to either use devicetree overlays and/or other
> architectures.
>
> That being said, I'm okay with having this until then: the only real
> topic for bikeshedding is the name.
> - Is KUnit best as a board name, or part of the vendor name?
> - Do we want to include the architecture in the name?
> Should it be "linux,kunit", "linux-kunit,uml", "linux,kunit-uml", etc?

I would not include an architecture (or virtualization method), as
this is independent of the architecture or virtualization method.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 3/8] kunit: Add test managed platform_device/driver APIs

[Maxime Ripard]

On Fri, Mar 03, 2023 at 03:15:31PM +0800, David Gow wrote:
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Introduce KUnit resource wrappers around platform_driver_register(),
> > platform_device_alloc(), and platform_device_add() so that test authors
> > can register platform drivers/devices from their tests and have the
> > drivers/devices automatically be unregistered when the test is done.
> >
> > This makes test setup code simpler when a platform driver or platform
> > device is needed. Add a few test cases at the same time to make sure the
> > APIs work as intended.
> >
> > Cc: Brendan Higgins <brendan.higgins@linux.dev>
> > Cc: David Gow <davidgow@google.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> > ---
> >
> > Should this be moved to drivers/base/ and called platform_kunit.c?
> > The include/kunit/platform_driver.h could also be
> > kunit/platform_device.h to match linux/platform_device.h if that is more
> > familiar.
> 
> DRM has a similar thing already (albeit with a root_device, which is
> more common with KUnit tests generally):
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_kunit_helpers.h
> 
> But that's reasonably drm-specific, so it makes sense that it lives
> with DRM stuff. platform_device is a bit more generic.

I'd be very happy to get something from the core to address the same
thing.

I think the main thing we needed that isn't covered by this patch is we
wanted the device to be bound to its driver, so with probe being called
before calling the test (see 57a84a97bbda).

Maxime

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1126 bytes --]

Hi,

On Wed, Mar 01, 2023 at 05:38:13PM -0800, Stephen Boyd wrote:
> This patch series adds unit tests for the clk fixed rate basic type and
> the clk registration functions that use struct clk_parent_data. To get
> there, we add support for loading a DTB into the UML kernel that's
> running the unit tests along with probing platform drivers to bind to
> device nodes specified in DT.
> 
> With this series, we're able to exercise some of the code in the common
> clk framework that uses devicetree lookups to find parents and the fixed
> rate clk code that scans devicetree directly and creates clks. Please
> review.
> 
> I Cced everyone to all the patches so they get the full context. I'm
> hoping I can take the whole pile through the clk tree as they almost all
> depend on each other. In the future I imagine it will be easy to add
> more test nodes to the clk.dtsi file and not need to go across various
> maintainer trees like this series does.

That's really great, thanks!

I wanted to have a look at how we could possibly do this for DRM, I
guess I have a starting point now :)

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/2/23 11:32, Rob Herring wrote:
> On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
>>
>> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>>>
>>> This patch series adds unit tests for the clk fixed rate basic type and
>>> the clk registration functions that use struct clk_parent_data. To get
>>> there, we add support for loading a DTB into the UML kernel that's
>>> running the unit tests along with probing platform drivers to bind to
>>> device nodes specified in DT.
>>>
>>> With this series, we're able to exercise some of the code in the common
>>> clk framework that uses devicetree lookups to find parents and the fixed
>>> rate clk code that scans devicetree directly and creates clks. Please
>>> review.
>>>
>>
>> Thanks Stephen -- this is really neat!
>>
>> This works well here, and I love all of the tests for the
>> KUnit/device-tree integration as well.
>>
>> I'm still looking through the details of it (alas, I've mostly lived
>> in x86-land, so my device-tree knowledge is, uh, spotty to say the
>> least), but apart from possibly renaming some things or similarly
>> minor tweaks, I've not got any real suggestions thus far.
>>
>> I do wonder whether we'll want, on the KUnit side, to have some way of
>> supporting KUnit device trees on non-UML architecctures (e.g., if we
>> need to test something architecture-specific, or on a big-endian
>> platform, etc), but I think that's a question for the future, rather
>> than something that affects this series.
> 
> I'll say that's a requirement. We should be able to structure the
> tests to not interfere with the running system's DT. The DT unittest
> does that.
> 
> As a side topic, Is anyone looking at getting UML to work on arm64?
> It's surprising how much x86 stuff there is which is I guess one
> reason it hasn't happened.
> 
>> Similarly, I wonder if there's something we could do with device tree
>> overlays, in order to make it possible for tests to swap nodes in and
>> out for testing.
> 
> Yes, that's how the DT unittest works. But it is pretty much one big
> overlay (ignoring the overlay tests). It could probably be more
> modular where it is apply overlay, test, remove overlay, repeat.

Actually, no, the bulk of the DT unittest devicetree data is _not_ an
overlay.  It is an FDT that is loaded via of_fdt_unflatten_tree() instead
of the overlay load API.  Note that the base DT unittest runs with
  CONFIG_OF_DYNAMIC=n
  CONFIG_OF_OVERLAY=n
so the overlay support code is not even present in the built kernel.

One can then enable CONFIG_OF_DYNAMIC to test the dynamic code.

One can further enable CONFIG_OF_OVERLAY to test the overlay code
(this will in turn select CONFIG_OF_DYNAMIC if not already enabled).

I would strongly discourage use of the overlay APIs for kunit tests,
unless the point of the kunit test is to test the overlay API.  Basic
tests should always be performed with devicetree data that has been
populated by the normal processing of an FDT during early boot.  If
one want to test proper overlay infrastructure functionality, then
those (essentially) same basic tests could/should be repeated with
devicetree data that has been populated by loading an overlay.

> 
> Rob


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/2/23 13:27, Stephen Boyd wrote:
> Quoting Rob Herring (2023-03-02 09:32:09)
>> On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
>>>
>>> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>
>>>> This patch series adds unit tests for the clk fixed rate basic type and
>>>> the clk registration functions that use struct clk_parent_data. To get
>>>> there, we add support for loading a DTB into the UML kernel that's
>>>> running the unit tests along with probing platform drivers to bind to
>>>> device nodes specified in DT.
>>>>
>>>> With this series, we're able to exercise some of the code in the common
>>>> clk framework that uses devicetree lookups to find parents and the fixed
>>>> rate clk code that scans devicetree directly and creates clks. Please
>>>> review.
>>>>
>>>
>>> Thanks Stephen -- this is really neat!
>>>
>>> This works well here, and I love all of the tests for the
>>> KUnit/device-tree integration as well.
>>>
>>> I'm still looking through the details of it (alas, I've mostly lived
>>> in x86-land, so my device-tree knowledge is, uh, spotty to say the
>>> least), but apart from possibly renaming some things or similarly
>>> minor tweaks, I've not got any real suggestions thus far.
>>>
>>> I do wonder whether we'll want, on the KUnit side, to have some way of
>>> supporting KUnit device trees on non-UML architecctures (e.g., if we
>>> need to test something architecture-specific, or on a big-endian
>>> platform, etc), but I think that's a question for the future, rather
>>> than something that affects this series.
>>
>> I'll say that's a requirement. We should be able to structure the
>> tests to not interfere with the running system's DT. The DT unittest
>> does that.
> 
> That could be another choice in the unit test choice menu.
> CONFIG_OF_KUNIT_NOT_UML that injects some built-in DTB overlay on an
> architecture that wants to run tests.
> 
>>
>> As a side topic, Is anyone looking at getting UML to work on arm64?
>> It's surprising how much x86 stuff there is which is I guess one
>> reason it hasn't happened.
> 
> I've no idea but it would be nice indeed.
> 
>>
>>> Similarly, I wonder if there's something we could do with device tree
>>> overlays, in order to make it possible for tests to swap nodes in and
>>> out for testing.
>>
>> Yes, that's how the DT unittest works. But it is pretty much one big
>> overlay (ignoring the overlay tests). It could probably be more
>> modular where it is apply overlay, test, remove overlay, repeat.
>>
> 
> I didn't want to rely on the overlay code to inject DT nodes. Having
> tests written for the fake KUnit machine is simple. It closely matches
> how clk code probes the DTB and how nodes are created and populated on
> the platform bus as devices. CLK_OF_DECLARE() would need the overlay to
> be applied early too, which doesn't happen otherwise as far as I know.
> 
> But perhaps this design is too much of an end-to-end test and not a unit
> test? In the spirit of unit testing we shouldn't care about how the node
> is added to the live devicetree, just that there is a devicetree at all.
> 
> Supporting overlays to more easily test combinations sounds like a good
> idea. Probably some kunit_*() prefixed functions could be used to

In an imaginary world where overlay support was completed, then _maybe_.

To me, the most important  environment to test is where the devictree
data is populated in early boot from an FDT.  This is the environment
that drivers currently exist in.

Populating devicetree data via an overlay adds in the functioning of the
overlay apply code (and how the rules behind that functioning may differ
from devicetree data populated in early boot from an FDT).

In an ideal world where overlay support was completed, most or all of the
devicetree tests that were performed against the devicetree data populated
in early boot from an FDT would be repeated, but against comparable
devicetree data populated via an overlay load.  The tests with the overlay
data may have to be aware of some differences in how an overlay load
processes an FDT vs how the early boot processing of an FDT behaves.
This extra testing would verify that the overlay environment behaves
the same as the non-overlay environment (with some known exceptions
due to overlay policies).

Overlay support is not complete:

   https://elinux.org/Device_Tree_Reference#Mainline_Linux_Support

   https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts

-Frank

> apply a test managed overlay and automatically remove it when the test
> is over would work. The clk registration tests could use this API to
> inject an overlay and then manually call the of_platform_populate()
> function to create the platform device(s). The overlay could be built in
> drivers/clk/ too and then probably some macroish function can find the
> blob and apply it.
> 
> Is there some way to delete the platform devices that we populate from
> the overlay? I'd like the tests to be hermetic.


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/2/23 11:13, Rob Herring wrote:
> On Wed, Mar 1, 2023 at 7:38 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>
>> This patch series adds unit tests for the clk fixed rate basic type and
>> the clk registration functions that use struct clk_parent_data. To get
>> there, we add support for loading a DTB into the UML kernel that's
>> running the unit tests along with probing platform drivers to bind to
>> device nodes specified in DT.
>>
>> With this series, we're able to exercise some of the code in the common
>> clk framework that uses devicetree lookups to find parents and the fixed
>> rate clk code that scans devicetree directly and creates clks. Please
>> review.
>>
>> I Cced everyone to all the patches so they get the full context. I'm
>> hoping I can take the whole pile through the clk tree as they almost all
>> depend on each other. In the future I imagine it will be easy to add
>> more test nodes to the clk.dtsi file and not need to go across various
>> maintainer trees like this series does.
>>
>> Stephen Boyd (8):
>>   dt-bindings: Add linux,kunit binding
>>   of: Enable DTB loading on UML for KUnit tests
>>   kunit: Add test managed platform_device/driver APIs
>>   clk: Add test managed clk provider/consumer APIs
>>   dt-bindings: kunit: Add fixed rate clk consumer test
>>   clk: Add KUnit tests for clk fixed rate basic type
>>   dt-bindings: clk: Add KUnit clk_parent_data test
>>   clk: Add KUnit tests for clks registered with struct clk_parent_data
> 
> Good to see bindings for this. I've been meaning to do something about
> the DT unittest ones being undocumented, but I hadn't really decided
> whether it was worth writing schemas for them. The compatibles at
> least show up with 'make dt_compatible_check'. Perhaps we want to just
> define some vendor (not 'linux') that's an exception rather than
> requiring schemas (actually, that already works for 'foo'). It's
> likely that we want test DTs that fail normal checks and schemas get
> in the way of that as we don't have a way to turn off checks.
> 
> We already have GPIO tests in the DT unittests, so why is clocks
> different? Or should the GPIO tests be moved out (yes, please!)?
> 
> What happens when/if the DT unittest is converted to kunit? I think

My current plan is to update the DT unittest output to be compatible
with the kunit output, so test harnesses can use the same framework
to process test output, and detect and report results.

kunit moved to the KTAP format a while ago.  I am working (more slowly
than I would like) to get the next version of the KTAP specification
agreed to, which has some features that will be needed to move DT
unittests to the KTAP output format.

Whether it is possible to subsequently move DT unittests into the
kunit framework is a different question, which could be addressed
as a possible next step of DT unittest transformation (but see my
opinion below).

> that would look confusing from the naming. My initial thought is
> 'kunit' should be dropped from the naming of a lot of this. Note that
> the original kunit submission converted the DT unittests. I would
> still like to see that happen. Frank disagreed over what's a unit test
> or not, then agreed, then didn't... I don't really care. If there's a
> framework to use, then we should use it IMO.

I don't think I ever agreed that the kunit framework was suitable to
implement DT unittest.

At a conceptual level, kunit and DT unittest differ architecturally
(the following is not what kunit looks like - the procedural flow is
hidden away in macros and the source looks more like data declarations).

  kunit
  -----
  test_1_initialization();
  test_1();
     test_1_a();
     test_1_b();
     ...
     test_1_N();
  test_1_cleanup();

  ## Each of test_1_*() reports pass / fail / skip
  ## I'm not sure if this is just one pass / fail / skip, or
  ## if multiple are supported.
  ##
  ## Each of test_1_*() are independent and could be reordered.


  DT unittest
  -----------
  some_initialization_in_early_boot()
  of_unittest()
     a_lot_of_initialization();
     subsystem_or_area_1_test();
        test_area_initialization();
        test_1_a();
        ## test_1_a() may or may not impact the devicetree data
        ## in a manner that is pre-requisite for test_1_b()
        test_1_b();
        ...
        ## At any point in test_1_a() .. test_1_N() may goto
        ##   out_ERROR_xxx: if a test fails in a way that
        ##   impacts subsequent test dependencies
        ##
        ## Possible clean up between or after each test_1_*()
        ## Possible validation that the devicetreee data is correct
        ##   after test activity
        test_1_c();
        ...
        test_1_N();
     subsystem_or_area_2_test();
        ...
     ## At arbitrary points, full tree or sub-tree validation to
     ## confirm tree integrity after completing the previous tests
     ...

   ## Much of test_1_*() are dependent on previously executed
   ## test_1_*() and can _not_ be reordered.

-Frank



> 
>>
>>  .../clock/linux,clk-kunit-parent-data.yaml    |  47 ++
>>  .../kunit/linux,clk-kunit-fixed-rate.yaml     |  35 ++
>>  .../bindings/kunit/linux,kunit.yaml           |  24 +
>>  arch/um/kernel/dtb.c                          |  29 +-
>>  drivers/clk/.kunitconfig                      |   3 +
>>  drivers/clk/Kconfig                           |   7 +
>>  drivers/clk/Makefile                          |   6 +
>>  drivers/clk/clk-fixed-rate_test.c             | 296 ++++++++++++
>>  drivers/clk/clk-kunit.c                       | 204 ++++++++
>>  drivers/clk/clk-kunit.h                       |  28 ++
>>  drivers/clk/clk_test.c                        | 456 +++++++++++++++++-
>>  drivers/of/Kconfig                            |  26 +
>>  drivers/of/Makefile                           |   1 +
>>  drivers/of/kunit/.kunitconfig                 |   4 +
>>  drivers/of/kunit/Makefile                     |   4 +
>>  drivers/of/kunit/clk.dtsi                     |  30 ++
>>  drivers/of/kunit/kunit.dtsi                   |   9 +
>>  drivers/of/kunit/kunit.dtso                   |   4 +
>>  drivers/of/kunit/uml_dtb_test.c               |  55 +++
>>  include/kunit/platform_driver.h               |  15 +
>>  lib/kunit/Makefile                            |   6 +
>>  lib/kunit/platform_driver-test.c              | 107 ++++
>>  lib/kunit/platform_driver.c                   | 207 ++++++++
> 
> Humm, we have DT platform driver unittests too. What's the difference?
> 
> Anyways, that's all just my initial reaction from only halfway looking
> at this. :)
> 
> Rob


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/2/23 14:18, Rob Herring wrote:
> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>
>> Quoting Rob Herring (2023-03-02 09:13:59)
>>> On Wed, Mar 1, 2023 at 7:38 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>>>
>>>> This patch series adds unit tests for the clk fixed rate basic type and
>>>> the clk registration functions that use struct clk_parent_data. To get
>>>> there, we add support for loading a DTB into the UML kernel that's
>>>> running the unit tests along with probing platform drivers to bind to
>>>> device nodes specified in DT.
>>>>
>>>> With this series, we're able to exercise some of the code in the common
>>>> clk framework that uses devicetree lookups to find parents and the fixed
>>>> rate clk code that scans devicetree directly and creates clks. Please
>>>> review.
>>>>
>>>> I Cced everyone to all the patches so they get the full context. I'm
>>>> hoping I can take the whole pile through the clk tree as they almost all
>>>> depend on each other. In the future I imagine it will be easy to add
>>>> more test nodes to the clk.dtsi file and not need to go across various
>>>> maintainer trees like this series does.
>>>>
>>>> Stephen Boyd (8):
>>>>   dt-bindings: Add linux,kunit binding
>>>>   of: Enable DTB loading on UML for KUnit tests
>>>>   kunit: Add test managed platform_device/driver APIs
>>>>   clk: Add test managed clk provider/consumer APIs
>>>>   dt-bindings: kunit: Add fixed rate clk consumer test
>>>>   clk: Add KUnit tests for clk fixed rate basic type
>>>>   dt-bindings: clk: Add KUnit clk_parent_data test
>>>>   clk: Add KUnit tests for clks registered with struct clk_parent_data
>>>
>>> Good to see bindings for this. I've been meaning to do something about
>>> the DT unittest ones being undocumented, but I hadn't really decided
>>> whether it was worth writing schemas for them. The compatibles at
>>> least show up with 'make dt_compatible_check'. Perhaps we want to just
>>> define some vendor (not 'linux') that's an exception rather than
>>> requiring schemas (actually, that already works for 'foo').
>>
>> Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?
> 
> We'd want to use the same thing on the DT unittests or anything else
> potentially. How about just 'test'?
> 
>>> It's
>>> likely that we want test DTs that fail normal checks and schemas get
>>> in the way of that as we don't have a way to turn off checks.
>>
>> Having the schemas is nice to make sure tests that are expecting some
>> binding are actually getting that. But supporting broken bindings is
>> also important to test any error paths in functions that parse
>> properties. Maybe we keep the schema and have it enforce that incorrect
>> properties are being set?
> 
> I wasn't suggesting throwing them out. More why I hadn't written any I guess.
> 
>> Do we really need to test incorrect bindings? Doesn't the
>> dt_bindings_check catch these problems so we don't have to write DTB
>> verifiers in the kernel?
> 
> Fair enough. Using my frequently stated position against me. :)
> 
> I do have a secret plan to implement (debug) type checks into the
> of_property_* APIs by extracting the type information from schemas
> into C.
> 
> 
>>> We already have GPIO tests in the DT unittests, so why is clocks
>>> different? Or should the GPIO tests be moved out (yes, please!)?
>>
>> Ah I didn't notice the GPIO tests in there. There are i2c tests too,
>> right? All I can say is clks are using kunit, that's the difference ;-)
> 
> Yeah, they should perhaps all move to the subsystems.
> 
>>> What happens when/if the DT unittest is converted to kunit? I think
>>> that would look confusing from the naming. My initial thought is
>>> 'kunit' should be dropped from the naming of a lot of this. Note that
>>> the original kunit submission converted the DT unittests. I would
>>> still like to see that happen. Frank disagreed over what's a unit test
>>> or not, then agreed, then didn't... I don't really care. If there's a
>>> framework to use, then we should use it IMO.
>>
>> Honestly I don't want to get involved in migrating the existing DT
>> unittest code to kunit. I'm aware that it was attempted years ago when
>> kunit was introduced. Maybe if the overlay route works well enough I can
>> completely sidestep introducing any code in drivers/of/ besides some
>> kunit wrappers for this. I'll cross my fingers!
> 
> Yeah, I wasn't expecting you to. I just want to make sure this meshes
> with any future conversion to kunit.
> 
> There's also some plans to always populate the DT root node if not
> present. That may help here. Or not. There's been a few versions
> posted with Frank's in the last week or 2.

As noted in that thread, by code inspection (not actual testing) I
think that the patch series breaks DT unittest for UML.  It should be
a trivial change in the next patch version to fix.

> 
> Rob


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/2/23 17:57, Stephen Boyd wrote:
> Quoting Rob Herring (2023-03-02 12:18:34)
>> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>>
>>> Quoting Rob Herring (2023-03-02 09:13:59)
>>>>
>>>> Good to see bindings for this. I've been meaning to do something about
>>>> the DT unittest ones being undocumented, but I hadn't really decided
>>>> whether it was worth writing schemas for them. The compatibles at
>>>> least show up with 'make dt_compatible_check'. Perhaps we want to just
>>>> define some vendor (not 'linux') that's an exception rather than
>>>> requiring schemas (actually, that already works for 'foo').
>>>
>>> Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?
>>
>> We'd want to use the same thing on the DT unittests or anything else
>> potentially. How about just 'test'?
> 
> Sounds good.
> 
>>
>>>> It's
>>>> likely that we want test DTs that fail normal checks and schemas get
>>>> in the way of that as we don't have a way to turn off checks.
>>>
>>> Having the schemas is nice to make sure tests that are expecting some
>>> binding are actually getting that. But supporting broken bindings is
>>> also important to test any error paths in functions that parse
>>> properties. Maybe we keep the schema and have it enforce that incorrect
>>> properties are being set?
>>
>> I wasn't suggesting throwing them out. More why I hadn't written any I guess.
>>
>>> Do we really need to test incorrect bindings? Doesn't the
>>> dt_bindings_check catch these problems so we don't have to write DTB
>>> verifiers in the kernel?
>>
>> Fair enough. Using my frequently stated position against me. :)
>>
>> I do have a secret plan to implement (debug) type checks into the
>> of_property_* APIs by extracting the type information from schemas
>> into C.
>>
> 
> Ok. I suspect we may want to test error paths though so I don't know

Yes, exactly.

> what to do here. For now I'll just leave the bindings in place and
> change the prefix to "test".
> 
>>
>>>> We already have GPIO tests in the DT unittests, so why is clocks
>>>> different? Or should the GPIO tests be moved out (yes, please!)?
>>>
>>> Ah I didn't notice the GPIO tests in there. There are i2c tests too,
>>> right? All I can say is clks are using kunit, that's the difference ;-)
>>
>> Yeah, they should perhaps all move to the subsystems.
> 
> Got it.
> 
>>
>>>> What happens when/if the DT unittest is converted to kunit? I think
>>>> that would look confusing from the naming. My initial thought is
>>>> 'kunit' should be dropped from the naming of a lot of this. Note that
>>>> the original kunit submission converted the DT unittests. I would
>>>> still like to see that happen. Frank disagreed over what's a unit test
>>>> or not, then agreed, then didn't... I don't really care. If there's a
>>>> framework to use, then we should use it IMO.
>>>
>>> Honestly I don't want to get involved in migrating the existing DT
>>> unittest code to kunit. I'm aware that it was attempted years ago when
>>> kunit was introduced. Maybe if the overlay route works well enough I can
>>> completely sidestep introducing any code in drivers/of/ besides some
>>> kunit wrappers for this. I'll cross my fingers!
>>
>> Yeah, I wasn't expecting you to. I just want to make sure this meshes
>> with any future conversion to kunit.
> 
> Phew!
> 
>>
>> There's also some plans to always populate the DT root node if not
>> present. That may help here. Or not. There's been a few versions
>> posted with Frank's in the last week or 2.
>>
> 
> Ok. I think I have some time to try this overlay approach so let me see
> what is needed.

Please avoid overlays.  See my other replies in this thread for why.


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/1/23 19:38, Stephen Boyd wrote:
> This patch series adds unit tests for the clk fixed rate basic type and
> the clk registration functions that use struct clk_parent_data. To get
> there, we add support for loading a DTB into the UML kernel that's
> running the unit tests along with probing platform drivers to bind to
> device nodes specified in DT.
> 
> With this series, we're able to exercise some of the code in the common
> clk framework that uses devicetree lookups to find parents and the fixed
> rate clk code that scans devicetree directly and creates clks. Please
> review.

I would _really_ like to _not_ have devicetree tests in two locations:
DT unittests and kunit tests.

For my testing, I already build and boot four times on real hardware:

  1) no DT unittests
  2) CONFIG_OF_UNITTEST
  3) CONFIG_OF_UNITTEST
     CONFIG_OF_DYNAMIC
  4) CONFIG_OF_UNITTEST
     CONFIG_OF_DYNAMIC
     CONFIG_OF_OVERLAY

I really should also be testing the four configurations on UML, but at
the moment I am not.

I also check for new compile warnings at various warn levels for all
four configurations.

If I recall correctly, the kunit framework encourages more (many more?)
kunit config options to select which test(s) are build for a test run.
Someone please correct this paragraph if I am mis-stating.

Adding devicetree tests to kunit adds additional build and boot cycles
and additional test output streams to verify.

Are there any issues with DT unittests that preclude adding clk tests
into the DT unittests?

-Frank

> 
> I Cced everyone to all the patches so they get the full context. I'm
> hoping I can take the whole pile through the clk tree as they almost all
> depend on each other. In the future I imagine it will be easy to add
> more test nodes to the clk.dtsi file and not need to go across various
> maintainer trees like this series does.
> 
> Stephen Boyd (8):
>   dt-bindings: Add linux,kunit binding
>   of: Enable DTB loading on UML for KUnit tests
>   kunit: Add test managed platform_device/driver APIs
>   clk: Add test managed clk provider/consumer APIs
>   dt-bindings: kunit: Add fixed rate clk consumer test
>   clk: Add KUnit tests for clk fixed rate basic type
>   dt-bindings: clk: Add KUnit clk_parent_data test
>   clk: Add KUnit tests for clks registered with struct clk_parent_data
> 
>  .../clock/linux,clk-kunit-parent-data.yaml    |  47 ++
>  .../kunit/linux,clk-kunit-fixed-rate.yaml     |  35 ++
>  .../bindings/kunit/linux,kunit.yaml           |  24 +
>  arch/um/kernel/dtb.c                          |  29 +-
>  drivers/clk/.kunitconfig                      |   3 +
>  drivers/clk/Kconfig                           |   7 +
>  drivers/clk/Makefile                          |   6 +
>  drivers/clk/clk-fixed-rate_test.c             | 296 ++++++++++++
>  drivers/clk/clk-kunit.c                       | 204 ++++++++
>  drivers/clk/clk-kunit.h                       |  28 ++
>  drivers/clk/clk_test.c                        | 456 +++++++++++++++++-
>  drivers/of/Kconfig                            |  26 +
>  drivers/of/Makefile                           |   1 +
>  drivers/of/kunit/.kunitconfig                 |   4 +
>  drivers/of/kunit/Makefile                     |   4 +
>  drivers/of/kunit/clk.dtsi                     |  30 ++
>  drivers/of/kunit/kunit.dtsi                   |   9 +
>  drivers/of/kunit/kunit.dtso                   |   4 +
>  drivers/of/kunit/uml_dtb_test.c               |  55 +++
>  include/kunit/platform_driver.h               |  15 +
>  lib/kunit/Makefile                            |   6 +
>  lib/kunit/platform_driver-test.c              | 107 ++++
>  lib/kunit/platform_driver.c                   | 207 ++++++++
>  23 files changed, 1599 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/linux,clk-kunit-parent-data.yaml
>  create mode 100644 Documentation/devicetree/bindings/kunit/linux,clk-kunit-fixed-rate.yaml
>  create mode 100644 Documentation/devicetree/bindings/kunit/linux,kunit.yaml
>  create mode 100644 drivers/clk/clk-fixed-rate_test.c
>  create mode 100644 drivers/clk/clk-kunit.c
>  create mode 100644 drivers/clk/clk-kunit.h
>  create mode 100644 drivers/of/kunit/.kunitconfig
>  create mode 100644 drivers/of/kunit/Makefile
>  create mode 100644 drivers/of/kunit/clk.dtsi
>  create mode 100644 drivers/of/kunit/kunit.dtsi
>  create mode 100644 drivers/of/kunit/kunit.dtso
>  create mode 100644 drivers/of/kunit/uml_dtb_test.c
>  create mode 100644 include/kunit/platform_driver.h
>  create mode 100644 lib/kunit/platform_driver-test.c
>  create mode 100644 lib/kunit/platform_driver.c
> 
> 
> base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/2/23 13:47, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Thu, Mar 2, 2023 at 8:28 PM Stephen Boyd <sboyd@kernel.org> wrote:
>> Quoting Rob Herring (2023-03-02 09:32:09)
>>> On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
>>>> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>> This patch series adds unit tests for the clk fixed rate basic type and
>>>>> the clk registration functions that use struct clk_parent_data. To get
>>>>> there, we add support for loading a DTB into the UML kernel that's
>>>>> running the unit tests along with probing platform drivers to bind to
>>>>> device nodes specified in DT.
>>>>>
>>>>> With this series, we're able to exercise some of the code in the common
>>>>> clk framework that uses devicetree lookups to find parents and the fixed
>>>>> rate clk code that scans devicetree directly and creates clks. Please
>>>>> review.
>>>>>
>>>>
>>>> Thanks Stephen -- this is really neat!
>>>>
>>>> This works well here, and I love all of the tests for the
>>>> KUnit/device-tree integration as well.
>>>>
>>>> I'm still looking through the details of it (alas, I've mostly lived
>>>> in x86-land, so my device-tree knowledge is, uh, spotty to say the
>>>> least), but apart from possibly renaming some things or similarly
>>>> minor tweaks, I've not got any real suggestions thus far.
>>>>
>>>> I do wonder whether we'll want, on the KUnit side, to have some way of
>>>> supporting KUnit device trees on non-UML architecctures (e.g., if we
>>>> need to test something architecture-specific, or on a big-endian
>>>> platform, etc), but I think that's a question for the future, rather
>>>> than something that affects this series.
>>>
>>> I'll say that's a requirement. We should be able to structure the
>>> tests to not interfere with the running system's DT. The DT unittest
>>> does that.
>>
>> That could be another choice in the unit test choice menu.
>> CONFIG_OF_KUNIT_NOT_UML that injects some built-in DTB overlay on an
>> architecture that wants to run tests.
> 
> As long as you use compatible values that don't exist elsewhere,
> and don't overwrite anything, you can load your kunit test overlays
> on any running system that has DT support.
> 
>>> As a side topic, Is anyone looking at getting UML to work on arm64?
>>> It's surprising how much x86 stuff there is which is I guess one
>>> reason it hasn't happened.
>>
>> I've no idea but it would be nice indeed.
> 
> I believe that's non-trivial. At least for arm32 (I didn't have any arm64
> systems last time I asked the experts).
> 
>>>> Similarly, I wonder if there's something we could do with device tree
>>>> overlays, in order to make it possible for tests to swap nodes in and
>>>> out for testing.
>>>
>>> Yes, that's how the DT unittest works. But it is pretty much one big
>>> overlay (ignoring the overlay tests). It could probably be more
>>> modular where it is apply overlay, test, remove overlay, repeat.
>>
>> I didn't want to rely on the overlay code to inject DT nodes. Having
>> tests written for the fake KUnit machine is simple. It closely matches
>> how clk code probes the DTB and how nodes are created and populated on
>> the platform bus as devices. CLK_OF_DECLARE() would need the overlay to
>> be applied early too, which doesn't happen otherwise as far as I know.
> 
> Don't all generic clock drivers also create a platform driver?
> At least drivers/clk/clk-fixed-factor.c does.
> 
>> But perhaps this design is too much of an end-to-end test and not a unit
>> test? In the spirit of unit testing we shouldn't care about how the node
>> is added to the live devicetree, just that there is a devicetree at all.
>>
>> Supporting overlays to more easily test combinations sounds like a good
>> idea. Probably some kunit_*() prefixed functions could be used to
>> apply a test managed overlay and automatically remove it when the test
>> is over would work. The clk registration tests could use this API to
>> inject an overlay and then manually call the of_platform_populate()
>> function to create the platform device(s). The overlay could be built in
>> drivers/clk/ too and then probably some macroish function can find the
>> blob and apply it.
> 
> No need to manually call of_platform_populate() to create the
> platform devices. That is taken care of automatically when applying
> an overlay.
> 
>> Is there some way to delete the platform devices that we populate from
>> the overlay? I'd like the tests to be hermetic.
> 

> Removing the overlay will delete the platform devices.

I _think_ that is incorrect.  Do you have a pointer to the overlay code that
deletes the device?  (If I remember correctly, the overlay remove code does not
even check whether the device exists and whether a driver is bound to it -- but
this is on my todo list to look into.)

-Frank

> 
> All of that works if you have your own code to apply a DT overlay.
> The recent fw_devlinks patches did cause some regressions, cfr.
> https://lore.kernel.org/all/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com
> 
> P.S. Shameless plug: for loading overlays from userspace, there are
>      my overlay branches, cfr. https://elinux.org/R-Car/DT-Overlays
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Geert Uytterhoeven]

Hi Frank,

On Sun, Mar 5, 2023 at 4:33 AM Frank Rowand <frowand.list@gmail.com> wrote:
> On 3/2/23 13:47, Geert Uytterhoeven wrote:
> > On Thu, Mar 2, 2023 at 8:28 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >> Quoting Rob Herring (2023-03-02 09:32:09)
> >>> On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
> >>>> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >>>>> This patch series adds unit tests for the clk fixed rate basic type and
> >>>>> the clk registration functions that use struct clk_parent_data. To get
> >>>>> there, we add support for loading a DTB into the UML kernel that's
> >>>>> running the unit tests along with probing platform drivers to bind to
> >>>>> device nodes specified in DT.
> >>>>>
> >>>>> With this series, we're able to exercise some of the code in the common
> >>>>> clk framework that uses devicetree lookups to find parents and the fixed
> >>>>> rate clk code that scans devicetree directly and creates clks. Please
> >>>>> review.
> >>>>>
> >>>>
> >>>> Thanks Stephen -- this is really neat!
> >>>>
> >>>> This works well here, and I love all of the tests for the
> >>>> KUnit/device-tree integration as well.
> >>>>
> >>>> I'm still looking through the details of it (alas, I've mostly lived
> >>>> in x86-land, so my device-tree knowledge is, uh, spotty to say the
> >>>> least), but apart from possibly renaming some things or similarly
> >>>> minor tweaks, I've not got any real suggestions thus far.
> >>>>
> >>>> I do wonder whether we'll want, on the KUnit side, to have some way of
> >>>> supporting KUnit device trees on non-UML architecctures (e.g., if we
> >>>> need to test something architecture-specific, or on a big-endian
> >>>> platform, etc), but I think that's a question for the future, rather
> >>>> than something that affects this series.
> >>>
> >>> I'll say that's a requirement. We should be able to structure the
> >>> tests to not interfere with the running system's DT. The DT unittest
> >>> does that.
> >>
> >> That could be another choice in the unit test choice menu.
> >> CONFIG_OF_KUNIT_NOT_UML that injects some built-in DTB overlay on an
> >> architecture that wants to run tests.
> >
> > As long as you use compatible values that don't exist elsewhere,
> > and don't overwrite anything, you can load your kunit test overlays
> > on any running system that has DT support.
> >
> >>> As a side topic, Is anyone looking at getting UML to work on arm64?
> >>> It's surprising how much x86 stuff there is which is I guess one
> >>> reason it hasn't happened.
> >>
> >> I've no idea but it would be nice indeed.
> >
> > I believe that's non-trivial. At least for arm32 (I didn't have any arm64
> > systems last time I asked the experts).
> >
> >>>> Similarly, I wonder if there's something we could do with device tree
> >>>> overlays, in order to make it possible for tests to swap nodes in and
> >>>> out for testing.
> >>>
> >>> Yes, that's how the DT unittest works. But it is pretty much one big
> >>> overlay (ignoring the overlay tests). It could probably be more
> >>> modular where it is apply overlay, test, remove overlay, repeat.
> >>
> >> I didn't want to rely on the overlay code to inject DT nodes. Having
> >> tests written for the fake KUnit machine is simple. It closely matches
> >> how clk code probes the DTB and how nodes are created and populated on
> >> the platform bus as devices. CLK_OF_DECLARE() would need the overlay to
> >> be applied early too, which doesn't happen otherwise as far as I know.
> >
> > Don't all generic clock drivers also create a platform driver?
> > At least drivers/clk/clk-fixed-factor.c does.
> >
> >> But perhaps this design is too much of an end-to-end test and not a unit
> >> test? In the spirit of unit testing we shouldn't care about how the node
> >> is added to the live devicetree, just that there is a devicetree at all.
> >>
> >> Supporting overlays to more easily test combinations sounds like a good
> >> idea. Probably some kunit_*() prefixed functions could be used to
> >> apply a test managed overlay and automatically remove it when the test
> >> is over would work. The clk registration tests could use this API to
> >> inject an overlay and then manually call the of_platform_populate()
> >> function to create the platform device(s). The overlay could be built in
> >> drivers/clk/ too and then probably some macroish function can find the
> >> blob and apply it.
> >
> > No need to manually call of_platform_populate() to create the
> > platform devices. That is taken care of automatically when applying
> > an overlay.
> >
> >> Is there some way to delete the platform devices that we populate from
> >> the overlay? I'd like the tests to be hermetic.
>
> > Removing the overlay will delete the platform devices.
>
> I _think_ that is incorrect.  Do you have a pointer to the overlay code that
> deletes the device?  (If I remember correctly, the overlay remove code does not
> even check whether the device exists and whether a driver is bound to it -- but
> this is on my todo list to look into.)

https://elixir.bootlin.com/linux/latest/source/drivers/of/platform.c#L769

> > All of that works if you have your own code to apply a DT overlay.
> > The recent fw_devlinks patches did cause some regressions, cfr.
> > https://lore.kernel.org/all/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/5/23 03:26, Geert Uytterhoeven wrote:
> Hi Frank,
> 
> On Sun, Mar 5, 2023 at 4:33 AM Frank Rowand <frowand.list@gmail.com> wrote:
>> On 3/2/23 13:47, Geert Uytterhoeven wrote:
>>> On Thu, Mar 2, 2023 at 8:28 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>>> Quoting Rob Herring (2023-03-02 09:32:09)
>>>>> On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow@google.com> wrote:
>>>>>> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>>> This patch series adds unit tests for the clk fixed rate basic type and
>>>>>>> the clk registration functions that use struct clk_parent_data. To get
>>>>>>> there, we add support for loading a DTB into the UML kernel that's
>>>>>>> running the unit tests along with probing platform drivers to bind to
>>>>>>> device nodes specified in DT.
>>>>>>>
>>>>>>> With this series, we're able to exercise some of the code in the common
>>>>>>> clk framework that uses devicetree lookups to find parents and the fixed
>>>>>>> rate clk code that scans devicetree directly and creates clks. Please
>>>>>>> review.
>>>>>>>
>>>>>>
>>>>>> Thanks Stephen -- this is really neat!
>>>>>>
>>>>>> This works well here, and I love all of the tests for the
>>>>>> KUnit/device-tree integration as well.
>>>>>>
>>>>>> I'm still looking through the details of it (alas, I've mostly lived
>>>>>> in x86-land, so my device-tree knowledge is, uh, spotty to say the
>>>>>> least), but apart from possibly renaming some things or similarly
>>>>>> minor tweaks, I've not got any real suggestions thus far.
>>>>>>
>>>>>> I do wonder whether we'll want, on the KUnit side, to have some way of
>>>>>> supporting KUnit device trees on non-UML architecctures (e.g., if we
>>>>>> need to test something architecture-specific, or on a big-endian
>>>>>> platform, etc), but I think that's a question for the future, rather
>>>>>> than something that affects this series.
>>>>>
>>>>> I'll say that's a requirement. We should be able to structure the
>>>>> tests to not interfere with the running system's DT. The DT unittest
>>>>> does that.
>>>>
>>>> That could be another choice in the unit test choice menu.
>>>> CONFIG_OF_KUNIT_NOT_UML that injects some built-in DTB overlay on an
>>>> architecture that wants to run tests.
>>>
>>> As long as you use compatible values that don't exist elsewhere,
>>> and don't overwrite anything, you can load your kunit test overlays
>>> on any running system that has DT support.
>>>
>>>>> As a side topic, Is anyone looking at getting UML to work on arm64?
>>>>> It's surprising how much x86 stuff there is which is I guess one
>>>>> reason it hasn't happened.
>>>>
>>>> I've no idea but it would be nice indeed.
>>>
>>> I believe that's non-trivial. At least for arm32 (I didn't have any arm64
>>> systems last time I asked the experts).
>>>
>>>>>> Similarly, I wonder if there's something we could do with device tree
>>>>>> overlays, in order to make it possible for tests to swap nodes in and
>>>>>> out for testing.
>>>>>
>>>>> Yes, that's how the DT unittest works. But it is pretty much one big
>>>>> overlay (ignoring the overlay tests). It could probably be more
>>>>> modular where it is apply overlay, test, remove overlay, repeat.
>>>>
>>>> I didn't want to rely on the overlay code to inject DT nodes. Having
>>>> tests written for the fake KUnit machine is simple. It closely matches
>>>> how clk code probes the DTB and how nodes are created and populated on
>>>> the platform bus as devices. CLK_OF_DECLARE() would need the overlay to
>>>> be applied early too, which doesn't happen otherwise as far as I know.
>>>
>>> Don't all generic clock drivers also create a platform driver?
>>> At least drivers/clk/clk-fixed-factor.c does.
>>>
>>>> But perhaps this design is too much of an end-to-end test and not a unit
>>>> test? In the spirit of unit testing we shouldn't care about how the node
>>>> is added to the live devicetree, just that there is a devicetree at all.
>>>>
>>>> Supporting overlays to more easily test combinations sounds like a good
>>>> idea. Probably some kunit_*() prefixed functions could be used to
>>>> apply a test managed overlay and automatically remove it when the test
>>>> is over would work. The clk registration tests could use this API to
>>>> inject an overlay and then manually call the of_platform_populate()
>>>> function to create the platform device(s). The overlay could be built in
>>>> drivers/clk/ too and then probably some macroish function can find the
>>>> blob and apply it.
>>>
>>> No need to manually call of_platform_populate() to create the
>>> platform devices. That is taken care of automatically when applying
>>> an overlay.
>>>
>>>> Is there some way to delete the platform devices that we populate from
>>>> the overlay? I'd like the tests to be hermetic.
>>
>>> Removing the overlay will delete the platform devices.
>>
>> I _think_ that is incorrect.  Do you have a pointer to the overlay code that
>> deletes the device?  (If I remember correctly, the overlay remove code does not
>> even check whether the device exists and whether a driver is bound to it -- but
>> this is on my todo list to look into.)
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/of/platform.c#L769

Thanks!  That is precisely what I failed to remember.

-Frank

> 
>>> All of that works if you have your own code to apply a DT overlay.
>>> The recent fw_devlinks patches did cause some regressions, cfr.
>>> https://lore.kernel.org/all/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Rob Herring]

On Sat, Mar 4, 2023 at 9:39 AM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 3/2/23 17:57, Stephen Boyd wrote:
> > Quoting Rob Herring (2023-03-02 12:18:34)
> >> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >>>
> >>> Quoting Rob Herring (2023-03-02 09:13:59)
> >>>>
> >>>> Good to see bindings for this. I've been meaning to do something about
> >>>> the DT unittest ones being undocumented, but I hadn't really decided
> >>>> whether it was worth writing schemas for them. The compatibles at
> >>>> least show up with 'make dt_compatible_check'. Perhaps we want to just
> >>>> define some vendor (not 'linux') that's an exception rather than
> >>>> requiring schemas (actually, that already works for 'foo').
> >>>
> >>> Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?
> >>
> >> We'd want to use the same thing on the DT unittests or anything else
> >> potentially. How about just 'test'?
> >
> > Sounds good.
> >
> >>
> >>>> It's
> >>>> likely that we want test DTs that fail normal checks and schemas get
> >>>> in the way of that as we don't have a way to turn off checks.
> >>>
> >>> Having the schemas is nice to make sure tests that are expecting some
> >>> binding are actually getting that. But supporting broken bindings is
> >>> also important to test any error paths in functions that parse
> >>> properties. Maybe we keep the schema and have it enforce that incorrect
> >>> properties are being set?
> >>
> >> I wasn't suggesting throwing them out. More why I hadn't written any I guess.
> >>
> >>> Do we really need to test incorrect bindings? Doesn't the
> >>> dt_bindings_check catch these problems so we don't have to write DTB
> >>> verifiers in the kernel?
> >>
> >> Fair enough. Using my frequently stated position against me. :)
> >>
> >> I do have a secret plan to implement (debug) type checks into the
> >> of_property_* APIs by extracting the type information from schemas
> >> into C.
> >>
> >
> > Ok. I suspect we may want to test error paths though so I don't know
>
> Yes, exactly.
>
> > what to do here. For now I'll just leave the bindings in place and
> > change the prefix to "test".
> >
> >>
> >>>> We already have GPIO tests in the DT unittests, so why is clocks
> >>>> different? Or should the GPIO tests be moved out (yes, please!)?
> >>>
> >>> Ah I didn't notice the GPIO tests in there. There are i2c tests too,
> >>> right? All I can say is clks are using kunit, that's the difference ;-)
> >>
> >> Yeah, they should perhaps all move to the subsystems.
> >
> > Got it.
> >
> >>
> >>>> What happens when/if the DT unittest is converted to kunit? I think
> >>>> that would look confusing from the naming. My initial thought is
> >>>> 'kunit' should be dropped from the naming of a lot of this. Note that
> >>>> the original kunit submission converted the DT unittests. I would
> >>>> still like to see that happen. Frank disagreed over what's a unit test
> >>>> or not, then agreed, then didn't... I don't really care. If there's a
> >>>> framework to use, then we should use it IMO.
> >>>
> >>> Honestly I don't want to get involved in migrating the existing DT
> >>> unittest code to kunit. I'm aware that it was attempted years ago when
> >>> kunit was introduced. Maybe if the overlay route works well enough I can
> >>> completely sidestep introducing any code in drivers/of/ besides some
> >>> kunit wrappers for this. I'll cross my fingers!
> >>
> >> Yeah, I wasn't expecting you to. I just want to make sure this meshes
> >> with any future conversion to kunit.
> >
> > Phew!
> >
> >>
> >> There's also some plans to always populate the DT root node if not
> >> present. That may help here. Or not. There's been a few versions
> >> posted with Frank's in the last week or 2.
> >>
> >
> > Ok. I think I have some time to try this overlay approach so let me see
> > what is needed.
>
> Please avoid overlays.  See my other replies in this thread for why.

If overlays work for the constrained environment of unit tests, then
use them. If overlays are not to be used, then remove the support from
the kernel. Putting issues in a todo list is not going to get them
done. Having users will.

Rob

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/6/23 06:53, Rob Herring wrote:
> On Sat, Mar 4, 2023 at 9:39 AM Frank Rowand <frowand.list@gmail.com> wrote:
>>
>> On 3/2/23 17:57, Stephen Boyd wrote:
>>> Quoting Rob Herring (2023-03-02 12:18:34)
>>>> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>
>>>>> Quoting Rob Herring (2023-03-02 09:13:59)
>>>>>>
>>>>>> Good to see bindings for this. I've been meaning to do something about
>>>>>> the DT unittest ones being undocumented, but I hadn't really decided
>>>>>> whether it was worth writing schemas for them. The compatibles at
>>>>>> least show up with 'make dt_compatible_check'. Perhaps we want to just
>>>>>> define some vendor (not 'linux') that's an exception rather than
>>>>>> requiring schemas (actually, that already works for 'foo').
>>>>>
>>>>> Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?
>>>>
>>>> We'd want to use the same thing on the DT unittests or anything else
>>>> potentially. How about just 'test'?
>>>
>>> Sounds good.
>>>
>>>>
>>>>>> It's
>>>>>> likely that we want test DTs that fail normal checks and schemas get
>>>>>> in the way of that as we don't have a way to turn off checks.
>>>>>
>>>>> Having the schemas is nice to make sure tests that are expecting some
>>>>> binding are actually getting that. But supporting broken bindings is
>>>>> also important to test any error paths in functions that parse
>>>>> properties. Maybe we keep the schema and have it enforce that incorrect
>>>>> properties are being set?
>>>>
>>>> I wasn't suggesting throwing them out. More why I hadn't written any I guess.
>>>>
>>>>> Do we really need to test incorrect bindings? Doesn't the
>>>>> dt_bindings_check catch these problems so we don't have to write DTB
>>>>> verifiers in the kernel?
>>>>
>>>> Fair enough. Using my frequently stated position against me. :)
>>>>
>>>> I do have a secret plan to implement (debug) type checks into the
>>>> of_property_* APIs by extracting the type information from schemas
>>>> into C.
>>>>
>>>
>>> Ok. I suspect we may want to test error paths though so I don't know
>>
>> Yes, exactly.
>>
>>> what to do here. For now I'll just leave the bindings in place and
>>> change the prefix to "test".
>>>
>>>>
>>>>>> We already have GPIO tests in the DT unittests, so why is clocks
>>>>>> different? Or should the GPIO tests be moved out (yes, please!)?
>>>>>
>>>>> Ah I didn't notice the GPIO tests in there. There are i2c tests too,
>>>>> right? All I can say is clks are using kunit, that's the difference ;-)
>>>>
>>>> Yeah, they should perhaps all move to the subsystems.
>>>
>>> Got it.
>>>
>>>>
>>>>>> What happens when/if the DT unittest is converted to kunit? I think
>>>>>> that would look confusing from the naming. My initial thought is
>>>>>> 'kunit' should be dropped from the naming of a lot of this. Note that
>>>>>> the original kunit submission converted the DT unittests. I would
>>>>>> still like to see that happen. Frank disagreed over what's a unit test
>>>>>> or not, then agreed, then didn't... I don't really care. If there's a
>>>>>> framework to use, then we should use it IMO.
>>>>>
>>>>> Honestly I don't want to get involved in migrating the existing DT
>>>>> unittest code to kunit. I'm aware that it was attempted years ago when
>>>>> kunit was introduced. Maybe if the overlay route works well enough I can
>>>>> completely sidestep introducing any code in drivers/of/ besides some
>>>>> kunit wrappers for this. I'll cross my fingers!
>>>>
>>>> Yeah, I wasn't expecting you to. I just want to make sure this meshes
>>>> with any future conversion to kunit.
>>>
>>> Phew!
>>>
>>>>
>>>> There's also some plans to always populate the DT root node if not
>>>> present. That may help here. Or not. There's been a few versions
>>>> posted with Frank's in the last week or 2.
>>>>
>>>
>>> Ok. I think I have some time to try this overlay approach so let me see
>>> what is needed.
>>
>> Please avoid overlays.  See my other replies in this thread for why.
> 
> If overlays work for the constrained environment of unit tests, then
> use them. If overlays are not to be used, then remove the support from
> the kernel. Putting issues in a todo list is not going to get them
> done. Having users will.

Overlays are not used to enable OF unittests that are unrelated to
overlays (to the best of my memory - I reserve the right to be
corrected).  Overlay usage in OF unittests is specifically to test
overlay features.

> 
> Rob


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Stephen Boyd]

Quoting Frank Rowand (2023-03-04 07:04:48)
> On 3/2/23 13:27, Stephen Boyd wrote:
> > 
> > But perhaps this design is too much of an end-to-end test and not a unit
> > test? In the spirit of unit testing we shouldn't care about how the node
> > is added to the live devicetree, just that there is a devicetree at all.
> > 
> > Supporting overlays to more easily test combinations sounds like a good
> > idea. Probably some kunit_*() prefixed functions could be used to
> 
> In an imaginary world where overlay support was completed, then _maybe_.
> 
> To me, the most important  environment to test is where the devictree
> data is populated in early boot from an FDT.  This is the environment
> that drivers currently exist in.
> 
> Populating devicetree data via an overlay adds in the functioning of the
> overlay apply code (and how the rules behind that functioning may differ
> from devicetree data populated in early boot from an FDT).

For the purposes of clk unit tests I don't care where the devicetree
nodes come from. All I care about is that they're rooted in the live
devicetree for the system and that they have platform devices attached
to them. The clk unit tests will assert that the overlay has been
applied and that should be sufficient to make sure the tests has
satisfied pre-conditions.

If these were end-to-end tests then I would agree that making the nodes
be loaded during early boot from an FDT would be the right approach.
That would test the integration of early DTB loading and code that runs
on the FDT. These aren't integration tests though, so when the nodes are
created and unflattened doesn't matter.

I'll introduce various unit tests around the kunit specific overlay
application API so that I know it makes platform devices and they have
device nodes attached to them. And those same tests should be able to
confirm that devices are destroyed when the overlay is removed.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Stephen Boyd]

Quoting Maxime Ripard (2023-03-03 06:38:35)
> Hi,
> 
> On Wed, Mar 01, 2023 at 05:38:13PM -0800, Stephen Boyd wrote:
> > This patch series adds unit tests for the clk fixed rate basic type and
> > the clk registration functions that use struct clk_parent_data. To get
> > there, we add support for loading a DTB into the UML kernel that's
> > running the unit tests along with probing platform drivers to bind to
> > device nodes specified in DT.
> > 
> > With this series, we're able to exercise some of the code in the common
> > clk framework that uses devicetree lookups to find parents and the fixed
> > rate clk code that scans devicetree directly and creates clks. Please
> > review.
> > 
> > I Cced everyone to all the patches so they get the full context. I'm
> > hoping I can take the whole pile through the clk tree as they almost all
> > depend on each other. In the future I imagine it will be easy to add
> > more test nodes to the clk.dtsi file and not need to go across various
> > maintainer trees like this series does.
> 
> That's really great, thanks!
> 
> I wanted to have a look at how we could possibly do this for DRM, I
> guess I have a starting point now :)
> 

Cool, thanks. You're on Cc now.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Rob Herring]

On Wed, Mar 01, 2023 at 05:38:15PM -0800, Stephen Boyd wrote:
> To fully exercise common clk framework code in KUnit we need to
> associate 'struct device' pointers with 'struct device_node' pointers so
> that things like clk_get() can parse DT nodes for 'clocks' and so that
> clk providers can use DT to provide clks; the most common mode of
> operation for clk providers.
> 
> Adding support to KUnit so that it loads a DTB is fairly simple after
> commit b31297f04e86 ("um: Add devicetree support"). We can simply pass a
> pre-compiled deviectree blob (DTB) on the kunit.py commandline and UML
> will load it. The problem is that tests won't know that the commandline
> has been modified, nor that a DTB has been loaded. Take a different
> approach so that tests can skip if a DTB hasn't been loaded.
> 
> Reuse the Makefile logic from the OF unittests to build a DTB into the
> kernel. This DTB will be for the mythical machine "linux,kunit", i.e.
> the devicetree for the KUnit "board". In practice, it is a dtsi file
> that will gather includes for kunit tests that rely in part on a
> devicetree being loaded. The devicetree should only be loaded if
> CONFIG_OF_KUNIT=y. Make that a choice config parallel to the existing
> CONFIG_OF_UNITTEST so that only one devicetree can be loaded in the
> system at a time. Similarly, the kernel commandline option to load a
> DTB is ignored if CONFIG_OF_KUNIT is enabled so that only one DTB is
> loaded at a time.
> 
> Add a simple unit test to confirm that the DTB loading worked. Future
> tests will add to the kunit.dtsi file to include their specific test
> nodes.
> 
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
>  arch/um/kernel/dtb.c            | 29 +++++++++++++++--
>  drivers/of/Kconfig              | 26 ++++++++++++++++
>  drivers/of/Makefile             |  1 +
>  drivers/of/kunit/.kunitconfig   |  4 +++
>  drivers/of/kunit/Makefile       |  4 +++
>  drivers/of/kunit/kunit.dtsi     |  8 +++++
>  drivers/of/kunit/kunit.dtso     |  4 +++
>  drivers/of/kunit/uml_dtb_test.c | 55 +++++++++++++++++++++++++++++++++
>  8 files changed, 128 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/of/kunit/.kunitconfig
>  create mode 100644 drivers/of/kunit/Makefile
>  create mode 100644 drivers/of/kunit/kunit.dtsi
>  create mode 100644 drivers/of/kunit/kunit.dtso
>  create mode 100644 drivers/of/kunit/uml_dtb_test.c
> 
> diff --git a/arch/um/kernel/dtb.c b/arch/um/kernel/dtb.c
> index 484141b06938..ee63951b12df 100644
> --- a/arch/um/kernel/dtb.c
> +++ b/arch/um/kernel/dtb.c
> @@ -15,9 +15,32 @@ void uml_dtb_init(void)
>  	long long size;
>  	void *area;
>  
> -	area = uml_load_file(dtb, &size);
> -	if (!area)
> -		return;
> +	if (IS_ENABLED(CONFIG_OF_KUNIT)) {
> +		/*
> +		 * __dtbo_kunit_begin[] and __dtbo_kunit_end[] are magically
> +		 * created by cmd_dt_S_dtbo in scripts/Makefile.lib from the
> +		 * drivers/of/kunit/kunit.dtsi file.
> +		 */
> +		extern uint8_t __dtbo_kunit_begin[];
> +		extern uint8_t __dtbo_kunit_end[];
> +
> +		size = __dtbo_kunit_end - __dtbo_kunit_begin;
> +		if (!size) {
> +			pr_warn("%s: kunit testcases is empty\n", __func__);
> +			return;
> +		}
> +
> +		/* creating copy */
> +		area = memblock_alloc(size, 8);
> +		if (!area)
> +			return;
> +
> +		memcpy(area, __dtbo_kunit_begin, size);
> +	} else {
> +		area = uml_load_file(dtb, &size);
> +		if (!area)
> +			return;
> +	}
>  
>  	if (!early_init_dt_scan(area)) {
>  		pr_err("invalid DTB %s\n", dtb);
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 80b5fd44ab1c..1f968b6a3dde 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -12,6 +12,20 @@ menuconfig OF
>  
>  if OF
>  
> +choice

No. This needs to be reworked such that a kernel rebuild is not needed 
to run different tests. I suspect that the overlay approach will do that 
for you.

> +	prompt "Devicetree Runtime Tests"
> +	default OF_UNITTEST
> +
> +config OF_KUNIT
> +	bool "Devicetree KUnit support" if KUNIT
> +	depends on UML

This is not a great dependency either...

Rob

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 1/8] dt-bindings: Add linux,kunit binding

[Stephen Boyd]

Quoting David Gow (2023-03-02 23:14:55)
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Document the linux,kunit board compatible string. This board is loaded
> > into the Linux kernel when KUnit is testing devicetree dependent code.
> 
> As with the series as a whole, this might need to change a little bit
> if we want to either use devicetree overlays and/or other
> architectures.
> 
> That being said, I'm okay with having this until then: the only real
> topic for bikeshedding is the name.
> - Is KUnit best as a board name, or part of the vendor name?
> - Do we want to include the architecture in the name?
> Should it be "linux,kunit", "linux-kunit,uml", "linux,kunit-uml", etc?

I think I will drop this patch. I have overlays working. I hijacked
of_core_init() to load the testcase data from drivers/of/unittest-data
and made a container node for kunit overlays to apply to.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Stephen Boyd]

Quoting David Gow (2023-03-02 23:15:04)
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > To fully exercise common clk framework code in KUnit we need to
> > associate 'struct device' pointers with 'struct device_node' pointers so
> > that things like clk_get() can parse DT nodes for 'clocks' and so that
> > clk providers can use DT to provide clks; the most common mode of
> > operation for clk providers.
> >
> > Adding support to KUnit so that it loads a DTB is fairly simple after
> > commit b31297f04e86 ("um: Add devicetree support"). We can simply pass a
> > pre-compiled deviectree blob (DTB) on the kunit.py commandline and UML
> > will load it. The problem is that tests won't know that the commandline
> > has been modified, nor that a DTB has been loaded. Take a different
> > approach so that tests can skip if a DTB hasn't been loaded.
> >
> > Reuse the Makefile logic from the OF unittests to build a DTB into the
> > kernel. This DTB will be for the mythical machine "linux,kunit", i.e.
> > the devicetree for the KUnit "board". In practice, it is a dtsi file
> > that will gather includes for kunit tests that rely in part on a
> > devicetree being loaded. The devicetree should only be loaded if
> > CONFIG_OF_KUNIT=y. Make that a choice config parallel to the existing
> > CONFIG_OF_UNITTEST so that only one devicetree can be loaded in the
> > system at a time. Similarly, the kernel commandline option to load a
> > DTB is ignored if CONFIG_OF_KUNIT is enabled so that only one DTB is
> > loaded at a time.
> 
> This feels a little bit like it's just papering over the real problem,
> which is that there's no way tests can skip themselves if no DTB is
> loaded.

Hmm. I think you're suggesting that the unit test data be loaded
whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
CONFIG_OF and skip if it isn't enabled?

> 
> That being said, I do think that there's probably some sense in
> supporting the compiled-in DTB as well (it's definitely simpler than
> patching kunit.py to always pass the extra command-line option in, for
> example).
> But maybe it'd be nice to have the command-line option override the
> built-in one if present.

Got it. I need to test loading another DTB on the commandline still, but
I think this won't be a problem. We'll load the unittest-data DTB even
with KUnit on UML, so assuming that works on UML right now it should be
unchanged by this series once I resend.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 3/8] kunit: Add test managed platform_device/driver APIs

[Stephen Boyd]

Quoting David Gow (2023-03-02 23:15:31)
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Introduce KUnit resource wrappers around platform_driver_register(),
> > platform_device_alloc(), and platform_device_add() so that test authors
> > can register platform drivers/devices from their tests and have the
> > drivers/devices automatically be unregistered when the test is done.
> >
> > This makes test setup code simpler when a platform driver or platform
> > device is needed. Add a few test cases at the same time to make sure the
> > APIs work as intended.
> >
> > Cc: Brendan Higgins <brendan.higgins@linux.dev>
> > Cc: David Gow <davidgow@google.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> > ---
> >
> > Should this be moved to drivers/base/ and called platform_kunit.c?
> > The include/kunit/platform_driver.h could also be
> > kunit/platform_device.h to match linux/platform_device.h if that is more
> > familiar.
> 
> DRM has a similar thing already (albeit with a root_device, which is
> more common with KUnit tests generally):
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_kunit_helpers.h
> 
> But that's reasonably drm-specific, so it makes sense that it lives
> with DRM stuff. platform_device is a bit more generic.
> 
> I'd probably personally err on the side of having these in
> drivers/base/, as I think we'll ultimately need similar things for a
> lot of different devices, and I'd rather not end up with things like
> USB device helpers living in the lib/kunit directory alongside the
> "core" KUnit code. But I could be persuaded otherwise.

Ok no problem. I'll move it.

> 
> >
> > And I'm not super certain about allocating a driver structure and
> > embedding it in a wrapper struct. Maybe the code should just use
> > kunit_get_current_test() instead?
> 
> I think there are enough cases througout the kernel where
> device/driver structs are needed that having this makes sense.
> Combined with the fact that, while kunit_get_current_test() can be
> used even when KUnit is not loaded, actually doing anything with the
> resulting struct kunit pointer will probably require (at least for the
> moment) KUnit functions to be reachable, so would break if
> CONFIG_KUNIT=m.

Wouldn't it still work in that case? The unit tests would be modular as
well because they depend on CONFIG_KUNIT.

> 
> So, unless you actually find kunit_get_current_test() and friends to
> be easier to work with, I'd probably stick with this.
> 

Alright thanks.

> > diff --git a/lib/kunit/platform_driver.c b/lib/kunit/platform_driver.c
> > new file mode 100644
> > index 000000000000..11d155114936
> > --- /dev/null
> > +++ b/lib/kunit/platform_driver.c
> > @@ -0,0 +1,207 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Test managed platform driver
> > + */
> > +
> > +#include <linux/device/driver.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include <kunit/resource.h>
> > +
> > +struct kunit_platform_device_alloc_params {
> > +       const char *name;
> > +       int id;
> > +};
> 
> FYI: It's my plan to eventually get rid of (or at least de-emphasize)
> the whole 'init' function aspect of KUnit resources so we don't need
> all of these extra structs and the like. It probably won't make it in
> for 6.4, but we'll see...

Will we be able to get the error values out of the init function? It's
annoying that the error values can't be returned as error pointers to
kunit_alloc_resource(). I end up skipping init, and doing it directly
before or after calling the kunit_alloc_resource() function. I'll try to
avoid init functions in the allocations.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 3/8] kunit: Add test managed platform_device/driver APIs

[Stephen Boyd]

Quoting Maxime Ripard (2023-03-03 06:35:28)
> On Fri, Mar 03, 2023 at 03:15:31PM +0800, David Gow wrote:
> > 
> > DRM has a similar thing already (albeit with a root_device, which is
> > more common with KUnit tests generally):
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_kunit_helpers.h
> > 
> > But that's reasonably drm-specific, so it makes sense that it lives
> > with DRM stuff. platform_device is a bit more generic.
> 
> I'd be very happy to get something from the core to address the same
> thing.
> 
> I think the main thing we needed that isn't covered by this patch is we
> wanted the device to be bound to its driver, so with probe being called
> before calling the test (see 57a84a97bbda).
> 

Can you clarify? This patch makes a poor attempt at waiting for the
platform driver to bind, but in reality it may not be bound by the time
the driver register function returns.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[David Gow]

On Sat, 4 Mar 2023 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 3/1/23 19:38, Stephen Boyd wrote:
> > This patch series adds unit tests for the clk fixed rate basic type and
> > the clk registration functions that use struct clk_parent_data. To get
> > there, we add support for loading a DTB into the UML kernel that's
> > running the unit tests along with probing platform drivers to bind to
> > device nodes specified in DT.
> >
> > With this series, we're able to exercise some of the code in the common
> > clk framework that uses devicetree lookups to find parents and the fixed
> > rate clk code that scans devicetree directly and creates clks. Please
> > review.
>
> I would _really_ like to _not_ have devicetree tests in two locations:
> DT unittests and kunit tests.
>

I agree we don't want to split things up needlessly, but I think there
is a meaningful distinction between:
- Testing the DT infrastructure itself (with DT unittests)
- Testing a driver which may have some interaction with DT (via KUnit)

So, rather than going for a "devicetree" KUnit suite (unless we wanted
to port OF_UNITTEST to KUnit, which as you point out, would involve a
fair bit of reworking), I think the goal is for there to be lots of
driver test suites, each of which may verify that their specific
properties can be loaded from the devicetree correctly.

This is also why I prefer the overlay method, if we can get it to
work: it makes it clearer that the organisational hierarchy for these
tests is [driver]->[devicetree], not [devicetree]->[drvier].

> For my testing, I already build and boot four times on real hardware:
>
>   1) no DT unittests
>   2) CONFIG_OF_UNITTEST
>   3) CONFIG_OF_UNITTEST
>      CONFIG_OF_DYNAMIC
>   4) CONFIG_OF_UNITTEST
>      CONFIG_OF_DYNAMIC
>      CONFIG_OF_OVERLAY
>
> I really should also be testing the four configurations on UML, but at
> the moment I am not.
>
> I also check for new compile warnings at various warn levels for all
> four configurations.
>
> If I recall correctly, the kunit framework encourages more (many more?)
> kunit config options to select which test(s) are build for a test run.
> Someone please correct this paragraph if I am mis-stating.

We do tend to suggest that there is a separate kconfig option for each
area being tested (usually one per test suite, but if there are
several closely related suites, sticking them under a single config
option isn't a problem.)

That being said:
- It's possible (and encouraged) to just test once with all of those
tests enabled, rather than needing to test every possible combination
of configs enabled/disabled.
- (Indeed, this is what we do with .kunitconfig files a lot: they're
collections of related configs, so you can quickly run, e.g., all DRM
tests)
- Because a KUnit test being run is an independent action from it
being built-in, it's possible to build the tests once and then just
run different subsets anyway, or possibly run them after boot if
they're compiled as modules.
- This of course, depends on two test configs not conflicting with
each other: obviously if there were some tests which relied on
OF_OVERLAY=n, and others which require OF_OVERLAY=y, you'd need two
builds.

The bigger point is that, if the KUnit tests are focused on individual
drivers, rather than the devicetree infrastructure itself, then these
probably aren't as critical to run on every devicetree change (the DT
unittests should hopefully catch anything which affects devicetree as
a whole), but only on tests which affect a specific driver (as they're
really intended to make sure the drivers are accessing / interacting
with the DT properly, not that the DT infrastructure functions).

And obviously if this KUnit/devicetree support ends up depending on
overlays, that means there's no need to test them with overlays
disabled. :-)

>
> Adding devicetree tests to kunit adds additional build and boot cycles
> and additional test output streams to verify.
>
> Are there any issues with DT unittests that preclude adding clk tests
> into the DT unittests?
>

I think at least part of it is that there are already some clk KUnit
tests, so it's easier to have all of the clk tests behave similarly
(for the same reasons, alas, as using DT unittests makes it easier to
keep all of the DT tests in the same place).

Of course, as DT unittests move to KTAP, and possibly in the future
are able to make use of more KUnit infrastructure, this should get
simpler for everyone.


Does that seem sensible?

-- David

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 1/8] dt-bindings: Add linux,kunit binding

[David Gow]

On Fri, 10 Mar 2023 at 07:12, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting David Gow (2023-03-02 23:14:55)
> > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Document the linux,kunit board compatible string. This board is loaded
> > > into the Linux kernel when KUnit is testing devicetree dependent code.
> >
> > As with the series as a whole, this might need to change a little bit
> > if we want to either use devicetree overlays and/or other
> > architectures.
> >
> > That being said, I'm okay with having this until then: the only real
> > topic for bikeshedding is the name.
> > - Is KUnit best as a board name, or part of the vendor name?
> > - Do we want to include the architecture in the name?
> > Should it be "linux,kunit", "linux-kunit,uml", "linux,kunit-uml", etc?
>
> I think I will drop this patch. I have overlays working. I hijacked
> of_core_init() to load the testcase data from drivers/of/unittest-data
> and made a container node for kunit overlays to apply to.

Makes sense to me, thanks!

Looking forward to seeing how the overlays work in practice!

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[David Gow]

On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting David Gow (2023-03-02 23:15:04)
> > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > To fully exercise common clk framework code in KUnit we need to
> > > associate 'struct device' pointers with 'struct device_node' pointers so
> > > that things like clk_get() can parse DT nodes for 'clocks' and so that
> > > clk providers can use DT to provide clks; the most common mode of
> > > operation for clk providers.
> > >
> > > Adding support to KUnit so that it loads a DTB is fairly simple after
> > > commit b31297f04e86 ("um: Add devicetree support"). We can simply pass a
> > > pre-compiled deviectree blob (DTB) on the kunit.py commandline and UML
> > > will load it. The problem is that tests won't know that the commandline
> > > has been modified, nor that a DTB has been loaded. Take a different
> > > approach so that tests can skip if a DTB hasn't been loaded.
> > >
> > > Reuse the Makefile logic from the OF unittests to build a DTB into the
> > > kernel. This DTB will be for the mythical machine "linux,kunit", i.e.
> > > the devicetree for the KUnit "board". In practice, it is a dtsi file
> > > that will gather includes for kunit tests that rely in part on a
> > > devicetree being loaded. The devicetree should only be loaded if
> > > CONFIG_OF_KUNIT=y. Make that a choice config parallel to the existing
> > > CONFIG_OF_UNITTEST so that only one devicetree can be loaded in the
> > > system at a time. Similarly, the kernel commandline option to load a
> > > DTB is ignored if CONFIG_OF_KUNIT is enabled so that only one DTB is
> > > loaded at a time.
> >
> > This feels a little bit like it's just papering over the real problem,
> > which is that there's no way tests can skip themselves if no DTB is
> > loaded.
>
> Hmm. I think you're suggesting that the unit test data be loaded
> whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
> CONFIG_OF and skip if it isn't enabled?
>

More of the opposite: that we should have some way of supporting tests
which might want to use a DTB other than the built-in one. Mostly for
non-UML situations where an actual devicetree is needed to even boot
far enough to get test output (so we wouldn't be able to override it
with a compiled-in test one).

I think moving to overlays probably will render this idea obsolete:
but the thought was to give test code a way to check for the required
devicetree nodes at runtime, and skip the test if they weren't found.
That way, the failure mode for trying to boot this on something which
required another device tree for, e.g., serial, would be "these tests
are skipped because the wrong device tree is loaded", not "I get no
output because serial isn't working".

Again, though, it's only really needed for non-UML, and just loading
overlays as needed should be much more sensible anyway.

> >
> > That being said, I do think that there's probably some sense in
> > supporting the compiled-in DTB as well (it's definitely simpler than
> > patching kunit.py to always pass the extra command-line option in, for
> > example).
> > But maybe it'd be nice to have the command-line option override the
> > built-in one if present.
>
> Got it. I need to test loading another DTB on the commandline still, but
> I think this won't be a problem. We'll load the unittest-data DTB even
> with KUnit on UML, so assuming that works on UML right now it should be
> unchanged by this series once I resend.

Again, moving to overlays should render this mostly obsolete, no? Or
am I misunderstanding how the overlay stuff will work?

One possible future advantage of being able to test with custom DTs at
boot time would be for fuzzing (provide random DT properties, see what
happens in the test). We've got some vague plans to support a way of
passing custom data to tests to support this kind of case (though, if
we're using overlays, maybe the test could just patch those if we
wanted to do that).


Cheers,
-- David

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 3/8] kunit: Add test managed platform_device/driver APIs

[David Gow]

On Fri, 10 Mar 2023 at 07:25, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting David Gow (2023-03-02 23:15:31)
> > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Introduce KUnit resource wrappers around platform_driver_register(),
> > > platform_device_alloc(), and platform_device_add() so that test authors
> > > can register platform drivers/devices from their tests and have the
> > > drivers/devices automatically be unregistered when the test is done.
> > >
> > > This makes test setup code simpler when a platform driver or platform
> > > device is needed. Add a few test cases at the same time to make sure the
> > > APIs work as intended.
> > >
> > > Cc: Brendan Higgins <brendan.higgins@linux.dev>
> > > Cc: David Gow <davidgow@google.com>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > > Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> > > ---
> > >
> > > Should this be moved to drivers/base/ and called platform_kunit.c?
> > > The include/kunit/platform_driver.h could also be
> > > kunit/platform_device.h to match linux/platform_device.h if that is more
> > > familiar.
> >
> > DRM has a similar thing already (albeit with a root_device, which is
> > more common with KUnit tests generally):
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_kunit_helpers.h
> >
> > But that's reasonably drm-specific, so it makes sense that it lives
> > with DRM stuff. platform_device is a bit more generic.
> >
> > I'd probably personally err on the side of having these in
> > drivers/base/, as I think we'll ultimately need similar things for a
> > lot of different devices, and I'd rather not end up with things like
> > USB device helpers living in the lib/kunit directory alongside the
> > "core" KUnit code. But I could be persuaded otherwise.
>
> Ok no problem. I'll move it.
>
> >
> > >
> > > And I'm not super certain about allocating a driver structure and
> > > embedding it in a wrapper struct. Maybe the code should just use
> > > kunit_get_current_test() instead?
> >
> > I think there are enough cases througout the kernel where
> > device/driver structs are needed that having this makes sense.
> > Combined with the fact that, while kunit_get_current_test() can be
> > used even when KUnit is not loaded, actually doing anything with the
> > resulting struct kunit pointer will probably require (at least for the
> > moment) KUnit functions to be reachable, so would break if
> > CONFIG_KUNIT=m.
>
> Wouldn't it still work in that case? The unit tests would be modular as
> well because they depend on CONFIG_KUNIT.
>

Yeah, the only case where this starts to get hairy is if the tests end
up in the same module as the thing being tested (which sometimes
happens to avoid having to export a bunch of symbols: see, e.g.
thunderbolt and amdgpu), and then someone wants to build production
kernels with CONFIG_KUNIT=m (alas, Red Hat and Android).

So that's the only real place where you might need to avoid the
non-'hook' KUnit functions, but those drivers are pretty few and far
between, and most of the really useful functionality should be moving
to 'hooks' which will be patched out cleanly at runtime.

> >
> > So, unless you actually find kunit_get_current_test() and friends to
> > be easier to work with, I'd probably stick with this.
> >
>
> Alright thanks.
>
> > > diff --git a/lib/kunit/platform_driver.c b/lib/kunit/platform_driver.c
> > > new file mode 100644
> > > index 000000000000..11d155114936
> > > --- /dev/null
> > > +++ b/lib/kunit/platform_driver.c
> > > @@ -0,0 +1,207 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Test managed platform driver
> > > + */
> > > +
> > > +#include <linux/device/driver.h>
> > > +#include <linux/platform_device.h>
> > > +
> > > +#include <kunit/resource.h>
> > > +
> > > +struct kunit_platform_device_alloc_params {
> > > +       const char *name;
> > > +       int id;
> > > +};
> >
> > FYI: It's my plan to eventually get rid of (or at least de-emphasize)
> > the whole 'init' function aspect of KUnit resources so we don't need
> > all of these extra structs and the like. It probably won't make it in
> > for 6.4, but we'll see...
>
> Will we be able to get the error values out of the init function? It's
> annoying that the error values can't be returned as error pointers to
> kunit_alloc_resource(). I end up skipping init, and doing it directly
> before or after calling the kunit_alloc_resource() function. I'll try to
> avoid init functions in the allocations.

Yeah, that's largely why the plan is to get rid of them: it just made
passing things around an enormous pain.
Just doing your own initialisation before adding it as a resource is
usually the right thing to do.

There's also going to be a simpler kunit_defer() wrapper around it,
which would just allow you to schedule a cleanup function to be called
(without the need to keep kunit_resource pointers around, etc), for
the cases where you don't need to look up resources elsewhere.

But just doing your own thing and calling kunit_alloc_resource() is
probably best for now, and should map well onto whatever this ends up
evolving into.

Cheers,
-- David

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 4/8] clk: Add test managed clk provider/consumer APIs

[Stephen Boyd]

Quoting David Gow (2023-03-02 23:15:35)
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Unit tests are more ergonomic and simpler to understand if they don't
> > have to hoist a bunch of code into the test harness init and exit
> > functions. Add some test managed wrappers for the clk APIs so that clk
> > unit tests can write more code in the actual test and less code in the
> > harness.
> >
> > Only add APIs that are used for now. More wrappers can be added in the
> > future as necessary.
> >
> > Cc: Brendan Higgins <brendan.higgins@linux.dev>
> > Cc: David Gow <davidgow@google.com>
> > Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> > ---
> 
> Looks good, modulo bikeshedding below.

Cool!

> >
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index e3ca0d058a25..7efce649b0d3 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -17,6 +17,11 @@ ifeq ($(CONFIG_OF), y)
> >  obj-$(CONFIG_COMMON_CLK)       += clk-conf.o
> >  endif
> >
> > +# KUnit specific helpers
> > +ifeq ($(CONFIG_COMMON_CLK), y)
> > +obj-$(CONFIG_KUNIT)            += clk-kunit.o
> 
> Do we want to compile these in whenever KUnit is enabled, or only when
> we're building clk tests specifically? I suspect this would be served
> better by being under a CLK_KUNIT config option, which all of the
> tests then depend on. (Whether that's the existing
> CONFIG_CLK_KUNIT_TEST, and all of the clk tests live under the same
> config option, or a separate parent option would be up to you).

I was thinking of building it in with whatever mode CONFIG_KUNIT is
built as. If this is a module because CONFIG_KUNIT=m, then unit tests
would depend on that, and this would be a module as well. modprobe would
know that some unit test module depends on symbols provided by
clk-kunit.ko and thus load clk-kunit.ko first.

> 
> Equally, this could be a bit interesting if CONFIG_KUNIT=m. Given
> CONFIG_COMMON_CLK=y, this would end up as a clk-kunit module, no?

Yes, that is the intent.

> 
> > +endif
> > +
> >  # hardware specific clock types
> >  # please keep this section sorted lexicographically by file path name
> >  obj-$(CONFIG_COMMON_CLK_APPLE_NCO)     += clk-apple-nco.o
> > diff --git a/drivers/clk/clk-kunit.c b/drivers/clk/clk-kunit.c
> > new file mode 100644
> > index 000000000000..78d85b3a7a4a
> > --- /dev/null
> > +++ b/drivers/clk/clk-kunit.c
> > @@ -0,0 +1,204 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * KUnit helpers for clk tests
> > + */
> > +#include <linux/clk.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/err.h>
> > +#include <linux/kernel.h>
> > +#include <linux/slab.h>
> > +
> > +#include <kunit/resource.h>
> > +
> > +#include "clk-kunit.h"
> > +
> > +static void kunit_clk_disable_unprepare(struct kunit_resource *res)
> 
> We need to decide on the naming scheme of these, and in particular if
> they should be kunit_clk or clk_kunit (or something else).
> 
> I'd lean to clk_kunit, if only to match DRM's KUnit helpers being
> drm_kunit_helper better, and so that these are more tightly bound to
> the subsystem being tested.
> (i.e., so I don't have to scroll through every subsystem's helpers
> when autocompleting kunit_).

Ok, got it. I was trying to match kunit_kzalloc() style. It makes it
easy to slap the 'kunit_' prefix on existing auto-completed function
names like kzalloc() or clk_prepare_enable().

I wasn't aware of drm_kunit_helper. That's a mouthful! We don't call it
slab_kunit_helper_kzalloc(). Maybe to satisfy all conditions it should
be:

	clk_prepare_enable_kunit()

so that kunit_ autocomplete doesn't have a big scroll list, and clk
subsystem autocompletes, and we know it is kunit specific.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Stephen Boyd]

Quoting David Gow (2023-03-10 00:09:48)
> On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> >
> > Hmm. I think you're suggesting that the unit test data be loaded
> > whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
> > CONFIG_OF and skip if it isn't enabled?
> >
> 
> More of the opposite: that we should have some way of supporting tests
> which might want to use a DTB other than the built-in one. Mostly for
> non-UML situations where an actual devicetree is needed to even boot
> far enough to get test output (so we wouldn't be able to override it
> with a compiled-in test one).

Ok, got it.

> 
> I think moving to overlays probably will render this idea obsolete:
> but the thought was to give test code a way to check for the required
> devicetree nodes at runtime, and skip the test if they weren't found.
> That way, the failure mode for trying to boot this on something which
> required another device tree for, e.g., serial, would be "these tests
> are skipped because the wrong device tree is loaded", not "I get no
> output because serial isn't working".
> 
> Again, though, it's only really needed for non-UML, and just loading
> overlays as needed should be much more sensible anyway.

I still have one niggle here. Loading overlays requires
CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
in each test, but I'm thinking it may be better to simply call
kunit_skip() from the overlay loading function if the config is
disabled. This way tests can simply call the overlay loading function
and we'll halt the test immediately if the config isn't enabled.

> 
> > >
> > > That being said, I do think that there's probably some sense in
> > > supporting the compiled-in DTB as well (it's definitely simpler than
> > > patching kunit.py to always pass the extra command-line option in, for
> > > example).
> > > But maybe it'd be nice to have the command-line option override the
> > > built-in one if present.
> >
> > Got it. I need to test loading another DTB on the commandline still, but
> > I think this won't be a problem. We'll load the unittest-data DTB even
> > with KUnit on UML, so assuming that works on UML right now it should be
> > unchanged by this series once I resend.
> 
> Again, moving to overlays should render this mostly obsolete, no? Or
> am I misunderstanding how the overlay stuff will work?

Right, overlays make it largely a moot issue. The way the OF unit tests
work today is by grafting a DTB onto the live tree. I'm reusing that
logic to graft a container node target for kunit tests to add their
overlays too. It will be clearer once I post v2.

> 
> One possible future advantage of being able to test with custom DTs at
> boot time would be for fuzzing (provide random DT properties, see what
> happens in the test). We've got some vague plans to support a way of
> passing custom data to tests to support this kind of case (though, if
> we're using overlays, maybe the test could just patch those if we
> wanted to do that).

Ah ok. I can see someone making a fuzzer that modifies devicetree
properties randomly, e.g. using different strings for clock-names.

This reminds me of another issue I ran into. I wanted to test adding the
same platform device to the platform bus twice to confirm that the
second device can't be added. That prints a warning, which makes
kunit.py think that the test has failed because it printed a warning. Is
there some way to avoid that? I want something like

	KUNIT_EXPECT_WARNING(test, <call some function>)

so I can test error cases.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 4/8] clk: Add test managed clk provider/consumer APIs

[David Gow]

On Sat, 11 Mar 2023 at 07:21, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting David Gow (2023-03-02 23:15:35)
> > On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > > Unit tests are more ergonomic and simpler to understand if they don't
> > > have to hoist a bunch of code into the test harness init and exit
> > > functions. Add some test managed wrappers for the clk APIs so that clk
> > > unit tests can write more code in the actual test and less code in the
> > > harness.
> > >
> > > Only add APIs that are used for now. More wrappers can be added in the
> > > future as necessary.
> > >
> > > Cc: Brendan Higgins <brendan.higgins@linux.dev>
> > > Cc: David Gow <davidgow@google.com>
> > > Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> > > ---
> >
> > Looks good, modulo bikeshedding below.
>
> Cool!
>
> > >
> > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > > index e3ca0d058a25..7efce649b0d3 100644
> > > --- a/drivers/clk/Makefile
> > > +++ b/drivers/clk/Makefile
> > > @@ -17,6 +17,11 @@ ifeq ($(CONFIG_OF), y)
> > >  obj-$(CONFIG_COMMON_CLK)       += clk-conf.o
> > >  endif
> > >
> > > +# KUnit specific helpers
> > > +ifeq ($(CONFIG_COMMON_CLK), y)
> > > +obj-$(CONFIG_KUNIT)            += clk-kunit.o
> >
> > Do we want to compile these in whenever KUnit is enabled, or only when
> > we're building clk tests specifically? I suspect this would be served
> > better by being under a CLK_KUNIT config option, which all of the
> > tests then depend on. (Whether that's the existing
> > CONFIG_CLK_KUNIT_TEST, and all of the clk tests live under the same
> > config option, or a separate parent option would be up to you).
>
> I was thinking of building it in with whatever mode CONFIG_KUNIT is
> built as. If this is a module because CONFIG_KUNIT=m, then unit tests
> would depend on that, and this would be a module as well. modprobe would
> know that some unit test module depends on symbols provided by
> clk-kunit.ko and thus load clk-kunit.ko first.
>

Personally, I'd rather have this behind CONFIG_CLK_KUNIT_TEST if
possible, if only to avoid needlessly building these if someone just
wants to test some other subsystem (but needs CONFIG_COMMON_CLK
enabled anyway). I doubt it'd be a problem in practice in this case,
but we definitely want to keep build (and hence iteration) times down
as much as possible, so it's probably good practice to keep all tests
behind at least some sort of "test this subsystem" option.

> >
> > Equally, this could be a bit interesting if CONFIG_KUNIT=m. Given
> > CONFIG_COMMON_CLK=y, this would end up as a clk-kunit module, no?
>
> Yes, that is the intent.
>
> >
> > > +endif
> > > +
> > >  # hardware specific clock types
> > >  # please keep this section sorted lexicographically by file path name
> > >  obj-$(CONFIG_COMMON_CLK_APPLE_NCO)     += clk-apple-nco.o
> > > diff --git a/drivers/clk/clk-kunit.c b/drivers/clk/clk-kunit.c
> > > new file mode 100644
> > > index 000000000000..78d85b3a7a4a
> > > --- /dev/null
> > > +++ b/drivers/clk/clk-kunit.c
> > > @@ -0,0 +1,204 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * KUnit helpers for clk tests
> > > + */
> > > +#include <linux/clk.h>
> > > +#include <linux/clk-provider.h>
> > > +#include <linux/err.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/slab.h>
> > > +
> > > +#include <kunit/resource.h>
> > > +
> > > +#include "clk-kunit.h"
> > > +
> > > +static void kunit_clk_disable_unprepare(struct kunit_resource *res)
> >
> > We need to decide on the naming scheme of these, and in particular if
> > they should be kunit_clk or clk_kunit (or something else).
> >
> > I'd lean to clk_kunit, if only to match DRM's KUnit helpers being
> > drm_kunit_helper better, and so that these are more tightly bound to
> > the subsystem being tested.
> > (i.e., so I don't have to scroll through every subsystem's helpers
> > when autocompleting kunit_).
>
> Ok, got it. I was trying to match kunit_kzalloc() style. It makes it
> easy to slap the 'kunit_' prefix on existing auto-completed function
> names like kzalloc() or clk_prepare_enable().

Yeah: my rule of thumb at the moment is to keep the kunit_ prefix for
things which are generic across the whole kernel (and tend to be
implemented in lib/kunit), and to use suffixes or infixes (whichever
works best) for things which are subsystem-specific.

> I wasn't aware of drm_kunit_helper. That's a mouthful! We don't call it
> slab_kunit_helper_kzalloc(). Maybe to satisfy all conditions it should
> be:
>
>         clk_prepare_enable_kunit()
>
> so that kunit_ autocomplete doesn't have a big scroll list, and clk
> subsystem autocompletes, and we know it is kunit specific.


Sounds good to me.

Cheers,
-- David

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[David Gow]

On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting David Gow (2023-03-10 00:09:48)
> > On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > >
> > > Hmm. I think you're suggesting that the unit test data be loaded
> > > whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
> > > CONFIG_OF and skip if it isn't enabled?
> > >
> >
> > More of the opposite: that we should have some way of supporting tests
> > which might want to use a DTB other than the built-in one. Mostly for
> > non-UML situations where an actual devicetree is needed to even boot
> > far enough to get test output (so we wouldn't be able to override it
> > with a compiled-in test one).
>
> Ok, got it.
>
> >
> > I think moving to overlays probably will render this idea obsolete:
> > but the thought was to give test code a way to check for the required
> > devicetree nodes at runtime, and skip the test if they weren't found.
> > That way, the failure mode for trying to boot this on something which
> > required another device tree for, e.g., serial, would be "these tests
> > are skipped because the wrong device tree is loaded", not "I get no
> > output because serial isn't working".
> >
> > Again, though, it's only really needed for non-UML, and just loading
> > overlays as needed should be much more sensible anyway.
>
> I still have one niggle here. Loading overlays requires
> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
> in each test, but I'm thinking it may be better to simply call
> kunit_skip() from the overlay loading function if the config is
> disabled. This way tests can simply call the overlay loading function
> and we'll halt the test immediately if the config isn't enabled.
>

That sounds sensible, though there is a potential pitfall. If
kunit_skip() is called directly from overlay code, might introduce a
dependency on kunit.ko from the DT overlay, which we might not want.
The solution there is either to have a kunit wrapper function (so the
call is already in kunit.ko), or to have a hook to skip the current
test (which probably makes sense to do anyway, but I think the wrapper
is the better option).


> >
> > > >
> > > > That being said, I do think that there's probably some sense in
> > > > supporting the compiled-in DTB as well (it's definitely simpler than
> > > > patching kunit.py to always pass the extra command-line option in, for
> > > > example).
> > > > But maybe it'd be nice to have the command-line option override the
> > > > built-in one if present.
> > >
> > > Got it. I need to test loading another DTB on the commandline still, but
> > > I think this won't be a problem. We'll load the unittest-data DTB even
> > > with KUnit on UML, so assuming that works on UML right now it should be
> > > unchanged by this series once I resend.
> >
> > Again, moving to overlays should render this mostly obsolete, no? Or
> > am I misunderstanding how the overlay stuff will work?
>
> Right, overlays make it largely a moot issue. The way the OF unit tests
> work today is by grafting a DTB onto the live tree. I'm reusing that
> logic to graft a container node target for kunit tests to add their
> overlays too. It will be clearer once I post v2.
>
> >
> > One possible future advantage of being able to test with custom DTs at
> > boot time would be for fuzzing (provide random DT properties, see what
> > happens in the test). We've got some vague plans to support a way of
> > passing custom data to tests to support this kind of case (though, if
> > we're using overlays, maybe the test could just patch those if we
> > wanted to do that).
>
> Ah ok. I can see someone making a fuzzer that modifies devicetree
> properties randomly, e.g. using different strings for clock-names.
>
> This reminds me of another issue I ran into. I wanted to test adding the
> same platform device to the platform bus twice to confirm that the
> second device can't be added. That prints a warning, which makes
> kunit.py think that the test has failed because it printed a warning. Is
> there some way to avoid that? I want something like
>
>         KUNIT_EXPECT_WARNING(test, <call some function>)
>
> so I can test error cases.

Hmm... I'd've thought that shouldn't be a problem: kunit.py should
ignore most messages during a test, unless it can't find a valid
result line. What does the raw KTAP output look like? (You can get it
from kunit.py by passing the --raw_output option).

That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
we've wanted for a while. I think that the KASAN folks have been
working on something similar using console tracepoints:
https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/

Cheers,
-- David

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Frank Rowand]

On 3/10/23 01:48, David Gow wrote:
> On Sat, 4 Mar 2023 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
>>
>> On 3/1/23 19:38, Stephen Boyd wrote:
>>> This patch series adds unit tests for the clk fixed rate basic type and
>>> the clk registration functions that use struct clk_parent_data. To get
>>> there, we add support for loading a DTB into the UML kernel that's
>>> running the unit tests along with probing platform drivers to bind to
>>> device nodes specified in DT.
>>>
>>> With this series, we're able to exercise some of the code in the common
>>> clk framework that uses devicetree lookups to find parents and the fixed
>>> rate clk code that scans devicetree directly and creates clks. Please
>>> review.
>>
>> I would _really_ like to _not_ have devicetree tests in two locations:
>> DT unittests and kunit tests.
>>
> 

This:

> I agree we don't want to split things up needlessly, but I think there
> is a meaningful distinction between:
> - Testing the DT infrastructure itself (with DT unittests)
> - Testing a driver which may have some interaction with DT (via KUnit)

> 
> So, rather than going for a "devicetree" KUnit suite (unless we wanted
> to port OF_UNITTEST to KUnit, which as you point out, would involve a
> fair bit of reworking), I think the goal is for there to be lots of
> driver test suites, each of which may verify that their specific
> properties can be loaded from the devicetree correctly.
> 
> This is also why I prefer the overlay method, if we can get it to
> work: it makes it clearer that the organisational hierarchy for these
> tests is [driver]->[devicetree], not [devicetree]->[drvier].
> 
>> For my testing, I already build and boot four times on real hardware:
>>
>>   1) no DT unittests
>>   2) CONFIG_OF_UNITTEST
>>   3) CONFIG_OF_UNITTEST
>>      CONFIG_OF_DYNAMIC
>>   4) CONFIG_OF_UNITTEST
>>      CONFIG_OF_DYNAMIC
>>      CONFIG_OF_OVERLAY
>>
>> I really should also be testing the four configurations on UML, but at
>> the moment I am not.
>>
>> I also check for new compile warnings at various warn levels for all
>> four configurations.
>>
>> If I recall correctly, the kunit framework encourages more (many more?)
>> kunit config options to select which test(s) are build for a test run.
>> Someone please correct this paragraph if I am mis-stating.
> 
> We do tend to suggest that there is a separate kconfig option for each
> area being tested (usually one per test suite, but if there are
> several closely related suites, sticking them under a single config
> option isn't a problem.)
> 
> That being said:
> - It's possible (and encouraged) to just test once with all of those
> tests enabled, rather than needing to test every possible combination
> of configs enabled/disabled.
> - (Indeed, this is what we do with .kunitconfig files a lot: they're
> collections of related configs, so you can quickly run, e.g., all DRM
> tests)
> - Because a KUnit test being run is an independent action from it
> being built-in, it's possible to build the tests once and then just
> run different subsets anyway, or possibly run them after boot if
> they're compiled as modules.
> - This of course, depends on two test configs not conflicting with
> each other: obviously if there were some tests which relied on
> OF_OVERLAY=n, and others which require OF_OVERLAY=y, you'd need two
> builds.
> 

And this:

> The bigger point is that, if the KUnit tests are focused on individual
> drivers, rather than the devicetree infrastructure itself, then these
> probably aren't as critical to run on every devicetree change (the DT
> unittests should hopefully catch anything which affects devicetree as
> a whole), but only on tests which affect a specific driver (as they're
> really intended to make sure the drivers are accessing / interacting
> with the DT properly, not that the DT infrastructure functions).

Those two paragraphs are correct, and my original assumption was wrong.

These tests appear to mostly be clock related and only minimally and
indirectly test devicetree functionality.  In more generic terms,
they are driver tests, not devicetree tests.

Thus I withdraw my concern of making the devicetree test environment
more complicated.

> 
> And obviously if this KUnit/devicetree support ends up depending on
> overlays, that means there's no need to test them with overlays
> disabled. :-)
> 
>>
>> Adding devicetree tests to kunit adds additional build and boot cycles
>> and additional test output streams to verify.
>>
>> Are there any issues with DT unittests that preclude adding clk tests
>> into the DT unittests?
>>
> 
> I think at least part of it is that there are already some clk KUnit
> tests, so it's easier to have all of the clk tests behave similarly
> (for the same reasons, alas, as using DT unittests makes it easier to
> keep all of the DT tests in the same place).
> 

> Of course, as DT unittests move to KTAP, and possibly in the future
> are able to make use of more KUnit infrastructure, this should get
> simpler for everyone.

I hope to move DT unitests to create KTAP V2 compatible data as a
first step.

I highly doubt that DT unittests fit the kunit model, but that would
be a question that could be considered after DT unittests move to the
KTAP V2 data format.

> 
> 
> Does that seem sensible?

Yes, thanks for the extra explanations.

> 
> -- David


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Frank Rowand]

On 3/11/23 00:42, David Gow wrote:
> On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd@kernel.org> wrote:
>>
>> Quoting David Gow (2023-03-10 00:09:48)
>>> On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>
>>>>
>>>> Hmm. I think you're suggesting that the unit test data be loaded
>>>> whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
>>>> CONFIG_OF and skip if it isn't enabled?
>>>>
>>>
>>> More of the opposite: that we should have some way of supporting tests
>>> which might want to use a DTB other than the built-in one. Mostly for
>>> non-UML situations where an actual devicetree is needed to even boot
>>> far enough to get test output (so we wouldn't be able to override it
>>> with a compiled-in test one).
>>
>> Ok, got it.
>>
>>>
>>> I think moving to overlays probably will render this idea obsolete:
>>> but the thought was to give test code a way to check for the required
>>> devicetree nodes at runtime, and skip the test if they weren't found.
>>> That way, the failure mode for trying to boot this on something which
>>> required another device tree for, e.g., serial, would be "these tests
>>> are skipped because the wrong device tree is loaded", not "I get no
>>> output because serial isn't working".
>>>
>>> Again, though, it's only really needed for non-UML, and just loading
>>> overlays as needed should be much more sensible anyway.
>>
>> I still have one niggle here. Loading overlays requires
>> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
>> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
>> in each test, but I'm thinking it may be better to simply call
>> kunit_skip() from the overlay loading function if the config is
>> disabled. This way tests can simply call the overlay loading function
>> and we'll halt the test immediately if the config isn't enabled.
>>
> 
> That sounds sensible, though there is a potential pitfall. If
> kunit_skip() is called directly from overlay code, might introduce a
> dependency on kunit.ko from the DT overlay, which we might not want.
> The solution there is either to have a kunit wrapper function (so the
> call is already in kunit.ko), or to have a hook to skip the current
> test (which probably makes sense to do anyway, but I think the wrapper
> is the better option).
> 
> 
>>>
>>>>>
>>>>> That being said, I do think that there's probably some sense in
>>>>> supporting the compiled-in DTB as well (it's definitely simpler than
>>>>> patching kunit.py to always pass the extra command-line option in, for
>>>>> example).
>>>>> But maybe it'd be nice to have the command-line option override the
>>>>> built-in one if present.
>>>>
>>>> Got it. I need to test loading another DTB on the commandline still, but
>>>> I think this won't be a problem. We'll load the unittest-data DTB even
>>>> with KUnit on UML, so assuming that works on UML right now it should be
>>>> unchanged by this series once I resend.
>>>
>>> Again, moving to overlays should render this mostly obsolete, no? Or
>>> am I misunderstanding how the overlay stuff will work?
>>
>> Right, overlays make it largely a moot issue. The way the OF unit tests
>> work today is by grafting a DTB onto the live tree. I'm reusing that
>> logic to graft a container node target for kunit tests to add their
>> overlays too. It will be clearer once I post v2.
>>
>>>
>>> One possible future advantage of being able to test with custom DTs at
>>> boot time would be for fuzzing (provide random DT properties, see what
>>> happens in the test). We've got some vague plans to support a way of
>>> passing custom data to tests to support this kind of case (though, if
>>> we're using overlays, maybe the test could just patch those if we
>>> wanted to do that).
>>
>> Ah ok. I can see someone making a fuzzer that modifies devicetree
>> properties randomly, e.g. using different strings for clock-names.
>>
>> This reminds me of another issue I ran into. I wanted to test adding the
>> same platform device to the platform bus twice to confirm that the
>> second device can't be added. That prints a warning, which makes
>> kunit.py think that the test has failed because it printed a warning. Is
>> there some way to avoid that? I want something like
>>
>>         KUNIT_EXPECT_WARNING(test, <call some function>)
>>
>> so I can test error cases.

DT unittests already have a similar concept.  A test can report that a
kernel warning (or any other specific text) either (1) must occur for the
test to pass or (2) must _not_ occur for the test to pass.  The check
for the kernel warning is done by the test output parsing program
scripts/dtc/of_unittest_expect.

The reporting by a test of an expected error in drivers/of/unittest.c
is done by EXPECT_BEGIN() and EXPECT_END().  These have been in
unittest for a long time.

The reporting by a test of a not expected to occur error is done
by EXPECT_NOT_BEGIN() and EXPECT_NOT_END().  These are added to
unittest in linux 6.3-rc1.

I discussed this concept in one of the early TAP / KTAP discussion
threads and expect to start a discussion thread on this specific
topic in the KTAP Specification V2 context.  I expect the discussion
to result in a different implementation than what DT unittests are
using (bike shedding likely to ensue) but whatever is agreed to
should be easy for DT to switch to.

> 
> Hmm... I'd've thought that shouldn't be a problem: kunit.py should
> ignore most messages during a test, unless it can't find a valid
> result line. What does the raw KTAP output look like? (You can get it
> from kunit.py by passing the --raw_output option).
> 
> That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
> we've wanted for a while. I think that the KASAN folks have been
> working on something similar using console tracepoints:
> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
> 
> Cheers,
> -- David


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Frank Rowand]

On 3/13/23 11:02, Frank Rowand wrote:
> On 3/11/23 00:42, David Gow wrote:
>> On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd@kernel.org> wrote:
>>>
>>> Quoting David Gow (2023-03-10 00:09:48)
>>>> On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>
>>>>>
>>>>> Hmm. I think you're suggesting that the unit test data be loaded
>>>>> whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
>>>>> CONFIG_OF and skip if it isn't enabled?
>>>>>
>>>>
>>>> More of the opposite: that we should have some way of supporting tests
>>>> which might want to use a DTB other than the built-in one. Mostly for
>>>> non-UML situations where an actual devicetree is needed to even boot
>>>> far enough to get test output (so we wouldn't be able to override it
>>>> with a compiled-in test one).
>>>
>>> Ok, got it.
>>>
>>>>
>>>> I think moving to overlays probably will render this idea obsolete:
>>>> but the thought was to give test code a way to check for the required
>>>> devicetree nodes at runtime, and skip the test if they weren't found.
>>>> That way, the failure mode for trying to boot this on something which
>>>> required another device tree for, e.g., serial, would be "these tests
>>>> are skipped because the wrong device tree is loaded", not "I get no
>>>> output because serial isn't working".
>>>>
>>>> Again, though, it's only really needed for non-UML, and just loading
>>>> overlays as needed should be much more sensible anyway.
>>>
>>> I still have one niggle here. Loading overlays requires
>>> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
>>> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
>>> in each test, but I'm thinking it may be better to simply call
>>> kunit_skip() from the overlay loading function if the config is
>>> disabled. This way tests can simply call the overlay loading function
>>> and we'll halt the test immediately if the config isn't enabled.
>>>
>>
>> That sounds sensible, though there is a potential pitfall. If
>> kunit_skip() is called directly from overlay code, might introduce a
>> dependency on kunit.ko from the DT overlay, which we might not want.
>> The solution there is either to have a kunit wrapper function (so the
>> call is already in kunit.ko), or to have a hook to skip the current
>> test (which probably makes sense to do anyway, but I think the wrapper
>> is the better option).
>>
>>
>>>>
>>>>>>
>>>>>> That being said, I do think that there's probably some sense in
>>>>>> supporting the compiled-in DTB as well (it's definitely simpler than
>>>>>> patching kunit.py to always pass the extra command-line option in, for
>>>>>> example).
>>>>>> But maybe it'd be nice to have the command-line option override the
>>>>>> built-in one if present.
>>>>>
>>>>> Got it. I need to test loading another DTB on the commandline still, but
>>>>> I think this won't be a problem. We'll load the unittest-data DTB even
>>>>> with KUnit on UML, so assuming that works on UML right now it should be
>>>>> unchanged by this series once I resend.
>>>>
>>>> Again, moving to overlays should render this mostly obsolete, no? Or
>>>> am I misunderstanding how the overlay stuff will work?
>>>
>>> Right, overlays make it largely a moot issue. The way the OF unit tests
>>> work today is by grafting a DTB onto the live tree. I'm reusing that
>>> logic to graft a container node target for kunit tests to add their
>>> overlays too. It will be clearer once I post v2.
>>>
>>>>
>>>> One possible future advantage of being able to test with custom DTs at
>>>> boot time would be for fuzzing (provide random DT properties, see what
>>>> happens in the test). We've got some vague plans to support a way of
>>>> passing custom data to tests to support this kind of case (though, if
>>>> we're using overlays, maybe the test could just patch those if we
>>>> wanted to do that).
>>>
>>> Ah ok. I can see someone making a fuzzer that modifies devicetree
>>> properties randomly, e.g. using different strings for clock-names.
>>>
>>> This reminds me of another issue I ran into. I wanted to test adding the
>>> same platform device to the platform bus twice to confirm that the
>>> second device can't be added. That prints a warning, which makes
>>> kunit.py think that the test has failed because it printed a warning. Is
>>> there some way to avoid that? I want something like
>>>
>>>         KUNIT_EXPECT_WARNING(test, <call some function>)
>>>
>>> so I can test error cases.
> 
> DT unittests already have a similar concept.  A test can report that a
> kernel warning (or any other specific text) either (1) must occur for the
> test to pass or (2) must _not_ occur for the test to pass.  The check
> for the kernel warning is done by the test output parsing program
> scripts/dtc/of_unittest_expect.
> 
> The reporting by a test of an expected error in drivers/of/unittest.c
> is done by EXPECT_BEGIN() and EXPECT_END().  These have been in
> unittest for a long time.
> 
> The reporting by a test of a not expected to occur error is done
> by EXPECT_NOT_BEGIN() and EXPECT_NOT_END().  These are added to
> unittest in linux 6.3-rc1.
> 
> I discussed this concept in one of the early TAP / KTAP discussion

The link to the early KTAP discussion on this concept is:

   https://lore.kernel.org/all/d38bf9f9-8a39-87a6-8ce7-d37e4a641675@gmail.com/T/#u


> threads and expect to start a discussion thread on this specific
> topic in the KTAP Specification V2 context.  I expect the discussion
> to result in a different implementation than what DT unittests are
> using (bike shedding likely to ensue) but whatever is agreed to
> should be easy for DT to switch to.

The link to the KTAP Specification Version 2 process and progress is:

   https://elinux.org/Test_Results_Format_Notes#KTAP_version_2

-Frank

> 
>>
>> Hmm... I'd've thought that shouldn't be a problem: kunit.py should
>> ignore most messages during a test, unless it can't find a valid
>> result line. What does the raw KTAP output look like? (You can get it
>> from kunit.py by passing the --raw_output option).
>>
>> That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
>> we've wanted for a while. I think that the KASAN folks have been
>> working on something similar using console tracepoints:
>> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
>>
>> Cheers,
>> -- David
> 


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[David Gow]

[-- Attachment #1.1: Type: text/plain, Size: 8548 bytes --]

On Tue, 14 Mar 2023 at 12:28, Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 3/13/23 11:02, Frank Rowand wrote:
> > On 3/11/23 00:42, David Gow wrote:
> >> On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd@kernel.org> wrote:
> >>>
> >>> Quoting David Gow (2023-03-10 00:09:48)
> >>>> On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
> >>>>>
> >>>>>
> >>>>> Hmm. I think you're suggesting that the unit test data be loaded
> >>>>> whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
> >>>>> CONFIG_OF and skip if it isn't enabled?
> >>>>>
> >>>>
> >>>> More of the opposite: that we should have some way of supporting tests
> >>>> which might want to use a DTB other than the built-in one. Mostly for
> >>>> non-UML situations where an actual devicetree is needed to even boot
> >>>> far enough to get test output (so we wouldn't be able to override it
> >>>> with a compiled-in test one).
> >>>
> >>> Ok, got it.
> >>>
> >>>>
> >>>> I think moving to overlays probably will render this idea obsolete:
> >>>> but the thought was to give test code a way to check for the required
> >>>> devicetree nodes at runtime, and skip the test if they weren't found.
> >>>> That way, the failure mode for trying to boot this on something which
> >>>> required another device tree for, e.g., serial, would be "these tests
> >>>> are skipped because the wrong device tree is loaded", not "I get no
> >>>> output because serial isn't working".
> >>>>
> >>>> Again, though, it's only really needed for non-UML, and just loading
> >>>> overlays as needed should be much more sensible anyway.
> >>>
> >>> I still have one niggle here. Loading overlays requires
> >>> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
> >>> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
> >>> in each test, but I'm thinking it may be better to simply call
> >>> kunit_skip() from the overlay loading function if the config is
> >>> disabled. This way tests can simply call the overlay loading function
> >>> and we'll halt the test immediately if the config isn't enabled.
> >>>
> >>
> >> That sounds sensible, though there is a potential pitfall. If
> >> kunit_skip() is called directly from overlay code, might introduce a
> >> dependency on kunit.ko from the DT overlay, which we might not want.
> >> The solution there is either to have a kunit wrapper function (so the
> >> call is already in kunit.ko), or to have a hook to skip the current
> >> test (which probably makes sense to do anyway, but I think the wrapper
> >> is the better option).
> >>
> >>
> >>>>
> >>>>>>
> >>>>>> That being said, I do think that there's probably some sense in
> >>>>>> supporting the compiled-in DTB as well (it's definitely simpler than
> >>>>>> patching kunit.py to always pass the extra command-line option in, for
> >>>>>> example).
> >>>>>> But maybe it'd be nice to have the command-line option override the
> >>>>>> built-in one if present.
> >>>>>
> >>>>> Got it. I need to test loading another DTB on the commandline still, but
> >>>>> I think this won't be a problem. We'll load the unittest-data DTB even
> >>>>> with KUnit on UML, so assuming that works on UML right now it should be
> >>>>> unchanged by this series once I resend.
> >>>>
> >>>> Again, moving to overlays should render this mostly obsolete, no? Or
> >>>> am I misunderstanding how the overlay stuff will work?
> >>>
> >>> Right, overlays make it largely a moot issue. The way the OF unit tests
> >>> work today is by grafting a DTB onto the live tree. I'm reusing that
> >>> logic to graft a container node target for kunit tests to add their
> >>> overlays too. It will be clearer once I post v2.
> >>>
> >>>>
> >>>> One possible future advantage of being able to test with custom DTs at
> >>>> boot time would be for fuzzing (provide random DT properties, see what
> >>>> happens in the test). We've got some vague plans to support a way of
> >>>> passing custom data to tests to support this kind of case (though, if
> >>>> we're using overlays, maybe the test could just patch those if we
> >>>> wanted to do that).
> >>>
> >>> Ah ok. I can see someone making a fuzzer that modifies devicetree
> >>> properties randomly, e.g. using different strings for clock-names.
> >>>
> >>> This reminds me of another issue I ran into. I wanted to test adding the
> >>> same platform device to the platform bus twice to confirm that the
> >>> second device can't be added. That prints a warning, which makes
> >>> kunit.py think that the test has failed because it printed a warning. Is
> >>> there some way to avoid that? I want something like
> >>>
> >>>         KUNIT_EXPECT_WARNING(test, <call some function>)
> >>>
> >>> so I can test error cases.
> >
> > DT unittests already have a similar concept.  A test can report that a
> > kernel warning (or any other specific text) either (1) must occur for the
> > test to pass or (2) must _not_ occur for the test to pass.  The check
> > for the kernel warning is done by the test output parsing program
> > scripts/dtc/of_unittest_expect.
> >
> > The reporting by a test of an expected error in drivers/of/unittest.c
> > is done by EXPECT_BEGIN() and EXPECT_END().  These have been in
> > unittest for a long time.
> >
> > The reporting by a test of a not expected to occur error is done
> > by EXPECT_NOT_BEGIN() and EXPECT_NOT_END().  These are added to
> > unittest in linux 6.3-rc1.
> >
> > I discussed this concept in one of the early TAP / KTAP discussion
>
> The link to the early KTAP discussion on this concept is:
>
>    https://lore.kernel.org/all/d38bf9f9-8a39-87a6-8ce7-d37e4a641675@gmail.com/T/#u
>
>

Thanks -- I'd totally forgotten about that!

I still personally would prefer a way of checking this from within the
kernel, as if we're just printing out "EXPECT: " lines, then it's not
possible to know if a test passes just from the raw results (and
things like statistics can't be updated without a separate tool like
kunit.py parsing the KTAP.

Indeed, my personal preference is that this log-based way of doing
expectations is probably best kept as a last resort. i.e.,
1. Try to add a hook to the code which prints the message, which can
then fail the test (or set a flag for the test to check later). This
probably needs some better KUnit-side helpers to be truly ergonomic,
but at least avoids too strict a dependency on the exact formatting of
the log messages.
2. If that doesn't work, use console tracepoints or similar to
implement an EXPECT_BEGIN() / EXPECT_END() or similar API entirely
within the kernel.
3. Only if we can't come up with a working way of doing the former
options, resort to adding "EXPECT:" lines and having a parser pick up
on this.

One of the downsides of doing "EXPECT" lines in KTAP is that it'll
suddenly be much more dependent on the exact layout of the tests, as
we'd need to be able to override a test result if an expectation fails
(at least, to maintain the KUnit structure). And overriding a result
which is already in the output seems really, really ugly.

There's a patch to the KASAN tests to move from doing option 1 to
option 2 above (in order to better support RCU, which didn't work with
the hook):
https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/


> > threads and expect to start a discussion thread on this specific
> > topic in the KTAP Specification V2 context.  I expect the discussion
> > to result in a different implementation than what DT unittests are
> > using (bike shedding likely to ensue) but whatever is agreed to
> > should be easy for DT to switch to.
>
> The link to the KTAP Specification Version 2 process and progress is:
>
>    https://elinux.org/Test_Results_Format_Notes#KTAP_version_2
>

Thanks! We've got a few more KTAP ideas to air, so will hopefully send
those out soon!

Cheers,
-- David

> >
> >>
> >> Hmm... I'd've thought that shouldn't be a problem: kunit.py should
> >> ignore most messages during a test, unless it can't find a valid
> >> result line. What does the raw KTAP output look like? (You can get it
> >> from kunit.py by passing the --raw_output option).
> >>
> >> That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
> >> we've wanted for a while. I think that the KASAN folks have been
> >> working on something similar using console tracepoints:
> >> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
> >>
> >> Cheers,
> >> -- David
> >
>

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 3/8] kunit: Add test managed platform_device/driver APIs

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]

Hi Stephen,

On Thu, Mar 09, 2023 at 03:31:15PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2023-03-03 06:35:28)
> > On Fri, Mar 03, 2023 at 03:15:31PM +0800, David Gow wrote:
> > > 
> > > DRM has a similar thing already (albeit with a root_device, which is
> > > more common with KUnit tests generally):
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_kunit_helpers.h
> > > 
> > > But that's reasonably drm-specific, so it makes sense that it lives
> > > with DRM stuff. platform_device is a bit more generic.
> > 
> > I'd be very happy to get something from the core to address the same
> > thing.
> > 
> > I think the main thing we needed that isn't covered by this patch is we
> > wanted the device to be bound to its driver, so with probe being called
> > before calling the test (see 57a84a97bbda).
>
> Can you clarify? This patch makes a poor attempt at waiting for the
> platform driver to bind, but in reality it may not be bound by the time
> the driver register function returns.

The issue was that devm will only clean up the resources if the device
was bound to a driver so we were exhausting resources when running
dozens of test in a sequence.

The way I solved it for vc4 was to create a dumb platform driver with a
waitqueue, and wait for probe to be called.

I think we could make it more generic by allowing a pointer to a probe
function and calling it into our own probe implementation. What do you
think?

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Frank Rowand]

On 3/15/23 02:04, David Gow wrote:
> On Tue, 14 Mar 2023 at 12:28, Frank Rowand <frowand.list@gmail.com> wrote:
>>
>> On 3/13/23 11:02, Frank Rowand wrote:
>>> On 3/11/23 00:42, David Gow wrote:
>>>> On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>
>>>>> Quoting David Gow (2023-03-10 00:09:48)
>>>>>> On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hmm. I think you're suggesting that the unit test data be loaded
>>>>>>> whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
>>>>>>> CONFIG_OF and skip if it isn't enabled?
>>>>>>>
>>>>>>
>>>>>> More of the opposite: that we should have some way of supporting tests
>>>>>> which might want to use a DTB other than the built-in one. Mostly for
>>>>>> non-UML situations where an actual devicetree is needed to even boot
>>>>>> far enough to get test output (so we wouldn't be able to override it
>>>>>> with a compiled-in test one).
>>>>>
>>>>> Ok, got it.
>>>>>
>>>>>>
>>>>>> I think moving to overlays probably will render this idea obsolete:
>>>>>> but the thought was to give test code a way to check for the required
>>>>>> devicetree nodes at runtime, and skip the test if they weren't found.
>>>>>> That way, the failure mode for trying to boot this on something which
>>>>>> required another device tree for, e.g., serial, would be "these tests
>>>>>> are skipped because the wrong device tree is loaded", not "I get no
>>>>>> output because serial isn't working".
>>>>>>
>>>>>> Again, though, it's only really needed for non-UML, and just loading
>>>>>> overlays as needed should be much more sensible anyway.
>>>>>
>>>>> I still have one niggle here. Loading overlays requires
>>>>> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
>>>>> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
>>>>> in each test, but I'm thinking it may be better to simply call
>>>>> kunit_skip() from the overlay loading function if the config is
>>>>> disabled. This way tests can simply call the overlay loading function
>>>>> and we'll halt the test immediately if the config isn't enabled.
>>>>>
>>>>
>>>> That sounds sensible, though there is a potential pitfall. If
>>>> kunit_skip() is called directly from overlay code, might introduce a
>>>> dependency on kunit.ko from the DT overlay, which we might not want.
>>>> The solution there is either to have a kunit wrapper function (so the
>>>> call is already in kunit.ko), or to have a hook to skip the current
>>>> test (which probably makes sense to do anyway, but I think the wrapper
>>>> is the better option).
>>>>
>>>>
>>>>>>
>>>>>>>>
>>>>>>>> That being said, I do think that there's probably some sense in
>>>>>>>> supporting the compiled-in DTB as well (it's definitely simpler than
>>>>>>>> patching kunit.py to always pass the extra command-line option in, for
>>>>>>>> example).
>>>>>>>> But maybe it'd be nice to have the command-line option override the
>>>>>>>> built-in one if present.
>>>>>>>
>>>>>>> Got it. I need to test loading another DTB on the commandline still, but
>>>>>>> I think this won't be a problem. We'll load the unittest-data DTB even
>>>>>>> with KUnit on UML, so assuming that works on UML right now it should be
>>>>>>> unchanged by this series once I resend.
>>>>>>
>>>>>> Again, moving to overlays should render this mostly obsolete, no? Or
>>>>>> am I misunderstanding how the overlay stuff will work?
>>>>>
>>>>> Right, overlays make it largely a moot issue. The way the OF unit tests
>>>>> work today is by grafting a DTB onto the live tree. I'm reusing that
>>>>> logic to graft a container node target for kunit tests to add their
>>>>> overlays too. It will be clearer once I post v2.
>>>>>
>>>>>>
>>>>>> One possible future advantage of being able to test with custom DTs at
>>>>>> boot time would be for fuzzing (provide random DT properties, see what
>>>>>> happens in the test). We've got some vague plans to support a way of
>>>>>> passing custom data to tests to support this kind of case (though, if
>>>>>> we're using overlays, maybe the test could just patch those if we
>>>>>> wanted to do that).
>>>>>
>>>>> Ah ok. I can see someone making a fuzzer that modifies devicetree
>>>>> properties randomly, e.g. using different strings for clock-names.
>>>>>
>>>>> This reminds me of another issue I ran into. I wanted to test adding the
>>>>> same platform device to the platform bus twice to confirm that the
>>>>> second device can't be added. That prints a warning, which makes
>>>>> kunit.py think that the test has failed because it printed a warning. Is
>>>>> there some way to avoid that? I want something like
>>>>>
>>>>>         KUNIT_EXPECT_WARNING(test, <call some function>)
>>>>>
>>>>> so I can test error cases.
>>>
>>> DT unittests already have a similar concept.  A test can report that a
>>> kernel warning (or any other specific text) either (1) must occur for the
>>> test to pass or (2) must _not_ occur for the test to pass.  The check
>>> for the kernel warning is done by the test output parsing program
>>> scripts/dtc/of_unittest_expect.
>>>
>>> The reporting by a test of an expected error in drivers/of/unittest.c
>>> is done by EXPECT_BEGIN() and EXPECT_END().  These have been in
>>> unittest for a long time.
>>>
>>> The reporting by a test of a not expected to occur error is done
>>> by EXPECT_NOT_BEGIN() and EXPECT_NOT_END().  These are added to
>>> unittest in linux 6.3-rc1.
>>>
>>> I discussed this concept in one of the early TAP / KTAP discussion
>>
>> The link to the early KTAP discussion on this concept is:
>>
>>    https://lore.kernel.org/all/d38bf9f9-8a39-87a6-8ce7-d37e4a641675@gmail.com/T/#u
>>
>>
> 
> Thanks -- I'd totally forgotten about that!
> 

> I still personally would prefer a way of checking this from within the
> kernel, as if we're just printing out "EXPECT: " lines, then it's not
> possible to know if a test passes just from the raw results (and
> things like statistics can't be updated without a separate tool like
> kunit.py parsing the KTAP.

Yes, I totally agree with that.  If there is a reasonable way to
implement.  But in the DT unittest world, I have not found a
reasonable way.  Adding hooks is suggested below, but for DT
unittest _I_ (opinion) do not find that reasonable.  I voice no
vote for kunit - that decision is up to the kunit crowd.

> 
> Indeed, my personal preference is that this log-based way of doing
> expectations is probably best kept as a last resort. i.e.,
> 1. Try to add a hook to the code which prints the message, which can
> then fail the test (or set a flag for the test to check later). This
> probably needs some better KUnit-side helpers to be truly ergonomic,
> but at least avoids too strict a dependency on the exact formatting of
> the log messages.

I'm not a fan of hooks.  I see them as a maintenance burden, dependent
upon the source version of the object being tested, yet another
thing that can go wrong, and adds complexity to creating a test
environment and running the test.  Again, this just a personal
opinion, and I'm not voting for or against this for kunit.

> 2. If that doesn't work, use console tracepoints or similar to
> implement an EXPECT_BEGIN() / EXPECT_END() or similar API entirely
> within the kernel.

Isn't this just another hook?  So same opinion.

> 3. Only if we can't come up with a working way of doing the former
> options, resort to adding "EXPECT:" lines and having a parser pick up
> on this.

Again, don't let my opinion affect the voting between 1, 2, 3, or other
for kunit.

> 
> One of the downsides of doing "EXPECT" lines in KTAP is that it'll
> suddenly be much more dependent on the exact layout of the tests, as
> we'd need to be able to override a test result if an expectation fails
> (at least, to maintain the KUnit structure). And overriding a result
> which is already in the output seems really, really ugly.

I don't understand "dependent on the exact layout of the tests".
If you are saying that the test result parser has to figure out
which test result to override, that has not been an issue in
the cases that I use EXPECTs in DT unittest.  The EXPECT begin and
EXPECT end have always immediately surrounded a single test, so
when the parser processes the EXPECT end, only the most recent
test result could be overridden.  This has worked because the
kernel warning and error messages have been from kernel action
that happens synchronously with the test.  If the test prods the
kernel in a way that results in the kernel performing an
asynchronous activity (eg in another thread), then it becomes
more complex to structure the EXPECT end -- I would imagine that the
test would have to block on the asynchronous activity just before
reporting the normal KTAP status result for the test (and the
EXPECT end would normally be just after reporting the KTAP
status result for the test).

I agree with overriding being ugly.  For the DT unittest results
parser, the EXPECT summary results are reported separately from
the individual test summary results.  The parser also flags the
EXPECT failure in line with the normal individual test result
lines.

I see both parsing results as valid, and as a policy choice for
each test parser.

> 
> There's a patch to the KASAN tests to move from doing option 1 to
> option 2 above (in order to better support RCU, which didn't work with
> the hook):
> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
> 
> 
>>> threads and expect to start a discussion thread on this specific
>>> topic in the KTAP Specification V2 context.  I expect the discussion
>>> to result in a different implementation than what DT unittests are
>>> using (bike shedding likely to ensue) but whatever is agreed to
>>> should be easy for DT to switch to.
>>
>> The link to the KTAP Specification Version 2 process and progress is:
>>
>>    https://elinux.org/Test_Results_Format_Notes#KTAP_version_2
>>
> 
> Thanks! We've got a few more KTAP ideas to air, so will hopefully send
> those out soon!

Glad to hear, I'm hoping that process starts progressing a bit.

-Frank

> 
> Cheers,
> -- David
> 
>>>
>>>>
>>>> Hmm... I'd've thought that shouldn't be a problem: kunit.py should
>>>> ignore most messages during a test, unless it can't find a valid
>>>> result line. What does the raw KTAP output look like? (You can get it
>>>> from kunit.py by passing the --raw_output option).
>>>>
>>>> That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
>>>> we've wanted for a while. I think that the KASAN folks have been
>>>> working on something similar using console tracepoints:
>>>> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
>>>>
>>>> Cheers,
>>>> -- David
>>>
>>


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Frank Rowand]

On 3/15/23 16:35, Frank Rowand wrote:
> On 3/15/23 02:04, David Gow wrote:
>> On Tue, 14 Mar 2023 at 12:28, Frank Rowand <frowand.list@gmail.com> wrote:
>>>
>>> On 3/13/23 11:02, Frank Rowand wrote:
>>>> On 3/11/23 00:42, David Gow wrote:
>>>>> On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>>
>>>>>> Quoting David Gow (2023-03-10 00:09:48)
>>>>>>> On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hmm. I think you're suggesting that the unit test data be loaded
>>>>>>>> whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
>>>>>>>> CONFIG_OF and skip if it isn't enabled?
>>>>>>>>
>>>>>>>
>>>>>>> More of the opposite: that we should have some way of supporting tests
>>>>>>> which might want to use a DTB other than the built-in one. Mostly for
>>>>>>> non-UML situations where an actual devicetree is needed to even boot
>>>>>>> far enough to get test output (so we wouldn't be able to override it
>>>>>>> with a compiled-in test one).
>>>>>>
>>>>>> Ok, got it.
>>>>>>
>>>>>>>
>>>>>>> I think moving to overlays probably will render this idea obsolete:
>>>>>>> but the thought was to give test code a way to check for the required
>>>>>>> devicetree nodes at runtime, and skip the test if they weren't found.
>>>>>>> That way, the failure mode for trying to boot this on something which
>>>>>>> required another device tree for, e.g., serial, would be "these tests
>>>>>>> are skipped because the wrong device tree is loaded", not "I get no
>>>>>>> output because serial isn't working".
>>>>>>>
>>>>>>> Again, though, it's only really needed for non-UML, and just loading
>>>>>>> overlays as needed should be much more sensible anyway.
>>>>>>
>>>>>> I still have one niggle here. Loading overlays requires
>>>>>> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
>>>>>> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
>>>>>> in each test, but I'm thinking it may be better to simply call
>>>>>> kunit_skip() from the overlay loading function if the config is
>>>>>> disabled. This way tests can simply call the overlay loading function
>>>>>> and we'll halt the test immediately if the config isn't enabled.
>>>>>>
>>>>>
>>>>> That sounds sensible, though there is a potential pitfall. If
>>>>> kunit_skip() is called directly from overlay code, might introduce a
>>>>> dependency on kunit.ko from the DT overlay, which we might not want.
>>>>> The solution there is either to have a kunit wrapper function (so the
>>>>> call is already in kunit.ko), or to have a hook to skip the current
>>>>> test (which probably makes sense to do anyway, but I think the wrapper
>>>>> is the better option).
>>>>>
>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> That being said, I do think that there's probably some sense in
>>>>>>>>> supporting the compiled-in DTB as well (it's definitely simpler than
>>>>>>>>> patching kunit.py to always pass the extra command-line option in, for
>>>>>>>>> example).
>>>>>>>>> But maybe it'd be nice to have the command-line option override the
>>>>>>>>> built-in one if present.
>>>>>>>>
>>>>>>>> Got it. I need to test loading another DTB on the commandline still, but
>>>>>>>> I think this won't be a problem. We'll load the unittest-data DTB even
>>>>>>>> with KUnit on UML, so assuming that works on UML right now it should be
>>>>>>>> unchanged by this series once I resend.
>>>>>>>
>>>>>>> Again, moving to overlays should render this mostly obsolete, no? Or
>>>>>>> am I misunderstanding how the overlay stuff will work?
>>>>>>
>>>>>> Right, overlays make it largely a moot issue. The way the OF unit tests
>>>>>> work today is by grafting a DTB onto the live tree. I'm reusing that
>>>>>> logic to graft a container node target for kunit tests to add their
>>>>>> overlays too. It will be clearer once I post v2.
>>>>>>
>>>>>>>
>>>>>>> One possible future advantage of being able to test with custom DTs at
>>>>>>> boot time would be for fuzzing (provide random DT properties, see what
>>>>>>> happens in the test). We've got some vague plans to support a way of
>>>>>>> passing custom data to tests to support this kind of case (though, if
>>>>>>> we're using overlays, maybe the test could just patch those if we
>>>>>>> wanted to do that).
>>>>>>
>>>>>> Ah ok. I can see someone making a fuzzer that modifies devicetree
>>>>>> properties randomly, e.g. using different strings for clock-names.
>>>>>>
>>>>>> This reminds me of another issue I ran into. I wanted to test adding the
>>>>>> same platform device to the platform bus twice to confirm that the
>>>>>> second device can't be added. That prints a warning, which makes
>>>>>> kunit.py think that the test has failed because it printed a warning. Is
>>>>>> there some way to avoid that? I want something like
>>>>>>
>>>>>>         KUNIT_EXPECT_WARNING(test, <call some function>)
>>>>>>
>>>>>> so I can test error cases.
>>>>
>>>> DT unittests already have a similar concept.  A test can report that a
>>>> kernel warning (or any other specific text) either (1) must occur for the
>>>> test to pass or (2) must _not_ occur for the test to pass.  The check
>>>> for the kernel warning is done by the test output parsing program
>>>> scripts/dtc/of_unittest_expect.
>>>>
>>>> The reporting by a test of an expected error in drivers/of/unittest.c
>>>> is done by EXPECT_BEGIN() and EXPECT_END().  These have been in
>>>> unittest for a long time.
>>>>
>>>> The reporting by a test of a not expected to occur error is done
>>>> by EXPECT_NOT_BEGIN() and EXPECT_NOT_END().  These are added to
>>>> unittest in linux 6.3-rc1.
>>>>
>>>> I discussed this concept in one of the early TAP / KTAP discussion
>>>
>>> The link to the early KTAP discussion on this concept is:
>>>
>>>    https://lore.kernel.org/all/d38bf9f9-8a39-87a6-8ce7-d37e4a641675@gmail.com/T/#u
>>>
>>>
>>
>> Thanks -- I'd totally forgotten about that!
>>
> 
>> I still personally would prefer a way of checking this from within the
>> kernel, as if we're just printing out "EXPECT: " lines, then it's not
>> possible to know if a test passes just from the raw results (and
>> things like statistics can't be updated without a separate tool like
>> kunit.py parsing the KTAP.
> 
> Yes, I totally agree with that.  If there is a reasonable way to
> implement.  But in the DT unittest world, I have not found a
> reasonable way.  Adding hooks is suggested below, but for DT
> unittest _I_ (opinion) do not find that reasonable.  I voice no
> vote for kunit - that decision is up to the kunit crowd.
> 
>>
>> Indeed, my personal preference is that this log-based way of doing
>> expectations is probably best kept as a last resort. i.e.,
>> 1. Try to add a hook to the code which prints the message, which can
>> then fail the test (or set a flag for the test to check later). This
>> probably needs some better KUnit-side helpers to be truly ergonomic,
>> but at least avoids too strict a dependency on the exact formatting of
>> the log messages.
> 
> I'm not a fan of hooks.  I see them as a maintenance burden, dependent
> upon the source version of the object being tested, yet another
> thing that can go wrong, and adds complexity to creating a test
> environment and running the test.  Again, this just a personal
> opinion, and I'm not voting for or against this for kunit.
> 
>> 2. If that doesn't work, use console tracepoints or similar to
>> implement an EXPECT_BEGIN() / EXPECT_END() or similar API entirely
>> within the kernel.
> 
> Isn't this just another hook?  So same opinion.
> 
>> 3. Only if we can't come up with a working way of doing the former
>> options, resort to adding "EXPECT:" lines and having a parser pick up
>> on this.

Adding one more thought here so I don't forget it before the topic picks
up again in the KTAP version 2 world...

The test parser could generate an artificial subtest test case status line
or normal test case status line to report the result of the EXPECT.  This
also is ugly because it is creating a new requirement on the parser vs the
expectations in the KTAP plan line (the plan line could include the EXPECT
in the number of tests count, but then the raw KTAP test output would be
missing the artificial EXPECT test result).  No need to hash out details
here, just a thought...

-Frank

> 
> Again, don't let my opinion affect the voting between 1, 2, 3, or other
> for kunit.
> 
>>
>> One of the downsides of doing "EXPECT" lines in KTAP is that it'll
>> suddenly be much more dependent on the exact layout of the tests, as
>> we'd need to be able to override a test result if an expectation fails
>> (at least, to maintain the KUnit structure). And overriding a result
>> which is already in the output seems really, really ugly.
> 
> I don't understand "dependent on the exact layout of the tests".
> If you are saying that the test result parser has to figure out
> which test result to override, that has not been an issue in
> the cases that I use EXPECTs in DT unittest.  The EXPECT begin and
> EXPECT end have always immediately surrounded a single test, so
> when the parser processes the EXPECT end, only the most recent
> test result could be overridden.  This has worked because the
> kernel warning and error messages have been from kernel action
> that happens synchronously with the test.  If the test prods the
> kernel in a way that results in the kernel performing an
> asynchronous activity (eg in another thread), then it becomes
> more complex to structure the EXPECT end -- I would imagine that the
> test would have to block on the asynchronous activity just before
> reporting the normal KTAP status result for the test (and the
> EXPECT end would normally be just after reporting the KTAP
> status result for the test).
> 
> I agree with overriding being ugly.  For the DT unittest results
> parser, the EXPECT summary results are reported separately from
> the individual test summary results.  The parser also flags the
> EXPECT failure in line with the normal individual test result
> lines.
> 
> I see both parsing results as valid, and as a policy choice for
> each test parser.
> 
>>
>> There's a patch to the KASAN tests to move from doing option 1 to
>> option 2 above (in order to better support RCU, which didn't work with
>> the hook):
>> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
>>
>>
>>>> threads and expect to start a discussion thread on this specific
>>>> topic in the KTAP Specification V2 context.  I expect the discussion
>>>> to result in a different implementation than what DT unittests are
>>>> using (bike shedding likely to ensue) but whatever is agreed to
>>>> should be easy for DT to switch to.
>>>
>>> The link to the KTAP Specification Version 2 process and progress is:
>>>
>>>    https://elinux.org/Test_Results_Format_Notes#KTAP_version_2
>>>
>>
>> Thanks! We've got a few more KTAP ideas to air, so will hopefully send
>> those out soon!
> 
> Glad to hear, I'm hoping that process starts progressing a bit.
> 
> -Frank
> 
>>
>> Cheers,
>> -- David
>>
>>>>
>>>>>
>>>>> Hmm... I'd've thought that shouldn't be a problem: kunit.py should
>>>>> ignore most messages during a test, unless it can't find a valid
>>>>> result line. What does the raw KTAP output look like? (You can get it
>>>>> from kunit.py by passing the --raw_output option).
>>>>>
>>>>> That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
>>>>> we've wanted for a while. I think that the KASAN folks have been
>>>>> working on something similar using console tracepoints:
>>>>> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
>>>>>
>>>>> Cheers,
>>>>> -- David
>>>>
>>>
> 


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[David Gow]

[-- Attachment #1.1: Type: text/plain, Size: 14781 bytes --]

On Thu, 16 Mar 2023 at 08:45, Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 3/15/23 16:35, Frank Rowand wrote:
> > On 3/15/23 02:04, David Gow wrote:
> >> On Tue, 14 Mar 2023 at 12:28, Frank Rowand <frowand.list@gmail.com> wrote:
> >>>
> >>> On 3/13/23 11:02, Frank Rowand wrote:
> >>>> On 3/11/23 00:42, David Gow wrote:
> >>>>> On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd@kernel.org> wrote:
> >>>>>>
> >>>>>> Quoting David Gow (2023-03-10 00:09:48)
> >>>>>>> On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd@kernel.org> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hmm. I think you're suggesting that the unit test data be loaded
> >>>>>>>> whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
> >>>>>>>> CONFIG_OF and skip if it isn't enabled?
> >>>>>>>>
> >>>>>>>
> >>>>>>> More of the opposite: that we should have some way of supporting tests
> >>>>>>> which might want to use a DTB other than the built-in one. Mostly for
> >>>>>>> non-UML situations where an actual devicetree is needed to even boot
> >>>>>>> far enough to get test output (so we wouldn't be able to override it
> >>>>>>> with a compiled-in test one).
> >>>>>>
> >>>>>> Ok, got it.
> >>>>>>
> >>>>>>>
> >>>>>>> I think moving to overlays probably will render this idea obsolete:
> >>>>>>> but the thought was to give test code a way to check for the required
> >>>>>>> devicetree nodes at runtime, and skip the test if they weren't found.
> >>>>>>> That way, the failure mode for trying to boot this on something which
> >>>>>>> required another device tree for, e.g., serial, would be "these tests
> >>>>>>> are skipped because the wrong device tree is loaded", not "I get no
> >>>>>>> output because serial isn't working".
> >>>>>>>
> >>>>>>> Again, though, it's only really needed for non-UML, and just loading
> >>>>>>> overlays as needed should be much more sensible anyway.
> >>>>>>
> >>>>>> I still have one niggle here. Loading overlays requires
> >>>>>> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
> >>>>>> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
> >>>>>> in each test, but I'm thinking it may be better to simply call
> >>>>>> kunit_skip() from the overlay loading function if the config is
> >>>>>> disabled. This way tests can simply call the overlay loading function
> >>>>>> and we'll halt the test immediately if the config isn't enabled.
> >>>>>>
> >>>>>
> >>>>> That sounds sensible, though there is a potential pitfall. If
> >>>>> kunit_skip() is called directly from overlay code, might introduce a
> >>>>> dependency on kunit.ko from the DT overlay, which we might not want.
> >>>>> The solution there is either to have a kunit wrapper function (so the
> >>>>> call is already in kunit.ko), or to have a hook to skip the current
> >>>>> test (which probably makes sense to do anyway, but I think the wrapper
> >>>>> is the better option).
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> That being said, I do think that there's probably some sense in
> >>>>>>>>> supporting the compiled-in DTB as well (it's definitely simpler than
> >>>>>>>>> patching kunit.py to always pass the extra command-line option in, for
> >>>>>>>>> example).
> >>>>>>>>> But maybe it'd be nice to have the command-line option override the
> >>>>>>>>> built-in one if present.
> >>>>>>>>
> >>>>>>>> Got it. I need to test loading another DTB on the commandline still, but
> >>>>>>>> I think this won't be a problem. We'll load the unittest-data DTB even
> >>>>>>>> with KUnit on UML, so assuming that works on UML right now it should be
> >>>>>>>> unchanged by this series once I resend.
> >>>>>>>
> >>>>>>> Again, moving to overlays should render this mostly obsolete, no? Or
> >>>>>>> am I misunderstanding how the overlay stuff will work?
> >>>>>>
> >>>>>> Right, overlays make it largely a moot issue. The way the OF unit tests
> >>>>>> work today is by grafting a DTB onto the live tree. I'm reusing that
> >>>>>> logic to graft a container node target for kunit tests to add their
> >>>>>> overlays too. It will be clearer once I post v2.
> >>>>>>
> >>>>>>>
> >>>>>>> One possible future advantage of being able to test with custom DTs at
> >>>>>>> boot time would be for fuzzing (provide random DT properties, see what
> >>>>>>> happens in the test). We've got some vague plans to support a way of
> >>>>>>> passing custom data to tests to support this kind of case (though, if
> >>>>>>> we're using overlays, maybe the test could just patch those if we
> >>>>>>> wanted to do that).
> >>>>>>
> >>>>>> Ah ok. I can see someone making a fuzzer that modifies devicetree
> >>>>>> properties randomly, e.g. using different strings for clock-names.
> >>>>>>
> >>>>>> This reminds me of another issue I ran into. I wanted to test adding the
> >>>>>> same platform device to the platform bus twice to confirm that the
> >>>>>> second device can't be added. That prints a warning, which makes
> >>>>>> kunit.py think that the test has failed because it printed a warning. Is
> >>>>>> there some way to avoid that? I want something like
> >>>>>>
> >>>>>>         KUNIT_EXPECT_WARNING(test, <call some function>)
> >>>>>>
> >>>>>> so I can test error cases.
> >>>>
> >>>> DT unittests already have a similar concept.  A test can report that a
> >>>> kernel warning (or any other specific text) either (1) must occur for the
> >>>> test to pass or (2) must _not_ occur for the test to pass.  The check
> >>>> for the kernel warning is done by the test output parsing program
> >>>> scripts/dtc/of_unittest_expect.
> >>>>
> >>>> The reporting by a test of an expected error in drivers/of/unittest.c
> >>>> is done by EXPECT_BEGIN() and EXPECT_END().  These have been in
> >>>> unittest for a long time.
> >>>>
> >>>> The reporting by a test of a not expected to occur error is done
> >>>> by EXPECT_NOT_BEGIN() and EXPECT_NOT_END().  These are added to
> >>>> unittest in linux 6.3-rc1.
> >>>>
> >>>> I discussed this concept in one of the early TAP / KTAP discussion
> >>>
> >>> The link to the early KTAP discussion on this concept is:
> >>>
> >>>    https://lore.kernel.org/all/d38bf9f9-8a39-87a6-8ce7-d37e4a641675@gmail.com/T/#u
> >>>
> >>>
> >>
> >> Thanks -- I'd totally forgotten about that!
> >>
> >
> >> I still personally would prefer a way of checking this from within the
> >> kernel, as if we're just printing out "EXPECT: " lines, then it's not
> >> possible to know if a test passes just from the raw results (and
> >> things like statistics can't be updated without a separate tool like
> >> kunit.py parsing the KTAP.
> >
> > Yes, I totally agree with that.  If there is a reasonable way to
> > implement.  But in the DT unittest world, I have not found a
> > reasonable way.  Adding hooks is suggested below, but for DT
> > unittest _I_ (opinion) do not find that reasonable.  I voice no
> > vote for kunit - that decision is up to the kunit crowd.
> >
> >>
> >> Indeed, my personal preference is that this log-based way of doing
> >> expectations is probably best kept as a last resort. i.e.,
> >> 1. Try to add a hook to the code which prints the message, which can
> >> then fail the test (or set a flag for the test to check later). This
> >> probably needs some better KUnit-side helpers to be truly ergonomic,
> >> but at least avoids too strict a dependency on the exact formatting of
> >> the log messages.
> >
> > I'm not a fan of hooks.  I see them as a maintenance burden, dependent
> > upon the source version of the object being tested, yet another
> > thing that can go wrong, and adds complexity to creating a test
> > environment and running the test.  Again, this just a personal
> > opinion, and I'm not voting for or against this for kunit.
> >

I definitely agree that they've got their problems, and aren't the
right solution for every test.

That being said, I think a few of those problems also apply to
expecting individual error lines, which are basically doing the same
thing, just less explicitly (though with the advantage of serving
another real-world purpose).

> >> 2. If that doesn't work, use console tracepoints or similar to
> >> implement an EXPECT_BEGIN() / EXPECT_END() or similar API entirely
> >> within the kernel.
> >
> > Isn't this just another hook?  So same opinion.
> >

I see what you mean. I guess the distinction I was trying to draw was
between a specific hook, implemented as such explicitly on both sides,
and a generic mechanism for console-message-based expectations.

So the difference is that, once the EXPECT_BEGIN()/EXPECT_END() macros
have been implemented this way, the uses of them should look the same.

> >> 3. Only if we can't come up with a working way of doing the former
> >> options, resort to adding "EXPECT:" lines and having a parser pick up
> >> on this.
>
> Adding one more thought here so I don't forget it before the topic picks
> up again in the KTAP version 2 world...
>
> The test parser could generate an artificial subtest test case status line
> or normal test case status line to report the result of the EXPECT.  This
> also is ugly because it is creating a new requirement on the parser vs the
> expectations in the KTAP plan line (the plan line could include the EXPECT
> in the number of tests count, but then the raw KTAP test output would be
> missing the artificial EXPECT test result).  No need to hash out details
> here, just a thought...
>

Yeah, I think if we have this done at the parser level, our options
are either that or an override.

For KUnit, I think the override makes much more sense, as logically,
any expectation would be considered part of an existing test case.
Maybe we could treat an override as a "subtest" of the current test,
but injecting a test case anywhere else would go pretty seriously
against the KUnit model.

> -Frank
>
> >
> > Again, don't let my opinion affect the voting between 1, 2, 3, or other
> > for kunit.
> >
> >>
> >> One of the downsides of doing "EXPECT" lines in KTAP is that it'll
> >> suddenly be much more dependent on the exact layout of the tests, as
> >> we'd need to be able to override a test result if an expectation fails
> >> (at least, to maintain the KUnit structure). And overriding a result
> >> which is already in the output seems really, really ugly.
> >
> > I don't understand "dependent on the exact layout of the tests".
> > If you are saying that the test result parser has to figure out
> > which test result to override, that has not been an issue in
> > the cases that I use EXPECTs in DT unittest.  The EXPECT begin and
> > EXPECT end have always immediately surrounded a single test, so
> > when the parser processes the EXPECT end, only the most recent
> > test result could be overridden.  This has worked because the
> > kernel warning and error messages have been from kernel action
> > that happens synchronously with the test.  If the test prods the
> > kernel in a way that results in the kernel performing an
> > asynchronous activity (eg in another thread), then it becomes
> > more complex to structure the EXPECT end -- I would imagine that the
> > test would have to block on the asynchronous activity just before
> > reporting the normal KTAP status result for the test (and the
> > EXPECT end would normally be just after reporting the KTAP
> > status result for the test).

Okay: I agree 100% with you there.

I think the difference I was thinking of is more whether expectations
are considered part of an existing test (which may need overriding),
or exist as their own separate test result (as you suggest in the
follow-up email above).

> >
> > I agree with overriding being ugly.  For the DT unittest results
> > parser, the EXPECT summary results are reported separately from
> > the individual test summary results.  The parser also flags the
> > EXPECT failure in line with the normal individual test result
> > lines.
> >
> > I see both parsing results as valid, and as a policy choice for
> > each test parser.
> >

I agree that each parser should have some leeway here, but do think we
want to make sure the results have some sensible, standardised
interpretation, so that we can use parsers interchangeably without
getting totally inconsistent results. That's the big advantage of
standardisation, after all.

My philosophical objection to overriding is that it's really confusing
to have an "ok" line in the results, indicating that a test has
passed, when the test has in fact failed (because the expectation
doesn't match). This gets worse when subtests are considered, and we
have these misleading results bubbled up to reported overall "suite"
results.

I guess one solution is to have an extra layer of parsing, which takes
raw kernel output, verifies the expectations, and then outputs
"processed KTAP", with all of the final results resolved. But that's
ugly in a way, too.

> >>
> >> There's a patch to the KASAN tests to move from doing option 1 to
> >> option 2 above (in order to better support RCU, which didn't work with
> >> the hook):
> >> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
> >>
> >>
> >>>> threads and expect to start a discussion thread on this specific
> >>>> topic in the KTAP Specification V2 context.  I expect the discussion
> >>>> to result in a different implementation than what DT unittests are
> >>>> using (bike shedding likely to ensue) but whatever is agreed to
> >>>> should be easy for DT to switch to.
> >>>
> >>> The link to the KTAP Specification Version 2 process and progress is:
> >>>
> >>>    https://elinux.org/Test_Results_Format_Notes#KTAP_version_2
> >>>
> >>
> >> Thanks! We've got a few more KTAP ideas to air, so will hopefully send
> >> those out soon!
> >
> > Glad to hear, I'm hoping that process starts progressing a bit.
> >

Yeah. I'll shift further discussion of this to a KTAP proposal: I
don't want to derail this thread too much further.

We'll keep looking at fully in-kernel ways of achieving similar things
in the meantime.

Cheers,
-- David

> > -Frank
> >
> >>
> >> Cheers,
> >> -- David
> >>
> >>>>
> >>>>>
> >>>>> Hmm... I'd've thought that shouldn't be a problem: kunit.py should
> >>>>> ignore most messages during a test, unless it can't find a valid
> >>>>> result line. What does the raw KTAP output look like? (You can get it
> >>>>> from kunit.py by passing the --raw_output option).
> >>>>>
> >>>>> That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
> >>>>> we've wanted for a while. I think that the KASAN folks have been
> >>>>> working on something similar using console tracepoints:
> >>>>> https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.1666113393.git.andreyknvl@google.com/
> >>>>>
> >>>>> Cheers,
> >>>>> -- David
> >>>>
> >>>
> >
>

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 4/8] clk: Add test managed clk provider/consumer APIs

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1994 bytes --]

On Sat, Mar 11, 2023 at 02:32:04PM +0800, David Gow wrote:
> > > > diff --git a/drivers/clk/clk-kunit.c b/drivers/clk/clk-kunit.c
> > > > new file mode 100644
> > > > index 000000000000..78d85b3a7a4a
> > > > --- /dev/null
> > > > +++ b/drivers/clk/clk-kunit.c
> > > > @@ -0,0 +1,204 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * KUnit helpers for clk tests
> > > > + */
> > > > +#include <linux/clk.h>
> > > > +#include <linux/clk-provider.h>
> > > > +#include <linux/err.h>
> > > > +#include <linux/kernel.h>
> > > > +#include <linux/slab.h>
> > > > +
> > > > +#include <kunit/resource.h>
> > > > +
> > > > +#include "clk-kunit.h"
> > > > +
> > > > +static void kunit_clk_disable_unprepare(struct kunit_resource *res)
> > >
> > > We need to decide on the naming scheme of these, and in particular if
> > > they should be kunit_clk or clk_kunit (or something else).
> > >
> > > I'd lean to clk_kunit, if only to match DRM's KUnit helpers being
> > > drm_kunit_helper better, and so that these are more tightly bound to
> > > the subsystem being tested.
> > > (i.e., so I don't have to scroll through every subsystem's helpers
> > > when autocompleting kunit_).
> >
> > Ok, got it. I was trying to match kunit_kzalloc() style. It makes it
> > easy to slap the 'kunit_' prefix on existing auto-completed function
> > names like kzalloc() or clk_prepare_enable().
> 
> Yeah: my rule of thumb at the moment is to keep the kunit_ prefix for
> things which are generic across the whole kernel (and tend to be
> implemented in lib/kunit), and to use suffixes or infixes (whichever
> works best) for things which are subsystem-specific.

A suffix is kind of weird though when any other managed call is using a
prefix: devm is always using a prefix including for clocks, kunit for
some calls too (like kzalloc).

Having clk_get vs devm_clk_get vs clk_get_kunit would be very
inconsistent and throws me off completely :)

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Re: [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests

[Stephen Boyd]

Quoting David Gow (2023-03-10 22:42:24)
> Hmm... I'd've thought that shouldn't be a problem: kunit.py should
> ignore most messages during a test, unless it can't find a valid
> result line. What does the raw KTAP output look like? (You can get it
> from kunit.py by passing the --raw_output option).
> 

I rebased and retried on v6.3-rc1 and it isn't a problem. Maybe there
was some problem on v6.2?

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um