linux-kernel - RE: [PATCH V2 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:
 <DU0PR04MB941722B7265053B7F703A11B88682@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date: Thu, 11 Jan 2024 00:07:30 +0000
From: Peng Fan <peng.fan@....com>
To: Cristian Marussi <cristian.marussi@....com>, "Peng Fan (OSS)"
	<peng.fan@....nxp.com>
CC: "sudeep.holla@....com" <sudeep.holla@....com>, "mturquette@...libre.com"
	<mturquette@...libre.com>, "sboyd@...nel.org" <sboyd@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Ranjani Vaidyanathan
	<ranjani.vaidyanathan@....com>, Glen G Wienecke <glen.wienecke@....com>,
	Nitin Garg <nitin.garg_3@....com>, Chuck Cannon <chuck.cannon@....com>
Subject: RE: [PATCH V2 2/2] clk: scmi: support state_ctrl_forbidden

> 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@....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...)

No particular reason, we not use atomic_ops in our case. So I am not able
to test it. I could add the same in atomic_ops in V3.

Thanks,
Peng.
> 
> Thanks,
> Cristian