Re: [PATCH v6 2/7] clk: test: introduce test suite for sibling rate changes on a divider

[Brian Masney]

On Fri, Mar 20, 2026 at 10:29 AM Maxime Ripard <mripard@xxxxxxxxxx> wrote:
> On Fri, Mar 20, 2026 at 09:08:29AM -0400, Brian Masney wrote:
> > On Fri, Mar 20, 2026 at 9:03 AM Maxime Ripard <mripard@xxxxxxxxxx> wrote:
> > > On Thu, Mar 19, 2026 at 07:08:07AM -0400, Brian Masney wrote:
> > > > On Thu, Mar 19, 2026 at 5:10 AM Maxime Ripard <mripard@xxxxxxxxxx> wrote:
> > > > > On Fri, Mar 13, 2026 at 12:43:09PM -0400, Brian Masney wrote:
> > > > > Anyway, what I'm trying to say at least is that, at least, we shouldn't
> > > > > frame it as a guarantee the framework provides, because it's really not
> > > > > the case.
> > > >
> > > > I see what you are saying, however these are divider tests, and this
> > > > is the way that clk-divider works.
> > >
> > > Yes, this is an undocumented behaviour of *clk-divider*. clk-divider is
> > > not the only divider implementation. If anything, it's the reference
> > > implementation, but that's pretty much it.
> > >
> > > So when you say:
> > >
> > > > +/*
> > > > + * Test that, for a parent with two divider-only children with CLK_SET_RATE_PARENT set
> > > > + * and one requests a rate compatible with the existing parent rate, the parent and
> > > > + * sibling rates are not affected.
> > > > + */
> > >
> > > And
> > >
> > > > I want to demonstrate that the clk core is being called, and that
> > > > ultimately the correct dividers are computed.
> > >
> > > This is only true for one implementation, and so far has been considered
> > > an implementation detail. It's not something you can generalize.
> > >
> > > And to make my point clearer, I wasn't saying this test shouldn't be
> > > there, I was saying we shouldn't do and document that generalization.
> > >
> > > > For example, on patch 7 of this series:
> > > >
> > > > - Parent, child1 and child2 all start out at 24 MHz.
> > > > - child1 requests 32 MHz.
> > > > - Parent is changed to 96 MHz, child1 at 32 MHz, child2 stays at 24 MHz.
> > > >
> > > > Child2 keeps the same rate, however the tests show that the clk is
> > > > actually updated since the divider is changed from 1 to 4 after this
> > > > operation. This is to simulate what would be programmed into a
> > > > register for real hardware.
> > > >
> > > > I can drop the expects for the dividers if you really want in the next
> > > > version. Personally, I see value since these are divider-specific
> > > > tests.
> > >
> > > Not really, these tests are clk-divider tests, nothing more.
> >
> > OK, I'll drop the checks for the actual dividers in the next version.
>
> It really wasn't the point I was trying to make. It's fine to have that
> test as a clk-divider test, but we should document it as just that,
> nothing more.

I can move them out of clk_test.c and create a new clk-divider_test.c
file, and make it clear that these are tests against that specific
implementation of clk-divider.c. Would that work? There's already a
clk-fixed-rate_test.c file in tree.

Brian