Messages in this thread |  | | Date | Wed, 10 Jan 2024 15:40:25 +0000 | | From | Cristian Marussi <> | | Subject | Re: [PATCH V2 2/2] clk: scmi: support state_ctrl_forbidden |
| |
On Thu, Dec 07, 2023 at 05:33:45PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@nxp.com> > > Some clocks may exported to linux, while those clocks are not allowed > to configure by Linux. For example: >
Hi,
> SYS_CLK1----- > \ > --MUX--->MMC1_CLK > / > SYS_CLK2----- > > MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux, > then the clk propagation will touch SYS_CLK1 or SYS_CLK2. > So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable > the clock of MMC1. >
So I was puzzled a bit at first (as said) by the fact that here we silently swallow the failure if the SCMI Clock cannot be disabled, BUT then I spotted in include/linux/clk.h
/** * clk_enable - inform the system when the clock source should be running. * @clk: clock source * * If the clock can not be enabled/disabled, this should return success.
..so I suppose it is fine for the CLK framework at the end.
My next remaining question is why are you not doing the same when (ret == -EACCES && clk->info->state_ctrl_forbidden) for atomic_ops ?
I.e. in:
clk-scmi.c::static int scmi_clk_atomic_enable(struct clk_hw *hw)
Any particular reason (beside not needing it in your particular case...)
Thanks, Cristian
|  |