Re: [PATCH v3] clk: spacemit: mark K1 pll1_d8 as critical

[Alex Elder]

On 7/7/25 9:28 AM, Yixun Lan wrote:
> Hi Alex,
>
> On 07:19 Mon 07 Jul     , Alex Elder wrote:
> > On 6/12/25 5:48 PM, Alex Elder wrote:
> > > The pll1_d8 clock is enabled by the boot loader, and is ultimately a
> > > parent for numerous clocks, including those used by APB and AXI buses.
> > > Guodong Xu discovered that this clock got disabled while responding to
> > > getting -EPROBE_DEFER when requesting a reset controller.
> > >
> > > The needed clock (CLK_DMA, along with its parents) had already been
> > > enabled.  To respond to the probe deferral return, the CLK_DMA clock
> > > was disabled, and this led to parent clocks also reducing their enable
> > > count.  When the enable count for pll1_d8 was decremented it became 0,
> > > which caused it to be disabled.  This led to a system hang.
> > >
> > > Marking that clock critical resolves this by preventing it from being
> > > disabled.
> > >
> > > Define a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to
> > > be supplied for a CCU_FACTOR_GATE clock.
> >
> > Is there any reason this bug fix cannot be merged?  It was
> > first posted a month ago, and although there was some initial
> > discussion that led to revisions, this version has been waiting
> > for over three weeks.
> Ok, let me explain..
>
> I've queued it at for-next but haven't sent out the "Applied" reply email,
> it should be eventually merged for version v6.17 if things goes well..
>
> the reason that I haven't pushed it hard for fixes branch is that only DMA
> is affected for now, but DMA isn't fully activated in current mainline
> (No DT, No config merged), so I think it's fine if we target for-next..

OK, thanks for the explanation Yixun.  I've been working in the
networking subsystem for a long time and they tend to push bug
fixes out right away (once reviewed).  But you're right, this
particular bug fix does not affect any currently upstream code.

					-Alex