[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230317083951.oaupqybf7llrpmeo@houat>
Date: Fri, 17 Mar 2023 09:39:51 +0100
From: Maxime Ripard <maxime@...no.tech>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Michael Turquette <mturquette@...libre.com>,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
patches@...ts.linux.dev,
Brendan Higgins <brendan.higgins@...ux.dev>,
David Gow <davidgow@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
Christian Marangi <ansuelsmth@...il.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
devicetree@...r.kernel.org, linux-kselftest@...r.kernel.org,
kunit-dev@...glegroups.com
Subject: Re: [PATCH v2 00/11] clk: Add kunit tests for fixed rate and parent
data
Hi,
On Wed, Mar 15, 2023 at 11:37:17AM -0700, 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 device tree overlays onto the live DTB
> along with probing platform drivers to bind to device nodes in the
> overlays. 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 device tree 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.
>
> Changes from v1 (https://lore.kernel.org/r/20230302013822.1808711-1-sboyd@kernel.org):
> * Don't depend on UML, use unittest data approach to attach nodes
> * Introduce overlay loading API for KUnit
> * Move platform_device KUnit code to drivers/base/test
> * Use #define macros for constants shared between unit tests and
> overlays
> * Settle on "test" as a vendor prefix
> * Make KUnit wrappers have "_kunit" postfix
Maybe I'm overthinking this, but wouldn't it make more sense to have a
kunit *prefix* to those functions? Any other function in the kernel
taking a kunit test pointer as a parameter starts with kunit (like
kunit_kzalloc), so it would make more sense to me that kunit-related clk
functions follow the same pattern.
Maxime
Powered by blists - more mailing lists