Hi Geert, On Tue, Dec 24, 2024 at 12:55 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Hi Prabhakar, > > On Mon, Dec 23, 2024 at 6:37 PM Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote: > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > > > Refactor MSTOP handling to switch from group-based to per-bit > > configuration. Introduce atomic counters for each MSTOP bit and update > > enable/disable logic. > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > --- > > v1->v2 > > - New patch > > Thanks for your patch! > > Early review comment: the big missing part in the patch description > is the answer to the "Why?"-question. So please elaborate. > Ahh, I was under the impression patch 1-4 will be squashed into the original patch series so I didn't elaborate it much. If that's not the case I'll update the commit message as below: clk: renesas: rzv2h: Switch MSTOP configuration to per-bit basis Switch MSTOP handling from group-based to per-bit configuration to address issues with shared dependencies between module clocks. In the current group-based configuration, multiple module clocks may rely on a single MSTOP bit. When both clocks are turned ON and one is subsequently turned OFF, the shared MSTOP bit will still be set, which is incorrect since the other dependent module clock remains ON. By switching to a per-bit configuration, we ensure precise control over individual MSTOP bits, preventing such conflicts. Replace the refcount API with atomic operations for managing MSTOP bit counters. The refcount API requires explicitly setting the counter to `1` before calling `refcount_inc()`, which introduces potential edge cases and unnecessary complexity. Using atomic operations simplifies the logic and avoids such issues, resulting in cleaner and more maintainable code. > No need to resend (for now). OK. Cheers, Prabhakar
