From: Rob Herring <robh+dt@kernel.org> To: David Gow <davidgow@google.com>, Stephen Boyd <sboyd@kernel.org> Cc: Michael Turquette <mturquette@baylibre.com>, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, patches@lists.linux.dev, Brendan Higgins <brendan.higgins@linux.dev>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J . Wysocki" <rafael@kernel.org>, Richard Weinberger <richard@nod.at>, Anton Ivanov <anton.ivanov@cambridgegreys.com>, Johannes Berg <johannes@sipsolutions.net>, Vincent Whitchurch <vincent.whitchurch@axis.com>, Frank Rowand <frowand.list@gmail.com>, Christian Marangi <ansuelsmth@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, devicetree@vger.kernel.org, linux-um@lists.infradead.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com Subject: Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data Date: Thu, 2 Mar 2023 11:32:09 -0600 [thread overview] Message-ID: <CAL_JsqJMd3Fi0ZBObdyE1VDKTH1_+smuGDymHnKOkVH2HB3jJQ@mail.gmail.com> (raw) In-Reply-To: <CABVgOSnpMNCtEEsJV28OzUoxdDuiT4a2T0avP0AYf9xFW1jxrw@mail.gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org> To: David Gow <davidgow@google.com>, Stephen Boyd <sboyd@kernel.org> Cc: Michael Turquette <mturquette@baylibre.com>, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, patches@lists.linux.dev, Brendan Higgins <brendan.higgins@linux.dev>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J . Wysocki" <rafael@kernel.org>, Richard Weinberger <richard@nod.at>, Anton Ivanov <anton.ivanov@cambridgegreys.com>, Johannes Berg <johannes@sipsolutions.net>, Vincent Whitchurch <vincent.whitchurch@axis.com>, Frank Rowand <frowand.list@gmail.com>, Christian Marangi <ansuelsmth@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, devicetree@vger.kernel.org, linux-um@lists.infradead.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com Subject: Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data Date: Thu, 2 Mar 2023 11:32:09 -0600 [thread overview] Message-ID: <CAL_JsqJMd3Fi0ZBObdyE1VDKTH1_+smuGDymHnKOkVH2HB3jJQ@mail.gmail.com> (raw) In-Reply-To: <CABVgOSnpMNCtEEsJV28OzUoxdDuiT4a2T0avP0AYf9xFW1jxrw@mail.gmail.com> 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
next prev parent reply other threads:[~2023-03-02 17:32 UTC|newest] Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-02 1:38 [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-02 1:38 ` [PATCH 1/8] dt-bindings: Add linux,kunit binding Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-03 7:14 ` David Gow 2023-03-03 7:14 ` David Gow 2023-03-03 7:49 ` Geert Uytterhoeven 2023-03-03 7:49 ` Geert Uytterhoeven 2023-03-09 23:12 ` Stephen Boyd 2023-03-09 23:12 ` Stephen Boyd 2023-03-10 7:55 ` David Gow 2023-03-10 7:55 ` David Gow 2023-03-02 1:38 ` [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-03 7:15 ` David Gow 2023-03-03 7:15 ` David Gow 2023-03-09 23:19 ` Stephen Boyd 2023-03-09 23:19 ` Stephen Boyd 2023-03-10 8:09 ` David Gow 2023-03-10 8:09 ` David Gow 2023-03-10 23:34 ` Stephen Boyd 2023-03-10 23:34 ` Stephen Boyd 2023-03-11 6:42 ` David Gow 2023-03-11 6:42 ` David Gow 2023-03-13 16:02 ` Frank Rowand 2023-03-13 16:02 ` Frank Rowand 2023-03-14 4:28 ` Frank Rowand 2023-03-14 4:28 ` Frank Rowand 2023-03-15 7:04 ` David Gow 2023-03-15 7:04 ` David Gow 2023-03-15 21:35 ` Frank Rowand 2023-03-15 21:35 ` Frank Rowand 2023-03-16 0:45 ` Frank Rowand 2023-03-16 0:45 ` Frank Rowand 2023-03-16 4:15 ` David Gow 2023-03-16 4:15 ` David Gow 2023-03-21 20:56 ` Stephen Boyd 2023-03-21 20:56 ` Stephen Boyd 2023-03-08 19:46 ` Rob Herring 2023-03-08 19:46 ` Rob Herring 2023-03-02 1:38 ` [PATCH 3/8] kunit: Add test managed platform_device/driver APIs Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-03 7:15 ` David Gow 2023-03-03 7:15 ` David Gow 2023-03-03 14:35 ` Maxime Ripard 2023-03-03 14:35 ` Maxime Ripard 2023-03-09 23:31 ` Stephen Boyd 2023-03-09 23:31 ` Stephen Boyd 2023-03-15 8:27 ` Maxime Ripard 2023-03-15 8:27 ` Maxime Ripard 2023-03-09 23:25 ` Stephen Boyd 2023-03-09 23:25 ` Stephen Boyd 2023-03-10 8:19 ` David Gow 2023-03-10 8:19 ` David Gow 2023-03-02 1:38 ` [PATCH 4/8] clk: Add test managed clk provider/consumer APIs Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-03 7:15 ` David Gow 2023-03-03 7:15 ` David Gow 2023-03-10 23:21 ` Stephen Boyd 2023-03-10 23:21 ` Stephen Boyd 2023-03-11 6:32 ` David Gow 2023-03-11 6:32 ` David Gow 2023-03-21 14:32 ` Maxime Ripard 2023-03-21 14:32 ` Maxime Ripard 2023-03-02 1:38 ` [PATCH 5/8] dt-bindings: kunit: Add fixed rate clk consumer test Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-02 1:38 ` [PATCH 6/8] clk: Add KUnit tests for clk fixed rate basic type Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-02 1:38 ` [PATCH 7/8] dt-bindings: clk: Add KUnit clk_parent_data test Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-02 1:38 ` [PATCH 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data Stephen Boyd 2023-03-02 1:38 ` Stephen Boyd 2023-03-02 8:13 ` [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data David Gow 2023-03-02 8:13 ` David Gow 2023-03-02 17:32 ` Rob Herring [this message] 2023-03-02 17:32 ` Rob Herring 2023-03-02 19:27 ` Stephen Boyd 2023-03-02 19:27 ` Stephen Boyd 2023-03-02 19:47 ` Geert Uytterhoeven 2023-03-02 19:47 ` Geert Uytterhoeven 2023-03-05 3:32 ` Frank Rowand 2023-03-05 3:32 ` Frank Rowand 2023-03-05 9:26 ` Geert Uytterhoeven 2023-03-05 9:26 ` Geert Uytterhoeven 2023-03-06 5:32 ` Frank Rowand 2023-03-06 5:32 ` Frank Rowand 2023-03-04 15:04 ` Frank Rowand 2023-03-04 15:04 ` Frank Rowand 2023-03-07 21:53 ` Stephen Boyd 2023-03-07 21:53 ` Stephen Boyd 2023-03-04 14:48 ` Frank Rowand 2023-03-04 14:48 ` Frank Rowand 2023-03-02 17:13 ` Rob Herring 2023-03-02 17:13 ` Rob Herring 2023-03-02 19:44 ` Stephen Boyd 2023-03-02 19:44 ` Stephen Boyd 2023-03-02 20:18 ` Rob Herring 2023-03-02 20:18 ` Rob Herring 2023-03-02 23:57 ` Stephen Boyd 2023-03-02 23:57 ` Stephen Boyd 2023-03-04 15:39 ` Frank Rowand 2023-03-04 15:39 ` Frank Rowand 2023-03-06 12:53 ` Rob Herring 2023-03-06 12:53 ` Rob Herring 2023-03-06 15:03 ` Frank Rowand 2023-03-06 15:03 ` Frank Rowand 2023-03-04 15:37 ` Frank Rowand 2023-03-04 15:37 ` Frank Rowand 2023-03-04 15:33 ` Frank Rowand 2023-03-04 15:33 ` Frank Rowand 2023-03-03 14:38 ` Maxime Ripard 2023-03-03 14:38 ` Maxime Ripard 2023-03-07 22:37 ` Stephen Boyd 2023-03-07 22:37 ` Stephen Boyd 2023-03-04 15:50 ` Frank Rowand 2023-03-04 15:50 ` Frank Rowand 2023-03-10 7:48 ` David Gow 2023-03-10 7:48 ` David Gow 2023-03-13 15:30 ` Frank Rowand 2023-03-13 15:30 ` Frank Rowand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAL_JsqJMd3Fi0ZBObdyE1VDKTH1_+smuGDymHnKOkVH2HB3jJQ@mail.gmail.com \ --to=robh+dt@kernel.org \ --cc=ansuelsmth@gmail.com \ --cc=anton.ivanov@cambridgegreys.com \ --cc=brendan.higgins@linux.dev \ --cc=davidgow@google.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=johannes@sipsolutions.net \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=kunit-dev@googlegroups.com \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-um@lists.infradead.org \ --cc=mturquette@baylibre.com \ --cc=patches@lists.linux.dev \ --cc=rafael@kernel.org \ --cc=richard@nod.at \ --cc=sboyd@kernel.org \ --cc=vincent.whitchurch@axis.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.