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 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.

Brian