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

[Maxime Ripard]

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.

Maxime

Attachment: signature.asc
Description: PGP signature