linux-kernel - Re: [PATCH V4 2/2] clk: scmi: support state_ctrl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZdcaDYqWcF2XWoLE@pluto>
Date: Thu, 22 Feb 2024 09:55:25 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: "Peng Fan (OSS)" <peng.fan@....nxp.com>, mturquette@...libre.com,
	sboyd@...nel.org, linux-arm-kernel@...ts.infradead.org,
	linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peng Fan <peng.fan@....com>
Subject: Re: [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden

On Thu, Feb 22, 2024 at 09:41:53AM +0000, Sudeep Holla wrote:
> On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@....com>
> > 
> > Some clocks may exported to linux, while those clocks are not allowed
> > to configure by Linux. For example:
> > 
> > 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, adding scmi_no_state_ctrl_clk_ops to use software
> > enable counter, while not calling scmi api.
> > 
> > Co-developed-by: Cristian Marussi <cristian.marussi@....com>
> > Signed-off-by: Cristian Marussi <cristian.marussi@....com>
> > Signed-off-by: Peng Fan <peng.fan@....com>
> > ---
> > 
> > V4:
> >  Add scmi_no_state_ctrl_clk_ops per Cristian
> >  Add Cristian's tag
> > 
> > V3:
> >  Add check in atomic enable
> > 
> > V2:
> >  New. Take Cristian's suggestion
> > 
> >  drivers/clk/clk-scmi.c | 15 +++++++++++++--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
> > index 8cbe24789c24..5747b6d651f0 100644
> > --- a/drivers/clk/clk-scmi.c
> > +++ b/drivers/clk/clk-scmi.c
> > @@ -194,6 +194,15 @@ static const struct clk_ops scmi_atomic_clk_ops = {
> >  	.determine_rate = scmi_clk_determine_rate,
> >  };
> >  
> > +static const struct clk_ops scmi_no_state_ctrl_clk_ops = {
> > +	.recalc_rate = scmi_clk_recalc_rate,
> > +	.round_rate = scmi_clk_round_rate,
> > +	.set_rate = scmi_clk_set_rate,
> > +	.set_parent = scmi_clk_set_parent,
> > +	.get_parent = scmi_clk_get_parent,
> > +	.determine_rate = scmi_clk_determine_rate,
> > +};
> > +
> >  static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk,
> >  			     const struct clk_ops *scmi_ops)
> >  {
> > @@ -290,8 +299,10 @@ static int scmi_clocks_probe(struct scmi_device *sdev)
> >  		 * specify (or support) an enable_latency associated with a
> >  		 * clock, we default to use atomic operations mode.
> >  		 */
> > -		if (is_atomic &&
> > -		    sclk->info->enable_latency <= atomic_threshold)
> > +		if (sclk->info->state_ctrl_forbidden)
> > +			scmi_ops = &scmi_no_state_ctrl_clk_ops;
> 
> With this, even if is_atomic and latency matches, we won't allow
> atomic operations ? One reason why it gets tricky and as Cristian 
> mentioned elsewhere we need dynamic assignment of these ops IMO.
> Let me know if I am getting things wrong here ?

It is fine that we wont allow atomic ops either since state_ctrl_forbidden
means the server will reject any enable/disable action, atomic or
not...what I missed here, though, is that we lost also is_enabled indeed,
which could be provided even if state_ctrl_forbidden BUT only if atomic
is supported...so yes this will need an additional atomic/non_atomic
split of this static ops...and so the need for dynamic allocation I was
saying elsewhere....indeed the is_enabled case is handled correctly
again with my pending clk dynamic allocation of ops patch.

My bad, thanks for spotting this Sudeep!
Cristian